Price self-balancing auction method under cloud-edge collaborative environment

Abstract

The application discloses a price self-balancing auction method in a cloud-edge collaborative environment. Through multiple rounds of resource allocation attempts, in each round of resource allocation attempt, a unit price increment parameter of each resource is determined according to the demand of the last round of active user set for different resources, the unit price of various resources on each edge server and the bandwidth resource on the cloud server is updated, then the active user set of the current round is updated, the active users in the updated active user set are arranged in descending order according to the size of the resource demand norm, then resource allocation is performed on each active user in turn, if all users in the current active user set successfully perform resource allocation, the final resource allocation scheme is obtained, otherwise the next round is entered. The application realizes price self-balancing, guides the generation of resource allocation and payment scheme, and makes the resource allocation scheme more reasonable.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing technology, and more specifically, relates to a price self-balancing auction method in a cloud-edge collaborative environment. Background Technology

[0002] With the development of cloud computing technology, cloud-edge collaborative computing has received increasing attention. For example, using information generated by vehicle sensors to transmit to the edge and cloud to train autonomous driving models can improve algorithm learning efficiency; or, through federated learning supported by cloud-edge collaboration, machine learning algorithms can be deployed to edge nodes to provide services to users; or, cloud-edge collaborative AI frameworks can enable users of the Metaverse (a cloud computing ecosystem) to have a better experience. Although service providers have built many edge nodes, such as edge servers within mobile base stations or roadside units (RSUs) in vehicle-to-everything (V2X) networks, the heterogeneous edge computing nodes, the geographical differences of edge computing devices, and the rapidly increasing demand for cloud-edge collaborative computing have brought significant challenges to the resource allocation design in cloud-edge collaborative computing. The characteristic of cloud-edge collaborative computing is that there is data interaction between any two of the cloud, edge, and device, which makes the resource allocation problem in cloud-edge collaborative computing even more complex.

[0003] Autonomous driving is an important application scenario for cloud-edge collaboration. Figure 1 This is a typical architecture diagram of cloud-edge collaborative AI computing for CAVs (connected and autonomous vehicles). For example... Figure 1 As shown, the cloud-edge collaboration process is roughly as follows: (1) During the vehicle's operation, some sensor data (such as video data and lidar data) is uploaded to the edge via a mobile base station; (2) Through decision-making, the data can be placed at the edge for local machine learning; then (3) the learned model is transmitted to the cloud, or (4) the base station directly transmits the data to the cloud for learning; finally (5) the cloud integrates the data to obtain a global model, which is then transmitted to the vehicle, allowing the vehicle to learn and predict based on the latest model. In this model, the bandwidth from the device to the edge, the computing power of the edge server, and the bandwidth from the edge to the cloud all become resources that users compete for. How to reasonably allocate resources to users so that service providers can obtain maximum utility (social welfare, service quality) has become the focus of research on this type of problem.

[0004] Auction mechanisms are an effective way to allocate resources through market behavior. The core of an auction mechanism lies in the fact that the value of an item is determined by the supply of resources, their quantity, and the combined bids of all bidders (market conditions), which determine the final allocation and payment price. In an auction, each user submits their resource request and bid to the resource provider, who then decides which user to allocate the resource to and calculates the final payment price for the winning user. Currently, many studies utilize auction mechanisms to solve virtual resource allocation problems, such as spectrum auctions, channel auctions, and auctions for computing and storage resources in cloud computing or edge computing.

[0005] Generally, the problem of allocating virtual resources using auction mechanisms is transformed into a social welfare maximization problem with multiple constraints (social welfare refers to the total bids of the winners), while also ensuring the reliability of the mechanism and economic characteristics such as individual rationality. Typical mechanism designs include optimal allocation plus VCG pricing, or monotonic allocation based on resource density plus key price pricing. While these mechanisms can achieve significant social welfare (because the allocation phase is equivalent to solving a knapsack problem, satisfying the principle of maximizing allocation), the final benefit is not necessarily positively correlated with social welfare. The main reason is that existing pricing algorithms do not adequately consider the differences in resource scarcity, deployment constraints, and multiple servers in cloud-edge collaborative computing. For example, in the cloud computing market, all resources originate from the same source, and the value of different resources is relatively easy to determine; reflecting the value differences of different resources through the proportion of dominant resources or resource density is reasonable. However, in edge computing, deployment constraints between users and edge servers (which edge servers a user can connect to) also lead to differences in resource scarcity across different edge servers. For example, edge server resources located in busy urban areas should be more valuable than those in remote areas. From an economic perspective, resource prices are determined by supply and demand; even the same type of resource will have different prices depending on its usage scenario. This implies that the prices of the same type of resource will differ across different edge servers. However, these characteristics are rarely considered in traditional mechanism designs, posing a significant challenge to the design of mechanisms in cloud-edge collaborative computing scenarios. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and provide a price self-balancing auction method in a cloud-edge collaborative environment. It introduces the principle of resource price increase and determines the price of different resources through characteristics such as heterogeneous servers, multi-dimensional resources, resource scarcity, and deployment constraints, thereby achieving price self-balancing and guiding the generation of resource allocation and payment schemes, making the resource allocation schemes more reasonable.

