Internet of Vehicles resource management method, system, device and medium

Abstract

The invention discloses an Internet of Vehicles resource management method, system and device and a medium. The method comprises the steps of obtaining a first node state of a first node, a second node state of a second node, a base station state of a third node and a request type of a resource request; inputting the first node state, the second node state, the base station state of the third node and the request type into a node determination model to obtain a target node output by the node determination model; predicting a future request of each vehicle in the first node and a future request of each vehicle in the second node according to the first node state and the second node state; according to the resource request, the target node state of the target node, the future request of each vehicle in the first node and the future request of each vehicle in the second node, a management strategy of resources corresponding to the resource request is determined, a cooperative game can be performed by combining the resource state of each node in the Internet of Vehicles, and an optimal unloading node is determined. The request processing efficiency is improved, and then resource allocation is optimized.

Description

Technical Field

[0001] This application relates to the field of vehicle network resource management technology, and in particular to a vehicle network resource management method, system, device and medium. Background Technology

[0002] The rapid development of the Internet of Vehicles (IoV) has spurred various real-time applications such as intelligent navigation and collaborative perception. These applications place stringent demands on computing, caching resources, and network latency. Due to the limited resources of vehicles themselves and the dynamic and ever-changing network environment, traditional centralized cloud computing is insufficient to meet these needs. Mobile edge computing, by offloading resources to edge nodes such as roadside units (RSUs) and collaborating vehicles, has become a key technology supporting real-time IoV services. Vehicle requests are categorized into content requests that do not require computation and service requests that require further computation. Collaborative caching and computation offloading are necessary to optimize system performance.

[0003] However, existing resource management technologies jointly formulate caching and unloading decisions at a single time scale, resulting in huge policy update overhead. Alternatively, a dual time scale separation framework is used to handle low-frequency cache updates and high-frequency unloading decisions separately, which severs the intrinsic connection between time slots, leading to increased system overhead and response latency, making it difficult to adapt to the high-concurrency and dynamically changing application scenarios of the Internet of Vehicles. Summary of the Invention

[0004] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0005] The main objective of this disclosure is to propose a method, system, device, and storage medium for managing vehicle network resources. This method can determine the optimal offloading node by combining the resource status of each node in the vehicle network to perform cooperative game theory, thereby improving request processing efficiency and optimizing resource allocation.

[0006] A first aspect of this application provides a method for managing vehicle network resources, the method comprising: In response to a resource request from a first node, the system acquires the first node status of the first node, the second node status of the second node, the base station status of the third node, and the request type of the resource request. The first node includes the vehicle that initiated the resource request; the second node includes vehicles that did not initiate a resource request and are within a preset communication range; and the third node includes an edge server or cloud server deployed within the preset communication range. The first node status, the second node status, the base station status of the third node, and the request type are input into the node determination model to obtain the target node output by the node determination model. Based on the state of the first node and the state of the second node, predict the future requests of each vehicle in the first node and the future requests of each vehicle in the second node, respectively. Based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node, the management strategy for the resource corresponding to the resource request is determined.

[0007] In some embodiments of this application, the node determination model is constructed based on a cooperative game algorithm and a deep deterministic policy gradient algorithm. The node determination model determines the target node through the following steps: Based on the state of the first node and the state of the second node, calculate the communication transmission rate between the first node and the second node, and based on the state of the first node and the base station state of the third node, calculate the communication transmission rate between the first node and the third node. Based on the state of the first node, the communication transmission rate between the first node and the second node, the communication transmission rate between the first node and the third node, and the request type, the target node of the resource request is determined.

[0008] In some embodiments of this application, the node state includes a node cache state, the base station state includes a base station cache state, and determining the target node of the resource request based on the first node state, the communication transmission rate between the first node and the second node, the communication transmission rate between the first node and the third node, and the request type includes: Based on the request type, and according to the node cache status of the first node, the node cache status of the second node, the base station cache status of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request are calculated respectively. The target node for the resource request is determined based on the time slot in which the first node executes the resource request, the time slot in which the second node executes the resource request, and the time slot in which the third node executes the resource request.

[0009] In some embodiments of this application, the request type includes a content request. The step of calculating the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request based on the request type, according to the node cache state of the first node, the node cache state of the second node, the base station cache state of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, respectively, includes: When the request type is a content request, the time slot for the first node to execute the resource request is determined based on the node cache status of the first node; Based on the node cache status of the second node and the communication transmission rate between the first node and the second node, calculate the time slot for the second node to execute the resource request; The time slot for the third node to execute the resource request is calculated based on the base station cache status of the third node and the communication transmission rate between the first node and the third node.

[0010] In some embodiments of this application, the node state further includes a computation rate, the request type includes a service request, and the step of calculating the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request based on the request type, according to the node cache state of the first node, the node cache state of the second node, the base station cache state of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, respectively, includes: When the request type is a service request, the transmission time slot for the first node to transmit the resource request is determined according to the node cache status of the first node, and the request time slot for the first node to request the resource corresponding to the resource request is calculated according to the data size of the resource request, the complexity of the resource request, and the computing speed of the first node. The time slot for the first node to execute the resource request is calculated based on the transmission time slot of the first node transmitting the resource request and the request time slot of the first node requesting the resource corresponding to the resource request. Based on the node cache status of the second node and the communication transmission rate between the first node and the second node, calculate the transmission time slot for the second node to transmit the resource corresponding to the resource request, and calculate the transmission delay of the second node to transmit the resource request based on the data size of the resource request and the communication transmission rate between the first node and the second node. Based on the data size of the resource request, the complexity of the resource request, and the computing speed of the second node, calculate the request time slot for the resource corresponding to the resource request made by the second node; Based on the transmission time slot of the resource corresponding to the resource request transmitted by the second node, the transmission delay of the resource request transmitted by the second node, and the request time slot of the resource corresponding to the resource request transmitted by the second node, the time slot for the second node to execute the resource request is calculated; Based on the node cache state of the third node and the communication transmission rate between the first node and the third node, the transmission time slot for the third node to transmit the resource corresponding to the resource request is calculated, and the transmission delay for the third node to transmit the resource request is calculated based on the data size of the resource request and the communication transmission rate between the first node and the third node. Based on the base station cache status of the third node and the communication transmission rate between the first node and the third node, calculate the transmission time slot for the third node to request the resource. Based on the transmission time slot of the resource corresponding to the resource request transmitted by the third node, the transmission delay of the resource request transmitted by the third node, and the transmission time slot of the resource request requested by the third node, the time slot for the third node to execute the resource request is calculated.

[0011] In some embodiments of this application, predicting the future requests of each vehicle in the first node and the future requests of each vehicle in the second node based on the state of the first node and the state of the second node, respectively, includes: A request prediction model is constructed using Zipf distribution and Hawkes model; The state of the first node is input into the request prediction model to obtain the future requests of each vehicle in the first node after a preset time interval from the current time, as output by the request prediction model. The state of the second node is input into the request prediction model to obtain the future requests of each vehicle in the second node after a preset time interval from the current time, as output by the request prediction model.

[0012] In some embodiments of this application, determining the management strategy for the resource corresponding to the resource request based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node includes: A resource management model is constructed based on a greedy algorithm; The resource request, the target node status of the target node, the future request of each vehicle in the first node, and the future request of each vehicle in the second node are input into the resource management model to obtain the management strategy output by the resource management model.

[0013] The first aspect of this application provides a vehicle network resource management method. This method involves acquiring the first node status of a first node, the second node status of a second node, the base station status of a third node, and the request type of a resource request; inputting the first node status, the second node status, the base station status of the third node, and the request type into a node determination model to obtain the target node output by the node determination model; predicting the future requests of each vehicle in the first node and the second node based on the first node status and the second node status, respectively; and determining the resource management strategy corresponding to the resource request based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node. This method can determine the optimal offloading node by combining the resource status of each node in the vehicle network for cooperative game theory, thereby improving request processing efficiency and optimizing resource allocation.

[0014] To achieve the above objectives, a second aspect of this application provides a vehicle network resource management system, the system comprising: The acquisition module is used to respond to a resource request from a first node by acquiring the first node status, the second node status, the base station status of a third node, and the request type of the resource request; the first node includes the vehicle that initiated the resource request; the second node includes vehicles that did not initiate a resource request and are within a preset communication range; the third node includes an edge server or cloud server deployed within the preset communication range. The determination module is used to input the state of the first node, the state of the second node, the base station state of the third node, and the request type into the node determination model to obtain the target node output by the node determination model; The prediction module is used to predict the future requests of each vehicle in the first node and the future requests of each vehicle in the second node based on the state of the first node and the state of the second node, respectively. The management module is used to determine the management strategy for the resource corresponding to the resource request based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node.

