An edge collaborative video caching method based on multiple popularity indicators

Abstract

The application belongs to the technical field of edge computing, and discloses an edge cooperative video caching method based on multiple popularity indexes. In the initial caching placement stage, the application considers the base station load balancing problem to carry out caching popularity balancing video content, adopts the initial segment caching and complete caching method to improve the video quantity of the edge end caching, carries out different caching update decisions according to the user video request data, and responds to the user request according to the actual caching condition. In the caching update stage, the application proposes two caching replacement strategies, carries out caching update on the cached video content in the edge server in different periods according to the change of the video popularity, better utilizes the change of the video popularity, better guarantees that the cached video content in the edge server has higher popularity, ensures that the more popular video is cached in the position closer to the user, effectively reduces the user request delay, and improves the user experience.

Description

Technical Field

[0001] This invention mainly relates to the field of edge computing technology, and in particular to an edge collaborative video caching method based on multiple popularity indicators. Background Technology

[0002] Today, video quality and bitrate are steadily improving, and video traffic is growing exponentially, making multimedia video a crucial component of internet service traffic. The user base for online video services is also rapidly expanding. According to the "China Online Audiovisual Development Research Report," as of December 2023, the number of online audiovisual users in China reached 1.074 billion, with a usage rate of 98.3%, and a market size of 115.481 billion yuan. Online audiovisual has become the number one internet application, and its position is increasingly solidified. Therefore, ensuring the quality of service provided by online video services has become a key consideration for service providers, and effectively improving the user experience using existing technologies has become extremely important.

[0003] Existing cloud computing video caching methods place a heavy burden on cloud data centers, which contain all resources and process all requests in the cloud. Furthermore, each user request is submitted to the cloud center for a response, often resulting in the same content being repeatedly transmitted over limited backhaul links. This leads to significant bandwidth waste and remote backhaul congestion, especially with ultra-high-definition video delivery, which is often unsatisfactory, causing long user request response times and severely impacting user experience. Typically, video requests follow a Zipf distribution, with the top 20% of videos accounting for nearly 80% of clicks. Therefore, user requests are repetitive. Edge computing technology can be used to pre-deploy some videos closer to users at the edge, effectively alleviating the pressure on the cloud center and reducing latency issues.

[0004] While edge caching technology utilizes the distribution patterns of video requests to pre-select videos from the cloud center and cache them on edge servers, reducing data transmission distance during user request responses and alleviating the load on central servers to some extent, edge servers have limited caching and computing capabilities. Current solutions only allow base stations to cache complete videos, resulting in a very limited amount of video content that can be stored at the edge. Furthermore, the popularity of videos dynamically changes, necessitating updates to the cached content at the edge. Existing cache update schemes use methods such as FIFO, LRU, and LFU for cache replacement, which cannot effectively track changes in video popularity based on actual user access data to predict the probability of a video being accessed. Summary of the Invention

[0005] To address the limitations of edge server caching and computing power, and the inability to effectively track changes in video popularity based on actual user access data to predict the probability of a video being accessed, this invention provides an edge collaborative video caching method based on multiple popularity indicators. This method aims to overcome the shortcomings of existing edge caching technologies, improve the response speed of user video content requests, optimize the video service experience, enhance the viewing quality for end users, and reduce the load on cloud data center servers.

[0006] To achieve the above objectives, this invention provides an edge collaborative video caching method based on multiple popularity metrics, comprising the following steps:

[0007] Step 1: Initially place cached data at the edge using a caching popularity-balanced approach.

[0008] Step 1.1: In the cloud data center, derive the long-term popularity index of the video based on user requests since the video was published, and assign it to the overall popularity of the video;

[0009] Step 1.2: Based on the ratio of the overall popularity index of the video to the video size obtained in Step 1.1, obtain the unit popularity index of the video, and sort the videos in descending order according to the unit popularity index;

[0010] Step 1.3: Using a greedy algorithm, select video content to cache on the edge server according to the video sorting in Step 1.2, until the edge server cache space is empty or all video content is cached, forming a cache summary table;

[0011] Step 2: Respond to user requests based on the actual video content caching situation:

[0012] Step 2.1: The base station receives a user's video content request;

[0013] Step 2.2: The edge server checks the actual video caching status based on the cache summary table in Step 1.3 and selects the response method for the user request;

