A dynamic compensation method for computing power of edge servers in Internet of Vehicles

By dividing edge servers into fixed sites and bus edge servers, using bus dynamic compensation computing power, the problem that fixed site edge servers cannot track dynamic load changes is solved, and load balancing and cost-effective Internet of Vehicles management are achieved.

CN116321059BActive Publication Date: 2025-08-19GUANGDONG UNIV OF TECH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202310249064.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-03-14
Publication Date
2025-08-19
Estimated Expiration
2043-03-14

AI Technical Summary

Technical Problem

In the prior art, the static deployment of fixed site edge servers cannot effectively track the spatio-temporal dynamics of computing needs of Internet of Vehicles users, resulting in load imbalance problems and the inability to dynamically adjust computing capabilities.

Method used

Divide edge servers into fixed site edge servers and bus edge servers, find out the overloaded fixed site edge servers through historical data analysis, and deploy bus edge servers on the bus to dynamically compensate for computing power while driving.

Benefits of technology

It realizes dynamic tracking of urban vehicle network users' computing needs, utilizes urban public resources, is low in cost, easy to install and configure, solves the problem of load imbalance, and provides reference for urban vehicle network management and basis for estimating the profit of bus service.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116321059B_ABST
    Figure CN116321059B_ABST
Patent Text Reader

Abstract

The present invention discloses a method for dynamically compensating the computing power of an Internet of Vehicles (IoV) edge server. The method comprises the following steps: dividing edge servers into fixed-site edge servers and bus edge servers; deploying the fixed-site edge servers at fixed locations, including roadside units and base stations; identifying fixed-site edge servers that experience overload based on historical data; deploying bus edge servers on corresponding buses to maximize the satisfaction of IoV terminal vehicle needs; and dynamically compensating the computing power of the fixed-site edge servers that experience overload using the bus edge servers while the buses are in motion. The present invention uses bus-mounted edge servers to dynamically track the computing needs of users of the urban IoV network, compensating for the lack of computing flexibility of fixed-site edge servers. Furthermore, the method utilizes existing public resources in the city and does not require changes to the existing routes of the buses.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle network edge computing infrastructure construction, and in particular to a method for dynamically compensating the computing power of a vehicle network edge server. Background Art

[0002] Edge computing is currently considered one of the core technologies for the future of intelligent connected vehicles. The concept of mobile edge computing is also gaining traction. Edge computing places computing power at the edge of the network, close to connected vehicle users, providing them with high-throughput, low-latency, and massively connected connected vehicle computing services. In the future 5G and even 6G connected vehicle era, the majority of end-user computing tasks will be performed by edge servers, which will be deployed in large numbers on roadside units, base stations, traffic lights, cameras, and even drones.

[0003] The deployment of edge computing servers is a crucial component of building autonomous digital transportation infrastructure. It's also a complex system engineering effort, requiring comprehensive consideration of multiple factors, including deployment carriers, deployment areas, server coverage, vehicle behavior, and optimization objectives. Currently, research on edge computing server deployment is still in its early stages, both domestically and internationally. Much of this research is limited to theoretical considerations, and practical deployment faces numerous challenges. More efficient, practical, widely applicable, and low-cost solutions are needed. A fundamental approach to edge server deployment involves deploying edge servers at existing network base stations and roadside units in a city, often referred to as fixed-site edge servers. While this approach is relatively easy to implement, once deployed, these servers cannot be moved, making real-time computing capacity adjustments difficult. IoV users are vehicles, and their computing needs are inherently spatiotemporally dynamic. This translates to a spatiotemporal dynamic load for edge computing servers. Providing computing services to IoV users using fixed-site edge servers is limited by fixed server location and coverage, and the inability to dynamically adjust computing capacity, resulting in inefficiencies in adapting to dynamic loads. For example, when heavy traffic occurs in Area A, the fixed-site edge servers in Area A may become overloaded. However, traffic in Area B may be light, and the servers may remain idle, resulting in a load imbalance. Later, most vehicles in Area A may move to Area B, creating the opposite situation, but the load imbalance persists. This is the problem with the static deployment of fixed-site edge servers, which cannot effectively track dynamic load changes. Summary of the Invention

[0004] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a method for dynamically compensating the computing power of an Internet of Vehicles edge server.

[0005] To achieve the above objectives, the technical solutions provided by the present invention are:

[0006] A method for dynamically compensating computing power of an Internet of Vehicles edge server, comprising:

[0007] Divide edge servers into fixed-site edge servers and bus edge servers;

[0008] Deploy fixed-site edge servers at fixed locations including roadside units and base stations;

[0009] Based on historical data, identify fixed-site edge servers that experience excessive load.

