A cloud-edge collaborative task offloading method based on blockchain

Abstract

The present invention provides a cloud-edge collaborative task offloading method based on blockchain, including: constructing a network model and a computing model for cloud-edge collaboration; using the network model and the computing model as constraints, and establishing a dynamic resource allocation problem with the optimization goal of maximizing the weighted sum of system energy consumption and service delay; using the Markov decision method to solve the allocation problem and using the evolutionary game to optimize the data sharing strategy of each node in the network model, obtaining a local offloading computing and a cloud offloading computing resource allocation strategy, and allocating offloading tasks to local servers and cloud servers according to the resource allocation strategy. The present invention solves the problem that the computation offloading and service caching of the MEC system in the prior art have many repeated computations and data transmissions, resulting in high overall system computation delay and energy consumption, and the user's service request access speed and service waiting time are affected to a certain extent.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular to a cloud-edge collaborative task offloading method based on blockchain. Background Art

[0002] As more and more latency-sensitive and computationally intensive applications emerge in the fields of digitalization and intelligence (image recognition, machine decision-making, AR / VR, etc.), the demand for computing power of data processing systems has also increased. As a data processing system and technology that is geographically distributed and performs computing tasks close to users, edge computing (MEC) technology has the potential to expand computing power through continuous updates, iterations, and cross-integration. In order to match computing power with demand, edge systems must use more efficient and reasonable computing offloading and service caching strategies to reduce unnecessary waste of system computing power, that is, to reduce offloading costs and communication overhead; at the same time, if the edge system can effectively build a MEC system that collaborates with cloud platforms, edge servers, and device ends (cloud-edge-end collaborative MEC system), it can achieve maximum utilization of available network resources and reduce computing latency and energy consumption, thereby improving the data processing capabilities of edge systems. Therefore, in the face of complex, diverse, and intensive computing tasks, in order to expand the computing power of mobile devices and reduce task computing overhead, it is an effective solution to use reinforcement learning methods to jointly optimize computing offloading and service caching strategies in cloud-edge-end collaborative MEC systems.

[0003] In actual situations, edge nodes, as intelligent agents in collaborative systems, need to process huge amounts of data of different types. MEC systems require efficient and intelligent algorithms to train intelligent agents so that their data processing time converges to system requirements. In addition, due to the heterogeneity of user systems and complex network environments, the same service can be used by multiple edge devices. The computational offloading and service caching of the MEC system involve a lot of repeated computation and data transmission, resulting in high computational latency and energy consumption in the overall system. The user's service request access speed and service waiting time are affected to a certain extent. Summary of the invention

[0004] In view of the shortcomings existing in the prior art, the present invention provides a cloud-edge collaborative task offloading method based on blockchain, which solves the problems in the prior art that the MEC system's computation offloading and service cache contain a large number of repeated computations and data transmissions, resulting in high overall system computing latency and energy consumption, and the user's service request access speed and service waiting time are affected to a certain extent.

[0005] According to an embodiment of the present invention, a cloud-edge collaborative task offloading method based on blockchain includes:

[0006] Build a network model and computing model for cloud-edge collaboration;

[0007] With the network model and computational model as constraints, a dynamic resource allocation problem is established with the optimization objective of maximizing the weighted sum of system energy cost and service delay;

[0008] The Markov decision method is used to solve the allocation problem, and the evolutionary game is used to optimize the data sharing strategy of each node in the network model. The local offload computing and cloud offload computing resource allocation strategies are obtained, and the offload tasks are allocated to the local server and cloud server according to the resource allocation strategy.

[0009] Preferably, a blockchain model is constructed according to the network model, each MEC server in the network model serves as a node in the blockchain model, and the resource consumption in the consensus forwarding process of the blockchain model is used as a constraint condition.

[0010] Preferably, each MEC server acts as a node in the blockchain model;

[0011] The consensus forwarding process of the blockchain model includes:

[0012] S1: A node is randomly designated as the master node. Any edge node sends a consensus request to the master node, and then the master node packages the consensus request into a block.

[0013] S2: Generate replica nodes of all nodes, the master node generates the first verification information and broadcasts the block and the first verification information to all replica nodes;

[0014] S3: Generate second verification information based on all replica nodes that have passed the first verification information verification, and send the block and the second verification information to all other nodes;

[0015] S4: All other nodes generate their own third verification information and send the block and the third verification information to all other nodes;

[0016] S5: All other nodes that have passed the verification according to the first verification information send a Relay message to the edge node.

[0017] Preferably, the resource consumption of consensus forwarding in the blockchain model is as follows:

[0018]

[0019] Where λ is the probability that the replica node passes the verification of the first verification information, d(t) is the total block size in time slot t, y(t) represents the average size of the block, f is the threshold for the number of successful node verifications, m is the number of nodes, and δ 1 and δ 2 The number of CPU cycles to generate / verify the message authentication code and node signature respectively.

