CN116828226A - Cloud edge end collaborative video stream caching system based on block chain - Google Patents

Abstract

The invention belongs to the field of edge caching technology in mobile communications. It discloses a cloud-edge-end collaborative video stream caching system based on blockchain, and realizes communication between a CDN server, an edge server, and a video user through a network module; the caching module is used It is used to calculate the popularity of video content, as well as the access delay, traffic cost and cache energy consumption when video content is cached at the CDN server layer and edge server layer; and minimize the content access delay, traffic cost and energy consumption of all video requests. ization; the blockchain module is used to calculate the energy consumption generated by uploading paid video content requested by video users. This invention gives full play to the computing and storage capabilities of the edge-side MEC server and adds blockchain technology to solve the problems of delay and excessive energy consumption caused by the substantial increase in Internet video traffic and the security of billing information; realizing collaborative edge cache.

Description

Cloud-edge collaborative video stream caching system based on blockchain

Technical Field

The present invention belongs to the field of edge caching technology in mobile communications, and specifically relates to a cloud-edge collaborative video stream caching system based on blockchain.

Background Art

With the explosive growth in the number of mobile devices, a large number of devices are connected and generate huge data traffic. At the same time, users' requirements for the quality of experience (QoE) of various video content are gradually increasing. Therefore, such large-scale video traffic and high QoE requirements have brought huge pressure to the backbone network.

Video content caching is widely used in content delivery networks (CDNs) to reduce duplicate traffic and improve QoE. However, the traffic between CDN servers and user terminals may still be largely redundant, and most content does not have to be uploaded to cloud data centers because only a small portion of content is frequently requested, which will lead to poor QoE and large content access latency. Fortunately, mobile edge computing (MEC) provides another solution, which makes up for the shortcomings of CDN by pushing video content closer to end users for edge caching. In the emerging 5G network, base stations (BSs) are equipped with edge servers to provide storage and computing capabilities for caching services. By caching appropriate video content at the edge of nearby base stations, users can obtain the corresponding target video locally instead of from remote CDN servers, which not only provides better QoE and lower latency, but also relieves the traffic pressure on the backbone network.

Compared with CDN servers, the video cache capacity of edge servers is limited; most current content providers use simple rule-based cache strategies, such as Least Recently Used (LRU), Least Frequently Used (LFU), etc. However, unlike the cache environment based on CDN servers, the edge cache environment is more complex. Different edge areas have diverse and dynamic video requests. Neighboring base stations need to use collaborative edge caches to better bear the limited storage capacity on a single edge server. Therefore, traditional cache strategies are no longer suitable for dynamic and complex edge cache environments.

The increasing demand for video services from users has generated more payment content, so the security and privacy of billing data must be protected. However, since different base stations (BSs) are operated by different vendors, there are trust issues in the data interaction between base stations. The mobility of user equipment makes the billing information returned by the base station to the user more vulnerable to leakage or manipulation.

Summary of the invention

In order to solve the above technical problems, the present invention provides a cloud-edge collaborative video stream caching system based on blockchain, which fully utilizes the computing and storage capabilities of the edge server and adds blockchain technology to solve the problems of latency and excessive energy consumption caused by the substantial growth of Internet video traffic and the problem of billing information security, and realizes collaborative edge caching.

The cloud-edge-end collaborative video stream caching system based on blockchain described in the present invention includes a network module, a cache module and a blockchain module;

The network module includes a CDN server layer, an edge server layer and a video user layer; the CDN server layer stores all video content and provides computing resources for the edge server layer; the video user layer sends a video request to the edge server layer and receives the video returned by the edge server layer;

The cache module includes a video content popularity calculation unit, an access delay calculation unit, a traffic cost calculation unit, and a cache energy consumption calculation unit, which are respectively used to calculate the popularity of the video content, and the access delay, traffic cost, and cache energy consumption when the video content is cached in the CDN server layer and the edge server layer; and minimize the content access delay, traffic cost, and energy consumption problems of all video requests;

For the paid video content generated, the blockchain module is used to calculate the additional energy consumption generated by putting the paid video content requested by the video user on the chain.

Furthermore, the edge server layer includes base stations and MEC servers; the base stations cover all MEC servers in the local area, and use microwaves to achieve data transmission between the base stations and MEC servers, and achieve coverage through the 5G network. Each base station is connected to the remote CDN server through the backbone network;

The edge server layer responds to the request of the video user layer by: Internal video content The number of requests is expressed as , binary variable Used to indicate a period of time Internal video content Whether the request should be served by the current MEC server; Indicates the time period Video content The request should be served by the current MEC server; Indicates that there is no video content on the current MEC server , then the service is provided by the adjacent MEC server or the remote CDN server; , Refers to caching video content MEC server or CDN server, Indicates the MEC server. Indicates the CDN server; in addition, using binary variables To represent the video content Is it cached on the server? middle, Indicates video content Cache on the server middle; Indicates video content Not cached on the server middle.