[0010] To maximize the needs of connected vehicle terminals, bus edge servers are deployed on corresponding buses.

[0011] A bus equipped with a bus edge server can dynamically compensate for the computing power of an overloaded fixed-site edge server through its bus edge server while driving.

[0012] Furthermore, based on historical data, identify fixed-site edge servers that are experiencing excessive load, including:

[0013] For a fixed-site edge server in the region, the coverage range is defined according to its location and coverage radius. The load subset W(t) of each time slice is determined in turn, which loads fall within the coverage range of the fixed-site edge server. These loads are sorted in ascending order of distance to the fixed-site edge server, and the top C loads are selected. RSU The load is taken as the load of the edge server at the fixed site in the time slice, and the C RSU The load is deleted from the corresponding load set W; C RSU Quantify the computing capacity of the edge server at a fixed site as the load it can bear in each time slice;

[0014] After repeating the above steps for all fixed-site edge servers, the remaining load W'={W'(t):t=1,2,...} is obtained, that is, the fixed-site edge servers with excess load are obtained.

[0015] Furthermore, before finding the fixed-site edge server with excessive load, the load set W and the load subset W(t) of each time slice t obtained by dividing the load records in the load set W by timestamp are calculated. The process is as follows:

[0016] Based on historical GPS data, the real-time location of buses and other terminal vehicles within a certain period of time, i.e., longitude and latitude, is extracted. A GPS record generated during a vehicle cycle is formalized as <timestamp, longitude, latitude>, and each such triple record is recorded as a load w i= <timestamp, longitude, latitude>; All records constitute the load set W = {<timestamp, longitude, latitude>};

[0017] Assign the load set W = {<timestamp, longitude, latitude>} to discrete time slices; divide a certain time period into multiple 10-second time slices, and divide the load records in the load set W into multiple subsets according to the timestamp. The load subset corresponding to time slice t is W(t) = {<timestamp, longitude, latitude>

[0018] :timestamp is within the current time slice t}.

[0019] Furthermore, in order to maximize the needs of IoV terminals, bus edge servers are deployed on corresponding buses, including:

[0020] The trajectory record of a bus b is an ordered set p b ={<timestamp, longitude, latitude>}, p b The records in are sorted by time; compared with fixed stops, bus track records have an additional timestamp attribute; the set of all buses is B, and the set initial value of the selected route, i.e. the final solution, is

[0021] Calculate the total load borne by the bus edge server when all bus routes in the bus set B operate independently; the computing capacity of the bus edge server is quantified as the load C that can be borne in each time slice. BUS , record the trajectory of bus b as p b = {<timestamp, longitude, latitude>] is discretized into all time slices, that is, the time slice corresponding to the location record is found according to the timestamp, and then the position relationship between the bus and other vehicles in the corresponding time slice is determined to obtain the position p of the bus in each time slice t. b (t) = <longitude, latitude>; for all time slices, according to the bus position, service radius R BUS , determine the loads that fall within the bus coverage area in the current time slice load W'(t), sort them in ascending order of distance to the bus, and select the first C BUS loads; cumulatively calculate the total load borne by the bus in all time slices;

[0022] Among all bus routes, select the bus route with the largest total load, delete the load it carries from the load W' = {W'(t): t = 1, 2, ...}; add this bus to the selected bus set S, and delete it from the set of all buses B;

[0023] Repeat the above steps and iterate until the number of buses in the bus set S reaches the given number N. The iteration stops and finally the bus edge server is deployed in the buses in the bus set S.

[0024] Compared with the existing technology, the principles and advantages of this solution are as follows:

[0025] 1. Use urban public transportation—buses equipped with edge servers—to dynamically track the computing needs of urban Internet of Vehicles users and compensate for the lack of computing elasticity of fixed-site edge servers.

[0026] 2. This solution utilizes the city's existing public resources, namely buses, without requiring additional land acquisition, occupying airspace, or changing existing bus routes. It is easy to install and configure, low-cost, and highly feasible.

[0027] 3. Based on cost requirements, select a certain number of buses from various bus routes to install edge servers, maximizing the terminal vehicle load that can be covered by the buses during their journey. This not only provides a reference for urban vehicle network management departments to solve the problem of dynamically changing loads in time and space, but also provides a basis for bus companies to select routes and estimate profits when launching such services in the future. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the services required for use in the embodiments or the prior art descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0029] Figure 1 This is a principle flow chart of a method for dynamically compensating the computing power of an Internet of Vehicles edge server according to the present invention;

[0030] Figure 2 Load map for time slices;

[0031] Figure 3 A diagram showing a fixed-site edge server responsible for one region;

[0032] Figure 4 A schematic diagram of a bus deployed with a bus edge server serving user vehicles within the service range;