[0007] To achieve the above-mentioned objectives, the price self-balancing auction method in a cloud-edge collaborative environment of the present invention includes the following steps:

[0008] S1: The cloud-edge collaborative system contains a cloud server and M edge servers, set... Let R represent the set of edge servers, and let R be the number of different types of computing resources in the system. Let the set of resources be represented; let the bandwidth resources of the cloud server be denoted as... Let c be the computing resource capacity of each edge server j. j =(c j1 ,c j2 ,...,c jR ), c jr This represents the capacity of the r-th computing resource on each edge server j, where the bandwidth resource of edge server j is... j=1,2,...,M, r=1,2,...,R;

[0009] S2: Let there be N users in the system, and set... Represents a set of users, and obtains the resource requirement information θ for each user i. i =(S i ,s iBW ,δ i ,σ i ,b i ), where S i =(s i1 ,s i2 ,...,s iR ) represents the resource demand vector of user i, s ir s represents the quantity of resource r that user i requires. iBW δ represents the bandwidth requirement of user i; i =(δ i1 ,δ i2 ,...δ im ) represents the resource deployment constraints for user i, δ ij =1 indicates that user i can be deployed on edge server j, δ ij =0 indicates that deployment is not possible; σ i This represents the data compression ratio of user i's task after it runs on the edge server and is uploaded to the cloud server. Its value range is σ. i ∈(0,1); b i This represents the bid made by user i for the resource request they have submitted;

[0010] S3: Initialize the unit price uc for each resource on edge server j. jr =0, initialize the active user set of each edge server j.

[0011] S4: Calculate the unit price increment parameter λ of the r-th computing resource on edge server j using the following formula. jr :

[0012]

[0013] Where e represents the natural constant;

[0014] Similarly, the incremental unit price parameter λ of bandwidth resources on edge server j is calculated using the following formula. jBW :

[0015]

[0016] S5: Update the unit price of various computing resources on each edge server j using the following formula:

[0017] uc jr =uc jr +λ jr ε

[0018] The unit price of bandwidth resources on each edge server j is updated using the following formula:

[0019] uc jBW =uc jBW +λ jBW ε

[0020] The unit price of bandwidth resources on the cloud server is updated using the following formula:

[0021]

[0022] Where α represents the preset adjustment parameter;

[0023] S6: The active user set for each edge server j is calculated using the following formula. Update:

[0024]

[0025] S7: Initialize the set of resource allocation schemes Resource usage price set Aggregate active users Let c be the computing resource capacity of each edge server j. j ′=c j Cloud server bandwidth resources Bandwidth resources of edge server j The resource usage price for user i via edge server j served by cloud server The resource usage price for user i to upload the computation results to the cloud server after being served by edge server j. p max Indicates the preset absolute maximum value;

[0026] S8: For the set of active users The resource demand norm s of user i″ is calculated according to the following formula. i″ norm :

[0027]

[0028] active user set Users are sorted in descending order according to their resource demand norm, and the original index of the k-th user after sorting is denoted as i. k k = 1, 2, ..., K, where K represents the set of currently active users. The number of users in;

[0029] S9: For active user sets The resource allocation for users in the system is performed as follows:

[0030] S9.1: Set user serial number k = 1;

[0031] S9.2: For each edge server j, if the user Then no action is taken if the user... There are two possible scenarios:

[0032] Determine if it satisfies and If so, it means user i k The resource usage price can be updated via the cloud server through the edge server j, using the following formula.

[0033]

[0034] If the above conditions are not met, no action will be taken;

[0035] Determine if it satisfies and This means that user i k The edge server j can then upload the computation results to the cloud server, and the resource usage price can be updated using the following formula.

[0036]

[0037] If the above conditions are not met, no action will be taken;

[0038] S9.3: From user i kThe lowest resource usage price is selected from all current resource usage prices and used as the price for user i. k payment price The minimum resource usage price corresponds to the edge server used by user i k Service edge server j k If the minimum resource usage price is through user i k If the result is generated by the edge server j and then uploaded to the cloud server, then user i... k Service logo Otherwise

[0039] S9.4: Determine if user i k payment price If so, it means that the current cloud-edge collaboration system's resources are insufficient for user i. k If resource allocation is performed, the allocation of resources to active users will end, and the allocation of resources to all active users will fail; otherwise, proceed to step S9.5.