[0020] Preferably, the steps of solving the allocation problem using the Markov decision method include:

[0021] Construct the state space and action space of the system at discrete time t;

[0022] Construct a reward function using state space and action space as constraints;

[0023] The reward function is solved with the optimization objective of maximizing the weighted sum of system energy cost and service delay.

[0024] Preferably, the constraints are:

[0025]

[0026] Among them, ω 1 and ω 2 is the weight factor of total energy cost and total service delay, p u1 (t) and p u2 (t) is the transmission power allocated when two different MEC servers send data to the cloud server, p a (t) is the transmission power allocated when sending data from the MEC server to the device, p c (t) is the transmission power allocated when the cloud server sends data to the MEC server, b(t) is the block size level, T c (t) is the time delay of block completion, β is a constant greater than 1, i(t) is the block interval level, B u is the communication bandwidth between MEC server and cloud server, B a is the communication bandwidth between the MEC server and the device, B max The upper limit of the communication bandwidth.

[0027] Preferably, the steps of using evolutionary game to improve the shared expectations of each node in the network model include:

[0028] Construct a shared evolution model of nodes, and calculate the revenue growth rate between nodes participating in data sharing and those not participating in data sharing based on the shared evolution model;

[0029] Find the system equilibrium point when the revenue growth rate is 0, and adjust the sharing strategy of each node in the network model according to the system equilibrium point.

[0030] Preferably, the shared evolution model is composed of a quaternion array G=(P, N, S, U), where P is the node set of nodes participating in data sharing, N is the set of all nodes, S is the available strategy space of the node, and U is the payment matrix between two nodes;

[0031] The revenue growth rate between nodes participating in data sharing and those not participating in data sharing is calculated based on the payment matrix.

[0032] Preferably, all nodes participating in data sharing will be given dynamic incentive benefits.

[0033] On the other hand, the present invention also provides a cloud-edge collaborative task offloading model based on blockchain, which is applied to the above-mentioned cloud-edge collaborative task offloading method based on blockchain, including:

[0034] A network model and a computing model, wherein the network model includes a central cloud layer, multiple base stations, and multiple device terminals, each base station is equipped with an MEC server, the central cloud layer is communicatively connected to all base stations, and each base station is communicatively connected to at least one device terminal;

[0035] The calculation model is as follows:

[0036] Total system energy consumption:

[0037]

[0038] Total system delay:

[0039]

[0040] where e c (t) is the energy cost of local offloading, e s (t) is the energy cost of offloading to the cloud, e n (t) is the energy cost of serving cache, t c (t) is the delay of local unloading, t s (t) is the latency of cloud offloading, t n (t) is the latency of serving cache, F c is the CPU calculation frequency of the MEC server, F s Calculate the CPU frequency of the cloud server, t b is the broadcast delay between nodes.

[0041] Compared with the prior art, the present invention has the following beneficial effects:

[0042] (1) The Markov decision method is used to adjust the resource allocation strategy in the network model, and the blockchain-assisted network model is used to calculate offloading and resource allocation. The network model shares its own offloading strategy in the blockchain network. At the same time, the decentralized characteristics of the blockchain network also ensure the privacy of shared data. In addition, the blockchain consensus technology is used to share the cache service of all MEC servers, which can effectively avoid the same service consuming more communication and computing resources, and ultimately achieve the goal of efficient use of resource services and optimization of network energy efficiency.

[0043] (2) Use evolutionary game algorithms to establish incentive mechanisms and adjust the strategies of each node in the network model to participate in data sharing, so as to maximize the available computing resources in the entire network model while reducing latency and energy consumption and improving user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a flowchart of collaborative task offloading according to an embodiment of the present invention.

[0045] Figure 2 This is a diagram of the network model architecture of an embodiment of the present invention.

[0046] Figure 3 This is a PBFT consensus flow chart of an embodiment of the present invention.

[0047] Figure 4 This is a trend diagram of the ESS according to an embodiment of the present invention. DETAILED DESCRIPTION

[0048] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0049] like Figure 1 As shown, the embodiment of the present invention proposes a cloud-edge collaborative task offloading method based on blockchain, including:

[0050] Build a network model and computing model for cloud-edge collaboration;

[0051] like Figure 2 As shown, the network model of the present invention is divided into three layers, namely the central cloud layer, the edge server layer, and the device end layer. The central cloud layer contains a cloud server, the edge server layer contains m base stations, the device end layer contains multiple device ends, and each base station is equipped with an MEC server. The central cloud layer is communicatively connected to all base stations, and each base station is communicatively connected to at least one device end.