Furthermore, the video user layer is composed of several video users; it is assumed that all video content files have the same unit size, which is S bits; it is stipulated that each user video request belongs to a specific edge area, and will be served by the base station and MEC server in the specific edge area, so the request of each video user is equivalently aggregated to its corresponding base station and MEC server.

Furthermore, the specific steps of calculating popularity using the video content popularity calculation unit are as follows:

S1-1, sorting the video contents requested by the video users in descending order of popularity, , Indicates video content The popularity of , K represents the number of videos; Indicates Video content has the highest popularity; Indicates The video content has the lowest popularity; and the video popularity follows a decay parameter Zipf distribution, that is, the popularity of the video has periodic changes;

S1-2. Calculating video content Request probability:

;

in, It is the content request coefficient that controls the popularity of video content. The larger the coefficient is, the higher the reuse rate of video content is.

Furthermore, the specific steps of using the access delay calculation unit to calculate the access delay are as follows:

S2-1, when a video request arrives, if the cached video content is found in the local MEC server, the local MEC server immediately returns the cached content, i.e., local hit;

S2-2, if the local MEC server cache does not hit, then turn to its neighboring MEC server to obtain the corresponding cache content, and if the content exists, return the content, that is, neighbor hit;

S2-3, if the adjacent hit does not hold, the local MEC server obtains the video content from the CDN server to serve the relevant cache request, i.e., CDN hit;

In the edge cache environment, there are three components of delay, depending on the different cache hit situations, including the delay from the video user layer to the edge server layer, the delay between edge server layers, and the delay from the edge server layer to the CDN server layer. Since the delay from the video user layer to the edge server layer is included in all requests, this delay is ignored for the convenience of calculation. Therefore, the time period Total transmission waiting time of MEC servers within It is expressed as:

,

in, Indicates the current MEC server and another server The waiting time between Represents a collection of video content; Indicates the adjacent MEC server; Indicates time period Internal video content The number of requests.

Furthermore, the specific steps of using the traffic cost calculation unit to calculate the traffic cost are as follows:

S3-1. For the video access traffic cost, ignore the cost from the video user layer to the edge server layer and calculate the video access traffic cost. for:

,

in, Indicates the current MEC server and other servers The communication cost between

S3-2. At the end of each cache cycle, if the video to be cached at the next moment is not exactly the same as the currently cached video, each MEC server needs to obtain a new video from a neighboring MEC server or CDN server, which will also introduce additional traffic costs. This cost is expressed as the video replacement traffic cost. , calculated as:

,

in Indicates the video content to be cached by the current MEC server at the next moment. Indicates the video content cached by the current MEC server at the current moment;

S3-3, the total flow cost expression is:

.

Furthermore, the specific steps of calculating cache energy consumption using the cache energy consumption calculation unit are as follows:

S4-1. When a video user requests video content in the CDN server layer If the video content Has been sent to the MEC server by the CDN server, then the video content The content is sent from the MEC server to the video user layer, that is, local hits or neighboring hits; only the transmission process of the content from the edge server layer to the video user layer via the wireless downlink channel is considered, in the time period The available downlink transmission rates are:

,

in, Indicates the transmit power of the MEC server. It is in the time period Internal video users With MEC server The channel gain between is the noise variance at the video user;

Therefore, by Send video content stored at the edge The energy consumption is expressed as:

,

Among them, all video content files have the same unit size, which is S bits; Indicates the transmit power of the MEC server; Indicates the available downlink transmission rate;

S4-2. If the video content Not yet stored on the MEC server In the MEC server The requested content will be obtained from the CDN server, and then the MEC server will send the video content Sent to the video user layer, i.e. CDN hit;

The more popular the video content is, the more likely it is to be requested by users, which will affect the energy consumption of the system; establish a relationship between the popularity of video content and energy consumption;

Assume that from the MEC server To CDN server The round-trip time for sending the received user request and returning the requested video content is Therefore, combined with the popularity of video content, Send video content that is not stored in the edge server layer The energy consumption is expressed as:

,

in, Indicates the transmission power between the edge server and the CDN server; Indicates that from the MEC server To CDN server Send the received user request and return the round-trip time of the requested video content;

S4-3. Consider transmitting all There are two cases of video content, and the energy consumption of this process is defined as:

,

in , Indicates video content Already cached at the edge server layer; Indicates video content Not cached at the edge server layer;

S4-4. If the requested video content is paid video content, the blockchain module is used to calculate the energy consumption of the consensus mechanism. ;