[0040] S9.5: Allow user i k and edge server j k Resource allocation identifier And As user i k The resource allocation scheme is added to the resource allocation scheme set. Immediately Set of payment prices

[0041] S9.6: Determine if k < K. If yes, proceed to step S9.7. Otherwise, it means that all users in the current active user set have been successfully allocated, the active user resource allocation is complete, and all active user resources have been successfully allocated.

[0042] S9.7: Update the resource quantity of edge servers and cloud servers:

[0043] If service identifier Then let

[0044] if Then let

[0045] S9.8: Set user number k = k + 1, and return to step S9.2;

[0046] S10: Determine whether all active users have successfully allocated resources. If not, return to step S4; otherwise, proceed to step S11.

[0047] S11: Based on the current set of resource allocation schemes Obtain each winning user and their resource allocation plan, based on the current set of payment prices. The winning user's payment price is obtained.

[0048] This invention presents a self-balancing auction method for cloud-edge collaborative environments. Through multiple rounds of resource allocation attempts, in each round, the incremental unit price parameter for each resource is determined based on the demand for different resources from the previous round's active user set. The unit prices of various resources on each edge server and bandwidth resources on the cloud server are updated, and then the active user set for the current round is updated. The active users in the updated active user set are sorted in descending order according to the magnitude of their resource demand norm, and resources are allocated to each active user in turn. If all users in the current active user set are successfully allocated resources, the final resource allocation scheme is obtained; otherwise, the next round begins.

[0049] The present invention has the following beneficial effects:

[0050] 1) This patent models the resource allocation problem in cloud-edge collaborative computing, which has characteristics such as heterogeneous servers, multi-dimensional resources, resource scarcity, and deployment constraints, and transforms it into a multi-dimensional resource multi-knapsack integer programming model with deployment constraints, which is more in line with the actual situation;

[0051] 2) This invention designs a price self-balancing auction mechanism. Specifically, based on the principle of resource price appreciation, it reflects the different resource scarcity on different servers according to user demand, server resource capacity, and edge deployment constraints. This scarcity is used to calculate the real-time unit price of resources, guiding the generation of allocation and payment schemes. This mechanism satisfies the economic characteristics of individual rationality and reliability, and has a polynomial-time execution time, making the final resource allocation scheme more reasonable and reliable. Attached Figure Description

[0052] Figure 1 This is a typical architecture diagram of CAV cloud-edge collaborative AI computing;

[0053] Figure 2 This is a flowchart illustrating a specific implementation of the price self-balancing auction method in a cloud-edge collaborative environment according to the present invention.

[0054] Figure 3 This is a flowchart of the active user resource allocation process in this invention. Detailed Implementation

[0055] The specific embodiments of the present invention will now be described with reference to the accompanying drawings to enable those skilled in the art to better understand the invention. It should be particularly noted that in the following description, detailed descriptions of known functions and designs that might obscure the main content of the invention will be omitted here.

[0056] To better illustrate the technical solution of the present invention, the technical derivation of the present invention will be briefly explained first.

[0057] The cloud-edge collaborative system comprises a cloud server (CCS, Cloud Container Service) and M edge servers (ECS, Edge Computing Servers), and integrates... Let R represent the set of edge servers, and let R be the number of different types of computing resources in the system. This represents a set of resources, typically including CPU, memory, and storage. Generally, the computing resource capacity in a cloud server is very large; it can be considered that the capacity of each computing resource in a cloud server is unlimited. Let's denote the bandwidth resource of a cloud server as... Let c be the computing resource capacity of each edge server j. j =(c j1 ,c j2 ,...,c jR ), c jr Let M represent the capacity of the r-th computing resource on each edge server j, where j = 1, 2, ..., M, r = 1, 2, ..., R, and the bandwidth resource of edge server j is...

[0058] Let there be N users in the system. Let S represent the set of users. The resource requirements of each user i are represented by the vector S. i =(s i1 ,s i2 ,...,s iR ) indicates that s ir This represents user i's demand for the r-th resource, and user i's bandwidth requirement is s. iBW User i bids b for its proposed resource request. i , Due to location limitations, users' resource needs can only be met by a few nearby edge servers. Therefore, we define a vector δ. i =(δ i1 ,δ i2 ,...δ im Let δ represent the resource deployment constraints for user i. ij =1 indicates that user i can be deployed on edge server j, δ ij=0 indicates deployment is not possible. Faced with numerous user demands, the processing capacity of edge servers still falls short of demand. In such cases, the edge server transforms into a content forwarding device with routing capabilities, directly sending user data to the cloud for processing. For user tasks processed on the edge server, only a small portion of the processing results needs to be uploaded to the cloud server. For example, in federated learning between the cloud and the edge, the edge server only needs to transmit the trained local model parameters to the cloud server for updates. Define σ. i ∈(0,1) represents the data compression ratio uploaded to the cloud after user i's task runs on the edge server. The final resource requirement information submitted by user i is θ. i =(S i ,s iBW ,δ i ,σ i ,b i All user-submitted resource requirements are represented by a resource requirement vector θ = (θ1, θ2, ..., θ). N )express.