[0052] The set M = {1, 2, ..., m} represents the set of MEC servers, and the energy of the MEC server is V(t) = {v 1 (t),v 2 (t),...,v m (t)} is used to represent that in order to improve the data transmission rate of the communication model, the cloud-edge-end data transmission uses a 6G-oriented terahertz channel.

[0053] According to the defined cloud-edge path loss, the signal-to-noise ratio of the uplink communication channel between the central cloud layer and the edge server layer can be expressed as follows:

[0054]

[0055] Where P u(t) represents the transmission power from MEC server to cloud server, N 0 is the noise power received by the cloud server, G t1 (t) and G r1 (t) are the transmit antenna gain and the receive antenna gain respectively. c1 represents the cloud-edge communication carrier frequency, l 1 Represents the distance from the MEC server to the cloud server. Therefore, the data transmission rate of the uplink channel from the MEC server to the cloud server can be expressed as:

[0056]

[0057] Among them B u Represents the communication bandwidth between MEC servers and cloud servers.

[0058] The uplink transmission delay from the central cloud layer to the edge server layer is expressed as follows:

[0059]

[0060] The uplink transmission power consumption from the central cloud layer to the edge server layer can be expressed as:

[0061]

[0062] When the service is cached from the cloud server to the MEC server, we need to obtain the cloud-edge downlink wireless data transmission rate.

[0063] According to the definition of path loss, the signal-to-noise ratio of downlink data transmission from the central cloud layer to the edge server layer can be expressed as follows:

[0064]

[0065] Where P c (t) represents the cloud-edge downlink transmission power, N r is the noise power received by the MEC server, and Represents the cloud-edge downlink transmit antenna gain and receive antenna gain.

[0066] Therefore, the data transmission rate of the downlink channel from the cloud server to the MEC server can be expressed as:

[0067]

[0068] The transmission delay from the central cloud layer to the edge server layer is expressed as follows:

[0069]

[0070] The transmission power consumption of the downlink from the central cloud layer to the edge server layer can be expressed as:

[0071]

[0072] Similarly, we need to derive the wireless data transmission rate from the MEC server to the device.

[0073] According to the defined edge-to-end downlink path loss, the signal-to-noise ratio of the downlink communication channel between the MEC server and the device can be expressed as follows:

[0074]

[0075] Where P a (t) represents the edge-to-end downlink transmission power, N u is the noise power received by the device, and They are the transmit antenna gain and the receive antenna gain respectively. represents the edge-to-end communication carrier frequency, l 2 Indicates the distance from the MEC server to the device.

[0076] Therefore, the data transmission rate of the MEC server-device downlink channel can be expressed as:

[0077]

[0078] Among them B a Represents the communication bandwidth between the MEC server and the device.

[0079] The transmission delay from MEC server to device downlink is as follows:

[0080]

[0081] The transmission power consumption of the MEC server-device downlink can be expressed as:

[0082]

[0083] The cache capacity of the MEC server distributed around the device is limited and can fully store the K popular contents provided by the cloud server. The cached content set can be expressed as k = {1, 2..., K}. The cloud server provides the content required by the device to the MEC server, and then forwards the content to the device through the MEC server. Assuming that the size of the content K cached by each MEC server is S bytes, the total cache capacity is K·S bits. The number of contents cached by the MEC server is always K. When the cloud server sends new content to the MEC server for cache storage, the old content will be deleted. The cloud server determines whether to cache the content in the MEC server based on the demand for content. The content delivery request set on the device is expressed as m = {1, 2,..., M}.

[0084] The preference of content can improve network cache performance and device satisfaction with data requests. When a content is prepared or stored in an MEC server, it can be used by other nearby requests, thereby reducing the cost of backhaul link transmission. Here, the preference of content m in the cloud server is expressed as, and a relationship is established between the preference of content and energy consumption. The higher the preference of content, the easier it is to be requested by the device, and the lower the energy consumption will be.

[0085] When the device side requests the content from the cloud server, the service cache delay and power consumption can be obtained according to the content preference from the cloud server-MEC server downlink and MEC server-device downlink transmission delay and power consumption expressions in the previous communication model part.

[0086]

[0087] φ m ∈[0,1],φ m =1 indicates that the service content has been cached in the MEC server in advance, φ m =0 indicates that the service content is not cached in advance to the MEC server.

