A request unloading system and roadside unit sleep method in vehicle networking

Abstract

The present application discloses a request unloading system and a roadside unit sleep method in a vehicle network, including: obtaining the device information of multiple service nodes at the current moment, the multiple service nodes include a collaborative node and at least one roadside unit connected to the collaborative node; according to the device information, determining the current state of the vehicle network and multiple candidate actions corresponding to the current state; inputting the current state and multiple candidate actions into the current Q network to obtain the first Q value corresponding to each candidate action, wherein the current Q network is iteratively updated based on the reward value, and the reward value at the same moment is inversely proportional to the total energy consumption of the vehicle network; according to the first Q value, determining the target action from the candidate actions, and controlling the sleep of each roadside unit based on the target action. Combined with the request unloading system architecture of the vehicle network, the total energy consumption is reduced as much as possible without affecting the vehicle request unloading.

Description

Technical Field

[0001] The present application belongs to the field of communication technology, and specifically relates to a request unloading system and a roadside unit sleep method in a vehicle network. Background Art

[0002] The Internet of Vehicle (IoV) is supported by the ubiquitous sensing capabilities of the Internet of Things (IoT). It can connect vehicles to the Internet, quickly exchange vehicle information through the network, provide efficient and low-latency transportation services, and improve vehicle transportation efficiency and safety.

[0003] In the existing technology, the cloud-edge collaborative architecture can be applied to IoV. By deploying a large number of road site units (RSU) as edge base stations, vehicle requests can be processed faster. At the same time, combined with the powerful computing and storage capabilities of the cloud, the latency of vehicle requests can be effectively reduced and the user experience can be improved.

[0004] However, the large-scale deployment of RSUs will result in huge energy consumption overhead. Moreover, in actual application scenarios, there are not a large number of vehicle requests in every period, and the vehicle request density in different areas is also different, resulting in the performance of each RSU cannot be fully utilized. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a request unloading system and a roadside unit sleep method, device, equipment and storage medium in a vehicle network, which can solve the problem that the current large-scale deployment of RSUs will lead to huge energy consumption overhead and the performance of each RSU cannot be fully utilized.

[0006] In a first aspect, an embodiment of the present application provides a request unloading system in a vehicle network, including a vehicle and a service node, wherein the service node includes a coordination node and at least one roadside unit connected to the coordination node, wherein:

[0007] The vehicle is used to send a connection request to the roadside unit;

[0008] The roadside unit is configured to establish a connection with the vehicle in response to the connection request when the roadside unit is not in a dormant state;

[0009] The vehicle is further configured to, when the connection with the roadside unit is successful, unload the vehicle request to the roadside unit; and when the connection with the roadside unit fails, unload the vehicle request to the coordination node.

[0010] Optionally, the coordination node includes a cloud and at least one base station connected to the cloud, and each base station is connected to at least one of the roadside units;

[0011] The vehicle is specifically used to offload the vehicle request to the base station to which the vehicle is connected when the connection with the roadside unit fails, so that the base station and the cloud can collaboratively process the vehicle request.

[0012] In a second aspect, an embodiment of the present application provides a roadside unit sleep method, including:

[0013] Acquire device information of multiple service nodes at a current moment, wherein the multiple service nodes include a coordination node and at least one roadside unit connected to the coordination node;

[0014] Determine, according to the device information, a current state of the connected vehicle network and a plurality of candidate actions corresponding to the current state, each candidate action being used to indicate whether each roadside unit enters sleep at a next moment;

[0015] Inputting the current state and the multiple candidate actions into the current Q network to obtain a first Q value corresponding to each candidate action, wherein the current Q network is iteratively updated based on the reward value, and the reward value at the same time is inversely proportional to the total energy consumption of the Internet of Vehicles;

[0016] According to the first Q value, a target action is determined from the candidate actions, and sleep control is performed on each roadside unit based on the target action.

[0017] Optionally, before inputting the current state and the multiple candidate actions into the current Q network to obtain a first Q value corresponding to each candidate action, the method further includes:

[0018] Determining the total energy consumption of the Internet of Vehicles based on the device information;

[0019] Inputting the current state and the multiple candidate actions into the target Q network to obtain a second Q value corresponding to each candidate action;

[0020] Determine the reward value based on the total energy consumption, and calculate the target Q value according to the maximum value of the second Q value and the reward value;

[0021] A loss value between the target Q value and a first Q value corresponding to a target action at a previous moment is determined, and the current Q network and the target Q network are updated based on the loss value.

[0022] Optionally, determining the total energy consumption of the Internet of Vehicles according to the device information includes:

[0023] Determining static energy consumption, processing energy consumption, and transmission energy consumption of the plurality of service nodes according to the device information;

[0024] The static energy consumption, the processing energy consumption, and the transmission energy consumption are added together to obtain the total energy consumption.

[0025] Optionally, the device information includes static power, and determining the static energy consumption of the multiple service nodes according to the device information includes:

[0026] The static energy consumption of the multiple service nodes is determined according to the static power of the roadside unit that has not entered sleep mode.

[0027] Optionally, the device information includes a task arrival rate, a number of nodes, a service rate, and a task processing power, and determining the processing energy consumption of the plurality of service nodes according to the device information includes:

[0028] Based on the task arrival rate, the number of nodes and the service rate, calculating the resource utilization rate of the service node and the probability distribution of the corresponding queue number of vehicle requests;

[0029] Calculating the average queuing delay of the service node according to the resource utilization and the probability distribution of the queue quantity;

[0030] Calculating the task processing delay of the service node according to the average queuing delay and the service rate;

[0031] The node energy consumption of each service node is calculated according to the task processing delay and the task processing power, and the node energy consumptions are summed to determine the processing energy consumption of the multiple service nodes.

[0032] Optionally, the coordination node includes a cloud and at least one base station connected to the cloud. Before calculating the resource utilization rate of the service node and the corresponding probability distribution of the number of queues of vehicle requests based on the task arrival rate, the number of nodes and the service rate, the following steps are included:

[0033] Sum the task arrival rates corresponding to the cloud and the base station as the task arrival rate of the collaborative node;