S4-5. Calculate the total energy consumption as:

.

Furthermore, for the blockchain module, all MEC servers are considered as blockchain nodes; for each time slot, when a video user requests delay-insensitive billing video content from a MEC server, each MEC server will collect the transaction data provided by the CDN server to the video user layer and send it to the blockchain system for transaction data verification and accounting; after the consensus process is completed, each MEC server will send the billing result to the video user for inspection and payment;

When the number of failed nodes is less than When using the PBFT mechanism to ensure the authenticity of the data, it is assumed that the generation or verification of the signature and the message authentication code MAC requires and CPU cycles, the PBFT consensus process includes the following steps:

S5-1, request phase: During each time slot, the CDN server uploads the billing video content bill to the MEC server. Each MEC server Broadcast the collected transaction information to the entire network; the master node is randomly assigned by the blockchain system based on the time exceeded for packaging. and maximum chunk size Pack the transaction information into a new block; then verify the signature and MAC on the master node; this process calculates the cycle It is expressed as:

,

in, represents the total transaction size in the block, Indicates the average size of a transaction;

S5-2, Pre-preparation phase; After all transactions are verified, the master node will discard the erroneous transactions collected by the MEC server and generate independent signatures and MACs will be sent to each secondary node together with the new block; if the secondary node receives this new block, the signature and MAC will be verified; the calculation cycle in this process is expressed as:

,

,

in, Indicates the percentage of correct transactions received via the MEC server; Indicates the masternode settlement cycle, Indicates the calculation period of the secondary node;

S5-3, preparation phase; if the new block and transaction have been verified, the secondary node generates a signature and MACs and send them to other blockchain nodes; each node then needs to receive and verify signatures and MACs, where ; Therefore, for the primary node and the secondary node, the calculation cycle of the process is expressed as:

,

;

S5-4, confirmation phase; if the verified node receives A correct message will be sent with a signature and MAC to other nodes; at the same time, each node must check signatures and MACs; therefore, for the master node and the slave node, the calculation formula for the calculation cycle is:

;

S5-5, reply phase; verification nodes collect After a valid confirmation message is sent to the master node, Signature and MAC reply message, the master node needs to check signatures and MACs; the calculation cycle is calculated as:

,

;

During the consensus process, all nodes need to verify signatures and MACs, which requires more computing resources to complete these computing tasks; therefore, nodes can choose MEC servers or CDN servers to perform computing tasks; moreover, each node chooses the computing method according to its own computing power requirements;

when When one node performs computing tasks through the CDN server and the other nodes select the MEC server, the total computing cycle is as follows:

,

The energy consumption of the blockchain consensus part is calculated as follows:

,

in, Indicates the transmission rate between the MEC server and the CDN server. Indicates the computing power of the CDN server. Indicates the computing power of the MEC server. Indicates the computing power of the CDN server. Indicates the computing power of the CPU processor chip.

Furthermore, we minimize the content access delay, traffic cost, and energy consumption of all video requests and formulate the problem as follows:

,

in, is a weighting factor used to adjust the preference between latency, traffic cost, and power consumption; constraint P1 ensures that each request will be served by only one MEC or CDN server; constraint P2 indicates that the storage usage of each MEC server should not exceed the storage capacity limit ; Constraint P3 ensures that video user requests can only be served by MEC or CDN servers that cache the corresponding video content; Constraints P4 and P5 restrict the optimization variables to binary values.

The beneficial effects described in the present invention are as follows: the system described in the present invention aims to minimize access delay, traffic cost and cache energy consumption, so as to solve the problems of delay and excessive energy consumption caused by the substantial growth of Internet video traffic; give full play to the computing and storage capabilities of the edge-side MEC server, and give the MEC server intelligent decision-making capabilities; add blockchain technology to solve the security issues of paid video content; fully consider the three service hit situations of local hit, neighboring hit and CDN hit, reduce the CDN server load, and realize collaborative edge caching.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is an architecture diagram of a cloud-edge-end collaborative video stream caching system based on blockchain according to the present invention;

Fig. 2 is a schematic diagram of a cache module framework;

Figure 3 is a diagram of the PBFT consensus process;

Figure 4 is a system framework diagram;

FIG5 is a flow chart of system operation.

DETAILED DESCRIPTION

In order to make the contents of the present invention more clearly understood, the present invention is further described in detail below based on specific embodiments in conjunction with the accompanying drawings.

The cloud-edge-end collaborative video stream caching system architecture based on blockchain of the present invention is shown in FIG1 and FIG4, including a network module, a cache module and a blockchain module; the network module includes a CDN server layer, an edge server layer and a video user layer;