[0088] The present invention introduces blockchain to ensure the security and reliability of data computing offloading and interaction processes, realizes data sharing, and all MEC servers equipped with base stations can be used as blockchain nodes in the blockchain network system. In actual scenarios, if the number of base stations increases or decreases, the blockchain nodes can also change accordingly. Using a deep reinforcement learning algorithm between each MEC server, the unchangeable training data collected by each MEC server can be recorded as a transaction and transmitted to the blockchain for information verification and consensus at each time slot t. For the blockchain system, there are M consensus nodes, denoted as M = {1,2,...,m}. Each MEC server will receive multiple computing tasks offloaded by mobile devices within its service coverage. By comprehensively considering the offloading decision, block interval and size, and transmission power, the system service delay and energy overhead are minimized. The wireless data transmission rate between the three-layer model is related to the path loss, and the path loss is related to the carrier frequency and distance. We define the path loss between the cloud server and the MEC server as The path loss between the MEC server and the device is: In order to better represent the transmission delay and transmission power consumption, we assume that D 1 (t),D 2 (t),D 3 (t) are the data size transmitted in each layer in time slot t

[0089] When the device uploads the task data to the blockchain node through a request at time slot t, the node can collect the corresponding data and package it into a transaction, and then send the transaction to the blockchain network for consensus. The PBFT smart consensus protocol is used at the consensus layer. According to the PBFT consensus rules, the effectiveness of the system can be guaranteed when the number of faulty nodes is less than m / 3. The block consensus process is divided into five stages. Figure 3 As shown:

[0090] (1) Request: Within a period of time, any edge node (any MEC server) submits a data consensus request to the blockchain system. The blockchain system randomly selects a node as the master node to verify the signature of the edge node. If valid, the message authentication code (MAC) will be verified. At the same time, the consensus request will be packaged into a new block by the master node. This process is executed in the block interval i(t). Assume that the number of CPU cycles required to generate / verify MAC and signature are denoted as δ 1 and δ 2 . Therefore, the CPU cycles consumed in this process are defined as follows:

[0091]

[0092] Where d(t) is defined as the total transaction batch size at time slot t, which depends on the block size. y(t) represents the average size of a transaction.

[0093] (2) Pre-prepare: Generate replica nodes for all nodes. At the same time, the master node broadcasts the signature block and generates (m-1) MACs and a signature for the replica nodes to verify. Each MAC and signature form the first verification information. As long as the above message sent by the master node is received, the replica node will first verify the MAC and signature of the block, and then check the MAC and signature of the transaction. The CPU cycles consumed in this process can be expressed as:

[0094]

[0095] where c 2m (t) and c 2r (t) are the computation cycles required by the master node and the replica node, respectively. In addition, λ represents the probability that the replica node successfully verifies the first verification information in the Request phase.

[0096] (3) prepare: The verified replica node generates (m-1) MACs and a signature (the MAC and signature are combined into the second verification information at this time) and sends them to all other nodes. After that, all MACs and signatures will be verified by the replica nodes and the master node. Once the number of failed verification nodes received is less than f = (m-1) / 3, it means that the fault tolerance point of the protocol has not been reached, and it enters the commit phase.

[0097] The CPU cycles consumed by the master node for verification in this process can be expressed as:

[0098] c 3m (t) = 2f·(δ 1 +δ 2 )

[0099] The CPU cycles consumed by the replica node for verification and generating MAC and signature are:

[0100] c 3r (t) = 2f·(δ 1 +δ 2 )+δ 2 +(m-1)·δ 1

[0101] (4) Commit: Different from the previous stage, all nodes will generate (m-1) MACs and a signature (the MAC and signature are combined into the third verification information) and pass them to all other blockchain nodes. If the number of wrong nodes is less than f, proceed to the next step.

[0102] The CPU cycles consumed in this phase are as follows:

[0103] c 4 (t) = 2f·(δ 1 +δ 2 )+δ 2 +(m-1)δ 1

[0104] (5) Relay: After verifying the submission message, each node sends a Relay message containing a MAC and a signature to the edge node. In addition, if the number of correctly verified nodes exceeds 2f, it means that the consensus process has been completed. Then, the valid block will be attached to the blockchain network.

[0105] The CPU cycles consumed in this process can be expressed as:

[0106] c 5 (t) = 2f·(δ 1 +δ 2 )+(δ 1 +δ 2 )

[0107] Based on the above analysis, the total CPU cycles consumed by a consensus process (total forwarding resource consumption) can be given by the following formula:

[0108]

[0109] Taking the blockchain consensus forwarding resource consumption and the maximum configuration resources of the MEC server as constraints, a dynamic resource allocation problem is established with the optimization goal of maximizing the weighted sum of system energy overhead and service delay;

[0110] When the performance meets the requirements, the device will directly process the task, but terminal devices often have problems such as excessive energy consumption, fast battery consumption and extended time. It is necessary to migrate the task data to the MEC server or cloud server for computing offload processing.

[0111] (1) Local offloading calculation model

[0112] If the MEC server chooses to process the computing task locally, the processing delay t generated by the MEC server in time slot t c (t) can be expressed as:

[0113]

[0114] Q(t) represents the CPU cycles consumed by executing the computing task in time slot t, and F c Indicates the CPU computing frequency of the MEC server.