[0034] Sum the number of nodes corresponding to the cloud and the base station as the number of nodes of the collaborative node;

[0035] The service rates corresponding to the cloud and the base station are summed up to serve as the service rate of the collaborative node.

[0036] Optionally, the device information includes data transmission power, a first average data volume and an uplink bandwidth requested by the vehicle, and a second average data volume and a downlink bandwidth of a return result corresponding to the vehicle request. Determining the transmission energy consumption of the multiple service nodes according to the device information includes:

[0037] Calculate the transmission delay of each service node according to the first average data amount, the second average data amount, the uplink bandwidth, and the downlink bandwidth;

[0038] The transmission energy consumption of the multiple service nodes is determined according to the transmission delay and the data transmission power.

[0039] Optionally, the device information includes a task arrival rate, a node number, and a service rate, and determining the current state of the Internet of Vehicles according to the device information includes:

[0040] Calculating an average value of the task arrival rate of each roadside unit within a preset time period before the current moment;

[0041] The average value, the number of nodes of each service node at the current moment, and the service rate of each service node at the current moment are taken as a set to obtain the current state of the Internet of Vehicles.

[0042] In a third aspect, an embodiment of the present application provides a roadside unit sleep device, the device comprising:

[0043] An acquisition module, used to acquire device information of multiple service nodes at a current moment, wherein the multiple service nodes include a coordination node and at least one roadside unit connected to the coordination node;

[0044] A determination module, used to determine the current state of the vehicle network and a plurality of candidate actions corresponding to the current state according to the device information, each candidate action being used to indicate whether each roadside unit enters sleep at the next moment;

[0045] A calculation module, configured to input the current state and the plurality of candidate actions into a current Q network to obtain a first Q value corresponding to each candidate action, wherein the current Q network is iteratively updated based on a reward value, and the reward value at the same time is inversely proportional to the total energy consumption of the Internet of Vehicles;

[0046] A control module is used to determine a target action from the candidate actions according to the first Q value, and perform sleep control on each roadside unit based on the target action.

[0047] In a fourth aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the steps of the method described in the second aspect are implemented.

[0048] In a fifth aspect, an embodiment of the present application provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the second aspect are implemented.

[0049] In a sixth aspect, an embodiment of the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method described in the second aspect.

[0050] In a seventh aspect, an embodiment of the present application provides a computer program product, which is stored in a storage medium and is executed by at least one processor to implement the method described in the second aspect.

[0051] As can be seen from the above, in this application, based on the reward value that is inversely proportional to the total energy consumption of the Internet of Vehicles, the current Q network is trained so that the first Q value output by the current Q network is related to the total energy consumption. Then, the current Q network performs reinforcement learning on the current state of the Internet of Vehicles at the current moment and the corresponding multiple candidate actions, calculates the first Q value of each candidate action, and determines the target action through the first Q value, so that the target action can achieve the effect of reducing the total energy consumption as much as possible. In this way, the intelligent sleep algorithm for the roadside unit can be realized, the sleep state of each roadside unit can be dynamically controlled, and the total energy consumption can be reduced as much as possible in combination with the request unloading system architecture of the Internet of Vehicles without affecting the vehicle request unloading. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 is a network architecture diagram of a request offloading system in a connected vehicle network according to an exemplary embodiment;

[0053] Figure 2 is a flow chart showing a method for dormancy of a roadside unit in a connected vehicle network according to an exemplary embodiment;

[0054] Figure 3 is an algorithm flow chart of a dual deep Q network according to an exemplary embodiment;

[0055] Figure 4 is a block diagram of a roadside unit sleep device according to an exemplary embodiment;

[0056] Figure 5 is a block diagram of an electronic device according to an exemplary embodiment;

[0057] Figure 6 The figure is a schematic diagram showing the hardware structure of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of this application.

[0059] The terms "first", "second", etc. in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0060] In conjunction with the accompanying drawings, a request unloading system and a roadside unit sleep method in a connected vehicle network provided by an embodiment of the present application are described in detail through specific embodiments and their application scenarios.

[0061] Applying the cloud-edge collaborative architecture to IoV and deploying a large number of road site units (RSU) as edge base stations can enable vehicle requests to be processed faster. At the same time, combined with the powerful computing and storage capabilities of the cloud, the latency of vehicle requests can be effectively reduced.

[0062] However, the large-scale deployment of RSUs will result in huge energy consumption overhead. Moreover, in actual application scenarios, there are not a large number of vehicle requests in every period, and the vehicle request density in different areas is also different, resulting in the performance of each RSU cannot be fully utilized.

[0063] Based on this, some roadside units can be temporarily put into sleep mode, and some vehicle requests can be offloaded to other RSUs or base stations for service. However, the overall network architecture does not fully consider the offloading solution for vehicle requests after RSU sleep mode. This may result in vehicle requests not being responded to in a timely manner after RSU sleep mode, or the number of requests offloaded to other RSUs being too large, resulting in network congestion and performance degradation.

[0064] Based on this, this application proposes a request unloading system and a roadside unit sleep method, which fully considers factors such as the unloading scheme of vehicle requests, the queuing process of vehicle requests, the data transmission energy consumption, and the continuity of sleep selection, and constructs a more accurate and comprehensive energy consumption model and optimization algorithm, so as to find a more efficient and energy-saving RSU sleep strategy.

[0065] The present application proposes a request unloading system in a vehicle network, including a vehicle and a service node, wherein the service node includes a coordination node and at least one roadside unit connected to the coordination node, wherein:

[0066] The vehicle is used to send a connection request to the roadside unit;

[0067] a roadside unit, configured to establish a connection with the vehicle in response to a connection request when not in a dormant state;

[0068] The vehicle is also used to unload the vehicle request to the roadside unit when the connection with the roadside unit is successful; and to unload the vehicle request to the coordination node when the connection with the roadside unit fails.