[0059] In the resource allocation problem, this invention introduces the decision variable x. ij Let ∈{1,0} represent whether the resource requirements of user i can be allocated on edge server j, and define y ij ∈{1,0} indicates whether user i's data can be transmitted to the cloud server for execution via edge server j instead of being executed on edge server j (in this case, edge server j only acts as a data forwarding device). Since this invention assumes that the computing resources provided by the cloud platform are unlimited, user requests will not be limited by resource capacity if they are transmitted to the cloud platform for execution.

[0060] The objective of this invention is to optimally allocate server resources to maximize the social welfare of resource providers. The total social welfare is denoted as V, and the problem is formulated as an integer programming problem as follows:

[0061]

[0062]

[0063]

[0064]

[0065]

[0066]

[0067] Formula (1) represents the total social welfare of the winning user across the entire edge computing and cloud computing system. Formula (1a) states that resource allocation cannot exceed the resource capacity of any edge server. Formula (1b) states that the bandwidth allocated to a user cannot exceed the bandwidth capacity of any edge server. Similarly, Formula (1c) states that the bandwidth allocated to all users cannot exceed the bandwidth capacity of the cloud server. Note This represents the bandwidth required for user data (which has been compressed) to be transmitted from the edge server to the cloud server. This indicates that the edge server is only used for content distribution, and the final execution occurs on the cloud server. Equation (1d) indicates that the user's needs can only be either executed on the edge server or executed in the cloud, and Equation (1e) indicates that the entire model is an integer programming problem.

[0068] To address the resource allocation problem in cloud-edge collaboration, an auction mechanism is typically employed. Existing auction mechanisms often use resource density to rank users for allocation and pricing. However, different resource density designs can lead to different ranking results. For example, the paper "L. Mashayekhy, MMNejad, and D. Grosu, 'Physical Machine Resource Management in Clouds: A Mechanism Design Approach,' IEEE Transactions on Cloud Computing, vol.3, no.3, 2015, doi:10.1109 / TCC.2014.2369419." uses... Resource density is defined by the proportion of dominant resources, while the literature "J. Zhang, X. Yang, N. Xie, X. Zhang, AV Vasilakos, and W. Li, “An online auction mechanism for time-varying multidimensional resource allocation in clouds,” Future Generation Computer Systems, vol. 111, 2020, doi:10.1016 / j.future.2020.04.029" uses the proportion of dominant resources to define resource density. in This represents the proportion of dominant resources available to user i on edge server j. The former doesn't consider deployment constraints, meaning all users can be allocated resources across all servers, which is unrealistic in a cloud-edge collaborative environment. The latter, while considering deployment constraints, doesn't accurately represent the difference in resource scarcity across servers. For example, suppose an edge server has CPU, memory, and storage resources of (5, 5, 100). User 1's request is ((4, 4, 10), 21), User 2's request is ((2, 1, 10), 10), and User 3's request is ((3, 1, 10), 15). This means User 1 needs 4 CPUs, 4 memory, and 10 storage resources, bidding 21. The interpretations for Users 2 and 3 are similar. Which user is more cost-effective for the resource provider? If we use resource density as the definition... It can be seen that User 1 has a resource advantage ratio of 4 / 5, and a resource density of 26. Similarly, User 2 and User 3 both have a resource density of 25. Because User 1 has a high resource density, the system will choose User 1 as the winner. However, it can be seen that the server would gain a greater benefit by choosing Users 2 and 3. Using resource density... The calculations show that users 2 and 3 are the winners. This means that many different criteria can be used as the standard for ranking resource density, resulting in different allocation and payment schemes. Furthermore, these schemes must satisfy the characteristics of credibility and individual rationality. But are these different allocation methods sufficiently reasonable, and where do the differences in their allocation and payment outcomes come from?

[0069] From the perspective of resource providers, the capacity of various resources differs. The cost of using abundant resources is not high, while scarce resources are the primary target of competition. This can also be seen in the pricing of virtual machines in the cloud computing market. For example, on the Alibaba Cloud platform, ordering a virtual machine with 1 core, 2GB of memory, and 30GB of storage costs 30 yuan per month. If only the memory is increased from 2GB to 4GB, the monthly fee is 38 yuan, an increase of 8 yuan. However, if only the storage is increased from 30GB to 40GB, the monthly cost is 32 yuan, an increase of 2 yuan. Therefore, in multi-dimensional resources, the unit price of each resource is different, making it reasonable for resource providers to consider the usage cost as a basis for winning user decisions. The second important reason comes from the cloud-edge collaborative computing framework. Due to geographical limitations, users face constraints on the deployment of edge servers. This means that even edge servers of the same specifications should have varying degrees of resource scarcity and usage costs (similar to how parking spaces in city centers are more expensive than those in remote areas). Therefore, different resources on different edge servers should have different unit prices. Clearly, the price of resources should depend on user resource needs, the quantity of server resources, and edge deployment constraints. The price of resources also guides the design of the final allocation and payment schemes.