[0115] The energy cost of MEC server can be expressed as:

[0116]

[0117] Among them, P c Indicates the computing power of the MEC server.

[0118] (2) Cloud Server Offloading Computation Model

[0119] If all MEC servers cannot process the unloaded data in time slot t, the system will offload the computing task to the cloud server for data processing. If the MEC system chooses the cloud server to perform the computing task, the delay and energy cost mainly come from the data transmission of the MEC server and the data processing of the cloud server. Therefore, the delay and energy cost of time slot t can be calculated as

[0120] and

[0121] Where D(t) is the data task size of time slot t, F s is the CPU computing frequency of the cloud server, P u is the transmission power between the edge server and the cloud server, P s is the computing power of the cloud server.

[0122] (3) MEC system latency and energy consumption

[0123] In addition, based on the total CPU cycles consumed by a consensus process, the service delay caused by the consensus process can be calculated as follows:

[0124]

[0125] Where i(t) represents the block interval, which is used to generate a new block. In addition, F = F s or F c , which depends on whether to choose MEC server or cloud server to handle consensus computing tasks. In addition, t b Indicates the broadcast delay between nodes.

[0126] In summary, the overall latency of the computation offloading and service cache of the entire computation model is expressed as follows:

[0127]

[0128] The total energy cost is expressed as follows:

[0129]

[0130] The Markov decision method is used to solve the allocation problem and obtain the local offload computing and cloud offload computing resource allocation strategies;

[0131] Considering the problem of computational offloading, a dynamic collaborative model needs to be established. First, the problem can be expressed as a Markov decision process (MDP). Then, the reinforcement learning method is used to deal with dynamic and complex optimization problems. In order to describe the optimization problem, a discrete MDP is established to optimize the system service delay and energy consumption, and the definitions of state space, action space and reward function are given. In this system, the MEC server not only has to perform a large number of heavy and complex computing tasks generated during the blockchain consensus process, but also has to decide on the computational offloading of a large number of uploaded tasks, which makes it difficult to accurately know the computing resources of the MEC server at the next moment. Therefore, the computing resources are represented as a random value η, η(t) represents the computing resources of the MEC server in time slot t, and the computing resource state of the MEC server is modeled as a finite state Markov process.

[0132] (1) State space

[0133] At each discrete time t, the agent in the MEC server first observes and perceives the state of the environment, then gains experience and updates the decision-making strategy by perceiving the state information of the environment. Let S(t) represent the state space at time t:

[0134]

[0135] where η(t) and Represent the available computing resources of MEC servers and cloud servers respectively. and It is the transmitting antenna gain and receiving antenna gain when the MEC server sends data to the cloud server. It is the transmit antenna gain and receive antenna gain when the cloud server sends data to the MEC server. It is the transmitting antenna gain and receiving antenna gain when the MEC server sends data to the cloud server.

[0136] (2) Action Space

[0137] In the entire system, the agent must dynamically adjust its behavior to maximize long-term benefits. Let the action space at decision time t be represented by a(t):

[0138] a(t)={γ(t),x n (t),i(t),b(t),p u (t),p a (t),p c (t)}

[0139] Where γ(t) represents the offloading decision, γ(t) = 0 means that the MEC server processes the computing task, γ(t) = 1 means that the MEC server offloads the computing task, x n(t) = {0,1} represents the cache decision of the service: x n (t) = 0, the service content is not cached in the edge server in advance, x n (t) = 1 service content has been cached to the edge server, b(t)∈{1,2,...,B} reflects the block size level, i(t)∈{0.2,0.5,...,i} represents the block interval level, p a (t) is the transmission power allocated when sending data from the MEC server to the device, p u (t) is the transmission power allocated when sending data from the MEC server to the cloud server, p c (t) is the transmission power allocated when the cloud server sends data to the MEC server.

[0140] (3) Reward Function

[0141] The optimization goal is to optimize the long-term system energy cost and service delay. Therefore, the optimization problem is to maximize the weighted sum of system energy cost and service delay through offloading decision, block interval and size and transmission power control. The proposed optimization problem is defined as:

[0142]

[0143] ω 1 and ω 2 are weight factors for energy cost and service delay, which should satisfy ω 1 +ω 2 = 1. Constraints C1-C3 are the transmission power range limits between the MEC server and the cloud server and the device end. 4 is the delay limit of block completion, where β>1. 5 Indicates the size limit of the data, and C6-C7 indicates the channel bandwidth limit of the data.

[0144] The reward function can be expressed as:

[0145]

[0146] θ represents the penalty value.

[0147] Evolutionary game is used to improve the data sharing strategy of each node in the network model.