[0069] The request offloading system mainly consists of two parts: vehicles and service nodes. The service nodes are further divided into coordination nodes and at least one roadside unit connected to the coordination node. As the user end of the system, the vehicle is responsible for sending connection requests to the roadside unit. As the infrastructure in the Internet of Vehicles, the roadside unit is responsible for responding to the vehicle's connection request and establishing a connection with the vehicle when it is not in a dormant state. Once the connection is established, the roadside unit can receive and process vehicle requests from the vehicle.

[0070] When the vehicle successfully establishes a connection with the roadside unit, the vehicle will offload the vehicle request to the roadside unit for processing, and return the processing result to the vehicle. If the vehicle fails to connect with the roadside unit, the vehicle will offload the vehicle request to the coordination node for processing.

[0071] In this way, after some RSUs go into sleep mode, vehicle requests will be offloaded to other connected RSUs or collaborative nodes for processing, which can save energy to a great extent without affecting the reliability of the system.

[0072] In one implementation, the coordination node includes a cloud and at least one base station connected to the cloud, and each base station is connected to at least one roadside unit;

[0073] The vehicle is specifically used to offload the vehicle request to the base station to which the vehicle is connected when the connection with the roadside unit fails, so that the base station and the cloud can jointly process the vehicle request.

[0074] That is to say, the collaborative node is usually composed of a cloud server and a base station, which are connected by a high-speed network and can collaboratively process vehicle requests from multiple vehicles. Since the collaborative node has stronger computing power and larger storage space, it can handle more complex and larger vehicle requests.

[0075] In the present application, the connection between the vehicle and the roadside unit, the connection between the roadside unit and the base station, and the connection between the base station and the cloud can be a direct connection or through an intermediate node such as a router or a switch, without specific limitation.

[0076] Figure 1 This is a network architecture diagram of a request offloading system in a connected vehicle network according to an exemplary embodiment. The architecture is implemented based on cloud-edge collaboration, and includes members such as the cloud, BS (Base Station), RSU, and vehicles.

[0077] In order from top to bottom, the top layer is the cloud, which contains one or more cloud servers; the middle layer is the BS, and the number of BSs directly connected to the cloud is N. B , the set is N B , the layer closest to the vehicle is RSU, and each BS is directly connected to a certain number of RSUs, for example, the i-th BS (denoted as BS i ) The number of directly connected RSUs is N i,R , the set is N i,R Each RSU and BS has the ability to cache and calculate. RSU is closer to the vehicle than BS, has more number and smaller computing and storage capacity than BS.

[0078] Among them, the cloud, BS and RSU are all service nodes that provide computing offloading services for vehicles. When vehicle requests arrive at these nodes, they obey the queuing model and the service nodes process the vehicle requests in sequence.

[0079] When seeking an unloading node, the vehicle first connects to the surrounding RSUs. If there is no RSU that can be connected, the vehicle request is unloaded to the BS for processing. In order to achieve load balancing and maximize resource utilization, each BS and the cloud can share computing resources and collaboratively process vehicle requests.

[0080] In this way, some RSUs can be put into sleep mode during periods of low workload, which greatly saves energy. Moreover, after the RSU goes into sleep mode, vehicle requests will be offloaded to other connected RSUs or BSs for processing, which will not cause abnormal processing of vehicle requests.

[0081] In order to better realize vehicle request unloading, it is necessary to intelligently control the sleep of RSU so that the computing resources of the non-sleeping RSU are sufficient to process the current vehicle request. Based on this, the present application also proposes a roadside unit sleep method to solve the above problem.

[0082] Figure 2 The present invention is a flowchart of a roadside unit sleep method in a connected vehicle network according to an exemplary embodiment. The roadside unit sleep method includes the following steps.

[0083] In step S11, device information of multiple service nodes at the current moment is obtained, where the multiple service nodes include a cooperative node and at least one roadside unit connected to the cooperative node.

[0084] In the Internet of Vehicles, service nodes play a vital role. They are responsible for receiving, processing and forwarding information from vehicles or other devices to ensure the smooth operation of the traffic system.

[0085] The service node includes a collaborative node and at least one roadside unit connected to the collaborative node. Collaborative nodes usually refer to those nodes that can share resources or information with other nodes. They have powerful computing power and storage resources. Roadside units are usually deployed near the road, responsible for receiving information from vehicles, and have some basic computing capabilities.

[0086] The first device information may include but is not limited to device status, resource usage, network connection status, software version, security configuration and other information, which is not limited in this application.

[0087] In step S12, the current state of the Internet of Vehicles and a plurality of candidate actions corresponding to the current state are determined according to the device information, and each candidate action is used to indicate whether each roadside unit enters sleep at the next moment.

[0088] According to the collected first device information, the current state of the Internet of Vehicles can be determined, and a strategy for each roadside unit (RSU) to enter sleep mode at the next moment can be planned accordingly. The current state is a result of a combination of multiple factors, such as the overall load of the Internet of Vehicles, network conditions, and equipment health conditions.

[0089] In one implementation, the device information includes a task arrival rate, a number of nodes, and a service rate. According to the device information, the current state of the Internet of Vehicles is determined, including:

[0090] Calculate the average of the task arrival rate of each roadside unit within a preset time period before the current moment;

[0091] The average value, the number of nodes of each service node at the current moment, and the service rate of each service node at the current moment are taken as a set to obtain the current state of the Internet of Vehicles.

[0092] For example, the state at the current time t can be defined as s t , expressed as:

[0093]

[0094] in, represents the set of average task arrival rates of all RSUs at time t, Indicates BS i The average task arrival rate set of connected RSUs, A t It represents the target action executed at the current time t, that is, the sleep selection of each RSU at the current time.

[0095] Indicates BS i The average task arrival rate of the jth RSU is expressed as:

[0096]

[0097] in, Indicates BS i The task arrival rate of the next j-th RSU at time τ, T0 is an integer greater than zero, indicating the number of time slots included in the preset duration; μ R,t , k R,t , μ B,t and k B,t They represent the service rate and number of nodes of RSU and the service rate and number of nodes of BS respectively. They are all vector groups and their expressions are the same as resemblance.