[0015] To achieve the above objectives, a third aspect of this application provides an electronic device, including: at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, the instructions being executed by the at least one control processor to enable the at least one control processor to perform the above-described vehicle network resource management method.

[0016] To achieve the above objectives, a fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described vehicle network resource management method.

[0017] It is understood that the beneficial effects of the second to fourth aspects compared with the related technologies are the same as the beneficial effects of the first aspect compared with the related technologies. Please refer to the relevant description in the first aspect above, which will not be repeated here. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating a vehicle network resource management method provided in an embodiment of this application; Figure 2 This is a schematic diagram provided in an embodiment of this application; Figure 3 This is another schematic diagram provided in the embodiments of this application; Figure 4 This is yet another schematic diagram provided in the embodiments of this application; Figure 5 This is another schematic diagram provided in the embodiments of this application; Figure 6 This is another schematic diagram provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of a vehicle network resource management system provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0020] In the description of this application, the use of terms such as "first," "second," etc., is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or the order of the technical features indicated.

[0021] In the description of this application, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0022] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0023] With the deep integration of vehicle-to-everything (V2X) and edge computing, the demands of massive heterogeneous in-vehicle applications for real-time and diverse computing and caching resources are becoming increasingly severe. Traditional resource management solutions often ignore the correlation between caching and unloading decisions on a time scale and fail to make full use of the intermediate state after task completion, resulting in high system overhead and high response latency.

[0024] Moreover, existing resource management technologies jointly formulate caching and unloading decisions at a single time scale, resulting in huge policy update overhead. Alternatively, a dual time scale separation framework can be used to handle low-frequency cache updates and high-frequency unloading decisions separately, severing the intrinsic connection between time slots. This leads to increased system overhead and higher response latency, making it difficult to adapt to the high-concurrency and dynamically changing application scenarios of the Internet of Vehicles.

[0025] Based on this, embodiments of this application provide a method, system, electronic device, and medium for managing vehicle network resources, aiming to determine the optimal offloading node by combining the resource status of each node in the vehicle network through cooperative game theory, thereby improving request processing efficiency and optimizing resource allocation.

[0026] The vehicle network resource management method, system, electronic device and medium provided in the embodiments of this application are specifically described through the following embodiments. First, the vehicle network resource management method in the embodiments of this application is described.

[0027] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0028] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0029] The vehicle network resource management method provided in this application relates to the field of vehicle network resource management technology. The vehicle network resource management method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the vehicle network resource management method, but is not limited to the above forms.

[0030] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0031] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0032] Therefore, referring to Figure 1 This application provides a method for managing vehicle network resources. This method is applied to a central controller, which can be a server, an electronic device, or a mobile terminal, etc. There are no specific limitations here. The method includes the following steps S110 to S140.

[0033] Step S110: In response to the resource request from the first node, obtain the first node status of the first node, the second node status of the second node, the base station status of the third node, and the request type of the resource request; the first node includes the vehicle that initiated the resource request; the second node includes vehicles that did not initiate a resource request and are within the preset communication range; the third node includes edge servers or cloud servers deployed within the preset communication range. Step S120: Input the status of the first node, the status of the second node, the base station status of the third node, and the request type into the node determination model to obtain the target node output by the node determination model; Step S130: Based on the state of the first node and the state of the second node, predict the future requests of each vehicle in the first node and the future requests of each vehicle in the second node. Step S140: Based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node, determine the management strategy for the resource corresponding to the resource request.

[0034] In this step, in response to a resource request from the first node, the system obtains the first node status, the second node status, the base station status of the third node, and the request type of the resource request. The first node is the vehicle that initiated the resource request; the second node is a vehicle that did not initiate a request but is within a preset communication range (e.g., an idle vehicle within one hop); and the third node encompasses both edge servers deployed within the preset communication range and remote cloud servers. Together, these three constitute the "cloud-edge-device" three-layer collaborative architecture of the vehicle-to-everything (V2X) network.

[0035] Specifically, the node status of the first and second nodes includes node cache status (whether the requested resources have been cached), computing rate (computing capacity), communication connection status (communication link quality with other nodes), and motion status (current location, driving speed, and trajectory); the base station status of the third node includes base station cache status, computing capacity, and current resource allocation and occupancy; resource requests are divided into two types: one is content requests that do not require additional computation and can be completed by simply calling cached resources (such as map resource calls), and the other is service requests that require calling the cached computing model and inputting data for computation before completion (such as route planning). Different request types correspond to different processing flows and resource requirements.

[0036] Furthermore, the states of the first, second, and third nodes, as well as the base station state and request type, are input into the node determination model to obtain the target node output by the model. The node determination model is constructed based on a cooperative game theory algorithm and a deep deterministic policy gradient algorithm. Its objective is to optimize the overall system efficiency (minimize total system latency), and a powerful edge server acts as a coordinator for centralized negotiation to find the solution. During the solution process, the node determination model first generates a set of feasible candidate nodes for each requesting vehicle (excluding nodes that are unreachable, lack cached resources, or have insufficient computing power). Then, by simulating a multi-node "negotiation" process, it traverses different node allocation combinations, evaluates the total system latency under each combination, and finally selects the optimal solution that balances resource consumption and avoids node overload—the target node.

[0037] Preferably, the target node can be selected from local vehicles of the first node (local processing without transmission), idle vehicles of the second node (utilizing distributed edge resources), edge servers (with strong computing power and abundant cache resources), or cloud servers (suitable for complex tasks with relatively relaxed latency requirements). The specific selection needs to be dynamically determined in combination with the request type, node status, and communication conditions.

[0038] Furthermore, based on a comprehensive analysis of historical system operation data and real-time node status: on the one hand, combining historical resource request patterns and resource popularity (popular resources have a higher probability of repeated requests); on the other hand, focusing on the movement status of the first and second nodes (driving trajectories determine future communication range and reachable nodes) and historical request characteristics (vehicle request preferences are regular), a prediction mechanism combining Hawkes' model and Zip distribution is used to infer the future requests of each vehicle in the first and second nodes within a preset time interval after the current moment. Preferably, the preset time interval is set to a small time scale slot, consistent with the system's task processing frequency, ensuring that the prediction results can directly serve the resource management decisions at the next moment, so that subsequent resource allocation and task retention decisions can not only meet the current request needs, but also adapt to future requests in advance.

[0039] Furthermore, based on the current resource requests (core requirements), the real-time status of the target nodes (remaining cache, computing, and communication resources, which determine the feasibility of the strategy), and the future requests of the first and second nodes (forward-looking adaptation requirements), a management strategy covering computing offloading, resource allocation, and task retention is formed. Specifically, the management strategy includes three core components: First, a computational offloading execution plan, which clarifies the specific processing path of the current resource request (such as the transmission link from the requesting vehicle to the target node, and the calling method of task data and cached resources); second, a dynamic resource allocation plan, which adopts the Deep Deterministic Policy Gradient (DDPG) algorithm to model the resource allocation problem as a Markov decision process for multiple concurrent tasks offloaded to edge servers or cloud servers, dynamically outputting the optimal resource allocation ratio to ensure that task computation latency is minimized, and that the reward function takes into account both current benefits and future impacts; third, a task retention decision, which calculates the benefit (total latency saved by reusing the resource in future requests) and cost (occupied storage space) of each task retention based on a greedy strategy, prioritizing the retention of tasks with the highest unit cost benefit, and retaining resources only in a small timescale slot for reuse by neighboring vehicles in the next moment. Finally, the three strategies are collaboratively optimized through a two-layer iterative approach, dynamically adjusting until the change in the overall system latency is less than a preset threshold, ultimately achieving the optimal overall latency for both the current and future time slots, fully leveraging the efficiency of cross-time slot collaboration and distributed resources.

[0040] In one embodiment, the node determination model determines the target node through the following steps: calculating the communication transmission rate between the first node and the second node based on the state of the first node and the state of the second node, and calculating the communication transmission rate between the first node and the third node based on the state of the first node and the base station state of the third node; and determining the target node of the resource request based on the state of the first node, the communication transmission rate between the first node and the second node, the communication transmission rate between the first node and the third node, and the request type.

[0041] In this embodiment, the node determination model calculates two sets of communication links: one is the vehicle-to-vehicle communication link between the first node (the vehicle initiating the resource request) and the second node (a vehicle within the preset communication range that has not initiated a request); the other is the vehicle-to-infrastructure or cloud communication link between the first node and the third node (an edge server or cloud server). The calculation process must fully consider the state dimensions of both types of nodes: for the vehicle-to-vehicle communication rate, the Euclidean distance is calculated based on the motion states (current position, driving speed) of the two nodes, combined with the channel gain, path loss factor, vehicle transmission power, and average power of Gaussian white noise in the node communication state, and the transmission rate is calculated according to the vehicle-to-vehicle communication model to determine the transmission efficiency of task data between distributed vehicle nodes; for the communication rate between the first node and the third node, the base station state of the third node (communication coverage, channel quality) and the motion state of the first node (whether it is within the base station communication range) are referenced, and the bidirectional transmission rate is calculated according to the vehicle-to-infrastructure or cloud communication model to determine the transmission capacity of task data and cached resources between the requesting vehicle and the edge or cloud server.