[0014] Step 2.3: The base station responds to the user's video content request;

[0015] Step 3: Replace cached content on the edge server using a cache replacement method based on multiple popularity metrics;

[0016] Step 3.1: Track and temporarily update the cache based on the sudden popularity index of each video content within a time period;

[0017] Step 3.2: After a time period ends, a greedy heuristic algorithm is used to periodically update the cached videos in the edge server.

[0018] Furthermore, in step 1.3, at the end of each round of caching, the caching order of the edge server is reversed. When the cache space is insufficient to cache the complete video, the initial segment of the video is selected for caching.

[0019] During the caching process, each edge server establishes a cache summary table containing its own cached content and the cached content of its neighbors.

[0020] Furthermore, the response methods for user requests in step 2.2 include three types:

[0021] K1: When the corresponding video is cached in the edge server of the base station, the base station will directly respond to the user's request. If the video is an initial segment cache, the edge server provides the cached part, and the cloud data center provides the remaining part.

[0022] K2: When the base station's edge server does not cache the corresponding video information, if the adjacent edge server has the corresponding video, the user request will be responded to through edge-to-edge collaboration. If the video is an initial segment cached in the adjacent edge server, the adjacent edge server will provide the cached portion, and the cloud data center will provide the remaining portion.

[0023] K3: If the corresponding video is not cached on any edge server, the cloud data center will respond to the user request by leveraging the cloud-edge collaboration relationship.

[0024] Furthermore, the prevalence indicators in step 3 include long-term prevalence indicators, short-term prevalence indicators, and outbreak prevalence indicators.

[0025] Furthermore, in step 3.1, the changes in the video's sudden popularity index are monitored within the time period. These changes serve as a temporary cache update decision indicator, and the threshold for sudden popularity is set as follows: The value of sudden epidemicity is expressed as ,in, It is the average number of all video requests in the previous time period. It is its standard deviation. It is a scaling factor used to detect significant demand peaks;

[0026] If the outbreak epidemic value exceeds the threshold limit within a time period If so, the video is temporarily cached on each edge server. After the time period ends, the decision on whether to retain the video on the edge server is made based on the periodic cache update decision method.

[0027] Furthermore, in step 3.2, based on the set time period, user access information from the time the video was published until the start of this time period is set as the long-term popularity metric, and user access information within this time period is set as the short-term popularity metric. The long-term and short-term popularity metrics are updated before the start of a period, including the following steps:

[0028] Step 3.2.1: Calculate the overall popularity index of the video;

[0029] Step 3.2.1.1: Calculate the video over time periods Short-term prevalence index before the start of the program; the short-term prevalence index is expressed as... ,in, Indicates time period Pre-start video Short-term popularity index Indicates a video library, Indicates window period Internal video Number of visits;

[0030] Step 3.2.1.2: Calculate the video over time period 0~ The long-term prevalence index is expressed as follows: ,in, The weight parameters are obtained from the KL divergence calculation. As the attenuation factor, Indicates the first The video content within a time period Long-term popularity before it begins;

[0031] Step 3.2.1.3: Calculate the video time period based on the latest short-term and long-term popularity indicators. The overall prevalence index before the start is expressed as ;

[0032] Step 3.2.2: Sort the videos in the cloud data center according to the latest overall video popularity index;

[0033] Step 3.2.3: Each edge server is sorted according to the video popularity index of the cloud data center, and the edge server with the highest number of user accesses is selected for caching based on the video access data received from each base station.

[0034] Beneficial Effects: This invention provides an edge collaborative video caching method based on multiple popularity metrics. By optimizing the cache placement method and considering base station load balancing, multiple popular video contents are evenly distributed and cached on different edge servers, avoiding a single server frequently responding to multiple requests. The invention uses both full and partial caching during caching, effectively storing more video content on edge servers. In the cache update phase, this invention proposes two cache replacement strategies, updating the cached video content on edge servers at different times based on changes in video popularity. This better utilizes changes in video popularity, ensuring that the edge servers cache more popular video content, ensuring that more popular videos are cached closer to the user, effectively reducing user request latency and improving user experience. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the edge collaborative video caching method based on multiple popularity indicators involved in the embodiments of the present invention;

[0036] Figure 2 This is a model architecture diagram of the edge video caching response system involved in an embodiment of the present invention;