For the CDN server layer, assuming that the CDN server has sufficient storage capacity and has the video content for all video requests, the CDN server layer is also used to provide more computing resources to the edge server layer;

For the edge server layer, the edge server layer includes base stations and MEC servers; MEC servers provide storage capacity for video caching and computing power for caching decisions, and each MEC server has a maximum storage capacity; each base station serves local video requests within its coverage area; each base station is connected to the remote CDN server through the backbone network; in the 5G network, the base station can communicate with other adjacent base stations, and each base station does not work alone. In addition, each base station can retrieve the requested video content from the adjacent base station through the forward link, such as using the high-bandwidth and low-latency CPRI link for data transmission.

The edge server layer responds to the request of the video user layer by: Internal video content The number of requests is expressed as , binary variable Used to indicate a period of time Internal video content Whether the request should be served by the current MEC server; Indicates the time period Video content The request should be served by the current MEC server; Indicates that there is no video content on the current MEC server , then the service is provided by the adjacent MEC server or the remote CDN server; , Refers to caching video content MEC server or CDN server, Indicates the MEC server. Indicates the CDN server; in addition, using binary variables To represent the video content Is it cached on the server? middle, Indicates video content Cache on the server middle; Indicates video content Not cached on the server middle.

For the video user layer, it is composed of video users; it is assumed that all video content files have the same unit size, which is S bits; it is stipulated that each user video request belongs to a specific edge area and will be served by the base station and MEC server therein, so each video user request is equivalently aggregated to its corresponding base station and MEC server.

For the blockchain layer, all MEC servers are regarded as blockchain nodes to protect the security of user paid video data.

As shown in FIG. 2 , the cache module includes a video content popularity calculation unit, an access delay calculation unit, a traffic cost calculation unit, and a cache energy consumption calculation unit.

The specific steps of the video content popularity calculation unit are as follows:

S1-1, sorting the video contents requested by the video users in descending order of popularity, , Indicates video content The popularity of , K represents the number of videos; Indicates Video content has the highest popularity; Indicates The video content has the lowest popularity; and the video popularity follows a decay parameter Zipf distribution, that is, the popularity of the video has periodic changes;

S1-2. Calculating video content Request probability:

;

in, It is the content request coefficient that controls the popularity of video content. The larger the coefficient is, the higher the reuse rate of video content is.

The specific steps of calculating the access delay unit are as follows:

S2-1, when a video request arrives, if the cached video content is found in the local MEC server, the local MEC server immediately returns the cached content, i.e., local hit;

S2-2, if the local MEC server cache does not hit, then turn to its neighboring MEC server to obtain the corresponding cache content, and if the content exists, return the content, that is, neighbor hit;

S2-3, if the adjacent hit does not hold, the local MEC server obtains the video content from the CDN server to serve the relevant cache request, i.e., CDN hit;

In the edge cache environment, there are three components of delay, depending on the different cache hit situations, including the delay from the video user layer to the edge server layer, the delay between edge server layers, and the delay from the edge server layer to the CDN server layer. Since the delay from the video user layer to the edge server layer is included in all requests, this delay is ignored for the convenience of calculation. Therefore, the time period Total transmission waiting time of MEC servers within It is expressed as:

,

in, Indicates the current MEC server and another server The waiting time between Represents a collection of video content; Indicates the adjacent MEC server; Indicates time period Internal video content The number of requests.

The specific steps of the traffic cost calculation unit are as follows:

S3-1. For the video access traffic cost, ignore the cost from the video user layer to the edge server layer and calculate the video access traffic cost. for:

,

in, Indicates the current MEC server and other servers The communication cost between

S3-2. At the end of each cache cycle, if the video to be cached at the next moment is not exactly the same as the currently cached video, each MEC server needs to obtain a new video from a neighboring MEC server or CDN server, which will also introduce additional traffic costs. This cost is expressed as the video replacement traffic cost. , calculated as:

,

in Indicates the video content to be cached by the current MEC server at the next moment. Indicates the video content cached by the current MEC server at the current moment;

S3-3, the total flow cost expression is:

.

The specific steps of calculating the cache energy consumption unit are as follows:

S4-1. When a video user requests video content in the CDN server layer If the video content Has been sent to the MEC server by the CDN server, then the video content The content is sent from the MEC server to the video user layer, that is, local hits or neighboring hits; only the transmission process of the content from the edge server layer to the video user layer via the wireless downlink channel is considered, in the time period The available downlink transmission rates are:

,

in, Indicates the transmit power of the MEC server. It is in the time period Internal video users With MEC server The channel gain between is the noise variance at the video user;

Therefore, by Send video content stored at the edge The energy consumption is expressed as:

;