[0148] Considering that the distributed offloading strategy training model must have the characteristics of dynamic changes and sharing of training results, although MDP gives the system model dynamic characteristics, the MEC server in the system will not actively share the training results. In order to realize the distributed MEC system of training sharing, this paper regards the MEC server as a training node, and uses evolutionary game to improve the sharing expectations of training nodes and encourage nodes to share training results. Nodes can only choose to participate or not to participate in training parameter sharing. The strategies of these two behaviors rely on the limited rationality of the nodes, and they continue to learn and gradually adjust their own strategies through trial and error. Therefore, the present invention models the game of node training parameter sharing through evolutionary game theory, and finds a method to adjust the node participation sharing expectations according to the current situation.

[0149] (1) Model establishment

[0150] The model is a symmetric MEC server participating in data sharing evolution model composed of a quaternion array G = (P, N, S, U), and the MEC server in this model is an intelligent edge node.

[0151] Among them, P represents a group consisting of multiple MEC servers (nodes participating in data sharing); N represents the set of all MEC servers; S represents the strategy space available to MEC servers; and U represents the payment matrix formed in a two-party game.

[0152] In this evolutionary game model, nodes can only choose to share training data or not to participate in sharing, so S = (S 1 ,S 2 ). 1 Indicates participation in sharing; S 2 Indicates not to participate in sharing.

[0153] In the data sharing game model, relevant data providers decide whether to participate in data sharing by calculating the sharing benefits and costs. The benefits of MEC servers can be divided into two categories: direct benefits and collaborative benefits.

[0154] Direct benefits refer to the benefits that data providers can obtain. For the ith node, its direct benefits only represent the training parameters obtained through training on its own node. The direct benefits are recorded as the logarithmic function μln(1+R), where R is the direct benefit parameter and can be a suitable fixed value. μ represents the scaling factor. The logarithmic benefit function ln (logarithmic function with e as the base) is used to calculate the benefits. The function characteristics are consistent with the characteristics of real social economics, that is, benefits have certain growth inhibition. According to the rationality of reality, μln(1+R)>0 is required.

[0155] When nodes i and j participating in decision-making both choose to participate in data sharing, in this case, each node shares data and can also receive data shared by other nodes to help increase revenue. This kind of revenue is called collaborative revenue, denoted as kμln(1+R). According to the rationality analysis of the actual situation, the revenue coefficient of collaboration k>1, otherwise the node will have no motivation to share. In the data sharing stage, the MEC server node needs to spend a certain amount of data sharing cost, denoted as τ and the number of CPU cycles consumed in the blockchain consensus stage c t (t) relevant.

[0156] The goal of the incentive mechanism is to encourage more MEC servers to participate in data sharing. When the initial number of MEC servers participating in data sharing is too small, under the condition of fixed income, MEC servers may be more inclined not to participate in decision-making. Therefore, in order to encourage more participation of system members, the system is set up so that when the initial number of participating MEC servers is small, the data sharing blockchain platform can provide incentives for all MEC servers. Each node MEC server can get rewards from the blockchain system for participating in sharing its own training data. The dynamic reward income is represented by I.

[0157] (2) Payoff Matrix

[0158] Assuming that the MEC servers participating in the data sharing evolutionary game are A and B, the decision-making of the two MEC servers can be divided into the following three categories. The first is that both A and B participate in data sharing. In this case, the profit formula for both A and B is kμln(1+R)+I A -τ and kμln(1+R)+I B -τ. The second case is that neither A nor B participates in data sharing, and their benefits depend only on themselves, that is, direct benefits μln(1+R). The third case is that only one of A and B chooses to participate in data sharing. MEC servers that choose to participate in this strategy join the data sharing blockchain platform and share their own data, but cannot obtain data from other MEC servers, incurring additional costs without additional sharing benefits. Non-participating MEC servers do not pay any fees and do not gain any benefits. Therefore, when one MEC server chooses to participate in this strategy and the other MEC server chooses not to participate, the former's benefit is μln(1+R)+I A -τ or μln(1+R)+I B -τ. The latter's gain is μln(1+R).

[0159] Since the MEC server of the present invention can only choose to participate or not participate, the game process of MEC server A and MEC server B conforms to the "general two-person symmetric game". The payout matrix of the income is shown in Table 1:

[0160] Table 1. Payoff matrix

[0161]

[0162] (3) Copy the dynamic equation

[0163] Assume that in the set N of all MEC server nodes, the probability that each MEC server chooses to participate in the data sharing strategy is x. Therefore, the probability that a MEC server chooses not to participate in data sharing is 1-x, where x is a function of time t, xò[0,1]. If MEC server A wants to gain more benefits, it must participate. Then, A's benefit is x[kμln(1+R)+I A -τ]+(1-x)[μln(1+R)+I A -τ] where x[kμln(1+R)+I A -τ] is the benefit of MEC server A when B participates with probability x, (1-x)[μln(1+R)+I A -τ] is the payoff of MEC server A when B does not participate with probability 1-x. The case of MEC server B can be analyzed in the same way as MEC server A.