[0037] Figure 3 This is a schematic diagram of the execution flow of each stage involved in the embodiments of the present invention;

[0038] Figure 4 This is a schematic diagram of a cache popularity balancing method in the initial cache placement stage according to an embodiment of the present invention;

[0039] Figure 5 This is a schematic diagram of a video request and response method based on collaborative response according to an embodiment of the present invention;

[0040] Figure 6 This is a schematic diagram illustrating the change in cache hit rate of the edge server using caching in this embodiment of the invention compared to the cache hit rate of traditional methods over the number of iterations in a time period.

[0041] Figure 7 This is a schematic diagram illustrating the change of the average response time of user requests on the edge server with caching, as described in this embodiment of the invention, compared to the average response time of user requests using traditional methods, with the number of iterations over a time period. Detailed Implementation

[0042] like Figures 1 to 7 As shown, this invention provides an edge collaborative video caching method based on multiple popularity indicators.

[0043] A caching method that balances caching popularity refers to a caching method that includes long-term popularity metrics, short-term popularity metrics, and sudden popularity metrics.

[0044] Greedy algorithms, also known as optima algorithms, are algorithms that, at each step, make the best or optimal choice given the current state, hoping to achieve the best or optimal outcome. In solving problems, greedy algorithms make choices that depend only on the current problem state, not on previous choices or future results. This type of algorithm is particularly effective in problems with optimal substructure, where the globally optimal solution can be obtained through a series of locally optimal choices.

[0045] Greedy heuristics are algorithms based on experience or intuition, typically used to solve complex combinatorial optimization problems (such as NP-hard problems). They seek a "satisfactory solution" rather than the global optimum within reasonable time and resource constraints. Heuristic algorithms are characterized by their flexibility and suitability for large-scale problems or scenarios that cannot be solved by exact algorithms. Common heuristic algorithms include neighborhood search, simulated annealing, and genetic algorithms.

[0046] Example 1: To address the difficulty of effectively improving user experience with existing edge video content caching technologies, this embodiment of the invention provides an edge collaborative video caching method based on multiple popularity metrics to efficiently utilize the caching and computing capabilities of the edge, such as... Figure 1 As shown, this includes: balancing video content based on base station load balancing during the initial cache placement phase; employing initial segment caching and full caching methods to increase the number of videos cached at the edge; making different cache update decisions based on user video request data; and responding to user requests based on the actual cache situation. These methods can effectively improve the utilization efficiency of edge servers. By analyzing changes in video popularity to determine the probability of user access to videos, higher-popularity videos are placed at the edge, improving the user experience.

[0047] like Figure 2 This paper demonstrates an edge video caching response system model, including a cloud, an edge, and a terminal. The cloud includes a cloud server, the edge includes a base station and an edge server, and the terminal includes user equipment. In this edge collaborative caching response architecture, users send video content requests to associated base stations. Each base station is equipped with an edge server for storage and computation. The base stations are connected to the cloud data center via a remote backhaul link, and collaboration between base stations is achieved through a local area network. The invention is described below in three steps: initial cache placement, user request response, and cache update. The actual execution flow of the different stages of this invention is as follows: Figure 3 As shown.

[0048] Step 1: Initial Cache Placement

[0049] During the initial caching phase, no videos are cached on the edge servers; all video content is stored in the cloud data center. At this point, as the process begins, the videos do not have short-term popularity. Long-term popularity of the video Based on the video's access data since its release in the cloud center, this stage requires initial video caching on edge servers during off-peak bandwidth usage periods, according to the video's popularity metrics. Figure 4 As shown.

[0050] Step 1.1: Popularity information initialization. First, the long-term popularity of the video since its release while it has been placed in the cloud center is assigned to the overall popularity.

[0051] (Equation 1);

[0052] (Equation 2).

[0053] Step 1.2: Use To indicate video, use This indicates an edge server. (Based on video size information) And overall video popularity information , to obtain the video popularity index per unit size of the video content: Unit Popularity: (Equation 3)

[0054] The videos are sorted in descending order of popularity. hour, .

[0055] Step 1.3: Number the edge servers, and select the videos with higher unit popularity from those videos that are not cached by any edge servers in the cloud center according to the edge server number. Cache can be implemented, and when there is insufficient cache space, initial fragment caching can be performed;

[0056] (Equation 4);

[0057] (Equation 5);

[0058] (Formula 6);