[0098] After determining the current state, it is necessary to determine whether the roadside unit will enter sleep mode at the next moment. For example, the candidate action can be represented by the following matrix A, where a i,j Indicates BS i The sleep selection of the jth RSU, 1 means on, 0 means sleep.

[0099]

[0100] If a roadside unit is unlikely to receive a large number of vehicle requests in the future, it can be considered to enter a dormant state to save energy and reduce maintenance costs. If a roadside unit is expected to receive a large number of vehicle requests in the future, it should be kept active to ensure the responsiveness and performance of the vehicle network.

[0101] In step S13, the current state and multiple candidate actions are input into the current Q network to obtain the first Q value corresponding to each candidate action, wherein the current Q network is iteratively updated based on the reward value, and the reward value at the same time is inversely proportional to the total energy consumption of the Internet of Vehicles.

[0102] The current Q network is used for reinforcement learning. In this step, the current state at the current moment and the candidate actions of the roadside unit can be used as inputs to the current Q network. The current Q network calculates a first Q value for each current state-candidate action pair, which represents the expected reward that can be obtained by taking the candidate action in the current state.

[0103] It can be understood that the current Q network needs to learn and optimize its internal parameters through continuous iterative updates, and the iterative update process is based on the reward value at the next moment. In other words, every time a candidate action is executed and the reward value at the next moment is observed, the current Q network will use this reward value to update the parameters in order to more accurately estimate the expected value of future rewards.

[0104] The reward value is inversely proportional to the total energy consumption of the Internet of Vehicles. That is, if a candidate action can significantly reduce the total energy consumption of the system, the Q value corresponding to the candidate action will be relatively high. On the contrary, if a candidate action leads to an increase in total energy consumption, a lower reward value will be given to the candidate action, thereby encouraging the current Q network to gradually learn to select candidate actions that can reduce energy consumption during the training process.

[0105] For example, according to the actual application scenario of the Internet of Vehicles, the optimization goal of the reward value can be expressed as:

[0106]

[0107] Among them, Min means minimization, Indicates that bu ranges from 1 to U b Summation is performed, where U b Represents the number of vehicles, Indicates that b ranges from 1 to N B Sum, where N B is the number of base stations, represents the sum of k from 1 to F, where F represents the number of services or functions that the service node can provide, and P I represents the total energy consumption of the Internet of Vehicles, θ i,j and θ coThey represent the upper limits of the response delay of RSU and collaborative nodes respectively. The first constraint C1 means that the task processing delay of the service node cannot exceed the upper limit of the service delay. If this limit is exceeded, the service quality will be seriously affected. The second constraint C2 means that the sleep selection can only be 0 or 1, that is, the RSU can only be in working or sleeping mode. The third constraint C3 means that the utilization rate of RSU and collaborative nodes shall not exceed 1, that is, the task arrival rate of each service node is limited by the number of nodes and service rate.

[0108] In step S14, a target action is determined from candidate actions according to the first Q value, and sleep control is performed on each roadside unit based on the target action.

[0109] After obtaining the first Q value of each candidate action, one of the candidate actions can be selected as the target action. This target action is considered to be the best choice in the current state because it can minimize the total energy consumption.

[0110] Among them, a greedy strategy can be used to select the target action. Specifically, a candidate action is randomly selected with a probability of ε, or the candidate action with the largest first Q value is selected with a probability of 1-ε. This strategy not only considers the possibility of exploring new actions, but also ensures the maximization of benefits.

[0111] Once the target action is determined, each RSU can be put into sleep mode based on the target action. Specifically, if the target action is to put a RSU into sleep mode, a sleep command will be sent to the RSU to put it into a low-power sleep mode. On the contrary, if the target action is to keep a RSU active, it will ensure that it has sufficient resources and capabilities to handle future requests and data.

[0112] In this application, sleep control is not a one-time process, but needs to be continuously optimized and adjusted. In actual operation, it is necessary to continuously monitor the status and performance of the roadside unit and the changes in traffic flow to ensure the stability and efficiency of the system.

[0113] In one implementation, before inputting the current state and multiple candidate actions into the current Q network and obtaining the first Q value corresponding to each candidate action, the method further includes:

[0114] Determine the total energy consumption of the Internet of Vehicles based on device information;

[0115] Input the current state and multiple candidate actions into the target Q network to obtain the second Q value corresponding to each candidate action;

[0116] Determine a reward value based on the total energy consumption, and calculate a target Q value based on the maximum value of the second Q value and the reward value;

[0117] Determine the loss value between the target Q value and the first Q value corresponding to the target action at the previous moment, and update the current Q network and the target Q network based on the loss value.

[0118] In other words, the current Q network can be iteratively updated based on the DDQN (Double Deep Q-Network) algorithm in deep reinforcement learning. The DDQN algorithm can solve the overestimation problem that may occur in the Q network during training.

[0119] The core idea of ​​the DDQN algorithm is to use two independent neural networks to estimate the Q values ​​of the current state and the target state respectively. These two neural networks are called the Current Q-Network and the Target Q-Network respectively.

[0120] Among them, the current Q network is a deep neural network, whose input is the state S and candidate action A at a certain moment, and the output is the expected benefit of taking candidate action A under the state S, that is, the first Q value. The current Q network continuously learns and updates its parameters ω during the training process.

[0121] The target Q network is another deep neural network with the same structure as the current Q network, but its parameters ω′ are periodically copied from the current Q network. The target Q network is used to calculate the target Q value, which can guide the update of the current Q network.

[0122] In the dormant algorithm process based on DDQN, first, it is necessary to design the expressions of state, action and reward value. The expressions of state and action have been explained in the previous steps and will not be repeated here.

[0123] The reward value is a function inversely proportional to the total energy consumption. Specifically, at time t, the target action a is executed t , and then calculate the total energy consumption P at time t I,t Then, considering that we cannot only consider the reward at the current moment, we need to consider the overall reward over a period of time to avoid the algorithm being short-sighted and falling into a local optimal solution. Therefore, the reward value R at time t can be t Set to:

[0124]