[0070] Based on the above technical derivation and analysis, this invention proposes a price self-balancing auction method in a cloud-edge collaborative environment. This method prices each resource on different edge servers individually, making the resource allocation scheme more reasonable. Figure 2 This is a flowchart illustrating a specific implementation of the price self-balancing auction method in a cloud-edge collaborative environment according to the present invention. Figure 2 As shown, the specific steps of the price self-balancing auction method in the cloud-edge collaborative environment of the present invention include:

[0071] S201: Obtain server information:

[0072] The cloud-edge collaborative system consists of a cloud server and M edge servers, which are collectively known as cloud servers. Let R represent the set of edge servers, and let R be the number of different types of computing resources in the system. Let the set of resources be represented; let the bandwidth resources of the cloud server be denoted as... Let c be the computing resource capacity of each edge server j. j =(c j1 ,c j2 ,...,c jR ), c jr This represents the capacity of the r-th computing resource on each edge server j, where the bandwidth resource of edge server j is... j=1,2,...,M, r=1,2,...,R.

[0073] S202: User submits resource request:

[0074] Let there be N users in the system, and set Represents a set of users, and retrieves the resource requirement information θ for each user i. i =(S i ,s iBW ,δ i ,σ i ,b i ), where S i =(s i1 ,s i2 ,...,s iR ) represents the resource demand vector of user i, s ir s represents the quantity of resource r that user i requires. iBW δ represents the bandwidth requirement of user i; i =(δ i1 ,δ i2 ,...δ im ) represents the resource deployment constraints for user i, δ ij =1 indicates that user i can be deployed on edge server j, δ ij =0 indicates that deployment is not possible; σ i This represents the data compression ratio of user i's task after it runs on the edge server and is uploaded to the cloud server. Its value range is σ. i ∈(0,1); b i This represents the bid made by user i for the resource request it has made.

[0075] S203: Initialize resource unit price and active user set:

[0076] Initialize the unit price uc for each resource on edge server j. jr =0, initialize the active user set of each edge server j.

[0077] S204: Calculate the incremental parameters for resource unit price.

[0078] This invention employs an iterative approach to determine a feasible resource allocation scheme, where the unit price increase for each type of computing resource on edge server j is determined by λ. jr ε is defined, where λ jr Let λ be the unit price increment parameter for the r-th computing resource on edge server j, and ε be the preset unit price increment step. Research has found that the unit price increment parameter λ... jrThe design needs to meet the following characteristics: First, when a certain resource is relatively scarce, the unit price increase of that resource is larger; conversely, when resources are relatively abundant, the unit price increase of that resource is smaller. Second, when a certain type of resource is sufficient to satisfy all users, the unit price increase step size is fixed at ε. Therefore, in this invention, the unit price increment parameter λ of the r-th computing resource on edge server j is calculated using the following formula. jr :

[0079]

[0080] Where e represents the natural constant, This represents the set of active users on edge server j.

[0081] Similarly, the incremental unit price parameter λ of bandwidth resources on edge server j is calculated using the following formula. jBW :

[0082]

[0083] S205: Update resource unit price:

[0084] The unit price of various computing resources on each edge server j is updated using the following formula:

[0085] uc jr =uc jr +λ jr ε (4)

[0086] The unit price of bandwidth resources on each edge server j is updated using the following formula:

[0087] uc jBW =uc jBW +λ jBW ε (5)

[0088] As can be seen, the above update method allows for separate updates to the unit price of different resources, thus reflecting the scarcity of different resources and better aligning with market principles. However, the bandwidth price of cloud servers cannot be calculated in this way. From the cloud server's perspective, transactions between edge servers and users resemble a secondary market, and data destined for the cloud server must first pass through edge servers. Therefore, the bandwidth price of the cloud server should be determined by the bandwidth price of each edge server. Therefore, this invention uses the following formula to update the unit price of bandwidth resources on cloud servers:

[0089]

[0090] Where α represents the preset adjustment parameter.

[0091] S206: Update the active user set:

[0092] The active user set for each edge server j is calculated using the following formula. Update:

[0093]

[0094] In the above formula, This represents the cost of allocating resources for user i on edge server j, uc jBW s iBW This represents the cost of transmitting user i's data to edge server j. This represents the cost of transmitting the result generated from user i's data after it has been processed on edge server j to the cloud server. This represents the cost of transmitting user i's data directly to the cloud server via edge server j. It can be simply understood as the set of active users on edge server j. It consists of two types of users. The first type of users' bids are still enough to pay for their resource requirements to be allocated on edge server j. The second type of users' bids are still enough to support their data to be transmitted directly to the cloud for computing (instead of being executed on edge server j).