[0059] in Represents edge server The video cache table, Represents edge server Cache space, Indicates video The cache size in the edge server. (Equation 4) represents the cache size in the edge server. Cached Videos Equation 5 represents the update of the edge server's cache size; Equation 6 represents the accumulation of the video popularity values ​​cached on the edge server. Based on the video's cache status—uncached, fully cached, and initial segment cached—the video cache status is... .

[0060] Repeat step 1.3 for caching operations. After each round of caching loop, reverse the caching order of the edge servers to ensure that the cumulative popularity value of cached videos in each edge server is more balanced until all cache space is empty or all videos are cached. Each edge server establishes a cache summary table of its own cached content and the cached content of its neighbors.

[0061] Step 2: User Request Response

[0062] After step 1, the edge servers cache the most popular videos. In step 2, when a user sends a video request, the corresponding base station can respond to the request based on the actual situation of the video on the edge server, and record the user's video request information at the same time.

[0063] Users and base stations are interconnected, with each base station equipped with an edge server. If the requested video exists on the edge server of the associated base station, the request is responded to directly. Otherwise, the video is retrieved from other edge servers in the local network via a fast LAN between base stations. If none of the base stations have cached the corresponding video, the request is retrieved by connecting to the cloud data center via a backhaul link. Figure 5 As shown. The specific response method is as follows:

[0064] (1) When the corresponding video is cached in the edge server of the base station, the base station will directly respond to the user request. If the video is an initial segment cache, the edge server provides the cached part, and the cloud data center provides the remaining part.

[0065] (2) When the associated edge server does not cache the corresponding video information, the adjacent edge server will have the relevant video and will respond to the user's request through edge-to-edge collaboration. If the video is an initial segment cached in the adjacent edge server, the adjacent edge server will provide the cached part, and the cloud data center will provide the remaining part.

[0066] (3) If the corresponding video is not cached in any edge server, the cloud data center responds to the user's request through the cloud-edge collaboration relationship.

[0067] Step 3: Edge Cache Update

[0068] In step 2, when responding to user requests, access data of user video content can be collected. Since the popularity of videos is constantly changing, in order to ensure that popular videos are placed close to users, it is necessary to update the changes in the popularity of videos and update the cached content in the edge server. The cache update phase is divided into two parts: periodic cache update and temporary cache update.

[0069] Step 3.1: Temporary cache update

[0070] a time period The data on user requests for videos before the event ends is called burst popularity. This phenomenon is common in video dissemination, especially when videos spread through social networks. This surge in popularity is short-lived and concentrated. A sudden increase in popularity can reasonably predict that the video will be viewed at a high level during this period, so the video can be cached on various edge devices before the end of the time period.

[0071] Temporary cache updates are based on a sudden surge in the popularity of a video within a given time period, reaching a certain threshold. If the video's popularity is abnormally high, monitoring for abnormal popularity is triggered. At this point, the popularity of the video is considered to have reached its maximum value, requiring immediate updating. Since the coverage area of ​​the video popularity base station is generally applicable, it can be assumed that all users within this area have a high probability of accessing the video during this phase. Therefore, the video is temporarily placed on all edge servers within the area. After the current time period ends, the redundant videos will be replaced according to the video periodic cache update rules.

[0072] Popularity value is expressed as ,in, It is the average of all video requests within the previous time window. It is its standard deviation, and This is a scaling factor used to detect significant demand spikes. Scaling Factor Controls the sensitivity of burst detection: smaller It will increase sensitivity, but may lead to more false alarms; while a larger... This would reduce the risk, but might cause you to miss some unexpected events.

[0073] Step 3.2: Periodically update the cache

[0074] Regular cache updates are performed at fixed time intervals. Before starting, the overall popularity index of the video is calculated based on the short-term popularity index and the long-term popularity index. Based on the changes in the overall popularity index, the videos with lower overall popularity stored on the edge server are replaced with uncached videos with higher overall popularity. This ensures that content with higher access probability is always closer to the user, and that limited storage resources are provided to more valuable video content.

[0075] The steps for periodically replacing the cache are as follows:

[0076] Step 3.2.1: Calculate the overall popularity index of the video.

[0077] Calculate video over time period Short-term video popularity metrics before start (Equation 8)