[0125] Among them, T e It represents the number of moments, which means how many moments ago the historical reward value needs to be considered before the current reward value. γ is the discount factor, which indicates the influence of the historical reward value on the current reward value.

[0126] like Figure 3As shown in the flowchart of DDQN algorithm, at each time step, we first observe the current state S t , based on the state S t , the current Q network Q outputs the first Q value corresponding to each candidate action;

[0127] According to the first Q value obtained, a target action is selected according to the greedy strategy. In this way, the target action with the greatest benefit can be selected through the existing data, while avoiding falling into the local optimal solution to adapt to the dynamic network environment;

[0128] Perform the selected target action A t After that, you can get the reward value R t and the next state S t+1 In addition, we can also judge S t+1 Is it the end state, represented by is_end. For example, it can be set if the vehicle request can be based on S t+1 The cache contents of the RSUs that are not dormant in the process are processed, then S t+1 It can be used as the termination state, is_end takes the value of true, otherwise, is_end takes the value of false;

[0129] Then, the quintuple (S t ,A t ,R t ,S t+1 ,is_end) is stored in the experience revisit unit and used to update the current Q network Q. In machine learning and data mining, using multiple quintuples as training samples can enhance the generalization ability of the model, which means that the model can better handle unseen data and improve the accuracy of prediction;

[0130] Next, we can randomly extract some five-tuples in small batches from the experience replay unit and input them into the target Q network Q' to calculate the state S t+1 Each candidate action A t+1 The corresponding maximum value of the second Q value is expressed as Among them, ω′ represents the parameters of the target Q network, and ω represents the parameters of the current Q network;

[0131] Among them, if only one quintuple is extracted, the result may be very accidental and cannot represent the overall situation. Therefore, by extracting multiple quintuples, a richer data sample is obtained, which further reduces the deviation caused by the abnormality of a single sample, thereby more accurately estimating the characteristics of the population;

[0132] Then, we can calculate the maximum value of the second Q value and the reward value R t , calculate the target Q value y t ,y tThe expression can be written as:

[0133]

[0134] Alternatively, another statistic of the second Q value, such as the average, maximum, minimum, or weighted sum, can be calculated as the target Q value y t ;

[0135] Furthermore, we can determine y t Based on the state S t and target action A t The first Q value Q(S t ,A t ; ω), and update the current Q network and the target Q network based on the loss value:

[0136] For example, the parameter ω of the current Q network can be updated using the mean square error loss function and through the gradient back propagation of the neural network. The loss function formula is:

[0137] L(ω)=E[(y t -Q(S t ,A t ;ω)) 2 ]

[0138] Among them, L(ω) represents the loss value, and E represents the expectation;

[0139] In addition, the target Q network parameter ω′ can be updated after a certain number of steps, so that ω′=ω. It can be understood that in the DDQN algorithm, the experience replay technology is usually used to store and reuse past experience. If the target Q network is updated frequently, the target Q value in the historical experience stored in the replay buffer will quickly become outdated. This is because the parameters of the target Q network have changed, resulting in different target Q values ​​for the same state-action pair, which leads to inconsistency when using these historical experiences to update the current Q network, thereby reducing the efficiency and stability of learning;

[0140] Ultimately, through continuous iterative updates, the parameters of the neural network will become more accurate and can make ideal roadside unit sleep decisions.

[0141] In one implementation, the total energy consumption of the Internet of Vehicles is determined based on the device information, including:

[0142] Determine the static energy consumption, processing energy consumption, and transmission energy consumption of multiple service nodes based on the device information;

[0143] Add the static energy consumption, processing energy consumption and transmission energy consumption to get the total energy consumption.

[0144] That is to say, in the IoV environment proposed in the present invention, the total energy consumption includes the static energy consumption of the service node operation, the processing energy consumption of processing vehicle requests, and the transmission energy consumption caused by transmitting data, and the total energy consumption is obtained by summing them up.

[0145] Among them, static energy consumption refers to the electric energy consumed by the service node in idle or standby state; processing energy consumption refers to the electric energy consumed by the service node when processing tasks, which increases with the increase of service node load and is closely related to the processing capacity, task type and task volume of the service node; transmission energy consumption refers to the electric energy consumed by the service node during data transmission, which depends on factors such as data transmission volume, transmission speed, transmission distance and efficiency of the network interface.

[0146] In one implementation, the device information includes static power, and the static energy consumption of the plurality of service nodes is determined according to the network information and the device information, including:

[0147] The static energy consumption of multiple service nodes is determined according to the static power of the roadside unit that has not entered sleep mode.

[0148] For static energy consumption, the sleep selection of RSU needs to be optimized. Regardless of whether RSU is asleep or not, the static energy consumption of BS and cloud will not change. Therefore, when calculating the total static energy consumption of service nodes, only the static energy consumption of RSU is considered.

[0149] For example, BS i The energy consumption of the next j-th RSU can be expressed as:

[0150]

[0151] Among them, P R Represents the static power of RSU in working state, so BS i The total static energy consumption P of the next j RSUs i It can be expressed as:

[0152]

[0153] The static power consumption P of all RSUs in the IoV network I,S It can be expressed as:

[0154]

[0155] In one implementation, the device information includes a task arrival rate, a number of nodes, a service rate, and a task processing power. According to the device information, the processing energy consumption of a plurality of service nodes is determined, including:

[0156] Based on the task arrival rate, node number and service rate, the resource utilization rate of the service node and the corresponding probability distribution of the queue number of vehicle requests are calculated;

[0157] Calculate the average queuing delay of the service node based on the resource utilization and the probability distribution of the number of queues;

[0158] Calculate the task processing delay of the service node based on the average queuing delay and service rate;

[0159] According to the task processing delay and task processing power, the node energy consumption of each service node is calculated, and the node energy consumption is summed to determine the processing energy consumption of multiple service nodes.

[0160] Specifically, the vehicle request will be processed by the RSU or the cooperative node. According to the M / M / k queuing model, the resource utilization rate ρ of the service node p p It can be expressed as:

[0161]