[0095] As shown in the formula above, after each resource unit price update, the set of active users on the edge server will be updated again based on user bids, resource unit prices, and deployment completion. This means that active users' bids must exceed the resource usage cost. Clearly, as the resource unit price on the edge server increases, the number of active users will decrease.

[0096] S207: Initialize resource allocation parameters:

[0097] Initialize resource allocation scheme set Resource usage price set Aggregate active users Let the computing resource capacity of each edge server j be c′ j =c j Cloud server bandwidth resources Bandwidth resources of edge server j The resource usage price for user i via edge server j served by cloud server The resource usage price for user i to upload the computation results to the cloud server after being served by edge server j. p max p represents the preset absolute maximum value. In this embodiment, p max =max(b i ).

[0098] S208: Ranking of Active Users:

[0099] Next, the active users in the active user set need to be sorted in descending order according to the norm of their resource demands, and then resources should be allocated according to this order to ensure that the reliability of the proof is not affected by the bids. Therefore, for the active user set... Each user i″ in The resource demand norm s is calculated using the following formula. i″ norm :

[0100]

[0101] active user set Users are sorted in descending order according to their resource demand norm, and the original index of the k-th user after sorting is denoted as i. k k = 1, 2, ..., K, where K represents the set of currently active users. The number of users in the game.

[0102] S209: Active User Resource Allocation:

[0103] Next, we need to analyze the active user set. In this invention, resources are allocated to each user in the manner that minimizes the cost among all feasible methods. Figure 3 This is a flowchart of the active user resource allocation process in this invention. For example... Figure 3 As shown, the specific steps for allocating active user resources in this invention include:

[0104] S301: Set user serial number k = 1.

[0105] S302: Obtain alternative allocation methods:

[0106] For each edge server j, if the user Then no action is taken if the user... There are two possible scenarios:

[0107] Determine if it satisfies and If so, it means user i k The resource usage price can be updated via the cloud server through the edge server j, using the following formula.

[0108]

[0109] If the above conditions are not met, no action will be taken.

[0110] Determine if it satisfies and This means that user i kThe edge server j can then upload the computation results to the cloud server, and the resource usage price can be updated using the following formula.

[0111]

[0112] If the above conditions are not met, no action will be taken.

[0113] S303: Filtering the optimal allocation method:

[0114] From user i k The lowest resource usage price is selected from all current resource usage prices and used as the price for user i. k payment price The minimum resource usage price corresponds to the edge server used by user i k Service edge server j k If the minimum resource usage price is through user i k If the result is generated by the edge server j and then uploaded to the cloud server, then user i... k Service logo Otherwise

[0115] S304: Determine if user i k payment price If so, it means that the current cloud-edge collaboration system's resources are insufficient for user i. k If resource allocation is performed, the allocation of resources to active users ends. If the allocation of resources to all active users fails, proceed to step S204 for a new round of allocation calculation; otherwise, proceed to step S305.

[0116] S305: Determine the current user resource allocation plan:

[0117] Let user i k and edge server j k Resource allocation identifier And As user i k The resource allocation scheme is added to the resource allocation scheme set. Immediately Set of payment prices

[0118] S306: Determine if k < K. If yes, proceed to step S307. Otherwise, it means that all users in the current active user set have been successfully allocated, the active user resource allocation is complete, and all active user resources have been successfully allocated.

[0119] S307: Updated resource quantity:

[0120] Since each user may be served by an edge server or transferred from an edge server to a cloud server for service, this invention uses the following method to update the resource quantity of the edge server and the cloud server:

[0121] If service identifier Then let

[0122] if Then let

[0123] S308: Set user number k = k + 1, and return to step S302.

[0124] S210: Determine whether all active users have successfully allocated resources. If not, return to step S204; otherwise, proceed to step S211.

[0125] S211: Obtain the resource allocation plan:

[0126] Based on the current set of resource allocation schemes Obtain each winning user and their resource allocation plan, based on the current set of payment prices. The winning user's payment price is obtained.