[0042] Furthermore, the calculation logic for total latency is first clarified based on the request type of the resource request: For content requests, the total latency only includes resource transmission latency, and it is necessary to determine whether a local call (without transmission latency) is possible based on the cache status of the first node. If a cross-node call is required, the communication transmission rate needs to be calculated to account for the transmission latency. For service requests, the total latency is the sum of transmission latency and computation latency, and it is necessary to additionally consider the computation rate (computing capability) of the candidate nodes and the complexity of the request task to calculate the computation time of the task on different candidate nodes. Moreover, collaborative decision-making is performed based on a cooperative game theory algorithm, treating all vehicles initiating resource requests as game participants, and the candidate nodes (first node, second node, third node) as the strategy space of the participants. The utility function is to minimize the overall total latency of the system, with the edge server acting as a centralized coordinator, traversing all feasible node allocation combinations to avoid resource contention caused by multiple tasks being simultaneously offloaded to the same node. Simultaneously, resource adaptation optimization is performed through a deep deterministic strategy gradient algorithm: when multiple tasks tend to offload to the same third node (edge ​​server or cloud), the optimal resource allocation ratio is dynamically output based on the real-time resource status (remaining computing power) and task characteristics (data volume, complexity) of the third node, adjusting the computation latency of each task, and thus optimizing the utility evaluation results of the cooperative game. Finally, through a two-layer iterative mechanism, the node allocation scheme and resource allocation ratio are continuously adjusted to select the node that meets the communication reachability constraint, cache resource matching constraint, and computation latency not exceeding the request tolerance latency constraint, and maximizes the overall system efficiency. This node is then identified as the target node, ensuring both the processing efficiency of individual tasks and the global balanced utilization of distributed resources.

[0043] In one embodiment, determining the target node for a resource request based on the state of the first node, the communication transmission rate between the first node and the second node, the communication transmission rate between the first node and the third node, and the request type includes: based on the request type, calculating the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request, respectively, according to the node cache state of the first node, the node cache state of the second node, the base station cache state of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node; and determining the target node for the resource request based on the time slots for the first node to execute the resource request, the time slots for the second node to execute the resource request, and the time slots for the third node to execute the resource request.

[0044] In this embodiment, by combining request type and real-time node status, the time taken by different candidate nodes to process the current resource request is quantified, providing a comparable core indicator for target node selection. The entire calculation process is based on real-time node status and communication rate, ensuring that the time slot results can accurately reflect the actual efficiency of each node in processing the current request.