S4-2. If the video content Not yet stored on the MEC server In the MEC server The requested content will be obtained from the CDN server, and then the MEC server will send the video content Sent to the video user layer, i.e. CDN hit;

In addition, using content popularity can greatly improve network cache performance and video users' satisfaction with data requests. When video content has been stored in an MEC server, it can be requested by neighboring MEC servers, thereby reducing the cost of backhaul transmission; establishing a connection between content popularity and energy consumption, the more popular the video content, the easier it is to be requested by users, which will affect the generation of system energy consumption;

Assume that from the MEC server To CDN server The round-trip time for sending the received user request and returning the requested video content is Therefore, combined with the popularity of video content, Send video content that is not stored in the edge server layer The energy consumption is expressed as:

,

in, Indicates the transmission power between the edge server and the CDN server;

S4-3. Consider transmitting all There are two cases of video content, and the energy consumption of this process is defined as:

,

in , Indicates video content Already cached at the edge server layer; Indicates video content Not cached at the edge server tier.

As shown in Figure 3, the PBFT consensus process: For the blockchain layer, all MEC servers are considered blockchain nodes. For each time slot, when the video user requests delay-insensitive billing video content from the MEC server, each MEC server will collect the transaction data provided by the CDN server to the video user layer and send it to the blockchain system for transaction data verification and accounting. After the consensus process is completed, each MEC server sends the billing result to the video user for inspection and payment.

When the number of failed nodes is less than When using the PBFT mechanism to ensure the authenticity of the data, it is assumed that the generation or verification of the signature and the message authentication code MAC requires and CPU cycles, the PBFT consensus process includes the following steps:

S5-1, request phase: During each time slot, the CDN server uploads the billing video content bill to the MEC server. Each MEC server Broadcast the collected transaction information to the entire network; the master node is randomly assigned by the blockchain system based on the time exceeded for packaging. and maximum chunk size Pack the transaction information into a new block; then verify the signature and MAC on the master node; this process calculates the cycle It is expressed as:

,

in, represents the total transaction size in the block, Indicates the average size of a transaction;

S5-2, Pre-preparation phase; After all transactions are verified, the master node will discard the erroneous transactions collected by the MEC server and generate independent signatures and MACs will be sent to each secondary node together with the new block; if the secondary node receives this new block, the signature and MAC will be verified; the calculation cycle in this process is expressed as:

,

,

in, Indicates the percentage of correct transactions received via the MEC server;

S5-3, preparation phase; if the new block and transaction have been verified, the secondary node generates a signature and MACs and send them to other blockchain nodes; each node then needs to receive and verify signatures and MACs, where ; Therefore, for the primary node and the secondary node, the calculation cycle of the process is expressed as:

,

;

S5-4, confirmation phase; if the verified node receives A correct message will be sent with a signature and MAC to other nodes; at the same time, each node must check signatures and MACs; therefore, for the master node and the slave node, the calculation formula for the calculation cycle is:

;

S5-5, reply phase; verification nodes collect After a valid confirmation message is sent to the master node, Signature and MAC reply message, the master node needs to check signatures and MACs; the calculation cycle is calculated as:

,

;

During the consensus process, all nodes need to verify signatures and MACs, which requires more computing resources to complete these computing tasks. Therefore, nodes can choose MEC servers or CDN servers to perform computing tasks; moreover, each node chooses a computing method based on its own computing power requirements. When one node performs computing tasks through the CDN server and the other nodes select the MEC server, the total computing cycle is as follows:

,

The energy consumption of the blockchain consensus part is calculated as follows:

,

in, Indicates the transmission rate between the MEC server and the CDN server. Indicates the computing power of the CDN server. Indicates the computing power of the MEC server. Indicates the computing power of the CDN server. Indicates the computing power of the CPU processor chip;

Therefore, the total energy consumption of this system is expressed as:

.

This system aims to minimize the content access delay, traffic cost and energy consumption of all video requests, and formulates the problem as follows:

,

in, is a weighting factor used to adjust the preference between latency, traffic cost, and power consumption; constraint P1 ensures that each request will be served by only one MEC or CDN server; constraint P2 indicates that the storage usage of each MEC server should not exceed the storage capacity limit ; Constraint P3 ensures that video user requests can only be served by MEC or CDN servers that cache the corresponding video content; Constraints P4 and P5 restrict the optimization variables to binary values.

The system operation process of the present invention is shown in Figure 5:

Step 1: Collect data; obtain the video content requests triggered by each video user in the coverage area of the edge cache system on the corresponding MEC server;

Step 2: Cache calculation: The cache module of the MEC server synchronously calculates the popularity of the requested video content, the access delay of the three hit states, the traffic cost, and the cache energy consumption;