[0127] As described above, the auction process requires multiple rounds. In each round, the resource unit price increment is calculated based on the active users from the previous round, and the resource unit price is updated. The active user set is then updated based on the updated resource unit price. An attempt is made to allocate resources to users in the active user set. If the resource allocation is successful, the corresponding payment price is calculated. The resource allocation ends when all active users in the active user set in a given round can successfully allocate resources. Initially, although resource competition is fierce, resource prices are relatively low, and there are many active users, so resources cannot satisfy all active users, and some users will inevitably fail to allocate resources. As the resource unit price increases, some low-bid users become less active, reducing the intensity of resource competition, and the resource unit price stabilizes at a reasonable level. When all current active users can be allocated resources in a given round, the resource allocation ends, and the users' payment prices are calculated simultaneously. Intuitively, all active users successfully allocating resources is equivalent to the current resource unit price just enough to deplete some resources, achieving the goal of resource clearing. This is similar to the descending price auction concept, but the difference is that the price increase method can determine the unit price of different resources based on their scarcity, making it more reasonable and in line with reality. As seen in the allocation phase, this invention selects users according to a descending order of their resource demand norm. This parameter is independent of the user's bid, thus ensuring the mechanism's reliability. The user's payment price is the lowest among all feasible options in terms of resource usage cost. Similarly, to ensure the mechanism's reliability, since increasing a user's bid does not improve their final payment price (revenue remains unchanged), while decreasing their bid may lead to inactivity and reduced revenue, users have no incentive to misreport their bids, further guaranteeing the mechanism's reliability from the user's perspective.

[0128] Example

[0129] To better illustrate the implementation process of this invention, a specific example is used for experimental verification. In this experiment, it is assumed that the cloud-edge collaborative system has two edge computing servers, ECS 1 and ECS 2, with resources including CPU, memory, and storage, each with a resource capacity of (40, 40, 200) and a bandwidth of 3; simultaneously, the cloud server has a bandwidth of 5. There are currently 3 users in the system, and Table 1 is the user information table in this embodiment.

[0130] user Resource requirements Bandwidth requirements Deployment constraints bid Data compression rate 1 (4,4,3) 3 (1,0) 14 0.15 2 (3,3,2) 3 (1,1) 10 0.1 3 (3,4,3) 3 (0,1) 15 0.2

[0131] Table 1

[0132] As shown in Table 1, User 1's resource requirements are (4,4,3), which can be understood as needing 4 units of CPU, 4 units of memory, 3 units of storage, and a bandwidth requirement of 3. The deployment constraint (1,0) indicates that User 1 can only be deployed on the edge server ECS1. User 1's bid for resources and bandwidth is 14. If the data is executed on the edge server and then transmitted to the cloud, the data compression ratio is 0.15. Users 2 and 3 are similar.

[0133] In this embodiment, in order to converge as quickly as possible, the unit price growth step size ε = 0.2 is set, the parameter α = 1 is adjusted, and the user demand model s1 of user 1 is calculated according to formula (8). norm :

[0134]

[0135] Similarly, we can obtain the user demand model s2 for users 2 and 3. norm =0.503,s3 norm =0.504.

[0136] According to the method of the present invention, resource allocation will be attempted in the order of users 1, 3, 2. In the first round of calculation, the unit price of each resource on each server is calculated first. The unit price of the resource is initialized to 0, so all users are active users. According to the deployment constraints, for edge server ECS 1, its active users are users 1 and 2. According to formulas (4) and (5), the CPU unit price uc of edge server ECS 1 is calculated. 11 :

[0137]

[0138] Similarly, the unit price of memory for edge server ECS1 can be obtained. 12 =0.2 and storage unit price uc 13 =0.2, the unit price of bandwidth uc 1BW :

[0139]

[0140] Similarly, the unit price of each resource in ECS 2 can be obtained as (0.2, 0.2, 0.2), and the unit price of bandwidth in ECS 2 is also 0.54.

[0141] The unit price of bandwidth for the cloud server is calculated according to formula (6).

[0142]

[0143] In this round, all users are active, and the system cannot meet the resource needs of all users, so the next round begins. Table 2 shows the results of multiple rounds of resource allocation in this embodiment.

[0144]

[0145] Table 2

[0146] As shown in Table 2, the method of this invention will obtain the results in the third round. At this time, User 2 becomes an inactive user because the bid cannot meet the resource allocation under the current unit price, while the system can now satisfy the allocation for User 1 and User 3. Since User 1 can only be deployed on the edge server ECS1, if User 1 executes the task on the edge server ECS1, the resource usage price is (4+4+3)*0.6+3*1.63+3*1.96*0.15=12.372. If User 1 only transmits data to the cloud for execution through the edge server ECS1, the resource usage price is 3*1.63+3*1.96=10.76. Therefore, User 1 will choose the option with the lower resource usage price. When processing user 3's payment, since user 1 has already consumed 3 units of cloud bandwidth, leaving only 2 units of bandwidth remaining, user 3 can only execute the task on the edge server ECS2. Therefore, the resource usage price is (3+4+3)*0.6+3*1.63+3*1.96*0.2=12.07. In this example, the main resource competed for by users is bandwidth, and it can be seen that the bandwidth unit price increases rapidly, while other resources are sufficient from the beginning, hence their price increases slowly.