[0045] Specifically, the dimensions of time slot composition are first determined based on the request type: for content requests (no additional calculation required), the time slot only includes resource transmission latency, which depends primarily on cache hit and communication transmission rate; for service requests (requiring computational support), the time slot is the sum of transmission latency and computation latency, requiring consideration of both transmission capacity and node computing resources. For the first node (the vehicle initiating the request), its node cache status is used to determine whether the resource corresponding to the request has been cached: if the cache hits, the time slot for content requests approaches 0 (only local calls are needed), and the time slot for service requests is only the local computation latency (calculated based on the node's remaining computing capacity and task complexity); if the cache misses, the first node needs to obtain resources from external sources to execute the request, and the time slot is calculated based on the transmission latency (content cache) or the transmission latency plus the local computation latency (service cache) according to the corresponding transmission link rate.

[0046] Furthermore, for the second node (an idle vehicle within the preset communication range), first check whether its node cache status matches the requested resource: when the cache hits, the time slot for the content request is the transmission delay between the first and second nodes (derived from the communication transmission rate and the amount of resource data), and the time slot for the service request is the transmission delay plus the computation delay of the second node (combined with the second node's computation resource occupancy status and task complexity); when the cache misses, since the second node has no corresponding resource support, its execution time slot is considered infeasible (or far exceeds the tolerable delay), and the node is excluded as a candidate.

[0047] Furthermore, for the third node (edge ​​server or cloud server), the resource matching situation is determined based on the base station cache status: when the cache is hit, the time slot for content requests is the transmission delay between the first node and the third node, and the time slot for service requests is the transmission delay plus the computation delay of the third node (based on the remaining computing power and task complexity of the third node); when the cache is missed, if it is an edge server, the feasibility of obtaining resources from other nodes can be further evaluated (the time slot is the multi-level transmission delay plus the computation delay), and if it is a cloud server, due to the long transmission distance, the time slot usually includes the long-distance transmission delay plus the computation delay.

[0048] Furthermore, by integrating the collaborative optimization logic of the cooperative game theory algorithm, target nodes that balance the efficiency of individual requests with the overall benefits of the system are selected from the candidate nodes. This ensures the processing efficiency of individual requests and achieves global balanced utilization of distributed resources, making it suitable for the high-concurrency and dynamically changing application scenarios of the Internet of Vehicles. Specifically, the scope of candidate nodes is first defined: only nodes whose time slot results are less than the current resource request tolerance latency (the effective ones among the first, second, and third nodes) are retained, excluding infeasible options that exceed the latency constraints. Then, a centralized negotiation decision is made based on the cooperative game theory algorithm: all first nodes that initiate resource requests at the same time are considered as game participants, and effective candidate nodes are considered as the strategy space of each participant. The utility function is to minimize the overall system latency (rather than minimizing the time slot of an individual request).

[0049] During the decision-making process, the coordinator (edge ​​server) simulates different node allocation combinations. For example, when multiple requests all point to the same third node in their optimal time slots, the resource capacity of that node needs to be assessed. If it accepts all requests simultaneously, it will lead to resource contention and a sharp increase in computation latency. In this case, the allocation strategy needs to be adjusted to allocate some requests to a second node or the local machine of the first node with slightly less optimal time slots but sufficient resources. Resource balance is achieved through "strategy negotiation" among the participants. At the same time, the decision-making process needs to be linked to the resource allocation logic of the deep deterministic strategy gradient algorithm: for multiple concurrent requests to be allocated to the third node (especially the edge server), the algorithm is used in advance to predict the impact of the resource allocation ratio on computation latency. If adjusting the allocation ratio can reduce the overall system time slots, the node selection result can be optimized in reverse.

[0050] Furthermore, the determination of the target node must meet two constraints: first, the time slot in which the node processes the current request does not exceed its tolerable latency, ensuring the service quality of a single request; second, the selection of the node should optimize the overall system latency for all resource requests at the same time, avoiding global inefficiency caused by local optima.

[0051] In one implementation of this embodiment, based on the request type, and according to the node cache status of the first node, the node cache status of the second node, the base station cache status of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request are calculated respectively. This includes: when the request type is a content request, determining the time slot for the first node to execute the resource request based on the node cache status of the first node; calculating the time slot for the second node to execute the resource request based on the node cache status of the second node and the communication transmission rate between the first node and the second node; and calculating the time slot for the third node to execute the resource request based on the base station cache status of the third node and the communication transmission rate between the first node and the third node.

[0052] In this step, the first step is to determine whether the node cache status of the first node has pre-cached the target resource corresponding to the current content request. The target resource of the content request is readily available data that does not require computation (such as map fragments, video resources, etc.), and its cache status is recorded in real time through a system-preset cache management mechanism.

[0053] Specifically, if the cache status shows that the first node has cached the target resource locally, it means that there is no need to transmit the resource through any communication link. The request response can be completed by directly calling the local cache. At this time, the time slot is close to 0 (only including a very short local resource call time, which can be ignored). If the cache status shows that the target resource is not cached, the first node cannot complete the processing of the content request independently. There is no effective execution time slot (or it is regarded as the time slot far exceeds the request tolerance latency). It needs to rely on other nodes to provide resource support. Therefore, the local cache matching result is the core judgment basis to ensure that the steps are simple and fit the processing logic of the content request.

[0054] Furthermore, for vehicles (second nodes) within the preset communication range that have not initiated a request, the time slot calculation for processing content requests is based on the cache availability of the second node and the communication transmission efficiency between the two nodes. This quantifies the time consumption of cross-node resource calls to fully utilize the distributed edge resources of the vehicle network. Specifically, the node cache status of the second node is first determined: the target resource of the content request must be cached on the second node to have a basis for cross-node calls. If the second node has not cached the resource, it means that it cannot directly provide resource support to the first node, and its execution time slot is considered infeasible (or far exceeds the tolerable latency), requiring no further calculation. If the cache status shows resource matching, the time slot is equal to the resource transmission time between the first and second nodes.

[0055] Furthermore, for the time slot calculation of content requests processed by edge servers or cloud servers (third nodes), it is first determined whether the base station cache status of the third node has pre-cached the target content resources. Among them, the edge server, as the core node for resource sinking, will pre-cachize popular content resources on a large time scale, while the cloud server stores massive amounts of full content resources, and its cache status is updated in real time through a centralized cache management system.

[0056] Specifically, if the base station cache status shows that the target resource has been cached, then the timeslot calculation only needs to calculate the communication transmission delay between the first node and the third node: For edge servers, because they are deployed within the preset communication range, the communication transmission rate is less affected by distance and channel interference, and their transmission delay value is relatively low; For cloud servers, even if the cache is hit, due to the long transmission distance and multiple network link layers, the communication transmission rate may be affected by factors such as backbone network bandwidth and routing forwarding, and the transmission delay value is usually higher than that of edge servers.

[0057] Furthermore, if the base station's cache status shows that the target resource is not cached, the edge server needs to obtain the resource from other nodes (such as nearby vehicles or the cloud) before transmitting it to the first node. In this case, the time slot is the transmission delay of the edge server obtaining the resource plus the transmission delay from the edge server to the first node, which will significantly increase the time. The cloud server, on the other hand, needs to directly retrieve the resource from its own storage and transmit it. The time slot is the time spent retrieving from the cloud storage and the long-distance transmission delay, which takes longer overall. It is usually only used as an alternative when none of the edge nodes can provide the resource.

[0058] In one implementation of this embodiment, based on the request type, and according to the node cache state of the first node, the node cache state of the second node, the base station cache state of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request are calculated respectively. This includes: when the request type is a service request, determining the transmission time slot for the first node to transmit the resource request based on the node cache state of the first node, and calculating the request time slot for the resource corresponding to the resource request based on the data size of the resource request, the complexity of the resource request, and the computing speed of the first node; calculating the time slot for the first node to execute the resource request based on the transmission time slot for the resource request and the request time slot for the resource corresponding to the resource request; calculating the transmission time slot for the second node to transmit the resource corresponding to the resource request based on the node cache state of the second node and the communication transmission rate between the first node and the second node, and calculating the time slot for the second node to execute the resource request based on the data size of the resource request, the complexity of the resource request, and the computing speed of the first node; calculating the time slot for the first node to execute the resource request based on the transmission time slot for the resource request and the request time slot for the resource corresponding to the resource request; and calculating the transmission time slot for the second node to transmit the resource corresponding to the resource request based on the node cache state of the second node and the communication transmission rate between the first node and the second node. The transmission latency of the resource request transmitted by the second node is calculated based on the communication transmission rate between the first and third nodes. The request time slot for the resource requested by the second node is calculated based on the data size, complexity, and computation rate of the resource request. The time slot for the second node to execute the resource request is calculated based on the transmission time slot, latency, and request time slot of the resource request. The transmission time slot for the resource request is calculated based on the node cache status of the third node and the communication transmission rate between the first and third nodes. The transmission latency of the resource request is also calculated based on the data size and communication transmission rate between the first and third nodes. The transmission time slot for the resource request is calculated based on the base station cache status and communication transmission rate between the first and third nodes. Finally, the time slot for the third node to execute the resource request is calculated based on the transmission time slot, latency, and transmission time slot of the resource request.

[0059] In this step, when the request type is a service request, the transmission time slot corresponding to the resource requested by the first node is first determined. Specifically, the node cache status of the first node is first determined. If the cache status shows that the computing resource is cached locally, it means that there is no need to transmit the resource across nodes, and only the model needs to be called locally. At this time, the transmission time slot is close to 0 (only including a very short local model call time, which can be ignored). If the cache status shows that the resource is not cached, the first node cannot independently provide the core computing resources required for the service. The time slot for executing the service request locally is considered infeasible (or far exceeds the tolerable latency), and there is no need to further calculate the subsequent time consumption. Then, the request time slot (essentially the local computing time slot) corresponding to the resource requested by the first node is calculated: the service request requires specific data (such as the starting point and ending point coordinates) to complete the calculation. The calculation takes the data size of the resource request (input data volume) and the task complexity (computational intensity) as the core input, combined with the computing speed of the first node (remaining CPU processing capacity), and is determined by the logical calculation that the computing time is positively correlated with the data volume and complexity and negatively correlated with the computing speed. Finally, the transmission time slots and the calculation time slots are added together to obtain the total time slots for the first node to execute the service request. If the transmission time slots are not feasible, the total time slots are directly determined to be infeasible.

[0060] Furthermore, for service requests processed by vehicles (second nodes) within the preset communication range that have not initiated a request, time slot calculation is performed. First, the transmission time slot corresponding to the resource requested by the second node is calculated. Specifically, if the resource is not cached, the second node does not have the core resource to provide the service, and the execution time slot is considered infeasible; if the resource is cached, the transmission time slot is the time consumed by resource invocation and transmission: since the second node and the first node are within the preset communication range, resource transmission is based on the vehicle-to-vehicle communication link. Second, the transmission delay of the resource request by the second node is calculated, that is, the delay of the first node transmitting the input data of the service request (such as the start and end point data of the route planning) to the second node. Its consumption time is calculated by the input data size and the communication transmission rate between the first node and the second node.

[0061] Furthermore, the request time slot for the resource requested by the second node is calculated: based on the size of the data input by the first node and the task complexity of the service request, combined with the computing speed (remaining processing capacity) of the second node. Finally, the resource transmission time slot, the input data transmission latency, and the computing time slot are added together to obtain the total time slot for the second node to execute the service request, ensuring that the entire process of unloading the service request across nodes is covered.

[0062] Furthermore, regarding the time slot calculation for edge servers or cloud servers (third nodes) processing service requests, the transmission time slot corresponding to the resource request transmitted by the third node is first calculated. Before the calculation, the base station cache status of the third node needs to be checked. If the cache is hit, the model transmission time slot is calculated based on the resource data size and the communication transmission rate between the first node and the third node (edge ​​servers have high speed and short time due to their short distance; cloud servers have longer time due to long-distance transmission and the speed is affected by the backbone network). If the cache is not hit, the edge server needs to obtain resources from other nodes (such as nearby vehicles or the cloud). In this case, the resource transmission time slot is calculated based on the cross-node transmission time of the edge server obtaining the model and the transmission time from the edge server to the first node. The cloud server directly retrieves the resources stored in its own storage, and its transmission time slot is obtained based on the model retrieval time and the long-distance transmission time.

[0063] Furthermore, the transmission latency of the resource request transmitted by the third node is calculated based on the input data size and the communication transmission rate between the first and third nodes. Then, the transmission time slot for the resource request by the third node is calculated: if the third node has cached the resource, this time slot represents the extremely short time required for local resource invocation (negligible); if not cached, the resource loading time needs to be added, further increasing the total time slot. Finally, the resource transmission time slot, the input data transmission latency, and the resource invocation or computation preparation time slot are added together to obtain the total time slot for the third node to execute the service request.

[0064] In one embodiment, taking a scenario where multiple vehicles operating within a Vehicular Edge Computing (VEC) architecture initiate different types of requests as an example, a three-layer VEC architecture is constructed, consisting of a cloud server, an edge server, and vehicles within the communication range of a base station associated with the edge server. The cloud server, edge server, and vehicles all have caching capabilities, with the edge server's cache space being significantly larger than the vehicle's cache space.

[0065] Specifically, in this embodiment, the network model is defined as follows: system time is divided into multiple time slots. Caching is performed on a large time scale, and further caching / retention is performed on a small time scale based on the predicted task request situation at the next time moment and the task initiation situation at the current time moment. The impact of task initiation on the next time moment is considered, and retained tasks are only kept for one time slot. In the time slot Making uninstallation decisions, the location of the uninstallation affects retention; task retention considers cost, and the goal is to consider... Time and Minimize both time delay and cost. Among these factors, the number of vehicles... Node set , Indicates base station, Indicates a vehicle. This indicates that cloud servers allow vehicle tasks to be processed locally within the vehicle, at a one-hop vehicle and RSU level. When requesting content and service caching, resources can come from... .

[0066] The system time is divided into multiple time slots. Caching is performed on a large time scale, while on a small time scale, task offloading and retention are performed based on the task caching status of the previous time step, the predicted task request status of the next time step, and the task initiation status of the current time step. The impact of task initiation on the next time step is considered, and retained tasks are kept for only one time slot. In the time slot Making uninstall decisions, the location of the uninstallation will affect retention; the goal is to consider... Time and Minimize dual-timeslot delay at any given time. Node state. ,in, This indicates the cache capacity of each node. To consume resources during major time periods. This represents the computing power of each node. This represents the initial cache state of each node over a large time scale, and is a binary set. The vehicle's cache status at the previous moment was: , , satisfy , Vehicles originate from the initiating node To compute node For the task The retention strategy is as follows: ,when =0 indicates that the task is not retained. =1 indicates that the task is retained.

[0067] Furthermore, each vehicle generates at most one task per time slot, assuming that in time, At each time, there are , The vehicle initiated a mission request. , , The vehicle group that initiates the mission at any time is , time The vehicle request task is: ,predict The vehicle that initiates the task request at any time is: , time The vehicle request task is: The number of task types initiated is Request collection = ,in, , This indicates the size of the input data requested for the task. It's the complexity of the task. =0 indicates that the requested content is cached. , All are 0. =1 indicates a request to the service cache. This indicates the size of the cached data required for the cache request. Indicates the maximum tolerable delay. = ,express vehicle The moment was generated Class of tasks, Indicates the predicted next moment. Car production For this type of task, predictions are made using the Zipf distribution and the Hawkes model.

[0068] ; in, for The prediction at time +1 The vehicle initiated the first The probability of each task. The first setting for the initial zipf distribution The probability of each task. For the first The vehicle initiated the first The time slot of each task, Historical data impact factor.

[0069] Furthermore, in this embodiment, the motion model is defined as follows: vehicle The two-dimensional coordinate information at time is , The Euclidean distance between the time and the collaborating node is , The Euclidean distance between the time and the collaborating node is , ,in, for time Nodes (Horizontal) coordinate, for time Nodes (Vertical) coordinate, for time Nodes coordinate, for time Nodes coordinate, It is the speed of the vehicle when it is traveling at a constant speed. The Euclidean distance between the time and the collaborating node is , ,in, for time Nodes coordinate, for time Nodes coordinate, for time Nodes coordinate, for time Nodes coordinate.

[0070] Furthermore, the communication model in this embodiment is defined as follows: The vehicle's communication range. The communication range of BS refers to the communication range between the vehicle and the base station, where It is the bandwidth for data transmission between vehicles. It is the channel gain for transmission between the vehicle and the base station. It refers to the European distance between vehicles. It is the path loss factor. It is the vehicle's transmission power. It is the average power of Gaussian white noise.

[0071] The vehicle-to-vehicle (V2V) transmission rate is obtained using the following formula: ; in, for time Nodes and Inter-node communication rate For the bandwidth used in vehicle-to-vehicle transmission, It is the channel gain for transmission between the vehicle and the base station. yes Nodes and Euclidean distance between nodes. It is the path loss factor. It is the vehicle's transmission power. It is the average power of Gaussian white noise. The vehicle's communication range. For vehicle assembly, For the first One vehicle, For the first One vehicle.

[0072] The vehicle-to-base station (V2I) transmission rate is obtained using the following formula: Formula for vehicle-to-base station transmission rate: ; in, for time Communication rate between node and BS For the bandwidth used in vehicle-to-vehicle transmission, It is the channel gain for transmission between the vehicle and the base station. yes Nodes and Euclidean distance between nodes. It is the path loss factor. It is the vehicle's transmission power. It is the average power of Gaussian white noise. This refers to the bandwidth used for transmission between the vehicle and the BS.

[0073] Formula for base station to vehicle transmission rate: ; in, for Time BS and Inter-node communication rate For the bandwidth used in vehicle-to-vehicle transmission, It is the channel gain for transmission between the vehicle and the base station. It refers to the European distance between vehicles. It is the path loss factor. It is the vehicle's transmission power. It is the average power of Gaussian white noise. This refers to the bandwidth used for transmission between the vehicle and the BS.

[0074] Furthermore, the transmission model in this embodiment is defined as follows: If the request type is a content request, first determine the local node. This indicates that the corresponding content has already been cached locally. for Time of the first The node is the first The cache check for resources corresponding to each task is performed at this time. ,in for time The latency of a node requesting cached resources; if This indicates that the vehicle does not have locally cached content. The vehicle requests content from nearby vehicles and edge servers. , This represents the nodes within a single hop of the vehicle. ,in for Time of the first The node is the first The cache determination of resources corresponding to each task, and the vehicle decision for the request are as follows: ,at this time ;like This indicates that the vehicle cannot obtain content from nodes within one hop; instead, it can obtain content from the cloud server and other nodes communicating with the edge server. The requested vehicle decision is , This refers to nodes outside the vehicle's communication range, including vehicle nodes and cloud servers within the base station's coverage area. ,at this time: .

[0075] Therefore, node Initiate content tasks at any time The requested transmission delay is: ; in, For nodes Initiate content tasks at any time Requested transmission latency, for Time of the first The node is the first Cache determination for resources corresponding to each task for Time of the first The node is the first Cache determination for resources corresponding to each task For the task The data size of the corresponding resource for time Nodes and Inter-node communication rate for time Node from Node request task Decisions based on corresponding resources, for time Communication rate between node and BS for Time BS and Inter-node communication rate; If the request type is a service request, first calculate the computation latency calculated locally, i.e., if This indicates a request for vehicle local computing services. The latency of calling local vehicle services is consistent with the latency of content requests. The computation time of the task is: ,in For edge nodes The computational speed and total latency are: .

[0076] Furthermore, in the case of calculating the vehicle node at the inner edge of a single hop, i.e. if This indicates that the vehicle is requesting an edge node. Computing service request Calculate vehicle nodes Service call latency , The computation latency of the task is: ,in For edge nodes The computational speed and total latency are: .

[0077] Furthermore, in the case where computation is performed on an edge server, i.e., if This indicates that the vehicle is requesting edge server computing services. Edge server call latency: The computation time of the task is: Total latency: ; Therefore, node Initiate service tasks at any time Requested transmission delay: ; in, for time Node initiates service-type tasks The time delay, for time Node request task Resource access latency for time Node request task Resource access latency for BS request task Resource access latency for time Nodes request tasks from local machines Decisions based on corresponding resources, For vehicle collaborative calculation of unloading decisions, Assigned to BS Vehicle computing resources for time Communication rate between node and BS Assigned to BS The vehicle's computing resources and unloading decision satisfy: ,in for time Node from Node requests resources The decision, For is Nodes and The Euclidean distance between nodes.

[0078] Furthermore, the task retention model in this embodiment is defined as follows: After completing the task, each node deletes the cached content from the previous node. When node To the node Request task After node Consider whether the task should be stored locally: ; Time-based content requests and task calculations are subject to The persistence strategy and task initiation status have an impact, therefore, the node Initiate content tasks at any time The requested transmission delay is: ; in, for time Node initiates content task The time delay, for Time of the first The node is the first Caching check for each task for Time of the first The node is the first Caching check for each task for time Nodes and Inter-node communication rate For the task The data size of the corresponding resource for time Node from Node request task Decisions based on corresponding resources, for time Communication rate between node and BS for Time BS and Communication rate between nodes.

[0079] Furthermore, nodes Initiate service tasks at any time The requested transmission delay is: ; in, for time Node initiates service task The time delay, For local vehicle unloading decisions, for time Node request task Resource access latency for time Node request task Resource access latency for The computing power of a node for time Node from Node request task Decisions based on corresponding resources, for time Nodes perform computational tasks via vehicle BS. The decision to uninstall for time Nodes and Inter-node communication rate for BS request task Resource access latency for time Communication rate between node and BS for Time BS assigned Vehicle computing resources.

[0080] Furthermore, after a vehicle initiates a task request, a time slot can be temporarily reserved. Based on the prediction results, the unloading decision determines the caching decision, and the caching decision is used to determine the unloading decision for the next time slot, with the goal of minimizing latency. Each time slot performs a large cache decision update with two time scales, and each time slot also performs a small cache and multi-user, multi-content offloading decision related to the next time slot. The utility function aims to minimize the overall latency of the dual-time-slot system by solving for the optimal dual-time-slot computation offloading strategy and task retention strategy.

[0081] ; in, for Unload decision-making at any time. for Real-time resource allocation decisions for Real-time task retention decision, for Unload decision-making at any time. for Real-time resource allocation decisions Parameters for determining task type. for time Nodes initiate content-based tasks The time delay, for time Node initiates service-type tasks The time delay, for time Nodes initiate content-based tasks The time delay, for time Node initiates service-type tasks The time delay.

[0082] The objective to be solved includes Real-time calculation of unloading decisions , Time-based resource allocation decision , Real-time task retention decision , Real-time calculation of unloading decisions , Time-based resource allocation decision : ; ; ; ; .

[0083] Furthermore, in the Task Retention and Depth Determination Strategy Gradient Strategy (TRDDPG), a greedy multi-type, multi-node cache placement strategy based on Bellman optimization is introduced to address the cache placement problem on a large timescale. Bellman optimization, based on dynamic programming principles, can provide an optimal solution to the cache placement problem. In large-scale networks, the cache placement problem is typically high-dimensional and complex. Bellman optimization effectively reduces the computational burden by decomposing the complex problem into subproblems. Simultaneously, it leverages the recursive properties of the value function to handle various complex scenarios and constraints. On a small timescale, when a vehicle initiates a request, the system provides services to the vehicle based on the request type. For content request carriers, the system selects the optimal content delivery link based on the caching model to complete the content delivery function. When a vehicle initiates a task request, the Deep Deterministic Policy Gradient (DDPG), a two-layer iterative scheme based on cooperative game theory, is used for selecting computational nodes and allocating server computational resources. The introduction of cooperative game theory enables multiple participants in the system to maximize their interests through cooperation. Based on the offloading decisions, a greedy algorithm is used to achieve task retention. Resource allocation typically involves a continuous action space, which DDPG can effectively handle, making resource allocation more granular and flexible, thus achieving better offloading decisions. Through a two-layer iterative framework, cooperative game theory is first used to determine the offloading decisions of each participant, and then DDPG is applied to allocate computational resources based on these decisions. This hierarchical structure allows each decision level to focus on its own optimization objective while considering the influence of other levels, thereby achieving global optimum.

[0084] The DDPG resource allocation algorithm does not run independently but is embedded in a two-layer iterative optimization framework. Its input is the offloading decision At generated by the cooperative game algorithm, which clarifies which tasks are offloaded to the current RSU, forming a task queue to be allocated resources. Within the inner loop of the two-layer iteration, the DDPG algorithm alternately optimizes with the offloading and retention algorithms. Given the current offloading decision At and retention decision Ct, the DDPG algorithm is invoked as a resource allocator, outputting an optimized resource allocation scheme Ft. This new Ft changes the computational latency of the tasks, thus affecting the utility evaluation of the offloading decision in the cooperative game, potentially leading to different offloading decisions Anewt in the next iteration. Similarly, different offloading results result in different task completion nodes and retention opportunities, influencing the greedy retention algorithm's decision. Its output is the final resource allocation scheme F output by the DDPG algorithm after iteration convergence. F This solution is a locally optimal solution that matches a specific offloading and retention strategy.

[0085] Specifically, experiments were conducted comparing four strategies: Unused Task Retention and Depth Determination Strategy Gradient Strategy (UTRDDPG), Task Retention and Depth Determination Strategy Gradient Strategy (TRDDPG), Task Retention and Unused Resource Allocation Strategy (TRUA), and Unused Task Retention and Unused Resource Allocation Strategy (UTRUA). UTRDDPG performs resource allocation using the DDPG algorithm without task retention; TRDDPG performs task retention and resource allocation using the DDPG algorithm (this is the example used here); TRUA performs task retention without resource allocation; and UTRUA performs neither task retention nor resource allocation. The simulation results and analysis are as follows: Regarding the impact of BS pre-caching ratio on system latency, such as Figure 2The figure shows the trend of total system latency as the number of requesting vehicles increases under different BS pre-caching ratios (rate=1, 0.9, 0.8, 0.7). Overall, as the number of requesting vehicles N increases from 5 to 25, the system latency under all four caching ratios shows an upward trend. A higher pre-caching ratio means that the edge server and collaborating vehicle nodes pre-cachise more currently popular content or services. When a vehicle initiates a request, the probability of hitting the local or neighboring node cache increases significantly, thereby greatly reducing the remote transmission latency (such as from the cloud to the origin) incurred to acquire resources. Especially in high-load scenarios with a large number of vehicle requests (such as N>15), the advantage of a high caching ratio (rate=0.9) is more obvious, and the gap between it and the latency curve gradually widens. However, when the pre-caching ratio is 1, it means that no task retention is performed, and all tasks are pre-cached. The effect is worse than the case with a caching ratio of 0.9, indicating that task retention can further increase system resource utilization by caching important resources currently generated by the system instead of some unimportant resources, thus reducing the latency of system cache resource access.

[0086] Regarding the impact of the number of task requests on system latency, Figure 3 The study demonstrates the trend of total system latency for four algorithms as the number of requesting vehicles (N) increases. Overall, latency increases with load for all algorithms, but the effectiveness of the optimization strategies determines the significant performance differences. The performance ranking is: TRDDPG is best, followed by UTRDPG, then TRUA, and finally UTRUA is worst. This gradient clearly reveals the core contributions of task retention and intelligent resource allocation: TRDDPG benefits from the synergistic optimization of cross-slot cache reuse and DDPG dynamic resource allocation through task retention, achieving dual gains in both time and resource dimensions, thus maintaining the lowest latency. While UTRDPG optimizes computational efficiency within a single time slot through DDPG, its lack of cross-slot task relevance utilization means it cannot avoid redundant resource acquisition overhead, resulting in lower performance. TRUA relies solely on task retention, and its uniform resource allocation strategy becomes a bottleneck when facing heterogeneous tasks, limiting its retention potential. UTRUA, as a baseline solution without any optimization mechanisms, highlights the necessity of introducing a collaborative optimization framework in dynamic vehicular networking environments due to its high latency. The experimental results strongly validate the strategy of integrating task retention and DDPG resource allocation proposed in this study. It can most effectively cope with the challenge of high-concurrency requests and improve the overall system performance through the synergy of spatiotemporal dimensions.

[0087] Regarding the impact of BS computing power on system latency, Figure 4The study demonstrates the changing trend of total latency for the four algorithms as base station computing power increases from 30GHz to 50GHz. Overall, latency decreases for all algorithms with increased computing resources, but the magnitude of the decrease differs significantly from the efficiency. Their performance ranking is consistent with the previous results: TRDDPG is the best, followed by UTRDPG, then TRUA, and LTRUA is the worst. This result reveals the underlying reasons for the performance differences among algorithms under the background of increased computing resource supply: the TRDDPG algorithm, with its cross-slot cache gain built by the task retention mechanism, forms a deep synergy with the DDPG dynamic resource allocation capability, and can most efficiently convert the increased computing resources of the BS into latency reduction, as shown by the steepest curve decline; the UTRDDPG algorithm, although it has no retention gain, can actively optimize resource matching through its DDPG allocation strategy, thus making good use of the enhanced computing power and showing a significant latency reduction; the TRUA algorithm, although it has some latency savings from retention, cannot intelligently schedule the newly added computing resources due to its uniform allocation strategy, resulting in limited performance improvement and a relatively gentle curve decline; while LTRUA, as the baseline without any optimization mechanism, is the least sensitive to the increase in computing power, with only a slight improvement in latency. This experiment further verifies that in real-world scenarios where the computing power of edge servers is variable, the collaborative strategy of integrating task retention and intelligent resource allocation (TRDDPG) proposed in this study can maximize the efficiency of infrastructure investment and achieve optimal system response speed.

[0088] Regarding the impact of BS caching capabilities on system latency, Figure 5The study demonstrates the response of the four algorithm systems to total latency as the base station storage capacity is gradually expanded from 10Gb to 30Gb. Overall, latency decreases with increasing storage capacity, but the magnitude and rate of latency reduction for each algorithm exhibit a tiered characteristic consistent with previous experiments: TRDDPG is the best, followed by UTRDPG, then TRUA, and UTRUA is the worst. This result profoundly reveals the coupling relationship between storage resources and algorithm mechanisms: TRDDPG's curve shows the most significant decline, indicating that its task retention mechanism can directly and efficiently convert the newly added storage space into cross-time slot caching benefits. DDPG resource allocation further ensures the service efficiency of retained tasks, and the synergy between the two maximizes the system's return on investment in storage resources. Although TRUA can utilize additional storage space to retain more tasks, its uniform resource allocation strategy cannot intelligently schedule computing resources to match changing cache distributions, resulting in limited performance improvement and a relatively gentle curve decline. UTRDPG and UTRUA's curves show the weakest decline, especially UTRUA, which is almost flat. This confirms that without a task retention mechanism, simply increasing storage capacity has limited contribution to latency optimization, where computation is the core bottleneck. Notably, when storage capacity increases to approximately 25Gb, the latency decline of all algorithms tends to level off, indicating that system performance gradually transitions from storage constraints to computation or communication constraints, reflecting the dynamic shift of resource bottlenecks. The experimental findings reinforce the core argument of this study: in vehicle-to-everything (V2X) edge computing systems, only by combining dynamic and forward-looking task retention strategies with adaptive intelligent resource allocation can we systematically manage multi-dimensional resources, including storage and computing, and achieve optimal overall performance improvement.

[0089] Regarding the impact of the total number of vehicles on system latency, Figure 6The study demonstrates the trend of total system latency as the number of vehicles within the coverage area increases from 20 to 40. Overall, the latency of all algorithms increases with the expansion of network size, but the rate of increase varies significantly. The performance ranking remains TRDDPG as the best, followed by UTRDPG, then TRUA, and UTRUA as the worst. This result indicates that in dynamic scenarios with network expansion and increased topology complexity, the proposed algorithms' collaborative optimization mechanism exhibits stronger scalability and robustness. Specifically, TRDDPG benefits from its task retention mechanism; the presence of more vehicle nodes in the network effectively expands the potential resource pool for distributed caching and computation, allowing task results to be retained and reused over a wider geographical area. Simultaneously, its DDPG resource allocation strategy adaptively addresses the increased resource competition due to scale expansion, effectively suppressing rapid latency growth, resulting in the most gradual increase in latency. In contrast, UTRDPG lacks cross-node and cross-timeslot retention gains, failing to convert newly added vehicle nodes into caching advantages, making its performance more sensitive to scale growth. While TRUA can utilize more nodes for retention, its uniform resource allocation strategy struggles to coordinate increasingly complex multi-node resource competition as the scale expands, leading to a rapid increase in latency. As a baseline, UTRUA's performance is most negatively impacted by scale expansion, with a sharp rise in latency, highlighting the necessity of adopting collaborative optimization strategies in large-scale vehicular networks. This experiment further demonstrates that the TRDDPG framework proposed in this study, by integrating task retention and intelligent resource allocation, can not only optimize performance under static resource conditions but also continuously and efficiently schedule and utilize distributed, incremental edge resources in the network when the system scales dynamically, thereby ensuring the quality of service under large-scale deployment.

[0090] In some embodiments, step S130 predicts the future requests of each vehicle in the first node and the future requests of each vehicle in the second node based on the state of the first node and the state of the second node, respectively, including the following steps S210 to S230: Step S210: Construct a request prediction model using the Zipf distribution and Hawkes model; Step S220: Input the state of the first node into the request prediction model to obtain the future requests of each vehicle in the first node after a preset time interval from the current time. Step S230: Input the state of the second node into the request prediction model to obtain the future requests of each vehicle in the second node after a preset time interval from the current time.

[0091] In this embodiment, based on the Zipf distribution, historical resource request data is input to determine the popularity weight of each resource type (popular resources are given a higher basic prediction probability); the Hawkes model is used as a dynamic adjustment module, inputting time series data of historical requests to learn the triggering intensity and decay coefficient of request events (such as the change in the triggering probability of the same type of request within a subsequent time t after a certain type of request occurs); the final request prediction model has both statistical popularity distribution adaptation capability and dynamic response to the temporal correlation characteristics of requests. The input dimension of the model is clearly defined as node state (movement state, historical request state, etc.), and the output is the resource request type and probability within a specific time interval in the future.

[0092] Among them, the Zipf distribution focuses on the static popularity of resource requests. By quantifying the request probability weights of different resources, it can avoid ineffective predictions of low-popularity resources. The Hawkes model, on the other hand, focuses on the dynamic temporal correlation of requests. It fits the spatiotemporal continuity of vehicle requests in the Internet of Vehicles (e.g., after a vehicle initiates a route planning request, nearby vehicles may initiate similar requests due to the need to pass through the same road segment within a short period of time). This model can capture the triggering effect and time decay pattern of requests.

[0093] Furthermore, the state of the first node is input into the request prediction model. First, using a Zipf distribution and combining it with the historical request data of the first node, high-frequency resources matching the node's preferences are selected and assigned a basic prediction probability. Then, using a Hawkes model, recent request events of the node (such as a recent highway navigation request) are analyzed to calculate the trigger probability of similar or related resources (such as highway service area location queries), and the basic probability is dynamically adjusted. At the same time, the prediction results are corrected by combining the motion state (such as increasing the prediction weight of scenic area-related services when a vehicle is driving towards a scenic spot). The final output prediction result is the future requests of each vehicle in the first node within a preset time slot after the current moment, including the specific resource request type (content cache request or service cache request) and the probability of occurrence, providing a precise basis for the forward-looking optimization of subsequent resource management strategies.

[0094] Furthermore, the state of the second node is input into the request prediction model. During the prediction process, high-demand resources are filtered based on the historical request data of the second node. The Hawkes model, on the one hand, explores the temporal correlation of the node's own requests (such as the navigation request patterns during past daily commuting hours), and on the other hand, it can indirectly refer to the recent request events of the first node within the same communication range (such as the first node initiating a concentrated congestion query for a certain road segment, which can appropriately increase the prediction probability of similar requests from the second node), reflecting the regional correlation of vehicle network requests. At the same time, the prediction results are corrected by combining the movement state of the second node (such as being in the same direction of travel as the first node, which may indicate the same route planning needs) and cache state (if popular resources are not cached, the probability of obtaining those resources in the future is predicted). Finally, the output shows the request type and probability of each vehicle in the second node within a preset time slot after the current moment. Together with the prediction results of the first node, this constitutes a panoramic view of the system's future requests, ensuring that subsequent resource allocation and task retention decisions can simultaneously adapt to current requests and potential future needs, and fully leverage the efficiency of cross-time slot collaborative optimization.

[0095] In some embodiments, in step S140, the management strategy for the resource corresponding to the resource request is determined based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node, including the following steps S310 to S320: Step S310: Construct a resource management model based on a greedy algorithm; Step S320: Input the resource request, the target node status of the target node, the future request of each vehicle in the first node, and the future request of each vehicle in the second node into the resource management model to obtain the management strategy output by the resource management model.

[0096] In this embodiment, the goal is to minimize the overall system latency in both the current and future time slots, thereby optimizing the full lifecycle management strategy for resource requests. Specifically, during model construction, the decision-making logic of the greedy algorithm is deeply integrated with the key constraints and benefit evaluation dimensions of vehicle network resource management: On the one hand, the core trade-off dimensions of decision-making are clarified, where benefit is defined as the total system latency reduction achieved after the strategy is implemented (including the reduction in latency for current request processing and the latency savings from reusing resources for future requests), and cost is defined as the system resources occupied by the strategy (such as cache space, computing resources, and communication bandwidth); on the other hand, the core rules of greedy selection are set: under limited resource constraints (such as the cache capacity and computing power limit of the target node), the decision scheme with the highest benefit per unit cost is selected first to ensure maximum resource utilization efficiency.

[0097] Furthermore, the model's input dimensions include resource requests, target node status, and future request predictions. The output dimension corresponds to management strategies, including computation offloading execution plans, dynamic allocation plans for computational resources, and retention decisions for task-related resources. System constraints are also embedded (such as cache space not exceeding limits, computation latency not exceeding the request tolerance latency, and communication link availability) to ensure the feasibility and compliance of the model's output strategies. In addition, the model needs to reserve interfaces for collaboration with other algorithms to enable subsequent integration with cooperative game theory algorithms and Deep Deterministic Policy Gradient (DDPG) algorithms, dynamically adjusting decision-making schemes until the overall system latency is optimized.

[0098] Furthermore, the resource requests, the target node status, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node are input into the resource management model. The resource management model first selects the processing path with the lowest current transmission and computation latency and without affecting the reuse of resources for future requests for computation offloading execution schemes. For example, if the target node is an edge server and multiple neighboring vehicles are predicted to initiate similar service requests in the future, then this path is selected as the offloading execution scheme, laying the groundwork for subsequent retention decisions.

[0099] Furthermore, regarding the dynamic allocation scheme for computing resources, if multiple requests are simultaneously offloaded to the target node (such as an edge server), the resource management model dynamically allocates resource ratios based on the principle of "maximizing latency reduction per unit of computing resource investment," combined with task complexity, data size, and future retention value. For example, more computing resources are allocated to tasks with a high probability of future reuse to ensure their rapid completion and retention. Finally, for task retention decisions, the resource management model calculates the unit cost-effectiveness of retaining each task, sorts them from highest to lowest effectiveness, and prioritizes retaining the task with the best unit effectiveness within the constraint of the remaining cache space on the target node, with the retention duration strictly limited to a preset time interval. Ultimately, the resource management model outputs the computing offload path, resource allocation, and retention decisions. This provides a foundation for resource allocation and retention through the computing offload path, ensures efficient processing of current requests through resource allocation, and transforms current processing results into future resources through retention decisions, achieving overall latency optimization for current and future time slots and fully leveraging the core value of cross-time slot collaborative optimization.

[0100] like Figure 7 As shown in some embodiments of this application, a vehicle network resource management system is provided. The system includes an acquisition module 710, a determination module 720, a prediction module 730, and a management module 740. Specifically: The acquisition module 710 is used to respond to the resource request of the first node, acquire the first node status of the first node, the second node status of the second node, the base station status of the third node, and the request type of the resource request; the first node includes the vehicle that initiated the resource request; the second node includes the vehicle that did not initiate the resource request and is within the preset communication range; the third node includes the edge server or cloud server deployed within the preset communication range. The determination module 720 is used to input the status of the first node, the status of the second node, the base station status of the third node, and the request type into the node determination model to obtain the target node output by the node determination model. The prediction module 730 is used to predict the future requests of each vehicle in the first node and the future requests of each vehicle in the second node based on the state of the first node and the state of the second node, respectively. The management module 740 is used to determine the management strategy for the resource corresponding to the resource request based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node.

[0101] It should be noted that the vehicle network resource management system provided in this embodiment is based on the same inventive concept as the above-described vehicle network resource management method. Therefore, the relevant content of the above-described vehicle network resource management method is also applicable to the content of the vehicle network resource management system, and will not be repeated here.

[0102] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described vehicle network resource management method.

[0103] like Figure 8 , Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device includes: At least one battery; At least one memory; At least one processor; At least one program; The program is stored in memory, and the processor executes at least one program to implement the above-described vehicle network resource management method of this disclosure.

[0104] This electronic device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), and in-vehicle computers.

[0105] The electronic devices according to embodiments of this application will now be described in detail.

[0106] The processor 1600 can be implemented using a general-purpose central processing unit (CPU), 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 disclosure. The memory 1700 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1700 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1700 and is called and executed by the processor 1600 to implement a vehicle network resource management method according to an embodiment of this disclosure.

[0107] The input / output interface 1800 is used to implement information input and output. The communication interface 1900 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 2000 transmits information between various components of the device (e.g., processor 1600, memory 1700, input / output interface 1800, and communication interface 1900); The processor 1600, memory 1700, input / output interface 1800 and communication interface 1900 are connected to each other within the device via bus 2000.

[0108] This disclosure also provides a storage medium, which is a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described vehicle network resource management method.

[0109] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0110] The embodiments described in this disclosure are for the purpose of more clearly illustrating the technical solutions of this disclosure and do not constitute a limitation on the technical solutions provided by this disclosure. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by this disclosure are also applicable to similar technical problems.