[0033] Figure 5 A comparison of the loads borne by bus 1 and bus 2 within the time slice load map;

[0034] Figure 6 This is a schematic diagram of a plurality of bus routes with a large service coverage area finally obtained in the region. DETAILED DESCRIPTION

[0035] The present invention will be further described below in conjunction with specific embodiments:

[0036] like Figure 1 As shown, the method for dynamically compensating the computing power of an Internet of Vehicles edge server described in this embodiment includes the following steps:

[0037] S1, divide the edge servers into fixed site edge servers and bus edge servers;

[0038] S2. Deploy fixed-site edge servers at fixed locations including roadside units and base stations;

[0039] S3. Based on historical data, identify fixed-site edge servers that will experience overload.

[0040] This step specifically includes:

[0041] The load set W and the load records in the load set W are divided by timestamp to obtain the load subset W(t) of each time slice t. The process is as follows:

[0042] Based on historical GPS data, the real-time location of buses and other terminal vehicles within a certain period of time (such as one day or one week), i.e., longitude and latitude, is extracted. A GPS record generated within a vehicle cycle (e.g., once every 10 seconds) is formalized as <timestamp, longitude, latitude>. Each such triple record is recorded as a load w i = <timestamp, longitude, latitude>; all records constitute the load set W = {<

[0043] timestamp, longitude, latitude>};

[0044] Assign the load set W = {<timestamp, longitude, latitude>} to discrete time slices; divide a certain time period (1 day or 1 week) into multiple 10-second time slices, and divide the load records in the load set W into multiple subsets according to the timestamp. The load subset corresponding to time slice t is W(t) = {<

[0045] timestamp, longitude, latitude>: timestamp is within the current time slice t}.

[0046] Use the designated container to record the real-time GPS location of buses and other terminal vehicles, and generate the following information on the server: Figure 2 The time slice load maps shown are 0~10s, 10s~20s, 20s~30s...

[0047] Next, for a fixed-site edge server in the area, the coverage range is defined according to its location and coverage radius. The load subset W(t) of each time slice is determined in turn, which loads fall within the coverage range of the fixed-site edge server. These loads are sorted in ascending order of distance to the fixed-site edge server, and the top C loads are selected. RSU The load is taken as the load of the edge server at the fixed site in the time slice, and the C RSU The load is deleted from the corresponding load set W; C RSU Quantify the computing capacity of the edge server at a fixed site as the load it can bear in each time slice;

[0048] like Figure 3 As shown, if the entire region is divided into 15 zones, each of the 15 fixed-site edge servers is responsible for a zone. The load occurring within a zone is handled by the corresponding edge server. In the time slice shown in the figure, fixed site A handles the load twice, fixed site B handles the load twice, fixed site C handles the load once, and so on. Fixed site O handles the load twice. After handling the load, the computing power of fixed site A decreases by 2, the computing power of fixed site B decreases by 2, the computing power of fixed site C decreases by 1, and so on. All handled loads are deleted from the map.

[0049] After repeating the above steps for all fixed-site edge servers, the remaining load W'={W'(t):t=1,2,...} is obtained.

[0050] S4. To maximize the needs of connected vehicle terminals, deploy bus edge servers on corresponding buses. The process includes:

[0051] The trajectory record of a bus b is an ordered set p b ={<timestamp, longitude, latitude>}, p b The records in are sorted by time; compared with fixed stops, bus track records have an additional timestamp attribute; the set of all buses is B, and the set initial value of the selected route, i.e. the final solution, is

[0052] Calculate the total load borne by the bus edge server when all bus routes in the bus set B operate independently; the computing capacity of the bus edge server is quantified as the load C that can be borne in each time slice. BUS and record the trajectory of bus b as p b = {<timestamp, longitude, latitude>} is discretized into all time slices to obtain the bus position p in each time slice t b (t) = <longitude, latitude>; for all time slices, according to the bus position, service radius R BUS, determine the loads that fall within the bus coverage area in the current time slice load W'(t), sort them in ascending order of distance to the bus, and select the first C BUS loads; cumulatively calculate the total load borne by the bus in all time slices;

[0053] like Figure 4 As shown in the figure, in a certain time slice, there are 12 vehicles around a bus sending load requests, among which c1, c2, c3, c4, c5, c6, c7, c8, c 11 The vehicles with the numbers are all within the service range of this bus (the service radius is R BUS In this time slice t, the bus is selected from the nearest load. If C BUS ≥9, then the number of loads covered by the bus in this time slice is 9; if C BUS <9, then the bus's capacity is insufficient to support all 9 loads, and the nearest C bus is selected. BUS Secondary load.

[0054] Among all bus routes, select the bus route with the largest total load, delete the load it carries from the load W' = {W'(t): t = 1, 2, ...} (equivalent to updating the load on the map); add this bus to the selected bus set S, and delete it from the set of all buses B;