[0162] Among them, λ p , k p , μ p They represent the task arrival rate, node number and service rate of service node p respectively. The M / M / k queuing model is an important model in queuing theory, which is used to describe and analyze the situation where multiple servers simultaneously process randomly arriving vehicle requests.

[0163] The task arrival rate is the number of vehicle requests that arrive at the service node per unit time. The number of nodes indicates the number of service nodes that can process vehicle requests simultaneously. The service rate is the number of vehicle requests that a service node can process per unit time.

[0164] When the vehicle request is waiting in the service node for processing, the equilibrium equation in the steady state is as follows:

[0165]

[0166] Among them, π n,p represents the probability that there are n vehicle requests in the queue system of service node p, π n-1,p represents the probability that there are n-1 vehicle requests in the queuing system serving node p.

[0167] That is, for n <k p In the case of n≥k, that is, when the number of vehicle requests in the service node is less than the number of service nodes, the arriving vehicle requests will be served immediately, so the transition probability of the number of vehicle requests from n to n+1 is proportional to the arrival rate. p That is, when the number of vehicle requests in the service node is equal to or greater than the number of service nodes, the arriving vehicle requests need to wait. Therefore, the transition probability of the number of vehicle requests from n to n+1 is not only related to the task arrival rate, but also to the service rate and the number of nodes.

[0168] Then, according to the equation as well as The idle probability π in service node p 0,p The specific formula is:

[0169]

[0170] π n,p The expression is:

[0171]

[0172] The average queue length L of vehicle requests at service node p can be determined according to the Erlang-C calculation formula: p :

[0173]

[0174] Therefore, the average queuing delay W of vehicle requests in service node p is p It can be expressed as:

[0175]

[0176] The total processing delay of a vehicle request in a service node p is the average queuing delay plus the service delay. The service delay is the inverse of the service rate and is expressed as:

[0177]

[0178] For example, when a vehicle requests access to Bs i When the jth RSU is processed, the task arrival rate of this RSU is λ i,j , the service rate is μ i,j , the number of nodes is k i,j , the resource utilization is:

[0179]

[0180] BS i The task processing delay of the jth RSU under can be expressed as:

[0181]

[0182] Among them, it means that the vehicle requests to be in BS i The average queuing delay of the jth RSU under .

[0183] In one implementation, the coordination node includes a cloud and at least one base station connected to the cloud. Based on the task arrival rate, the number of nodes and the service rate, before calculating the resource utilization rate of the service node and the corresponding probability distribution of the number of queues of vehicle requests, the coordination node includes:

[0184] The sum of the task arrival rates corresponding to the cloud and the base station is taken as the task arrival rate of the collaborative node;

[0185] The sum of the number of nodes corresponding to the cloud and base stations is taken as the number of nodes of the collaborative nodes;

[0186] The service rates corresponding to the cloud and base stations are summed up as the service rate of the collaborative node.

[0187] It can be understood that when the RSU is dormant, the vehicle request needs to be processed collaboratively by the BS and the cloud. In this case, all BSs and the cloud can be regarded as a super-large service node that shares computing resources, called a collaborative node.

[0188] For the collaborative node, its task arrival rate is the sum of the task arrival rates of all vehicle requests that need to be processed by all dormant RSUs, which can be expressed as:

[0189]

[0190] The service rate is the sum of the cloud service rate and all BS service rates, expressed as:

[0191]

[0192] Among them, μ c is the cloud service rate, μ i It's BS i service rate;

[0193] The number of nodes is the sum of the number of cloud nodes and the number of all BS nodes, expressed as:

[0194]

[0195] Among them, k c is the number of cloud nodes, k i It's BS i The number of nodes.

[0196] Therefore, the resource utilization of the collaborative node composed of the cloud and BS can be expressed as:

[0197]

[0198] Then, the task processing delay of the collaborative node is:

[0199]

[0200] Where, represents the average queuing delay of vehicle requests in the collaborative node.

[0201] Combining the above two situations, the processing power consumption of vehicle requests in the IoV environment can be expressed as:

[0202]

[0203] Among them, p R,H and p co,H They are the unit power consumption of RSU and cooperative node when processing vehicle requests.

[0204] In one implementation, the device information includes data transmission power, a first average data volume and an uplink bandwidth requested by the vehicle, and a second average data volume and a downlink bandwidth of a return result corresponding to the vehicle request. According to the device information, transmission energy consumption of multiple service nodes is determined, including:

[0205] Calculate the transmission delay of each service node according to the first average data volume, the second average data volume, the uplink bandwidth, and the downlink bandwidth;

[0206] The transmission energy consumption of multiple service nodes is determined based on the transmission delay and data transmission power.

[0207] Transmission energy consumption refers to the energy consumption required to transmit the result back to the vehicle after the vehicle request is uploaded to the service node for processing.

[0208] When the vehicle request is BS i When the jth RSU processes the transmission delay, it can be expressed as:

[0209]

[0210] Among them, s up and down are the average size of vehicle requests and returned results, l up,R and l down,R are the uplink and downlink bandwidths between RSU and vehicle, respectively.

[0211] When a vehicle request is responded to by a cooperative node, its transmission delay can be expressed as:

[0212]

[0213] Among them, l up,B and l down,B are the uplink and downlink bandwidths between the BS and the vehicle, respectively. Considering that the internal routing between the BS and the cloud also requires latency, l co Represents the average routing bandwidth between each BS and the cloud.

[0214] Combining these two situations, we can conclude that the transmission energy consumption in the IoV environment is:

[0215]

[0216] Among them, pR,T and p co,T are the unit power consumption required by RSU and collaborative nodes to transmit data. Therefore, the total energy consumption of service nodes in the IoV environment is:

[0217] P I =P I,S +P I,H +P I,T

[0218] As can be seen from the above, the technical solution provided by the embodiment of the present application is based on a reward value that is inversely proportional to the total energy consumption of the Internet of Vehicles, and trains the current Q network so that the first Q value output by the current Q network is related to the total energy consumption. Then, the current Q network performs reinforcement learning on the current state of the Internet of Vehicles at the current moment and the corresponding multiple candidate actions, calculates the first Q value of each candidate action, and determines the target action through the first Q value, so that the target action can achieve the effect of reducing the total energy consumption as much as possible. In this way, it is possible to implement an intelligent sleep algorithm for the roadside unit, dynamically control the sleep state of each roadside unit, and combine the request unloading system architecture of the Internet of Vehicles to reduce the total energy consumption as much as possible without affecting the vehicle request unloading.