Step 3: On-chain calculation: The blockchain module further calculates the additional energy consumption of the consensus part of the paid video content;

Step 4: Solve; jointly optimize access delay, traffic cost and energy consumption, model the optimization problem, and solve the optimization problem based on the MAPPO algorithm framework.

Step 5: Output cache decision; the system controls each MEC server to execute the corresponding action decision.

Based on step 4, the present invention establishes an edge caching strategy based on a multi-agent proximal strategy optimization algorithm structure, and the specific steps are as follows:

Step 4-1, strategy design;

The scenario of multi-agent reinforcement learning is set to minimize the access delay, traffic cost and energy consumption of the MEC server to obtain video content. In this system, the decisions made by each MEC server are based on obtaining smaller access delays, traffic costs and energy consumption for itself, and the actions made based on the decisions will cause environmental changes, which will affect the delay of other MEC servers obtaining content. Reinforcement learning abstracts the problem into a Markov process. The three most important elements in this process are state, action and reward. Action is the choice made by the MEC server in each task, state is the basis for making choices, and reward is the basis for evaluating whether the action is good or not.

The edge caching strategy based on multi-agent proximal strategy optimization proposed in the present invention is based on a partially observable Markov decision process; each MEC server can only observe its own video request content and the cache status of surrounding MEC servers; each MEC server can independently choose whether to cache the requested video content and the way to obtain the video request content according to its own observation results; there are three ways to request content, namely, local MEC server, neighboring MEC server and remote CDN server; the actions taken by each MEC server will affect the observation results of other MEC servers; the goal of this strategy is to minimize the access delay, traffic cost and energy consumption of the requested video content during the delivery process; in this strategy, the MEC server will obtain an immediate reward given by the system after taking an action in the time slot; if the video content request cannot obtain the requested content within the effective delay, the system will punish the MEC server; the reward of the MEC server is the weighted sum of all rewards obtained by the MEC server from a certain moment to the time when the reward is calculated, and the reward of the MEC server depends on all actions starting from this time slot.

Step 4-2: Train a distributed multi-agent proximal policy optimization framework; the method is as follows:

The multi-agent proximal policy optimization framework is based on a partially observable Markov decision process. Each MEC server has its own policy network, and the CDN server has G value networks. Each value network corresponds to a MEC server. The learning algorithm structure adopted by the present invention is centralized training-distributed execution.

The observation results of the MEC server can be mapped to the effective action space through the strategy; in each time slot, the MEC server will select the appropriate action according to its own observation results and strategy. The value network is used to estimate the state-action function of each MEC server. After each MEC server executes the action selected by its own policy network, it will send the action as well as the feedback from the environment, the observation results of the current environment and the reward obtained to the CDN server, and then train the parameters of the value network on the CDN server. The output of the value network will be sent to the policy network of the corresponding MEC server to train the parameters of the policy network.

Step 4-3, the edge cache algorithm based on multi-agent reinforcement learning is described as follows:

Step 4-3-1, initialize the state space, the target policy network of each MEC server, the parameters of the main value network and the main policy network, the number of MEC servers, the maximum cache capacity of the MEC servers, the video content set, and the sampling batch size;

Step 4-3-2, initialize a random process for exploration and initialize the received state space;

Step 4-3-3, obtaining the request probability of the video content according to the Zipf distribution and requesting the content according to the probability;

Step 4-3-4, each MEC server selects an action and executes it according to its own policy network;

Step 4-3-5: After executing the action, determine whether the cached video content exceeds the cache capacity. If it exceeds, delete the video content with a lower request probability in the cache module, obtain the environmental reward and the new observation space, and store the current state, execution action, reward, and next state of each MEC server in the corresponding experience replay pool;

Step 4-3-6, assign the new environmental observation space to the original observation results, randomly select data from the experience replay pool, and each MEC server updates the parameters of the policy network and the value network according to the formula, and updates the parameters of the target network of each MEC server.

The above description is only a preferred embodiment of the present invention and is not intended to be a further limitation of the present invention. All equivalent changes made using the contents of the present specification and drawings are within the protection scope of the present invention.

Claims (9)