[0147] Although the illustrative specific embodiments of the present invention have been described above to enable those skilled in the art to understand the invention, it should be understood that the invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the invention as defined and determined by the appended claims, and all inventions utilizing the concept of the present invention are protected.

Claims

1. A price self-balancing auction method in a cloud-edge collaborative environment, characterized in that, Includes the following steps: S1: The cloud-edge collaborative system contains a cloud server and M edge servers, set... Let R represent the set of edge servers, and let R be the number of different types of computing resources in the system. Let the set of resources be represented; let the bandwidth resources of the cloud server be denoted as... Let c be the computing resource capacity of each edge server j. j =(c j1 ,c j2 ,...,c jR ), c jr This represents the capacity of the r-th computing resource on each edge server j, where the bandwidth resource of edge server j is... S2: Let there be N users in the system, and set... Represents a set of users, and obtains the resource requirement information θ for each user i. i =(S i ,s iBW ,δ i ,σ i ,b i ), where S i =(s i1 ,s i2 ,...,s iR ) represents the resource demand vector of user i, s ir s represents the quantity of resource r that user i requires. iBW δ represents the bandwidth requirement of user i; i =(δ i1 ,δ i2 ,...δ im ) represents the resource deployment constraints for user i, δ ij =1 indicates that user i can be deployed on edge server j, δ ij =0 indicates that deployment is not possible; σ i This represents the data compression ratio of user i's task after it runs on the edge server and is uploaded to the cloud server. Its value range is σ. i ∈(0,1); b i This represents the bid made by user i for the resource request they have submitted; S3: Initialize the unit price uc for each resource on edge server j. jr =0, initialize the active user set of each edge server j. S4: Calculate the unit price increment parameter λ of the r-th computing resource on edge server j using the following formula. jr : Where e represents the natural constant; Similarly, the incremental unit price parameter λ of bandwidth resources on edge server j is calculated using the following formula. jBW : S5: Update the unit price of various computing resources on each edge server j using the following formula: uc jr =uc jr +λ jr e The unit price of bandwidth resources on each edge server j is updated using the following formula: uc jBW =uc jBW +λ jBW e The unit price of bandwidth resources on the cloud server is updated using the following formula: Where α represents the preset adjustment parameter; S6: The active user set for each edge server j is calculated using the following formula. Update: S7: Initialize the set of resource allocation schemes Resource usage price set Aggregate active users Let the computing resource capacity of each edge server j be c′ j =c j Cloud server bandwidth resources Bandwidth resources of edge server j The resource usage price for user i via edge server j served by cloud server The resource usage price for user i to upload the computation results to the cloud server after being served by edge server j. p max Indicates the preset absolute maximum value; S8: For the set of active users The resource demand norm s of user i″ is calculated according to the following formula. i″ norm : active user set Users are sorted in descending order according to their resource demand norm, and the original index of the k-th user after sorting is denoted as i. k k = 1, 2, ..., K, where K represents the set of currently active users. The number of users in; S9: For active user sets The resource allocation for users in the system is performed as follows: S9.1: Set user serial number k = 1; S9.2: For each edge server j, if the user Then no action is taken if the user... There are two possible scenarios: Determine if it satisfies and If so, it means user i k The resource usage price can be updated via the cloud server through the edge server j, using the following formula. If the above conditions are not met, no action will be taken; Determine if it satisfies and This means that user i k The edge server j can then upload the computation results to the cloud server, and the resource usage price can be updated using the following formula. If the above conditions are not met, no action will be taken; S9.3: From user i k The lowest resource usage price is selected from all current resource usage prices and used as the price for user i. k payment price The minimum resource usage price corresponds to the edge server used by user i k Service edge server j k If the minimum resource usage price is through user i k If the result is generated by the edge server j and then uploaded to the cloud server, then user i... k Service logo Otherwise S9.4: Determine if user i k payment price If so, it means that the current cloud-edge collaboration system's resources are insufficient for user i. k If resource allocation is performed, the allocation of resources to active users will end, and the allocation of resources to all active users will fail; otherwise, proceed to step S9.

5. S9.5: Allow user i k and edge server j k Resource allocation identifier And As user i k The resource allocation scheme is added to the resource allocation scheme set. Immediately Set of payment prices S9.6: Determine if k < K. If yes, proceed to step S9.

7. Otherwise, it means that all users in the current active user set have been successfully allocated, the active user resource allocation is complete, and all active user resources have been successfully allocated. S9.7: Update the resource quantity of edge servers and cloud servers: If service identifier Then let if Then let S9.8: Set user number k = k + 1, and return to step S9.2; S10: Determine whether all active users have successfully allocated resources. If not, return to step S4; otherwise, proceed to step S11. S11: Based on the current set of resource allocation schemes Obtain each winning user and their resource allocation plan, based on the current set of payment prices. The winning user's payment price is obtained.

Images