[0111] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this disclosure, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0112] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0114] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any related variations, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0115] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0119] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

[0121] The embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of this application.

Claims

1. A method for managing vehicle network resources, characterized in that, The method includes: In response to a resource request from a first node, the system acquires the first node status of the first node, the second node status of the second node, the base station status of the third node, and the request type of the resource request. The first node includes the vehicle that initiated the resource request; the second node includes vehicles that did not initiate a resource request and are within a preset communication range; and the third node includes an edge server or cloud server deployed within the preset communication range. The first node status, the second node status, the base station status of the third node, and the request type are input into the node determination model to obtain the target node output by the node determination model. Based on the state of the first node and the state of the second node, predict the future requests of each vehicle in the first node and the future requests of each vehicle in the second node, respectively. Based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node, the management strategy for the resource corresponding to the resource request is determined.

2. The vehicle network resource management method according to claim 1, characterized in that, The node determination model is constructed based on a cooperative game theory algorithm and a deep deterministic policy gradient algorithm. The target node is determined by the node determination model through the following steps: Based on the state of the first node and the state of the second node, calculate the communication transmission rate between the first node and the second node, and based on the state of the first node and the base station state of the third node, calculate the communication transmission rate between the first node and the third node. Based on the state of the first node, the communication transmission rate between the first node and the second node, the communication transmission rate between the first node and the third node, and the request type, the target node of the resource request is determined.