[0055] Repeat the above steps and iterate until the number of buses in the bus set S reaches the given number N. The iteration stops and finally the bus edge server is deployed in the buses in the bus set S.

[0056] like Figure 5 As shown in the load map of time slices 0-10s, 10s-20s, 20s-30s, etc., it is obvious that the total load borne by bus 2 is greater than that of bus 1. That is, bus 2 is selected, added to the bus set S, and deleted from the bus set B. The load assigned to this bus is also deleted from the load set W'={W'(t):t=1,2,...}.

[0057] like Figure 6 As shown, five bus lines A, B, C, D, and E with larger service coverage areas in the area are finally selected from multiple bus lines in the area.

[0058] S5. The bus deployed with the bus edge server dynamically compensates the computing power of the fixed site edge server with excess load through its bus edge server while driving.

[0059] The embodiments described above are only preferred embodiments of the present invention and are not intended to limit the scope of implementation of the present invention. Therefore, any changes made based on the shape and principle of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for dynamically compensating the computing power of an Internet of Vehicles edge server, characterized in that: include: Divide edge servers into fixed-site edge servers and bus edge servers; Deploy fixed-site edge servers at fixed locations including roadside units and base stations; Based on historical data, identify fixed-site edge servers that experience excessive load. To maximize the needs of connected vehicle terminals, bus edge servers are deployed on corresponding buses. A bus equipped with a bus edge server dynamically compensates the computing power of an overloaded fixed-site edge server through its bus edge server while driving. To maximize the needs of connected vehicle terminals, bus edge servers are deployed on corresponding buses, including: The trajectory record of a bus b is an ordered set p b ={<timestamp, longitude, latitude>}, p b The records in are sorted by time; compared with fixed stops, bus track records have an additional timestamp attribute; the set of all buses is B, and the set initial value of the selected route, i.e. the final solution, is Calculate the total load borne by the bus edge server when all bus routes in the bus set B operate independently; the computing capacity of the bus edge server is quantified as the load C that can be borne in each time slice. BUS and record the trajectory of bus b as p b = {<timestamp, longitude, latitude>} is discretized into all time slices to obtain the bus position p in each time slice t b (t)=< Longitude, latitude>; For all time slices, according to the bus location, service radius R BUS , determine the loads that fall within the bus coverage area in the current time slice load W'(t), sort them in ascending order of distance to the bus, and select the first C BUS loads; cumulatively calculate the total load borne by the bus in all time slices; Among all bus routes, select the bus route with the largest total load, and delete its load from the load W' = {W'(t): t = 1, 2, ...}; add this bus to the selected bus set S, and delete it from the set of all buses B; Repeat the above steps and iterate until the number of buses in the bus set S reaches the given number N. The iteration stops and finally the bus edge server is deployed in the buses in the bus set S.

2. A method for dynamically compensating computing power of an Internet of Vehicles edge server according to claim 1, characterized in that: Based on historical data, identify fixed-site edge servers that experience excessive load, including: For a fixed-site edge server in the region, the coverage range is defined according to its location and coverage radius. The load subset W(t) of each time slice is determined in turn, which loads fall within the coverage range of the fixed-site edge server. These loads are sorted in ascending order of distance to the fixed-site edge server, and the top C loads are selected. RSU The load is taken as the load of the edge server at the fixed site in the time slice, and the C RSU The load is deleted from the corresponding load set W; C RSU Quantify the computing capacity of the edge server at a fixed site as the load it can bear in each time slice; After repeating the above steps for all fixed-site edge servers, the remaining load W'={W'(t):t=1,2,...} is obtained, that is, the fixed-site edge servers with excess load are obtained.

3. The method for dynamically compensating computing power of an IoV edge server according to claim 2, characterized in that: Before finding the fixed-site edge servers that will have excessive load, the load set W and the load subset W(t) for each time slice t obtained by dividing the load records in the load set W by timestamp are calculated. The process is as follows: Based on historical GPS data, the real-time location of buses and other terminal vehicles within a certain period of time, i.e., longitude and latitude, is extracted. A GPS record generated during a vehicle cycle is formalized as <timestamp, longitude, latitude>, and each such triple record is recorded as a load w i = <timestamp, longitude, latitude>; All records constitute the load set W = {<timestamp, longitude, latitude>}; Assign the load set W = {<timestamp, longitude, latitude>} to discrete time slices; divide a certain time period into multiple 10-second time slices, and divide the load records in the load set W into multiple subsets according to the timestamp. The load subset corresponding to time slice t is W(t) = {<timestamp, longitude, latitude>: timestamp is within the current time slice t}.