[0219] The roadside unit sleep method provided in the embodiment of the present application can be executed by a roadside unit sleep device. In the embodiment of the present application, a method for executing terminal access by a roadside unit sleep device is taken as an example to illustrate the device of the roadside unit sleep method provided in the embodiment of the present application.

[0220] Figure 4 The present invention is a block diagram of a roadside unit sleep device according to an exemplary embodiment, including:

[0221] An acquisition module 201 is used to acquire device information of multiple service nodes at a current moment, wherein the multiple service nodes include a coordination node and at least one roadside unit connected to the coordination node;

[0222] A determination module 202, configured to determine, based on the device information, a current state of the connected vehicle network and a plurality of candidate actions corresponding to the current state, each candidate action being configured to indicate whether each roadside unit enters sleep at a next moment;

[0223] A calculation module 203 is used to input the current state and the multiple candidate actions into the current Q network to obtain a first Q value corresponding to each candidate action, wherein the current Q network is iteratively updated based on the reward value, and the reward value at the same time is inversely proportional to the total energy consumption of the Internet of Vehicles;

[0224] The control module 204 is configured to determine a target action from the candidate actions according to the first Q value, and perform sleep control on each roadside unit based on the target action.

[0225] As can be seen from the above, the technical solution provided by the embodiment of the present application is based on a reward value that is inversely proportional to the total energy consumption of the Internet of Vehicles, and trains the current Q network so that the first Q value output by the current Q network is related to the total energy consumption. Then, the current Q network performs reinforcement learning on the current state of the Internet of Vehicles at the current moment and the corresponding multiple candidate actions, calculates the first Q value of each candidate action, and determines the target action through the first Q value, so that the target action can achieve the effect of reducing the total energy consumption as much as possible. In this way, it is possible to implement an intelligent sleep algorithm for the roadside unit, dynamically control the sleep state of each roadside unit, and combine the request unloading system architecture of the Internet of Vehicles to reduce the total energy consumption as much as possible without affecting the vehicle request unloading.

[0226] The roadside unit sleep method provided in the embodiment of the present application can be executed by a terminal access terminal. In the embodiment of the present application, a method in which a terminal access terminal executes a terminal access is taken as an example to illustrate the device of the roadside unit sleep method provided in the embodiment of the present application.

[0227] The roadside unit dormancy device in the embodiment of the present application can be an electronic device, or a component in the electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal, or other devices other than a terminal. Exemplarily, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a PDA, a vehicle-mounted electronic device, a mobile Internet device (Mobile Internet Device, MID), an augmented reality (augmented reality, AR) / virtual reality (virtual reality, VR) device, a robot, a wearable device, an ultra-mobile personal computer (ultra-mobile personal computer, UMPC), a netbook or a personal digital assistant (personal digital assistant, PDA), etc. It can also be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a television (television, TV), a teller machine or a self-service machine, etc., which is not specifically limited in the embodiment of the present application.

[0228] The roadside unit sleep device provided in the embodiment of the present application can achieve Figures 1 to 3 To avoid repetition, the various processes implemented by the method embodiment are not described here.

[0229] Alternatively, if Figure 5As shown, an embodiment of the present application also provides an electronic device 500, including a processor 501 and a memory 502, wherein the memory 502 stores programs or instructions that can be executed on the processor 501, and when the program or instructions are executed by the processor 501, the various steps of the above-mentioned roadside unit sleep method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, they are not described here.

[0230] It should be noted that the electronic devices in the embodiments of the present application include the mobile electronic devices and non-mobile electronic devices mentioned above.

[0231] Figure 6 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of the present application.

[0232] The electronic device 1000 includes but is not limited to: a radio frequency unit 1001, a network module 1002, an audio output unit 1003, an input unit 1004, a sensor 1005, a display unit 1006, a user input unit 1007, an interface unit 1008, a memory 1009, and a processor 1010 and other components.

[0233] Those skilled in the art will appreciate that the electronic device 1000 may also include a power source (such as a battery) for supplying power to each component, and the power source may be logically connected to the processor 1010 through a power management system, thereby implementing functions such as managing charging, discharging, and power consumption management through the power management system. Figure 6 The electronic device structure shown in the figure does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently, which will not be described in detail here.

[0234] As can be seen from the above, the technical solution provided by the embodiment of the present application is based on a reward value that is inversely proportional to the total energy consumption of the Internet of Vehicles, and trains the current Q network so that the first Q value output by the current Q network is related to the total energy consumption. Then, the current Q network performs reinforcement learning on the current state of the Internet of Vehicles at the current moment and the corresponding multiple candidate actions, calculates the first Q value of each candidate action, and determines the target action through the first Q value, so that the target action can achieve the effect of reducing the total energy consumption as much as possible. In this way, it is possible to implement an intelligent sleep algorithm for the roadside unit, dynamically control the sleep state of each roadside unit, and combine the request unloading system architecture of the Internet of Vehicles to reduce the total energy consumption as much as possible without affecting the vehicle request unloading.

[0235] It should be understood that in the embodiment of the present application, the input unit 1004 may include a graphics processor (Graphics Processing Unit, GPU) 10041 and a microphone 10042, and the graphics processor 10041 processes the image data of the static picture or video obtained by the image capture device (such as a camera) in the video capture mode or the image capture mode. The display unit 1006 may include a display panel 10061, and the display panel 10061 may be configured in the form of a liquid crystal display, an organic light emitting diode, etc. The user input unit 1007 includes a touch panel 10071 and at least one of other input devices 10072. The touch panel 10071 is also called a touch screen. The touch panel 10071 may include two parts: a touch detection device and a touch controller. Other input devices 10072 may include, but are not limited to, a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which will not be repeated here.