3. The vehicle network resource management method according to claim 2, characterized in that, The node status includes node cache status, the base station status includes base station cache status, and determining the target node of the resource request based on the first node status, the communication transmission rate between the first node and the second node, the communication transmission rate between the first node and the third node, and the request type includes: Based on the request type, and according to the node cache status of the first node, the node cache status of the second node, the base station cache status of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request are calculated respectively. The target node for the resource request is determined based on the time slot in which the first node executes the resource request, the time slot in which the second node executes the resource request, and the time slot in which the third node executes the resource request.

4. The vehicle network resource management method according to claim 3, characterized in that, The request type includes a content request. Based on the request type, and according to the node cache status of the first node, the node cache status of the second node, the base station cache status of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, respectively, the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request are calculated, including: When the request type is a content request, the time slot for the first node to execute the resource request is determined based on the node cache status of the first node; Based on the node cache status of the second node and the communication transmission rate between the first node and the second node, calculate the time slot for the second node to execute the resource request; The time slot for the third node to execute the resource request is calculated based on the base station cache status of the third node and the communication transmission rate between the first node and the third node.

5. The vehicle network resource management method according to claim 3, characterized in that, The node status also includes computing rate, the request type includes service request, and the calculation of the time slot for the first node to execute the resource request, the time slot for the second node to execute the resource request, and the time slot for the third node to execute the resource request based on the request type, according to the node cache status of the first node, the node cache status of the second node, the base station cache status of the third node, the communication transmission rate between the first node and the second node, and the communication transmission rate between the first node and the third node, respectively, includes: When the request type is a service request, the transmission time slot for the first node to transmit the resource request is determined according to the node cache status of the first node, and the request time slot for the first node to request the resource corresponding to the resource request is calculated according to the data size of the resource request, the complexity of the resource request, and the computing speed of the first node. The time slot for the first node to execute the resource request is calculated based on the transmission time slot of the first node transmitting the resource request and the request time slot of the first node requesting the resource corresponding to the resource request. Based on the node cache status of the second node and the communication transmission rate between the first node and the second node, calculate the transmission time slot for the second node to transmit the resource corresponding to the resource request, and calculate the transmission delay of the second node to transmit the resource request based on the data size of the resource request and the communication transmission rate between the first node and the second node. Based on the data size of the resource request, the complexity of the resource request, and the computing speed of the second node, calculate the request time slot for the resource corresponding to the resource request made by the second node; Based on the transmission time slot of the resource corresponding to the resource request transmitted by the second node, the transmission delay of the resource request transmitted by the second node, and the request time slot of the resource corresponding to the resource request transmitted by the second node, the time slot for the second node to execute the resource request is calculated; Based on the node cache state of the third node and the communication transmission rate between the first node and the third node, the transmission time slot for the third node to transmit the resource corresponding to the resource request is calculated, and the transmission delay for the third node to transmit the resource request is calculated based on the data size of the resource request and the communication transmission rate between the first node and the third node. Based on the base station cache status of the third node and the communication transmission rate between the first node and the third node, calculate the transmission time slot for the third node to request the resource. Based on the transmission time slot of the resource corresponding to the resource request transmitted by the third node, the transmission delay of the resource request transmitted by the third node, and the transmission time slot of the resource request requested by the third node, the time slot for the third node to execute the resource request is calculated.