[0164] Based on the above analysis, we can get the MEC server p i Benefits of choosing a participation strategy during the data sharing decision-making phase:

[0165] u(s 1 ,x)=x[kμln(1+R)+I i -τ]+(1-x)[μln(1+R)+I i -τ]

[0166] The payoff of a MEC server that chooses not to participate in this strategy is expressed as:

[0167] u(s 2 ,x)=x(μln(1+R))+(1-x)μln(1+R)

[0168] The average revenue of MEC servers is as follows:

[0169]

[0170] The dynamic equation for replication in the evolutionary game of MEC servers participating in data sharing is expressed as follows using the growth rate of the sharing strategy:

[0171]

[0172] (4) Stability analysis

[0173] The stability of the model is analyzed using the local stability analysis method. According to the stability theorem of the replication dynamic equation, by substituting the equilibrium point x into the replication dynamic equation, the stability strategy of the MEC server can be determined and analyzed. If F(x) = 0, the three stable states of the MEC server replication dynamic equation F(x) can be obtained: x 1 =0;x 2 =1;

[0174]

[0175] In the analysis based on the game evolutionary stable strategy (ESS) and the stability theorem, when there is a small disturbance in the dynamic system, the steady state should be stable, therefore, it should satisfy F′(x)<0, that is,

[0176] F'(x)=(1-2x)[x(k-1)μln(1+R)+I i -τ]+x(1-x)(k-1)μln(1+R)<0

[0177] The three stable points x 1 ,x 2 ,x 3 Substituting in the formula, we get the following:

[0178]

[0179] Analyze ESS from the following situations:

[0180] 1) Case 1: (τ-I i )>(k-1)μln(1+R). This condition means that the cost of MEC server participating in data sharing is higher than the benefit that can be obtained. At this time, F′(0)<0, F′(1)>0, x 3 does not exist. Therefore, x 1 It is the only evolutionary equilibrium point of the system. It is concluded that the final evolutionary strategy ESS of the system MEC server does not participate in data sharing.

[0181] 2) Case 2: 0<(τ-I i )<(k-1)μln(1+R). This condition means that the collaborative benefits that the MEC server can obtain from participating in data sharing are higher than the participation cost. At this time, F′(x 2 )<0,F′(x 1 )<0,F′(x 3 )>0. Therefore, x 1 and x 2 is the evolutionary equilibrium point of the system. The final decision of the system MEC server will depend on the proportion of MEC servers initially participating in data sharing in the model x * When x * <x3 When x * >x 3 , the strategy tends to be a participation strategy.

[0182] 3) Case 3: (τ-I i )<(k-1)μln(1+R) and I i -τ>0. Under this condition, F′(x 2 )<0,F′(x 1 )>0,F′(x 3 )<0, and x 3 <0 does not exist. Therefore, x 2 It is the evolutionary equilibrium point of the system. MEC servers will eventually choose to participate in data sharing.

[0183] The above analysis shows the evolution and stability trend of data sharing. The choice of strategy by MEC servers will affect the evolution stability. ESS depends on the benefits obtained from MEC server data sharing and the proportion of MEC servers involved in the initial state of the system. Figure 4 The evolution trends under different conditions are summarized.

[0184] The total benefit of the participants is related to the participation cost τ, the direct benefit parameter R and the dynamic incentive benefit I. In the case that the MEC server can allocate fixed benefits, the dynamic incentive benefit is the key factor to increase the participation ratio of the system MEC server. Based on the above stability analysis, the threshold It can be used to motivate MEC servers to participate in data sharing. i The value range of is:

[0185] I i >τ-(k-1)x * μln(1+R)

[0186] In order to encourage MEC servers to participate in data sharing, the following strategy can be used: When the initial proportion of MEC servers participating in data sharing is less than x 3 When the participation rate exceeds the threshold, the incentive income I is increased to improve the participation rate. When the participation rate exceeds the threshold, there is no need to increase it. Therefore, the system can achieve an increase in the participation rate.

[0187] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solution of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solution of the present invention, which should be included in the scope of the claims of the present invention.

Claims

1. A cloud-edge collaborative task offloading method based on blockchain, characterized by: include: Build a network model and computing model for cloud-edge collaboration; With the network model and computational model as constraints, a dynamic resource allocation problem is established with the optimization objective of maximizing the weighted sum of system energy cost and service delay; The Markov decision method is used to solve the allocation problem, and the evolutionary game is used to optimize the data sharing strategy of each node in the network model. The local offload computing and cloud offload computing resource allocation strategies are obtained, and the offload tasks are allocated to the local server and cloud server according to the resource allocation strategy.