[0078] in, Indicates the first The video content within a time period Short-term popularity before the start Indicates a video library, Indicates window period Internal video The number of visits is normalized to convert the results into a probability distribution to reflect relative demand.

[0079] In time period Long-term popularity before the start of the event is expressed as 0~ after the video is published online. The long-term overall access information is represented as (Equation 9), where, As a decay factor, it is used to reduce the impact of historical data; It is a dynamic weight obtained by quantifying the differences in popularity distribution using KL divergence, used to measure... and The degree of difference between distributions, which dynamically balances the contributions of short-term and long-term trends, ensures that the model can adapt to constantly changing user preferences and dynamically generates update factors to drive the iteration and fusion of popularity indicators, enabling the algorithm to efficiently capture dynamic changes in user interests.

[0080] (Equation 10), where, It is the basic weighting factor. It is a scaling factor that amplifies the effect of divergence. Used for measurement and The KL divergence between them. It is a normalization constant used to limit the upper bound of the divergence's influence. This formula makes... It can increase with the increase of divergence, thus effectively balancing and The differences between them.

[0081] The video duration was calculated based on the latest short-term and long-term popularity indicators. The overall prevalence index before the start is expressed as (Equation 11).

[0082] Step 3.2.2: Sort the videos in the cloud data center according to the latest overall video popularity.

[0083] Step 3.2.3: Each edge server sorts the videos according to their popularity in the cloud center and replaces the low-popularity videos stored on the edge servers with videos that have higher popularity. When selecting the video storage location, the edge server with the highest number of user accesses is selected for caching based on the access data of the video received by each base station. This reduces the number of times the base station requests coordination from other base stations and reduces communication pressure.

[0084] When replacing the cache, it is still necessary to ensure that the video is stored only once on all edge servers. When the cache space is insufficient, the initial segment caching strategy is adopted. When the cache is updated, the cache table of the edge servers needs to be updated synchronously.

[0085] To verify the effectiveness of this invention, the improved method of this invention was compared with the performance of traditional edge computing methods. The comparison method employed two different approaches: the traditional method combined with LFU for caching and replacement, and the traditional method combined with LRU for caching and replacement. The edge server cache hit rates of the three methods under varying iteration counts over time were as follows: Figure 6 As shown. From Figure 6 It can be seen that the cache hit rates of several algorithms gradually become smoother as the number of iterations changes over time, and the method in this invention consistently outperforms the other two methods in terms of cache hit rate on edge servers. Specifically, the traditional method combining LFU algorithm for caching and replacement achieves a final cache hit rate of 75.30%, the traditional method using LRU for cache replacement achieves a final cache hit rate of 50.69%, while the method in this invention achieves a final hit rate of 95.09%. Figure 7 This compares the average request response time of each request sent by the user to the base station using our experimental method with the two methods mentioned above, as the number of iterations changes over the time period. From Figure 7It can be seen that as the number of iterations changes over the time period, the average request response time per request for all algorithms gradually smooths out, and the method in this invention consistently outperforms the other two methods in terms of average request response time per user request. Specifically, the average request response time per user request using the traditional method combined with the LFU algorithm for caching and replacement is 10.38 s, and the average request response time per user request using the traditional method with LRU for caching and replacement is 24.76 s. In contrast, the average request response time per user request using the method of this invention reaches 1.85 s. Therefore, the edge collaborative video caching method based on multiple popularity metrics proposed in this invention is feasible in improving the user experience of video users, effectively reducing user request response time and improving the cache hit rate of edge servers.

[0086] It should be noted that although the steps are described in a specific order above, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required function can be achieved.

[0087] This invention provides an edge-collaborative video caching method based on multiple popularity metrics. When caching video at the edge, it leverages video stream characteristics to employ initial segment caching and full caching methods, effectively improving the utilization efficiency of the edge server's cache space. By utilizing cloud-edge collaboration and edge-to-edge collaboration to respond to user requests, when a video is partially cached at the edge, the initial portion of the video content can be provided to the user, with the remaining portion then provided by the cloud center, effectively reducing user request waiting time. Regarding the selection of cached content, a caching decision method is derived based on a reasonable analysis of multiple popularity metrics for different time periods of the video, dynamically changing the videos cached on the edge server and placing videos with a high probability of access closer to the user.