1. A cloud-edge-end collaborative video stream caching system based on blockchain, characterized by comprising a network module, a cache module and a blockchain module; The network module includes a CDN server layer, an edge server layer and a video user layer; the CDN server layer stores all video content and provides computing resources for the edge server layer; the video user layer sends a video request to the edge server layer and receives the video returned by the edge server layer; The cache module includes a video content popularity calculation unit, an access delay calculation unit, a traffic cost calculation unit, and a cache energy consumption calculation unit, which are respectively used to calculate the popularity of the video content, and the access delay, traffic cost, and cache energy consumption when the video content is cached in the CDN server layer and the edge server layer; and minimize the content access delay, traffic cost, and energy consumption problems of all video requests; For the paid video content generated, the blockchain module is used to calculate the additional energy consumption generated by putting the paid video content requested by the video user on the chain. 2. According to the blockchain-based cloud-edge collaborative video stream caching system of claim 1, the edge server layer includes base stations and MEC servers; the base stations cover all MEC servers in the local area, and microwaves are used to realize data transmission between the base stations and MEC servers, and coverage is achieved through 5G networks, and each base station is connected to a remote CDN server through a backbone network; The edge server layer responds to the request of the video user layer by: Internal video content The number of requests is expressed as , binary variable Used to indicate a period of time Internal video content Whether the request should be served by the current MEC server; Indicates the time period Video content The request should be served by the current MEC server; Indicates that there is no video content on the current MEC server , then the service is provided by the adjacent MEC server or the remote CDN server; , Refers to caching video content MEC server or CDN server, Indicates the MEC server. Indicates the CDN server; in addition, using binary variables To represent the video content Is it cached on the server? middle, Indicates video content Cache on the server middle; Indicates video content Not cached on the server middle. 3. According to the blockchain-based cloud-edge collaborative video stream caching system according to claim 2, it is characterized in that the video user layer is composed of several video users; it is assumed that all video content files have the same unit size, which is S bits; and it is stipulated that each user video request belongs to a specific edge area. 4. According to the blockchain-based cloud-edge collaborative video stream caching system of claim 2, it is characterized in that the specific steps of using the video content popularity calculation unit to calculate popularity are as follows: S1-1, sorting the video contents requested by the video users in descending order of popularity, , Indicates video content The popularity of , K represents the number of videos; Indicates Video content has the highest popularity; Indicates The video content has the lowest popularity; and the video popularity follows a decay parameter Zipf distribution, that is, the popularity of the video has periodic changes; S1-2. Calculating video content Request probability: ; in, It is the content request coefficient that controls the popularity of video content. The larger the coefficient is, the higher the reuse rate of video content is. 5. According to the blockchain-based cloud-edge collaborative video stream caching system of claim 4, it is characterized in that the specific steps of using the access delay calculation unit to perform access delay calculation are as follows: S2-1, when a video request arrives, if the cached video content is found in the local MEC server, the local MEC server immediately returns the cached content, i.e., local hit; S2-2, if the local MEC server cache does not hit, then turn to its neighboring MEC server to obtain the corresponding cache content, and if the content exists, return the content, that is, neighbor hit; S2-3, if the adjacent hit does not hold, the local MEC server obtains the video content from the CDN server to serve the relevant cache request, i.e., CDN hit; In the edge cache environment, there are three components of delay, depending on the different cache hit situations, including the delay from the video user layer to the edge server layer, the delay between edge server layers, and the delay from the edge server layer to the CDN server layer. Since the delay from the video user layer to the edge server layer is included in all requests, this delay is ignored for the convenience of calculation. Therefore, the time period Total transmission waiting time of MEC servers within It is expressed as: , in, Indicates the current MEC server and another server The waiting time between Represents a collection of video content; Indicates the adjacent MEC server; Indicates time period Internal video content The number of requests. 6. According to the blockchain-based cloud-edge collaborative video stream caching system of claim 5, it is characterized in that the specific steps of using the traffic cost calculation unit to calculate the traffic cost are as follows: S3-1. For the video access traffic cost, ignore the cost from the video user layer to the edge server layer and calculate the video access traffic cost. for: , in, Indicates the current MEC server and other servers The communication cost between S3-2. At the end of each cache cycle, if the video to be cached at the next moment is not exactly the same as the currently cached video, each MEC server needs to obtain a new video from a neighboring MEC server or CDN server, which will also introduce additional traffic costs. This cost is expressed as the video replacement traffic cost. , calculated as: , in Indicates the video content to be cached by the current MEC server at the next moment. Indicates the video content cached by the current MEC server at the current moment; S3-3, the total flow cost expression is: . 7. The cloud-edge-end collaborative video stream caching system based on blockchain according to claim 6 is characterized in that the specific steps of calculating cache energy consumption using the cache energy consumption calculation unit are as follows: S4-1. When a video user requests video content in the CDN server layer If the video content Has been sent to the MEC server by the CDN server, then the video content The content is sent from the MEC server to the video user layer, that is, local hits or neighboring hits; only the transmission process of the content from the edge server layer to the video user layer via the wireless downlink channel is considered, in the time period The available downlink transmission rates are: , in, Indicates the transmit power of the MEC server. It is in the time period Internal video users With MEC server The channel gain between is the noise variance at the video user; Therefore, by Send video content stored at the edge The energy consumption is expressed as: , Among them, all video content files have the same unit size, which is S bits; Indicates the transmit power of the MEC server; Indicates the available downlink transmission rate; S4-2. If the video content Not yet stored on the MEC server In the MEC server The requested content will be obtained from the CDN server, and then the MEC server will send the video content Sent to the video user layer, i.e. CDN hit; The more popular the video content is, the more likely it is to be requested by users, which will affect the energy consumption of the system; establish a relationship between the popularity of video content and energy consumption; Assume that from the MEC server To CDN server The round-trip time for sending the received user request and returning the requested video content is Therefore, combined with the popularity of video content, Send video content that is not stored in the edge server layer The energy consumption is expressed as: , in, Indicates the transmission power between the edge server and the CDN server; Indicates that from the MEC server To CDN server Send the received user request and return the round-trip time of the requested video content; S4-3. Consider transmitting all There are two cases of video content, and the energy consumption of this process is defined as: , in , Indicates video content Already cached at the edge server layer; Indicates video content Not cached at the edge server layer; S4-4. If the requested video content is paid video content, the blockchain module is used to calculate the energy consumption of the consensus mechanism. ; S4-5. Calculate the total energy consumption as: . 8. The blockchain-based cloud-edge-end collaborative video stream caching system according to claim 7 is characterized in that, for the blockchain module, all MEC servers are regarded as blockchain nodes; for each time slot, when the video user requests delay-insensitive billing video content from the MEC server, each MEC server will collect the transaction data provided by the CDN server to the video user layer and send it to the blockchain system for transaction data verification and accounting; after the consensus process is completed, each MEC server will send the billing result to the video user for inspection and payment; When the number of failed nodes is less than When using the PBFT mechanism to ensure the authenticity of the data, it is assumed that the generation or verification of the signature and the message authentication code MAC requires and CPU cycles, the PBFT consensus process includes the following steps: S5-1, request phase: During each time slot, the CDN server uploads the billing video content bill to the MEC server. Each MEC server Broadcast the collected transaction information to the entire network; the master node is randomly assigned by the blockchain system based on the time exceeded for packaging. and maximum chunk size Pack the transaction information into a new block; then verify the signature and MAC on the master node; this process calculates the cycle It is expressed as: , in, represents the total transaction size in the block, Indicates the average size of a transaction; S5-2, Pre-preparation phase; After all transactions are verified, the master node will discard the erroneous transactions collected by the MEC server and generate independent signatures and MACs will be sent to each secondary node together with the new block; if the secondary node receives this new block, the signature and MAC will be verified; the calculation cycle in this process is expressed as: , , in, Indicates the percentage of correct transactions received via the MEC server; Indicates the masternode settlement cycle, Indicates the calculation period of the secondary node; S5-3, preparation phase; if the new block and transaction have been verified, the secondary node generates a signature and MACs and send them to other blockchain nodes; each node then needs to receive and verify signatures and MACs, where ; Therefore, for the primary node and the secondary node, the calculation cycle of the process is expressed as: , ; S5-4, confirmation phase; if the verified node receives A correct message will be sent with a signature and MAC to other nodes; at the same time, each node must check signatures and MACs; therefore, for the master node and the slave node, the calculation formula for the calculation cycle is: ; S5-5, reply phase; verification nodes collect After a valid confirmation message is sent to the master node, Signature and MAC reply message, the master node needs to check signatures and MACs; the calculation cycle is calculated as: , ; During the consensus process, all nodes need to verify signatures and MACs, which requires more computing resources to complete these computing tasks; therefore, nodes can choose MEC servers or CDN servers to perform computing tasks; moreover, each node chooses the computing method according to its own computing power requirements; when When nodes perform computing tasks through CDN servers and the remaining nodes choose MEC servers, the total computing cycle is as follows: , The energy consumption of the blockchain consensus part is calculated as follows: , in, Indicates the transmission rate between the MEC server and the CDN server. Indicates the computing power of the CDN server. Indicates the computing power of the MEC server. Indicates the computing power of the CDN server. Indicates the computing power of the CPU processor chip. 9. The blockchain-based cloud-edge collaborative video stream caching system according to claim 8 is characterized in that the content access delay, traffic cost and energy consumption of all video requests are minimized, and the problem is formulated as: , in, is a weighting factor used to adjust the preference between latency, traffic cost, and power consumption; constraint P1 ensures that each request will be served by only one MEC or CDN server; constraint P2 indicates that the storage usage of each MEC server should not exceed the storage capacity limit ; Constraint P3 ensures that video user requests can only be served by MEC or CDN servers that cache the corresponding video content; Constraints P4 and P5 restrict the optimization variables to binary values.