2. A cloud-edge collaborative task offloading method based on blockchain as claimed in claim 1, characterized in that: The blockchain model is constructed according to the network model. Each MEC server in the network model serves as a node in the blockchain model, and the resource consumption in the consensus forwarding process of the blockchain model is used as a constraint.

3. A cloud-edge collaborative task offloading method based on blockchain as claimed in claim 2, characterized in that: The consensus forwarding process of the blockchain model includes: S1: A node is randomly designated as the master node. Any edge node sends a consensus request to the master node, and then the master node packages the consensus request into a block. S2: Generate replica nodes of all nodes, the master node generates the first verification information and broadcasts the block and the first verification information to all replica nodes; S3: Generate second verification information based on all replica nodes that have passed the first verification information verification, and send the block and the second verification information to all other nodes; S4: All other nodes generate their own third verification information and send the block and the third verification information to all other nodes; S5: All other nodes that have passed the verification according to the first verification information send a Relay message to the edge node.

4. A cloud-edge collaborative task offloading method based on blockchain as claimed in claim 3, characterized in that: The resource consumption of consensus forwarding in the blockchain model is as follows: Where λ is the probability that the replica node successfully verifies the first verification information, d(t) is the total block size in time slot t, y(t) represents the average size of the block, f is the threshold for the number of successful node verifications, m is the number of nodes, δ1 and δ2 are the number of CPU cycles for generating / verifying the message authentication code and node signature, respectively.

5. The cloud-edge collaborative task offloading method based on blockchain as claimed in claim 1, characterized in that: The steps to solve the allocation problem using the Markov decision method include: Construct the state space and action space of the system at discrete time t; Construct a reward function using state space and action space as constraints; The reward function is solved with the optimization objective of maximizing the weighted sum of system energy cost and service delay.

6. A cloud-edge collaborative task offloading method based on blockchain as claimed in claim 1, characterized in that: The constraints are: C1:p u1 (t)∈(0,P max ] s.t.C2:p u2 (t)∈(0,P max ] C3:p c (t)∈(0,P max ] C4:T c (t)≤β×i(t) C5:d(t)≤b(t) C6:B u ≤B max C7:B a ≤B max Where ω1 and ω2 are the weight factors of total energy cost and total service delay, p u1 (t) and p u2 (t) is the transmission power allocated when two different MEC servers send data to the cloud server, p a (t) is the transmission power allocated when sending data from the MEC server to the device, p c (t) is the transmission power allocated when the cloud server sends data to the MEC server, b(t) is the block size level, T c (t) is the time delay of block completion, β is a constant greater than 1, i(t) is the block interval level, B u is the communication bandwidth between MEC server and cloud server, B a is the communication bandwidth between the MEC server and the device, B max The upper limit of the communication bandwidth.

7. A blockchain-based cloud-edge collaborative task offloading method as claimed in claim 1, characterized in that: The steps of using evolutionary game to optimize the sharing strategy of each node in the network model include: Construct a shared evolution model of nodes, and calculate the revenue growth rate between nodes participating in data sharing and those not participating in data sharing based on the shared evolution model; Find the system equilibrium point when the revenue growth rate is 0, and adjust the sharing strategy of each node in the network model according to the system equilibrium point.

8. A cloud-edge collaborative task offloading method based on blockchain as claimed in claim 7, characterized in that: The shared evolution model is composed of a quaternion array G=(P, N, S, U), where P is the node set of nodes participating in data sharing, N is the set of all nodes, S is the available strategy space of the node, and U is the payment matrix between two nodes; The revenue growth rate between nodes participating in data sharing and those not participating in data sharing is calculated based on the payment matrix.

9. A cloud-edge collaborative task offloading method based on blockchain as claimed in claim 8, characterized in that: All nodes participating in data sharing will be given dynamic incentive benefits.

10. A cloud-edge collaborative task offloading model based on blockchain, characterized by: The model is applied to a cloud-edge collaborative task offloading method based on blockchain as described in any one of claims 1 to 9, including: A network model and a computing model, wherein the network model includes a central cloud layer, multiple base stations, and multiple device terminals, each base station is equipped with an MEC server, the central cloud layer is communicatively connected to all base stations, and each base station is communicatively connected to at least one device terminal; The calculation model is as follows: Total system energy consumption: Total system delay: where e c (t) is the energy cost of local offloading, e s (t) is the energy cost of offloading to the cloud, e n (t) is the energy cost of serving cache, t c (t) is the delay of local unloading, t s (t) is the latency of cloud offloading, t n (t) is the latency of serving cache, F c is the CPU calculation frequency of the MEC server, F s Calculate the CPU frequency of the cloud server, t b is the broadcast delay between nodes.

Images