[0236] The memory 1009 can be used to store software programs and various data. The memory 1009 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, an application program or instructions required for at least one function (such as a sound playback function, an image playback function, etc.), etc. In addition, the memory 1009 may include a volatile memory or a non-volatile memory, or the memory 1009 may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synchronous link dynamic random access memory (SLDRAM) and a direct memory bus random access memory (DRRAM). The memory 109 in the embodiment of the present application includes but is not limited to these and any other suitable types of memory.

[0237] The processor 1010 may include one or more processing units; optionally, the processor 1010 integrates an application processor and a modem processor, wherein the application processor mainly processes operations related to an operating system, a user interface, and application programs, and the modem processor mainly processes wireless communication signals, such as a baseband processor. It is understandable that the modem processor may not be integrated into the processor 1010.

[0238] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the various processes of the above-mentioned roadside unit sleep method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0239] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0240] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned roadside unit sleep method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0241] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0242] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned roadside unit sleep method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0243] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0244] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0245] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A request unloading system in a vehicle network, characterized in that: The system comprises a vehicle and a service node, wherein the service node comprises a coordination node and at least one roadside unit connected to the coordination node, wherein: The vehicle is used to send a connection request to the roadside unit; The roadside unit is configured to establish a connection with the vehicle in response to the connection request when the roadside unit is not in a dormant state; The vehicle is further configured to, when the connection with the roadside unit is successful, unload the vehicle request to the roadside unit; and when the connection with the roadside unit fails, unload the vehicle request to the coordination node.

2. The method for requesting uninstallation according to claim 1, characterized in that: The coordination node includes a cloud and at least one base station connected to the cloud, and each base station is connected to at least one of the roadside units; The vehicle is specifically used to offload the vehicle request to the base station to which the vehicle is connected when the connection with the roadside unit fails, so that the base station and the cloud can collaboratively process the vehicle request.

3. A roadside unit sleep method in a vehicle network, characterized in that: The method comprises: Acquire device information of multiple service nodes at a current moment, wherein the multiple service nodes include a coordination node and at least one roadside unit connected to the coordination node; Determine, according to the device information, a current state of the connected vehicle network and a plurality of candidate actions corresponding to the current state, each candidate action being used to indicate whether each roadside unit enters sleep at a next moment; Inputting the current state and the multiple candidate actions into the current Q network to obtain a first Q value corresponding to each candidate action, wherein the current Q network is iteratively updated based on the reward value, and the reward value at the same time is inversely proportional to the total energy consumption of the Internet of Vehicles; According to the first Q value, a target action is determined from the candidate actions, and sleep control is performed on each roadside unit based on the target action.

4. The roadside unit sleep method according to claim 3, characterized in that: Before inputting the current state and the plurality of candidate actions into the current Q network to obtain the first Q value corresponding to each candidate action, the method further includes: Determining the total energy consumption of the Internet of Vehicles based on the device information; Inputting the current state and the multiple candidate actions into the target Q network to obtain a second Q value corresponding to each candidate action; Determine the reward value based on the total energy consumption, and calculate the target Q value according to the maximum value of the second Q value and the reward value; A loss value between the target Q value and a first Q value corresponding to a target action at a previous moment is determined, and the current Q network and the target Q network are updated based on the loss value.

5. The roadside unit sleep method according to claim 4, characterized in that: Determining the total energy consumption of the Internet of Vehicles according to the device information includes: Determining static energy consumption, processing energy consumption, and transmission energy consumption of the plurality of service nodes according to the device information; The static energy consumption, the processing energy consumption, and the transmission energy consumption are added together to obtain the total energy consumption.

6. The roadside unit sleep method according to claim 5, characterized in that: The device information includes static power, and determining the static energy consumption of the plurality of service nodes according to the device information includes: The static energy consumption of the multiple service nodes is determined according to the static power of the roadside unit that has not entered sleep mode.

7. The roadside unit sleep method according to claim 5, characterized in that: The device information includes a task arrival rate, a number of nodes, a service rate, and a task processing power. According to the device information, the processing energy consumption of the plurality of service nodes is determined, including: Based on the task arrival rate, the number of nodes and the service rate, calculating the resource utilization rate of the service node and the probability distribution of the corresponding queue number of vehicle requests; Calculating the average queuing delay of the service node according to the resource utilization and the probability distribution of the queue quantity; Calculating the task processing delay of the service node according to the average queuing delay and the service rate; The node energy consumption of each service node is calculated according to the task processing delay and the task processing power, and the node energy consumptions are summed to determine the processing energy consumption of the multiple service nodes.

8. The roadside unit sleep method according to claim 7, characterized in that: The coordination node includes a cloud and at least one base station connected to the cloud. Before calculating the resource utilization rate of the service node and the corresponding probability distribution of the number of queues of vehicle requests based on the task arrival rate, the number of nodes and the service rate, the method includes: Sum the task arrival rates corresponding to the cloud and the base station as the task arrival rate of the collaborative node; Sum the number of nodes corresponding to the cloud and the base station as the number of nodes of the collaborative node; The service rates corresponding to the cloud and the base station are summed up to serve as the service rate of the collaborative node.

9. The roadside unit sleep method according to claim 5, characterized in that: The device information includes data transmission power, a first average data volume and an uplink bandwidth requested by the vehicle, and a second average data volume and a downlink bandwidth of a return result corresponding to the vehicle request. The transmission energy consumption of the multiple service nodes is determined according to the device information, including: Calculate the transmission delay of each service node according to the first average data amount, the second average data amount, the uplink bandwidth, and the downlink bandwidth; The transmission energy consumption of the multiple service nodes is determined according to the transmission delay and the data transmission power.

10. The roadside unit sleep method according to claim 3, characterized in that: The device information includes a task arrival rate, a node number, and a service rate. The determining the current state of the Internet of Vehicles according to the device information includes: Calculating an average value of the task arrival rate of each roadside unit within a preset time period before the current moment; The average value, the number of nodes of each service node at the current moment, and the service rate of each service node at the current moment are taken as a set to obtain the current state of the Internet of Vehicles.

Images