[0088] Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. However, any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An edge-collaborative video caching method based on multiple popularity metrics, characterized in that, Includes the following steps: Step 1: Initially place cached data at the edge using a caching popularity-balanced approach. Step 1.1: In the cloud data center, derive the long-term popularity index of the video based on user requests since the video was published, and assign it to the overall popularity of the video; Step 1.2: Based on the ratio of the overall popularity index of the video to the video size obtained in Step 1.1, obtain the unit popularity index of the video, and sort the videos in descending order according to the unit popularity index; Step 1.3: Using a greedy algorithm, select video content to cache on the edge server according to the video sorting in Step 1.2, until the edge server cache space is empty or all video content is cached, forming a cache summary table; Step 2: Respond to user requests based on the actual video content caching situation: Step 2.1: The base station receives a user's video content request; Step 2.2: The edge server checks the actual video caching status based on the cache summary table in Step 1.3 and selects the response method for the user request; Step 2.3: The base station responds to the user's video content request; Step 3: At the edge, cached content in the edge server is replaced using a cache based on multiple popularity metrics, including long-term popularity metrics, short-term popularity metrics, and burst popularity metrics. Step 3.1: Track and temporarily update the cache based on the sudden popularity index of each video content within a time period; Step 3.2: After a time period ends, a greedy heuristic algorithm is used to periodically update the cached videos in the edge server.

2. The edge collaborative video caching method based on multiple popularity indicators according to claim 1, characterized in that, In step 1.3, at the end of each caching cycle, the caching order of the edge server is reversed. When the cache space is insufficient to cache the complete video, the initial segment of the video is selected for caching. During the caching process, each edge server establishes a cache summary table containing its own cached content and the cached content of its neighbors.

3. The edge collaborative video caching method based on multiple popularity indicators according to claim 1, characterized in that, The response methods for user requests in step 2.2 include three types: K1: When the corresponding video is cached in the edge server of the base station, the base station will directly respond to the user's request. If the video is an initial segment cache, the edge server provides the cached part, and the cloud data center provides the remaining part. K2: When the edge server of the base station does not cache the corresponding video information, if the adjacent edge server has the corresponding video, the user request will be responded to through edge-to-edge collaboration. If the video is an initial segment cached in the adjacent edge server, the adjacent edge server will provide the cached part, and the cloud data center will provide the remaining part. K3: If the corresponding video is not cached on any edge server, the cloud data center will respond to the user request by leveraging the cloud-edge collaboration relationship.

4. The edge collaborative video caching method based on multiple popularity indicators according to claim 1, characterized in that, In step 3.1, the changes in the sudden popularity index of the video are monitored within the time period. The changes in the sudden popularity index are used as a temporary cache update decision indicator, and the threshold of the sudden popularity index is set to [value missing]. The value of the outbreak epidemic index is expressed as ,in, It is the average number of all video requests in the previous time period. It is its standard deviation. It is a scaling factor used to detect significant demand peaks; If the value of the outbreak epidemic index exceeds the threshold limit within a time period... If so, the video is temporarily cached on each edge server. After the time period ends, the decision on whether to retain the video on the edge server is made based on the periodic cache update decision method.

5. The edge collaborative video caching method based on multiple popularity indicators according to claim 1, characterized in that, In step 3.2, based on the set time period, user access information from the video's release to the start of this time period is set as the long-term popularity metric, and user access information within this time period is set as the short-term popularity metric. The long-term and short-term popularity metrics are updated before the start of a period, including the following steps: Step 3.2.1: Calculate the overall popularity index of the video; Step 3.2.1.1: Calculate the video over time periods Short-term prevalence index before the start of the program; the short-term prevalence index is expressed as... ,in, Indicates time period Pre-start video Short-term popularity index Indicates a video library, Indicates window period Internal video Number of visits; Step 3.2.1.2: Calculate the video over time period 0~ The long-term prevalence index is expressed as follows: ,in, The weight parameters are obtained from the KL divergence calculation. As the attenuation factor, Indicates the first The video content within a time period Long-term popularity before it begins; Step 3.2.1.3: Calculate the video time period based on the latest short-term and long-term popularity indices. The overall prevalence index before the start is expressed as ; Step 3.2.2: Sort the videos in the cloud data center according to the latest overall video popularity index; Step 3.2.3: Each edge server is sorted according to the video popularity index of the cloud data center, and the edge server with the highest number of user accesses is selected for caching based on the video access data received from each base station.

Images