6. The vehicle network resource management method according to claim 1, characterized in that, The step of predicting the future requests of each vehicle in the first node and the future requests of each vehicle in the second node based on the states of the first node and the second node, respectively, includes: A request prediction model is constructed using Zipf distribution and Hawkes model; The state of the first node is input into the request prediction model to obtain the future requests of each vehicle in the first node after a preset time interval from the current time, as output by the request prediction model. The state of the second node is input into the request prediction model to obtain the future requests of each vehicle in the second node after a preset time interval from the current time, as output by the request prediction model.

7. The vehicle network resource management method according to claim 1, characterized in that, The step of determining the management strategy for the resource corresponding to the resource request based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node includes: A resource management model is constructed based on a greedy algorithm; The resource request, the target node status of the target node, the future request of each vehicle in the first node, and the future request of each vehicle in the second node are input into the resource management model to obtain the management strategy output by the resource management model.

8. A vehicle network resource management system, characterized in that, The system includes: The acquisition module is used to respond to a resource request from a first node by acquiring the first node status, the second node status, the base station status of a third node, and the request type of the resource request; the first node includes the vehicle that initiated the resource request; the second node includes vehicles that did not initiate a resource request and are within a preset communication range; the third node includes an edge server or cloud server deployed within the preset communication range. The determination module is used to input the state of the first node, the state of the second node, the base station state of the third node, and the request type into the node determination model to obtain the target node output by the node determination model; The prediction module is used to predict the future requests of each vehicle in the first node and the future requests of each vehicle in the second node based on the state of the first node and the state of the second node, respectively. The management module is used to determine the management strategy for the resource corresponding to the resource request based on the resource request, the target node status of the target node, the future requests of each vehicle in the first node, and the future requests of each vehicle in the second node.

9. An electronic device, characterized in that, It includes at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, which, when executed by the at least one control processor, enable the at least one control processor to perform a vehicle network resource management method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which are used to cause a computer to perform the vehicle network resource management method according to any one of claims 1 to 7.

Images