Bandwidth overhead adjustment method, controller, and computer-readable storage medium

Abstract

Embodiments of the present invention disclose a bandwidth overhead adjustment method, a controller, and a computer readable storage medium, which are used for improving the efficiency of bandwidth overhead adjustment. The method comprises: acquiring a target bandwidth overhead of each central line among N central lines, the target bandwidth overhead of each central line being the real-time bandwidth overhead expected to be reached by the central line, and N being an integer greater than 1; generating a threshold adjustment amount of a target domain name, the threshold adjustment amount being an adjustment amount of a measurement index of the target domain name, and the measurement index being used for dividing the data flow of the target domain name into multiple popularity levels; determining a target value for the threshold adjustment amount, the target value being used for indicating the difference between the expected bandwidth overhead and the target bandwidth overhead of the N central lines, and the expected bandwidth overhead of each central line being the real-time bandwidth overhead expected by the central line after the measurement index is updated according to the threshold adjustment amount; and if the target value of the threshold adjustment amount satisfies a preset condition, updating the measurement index according to the threshold adjustment amount.

Description

A method for adjusting bandwidth overhead, a controller and a computer-readable storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 22, 2024, with application number 202410345577.X and application name “A method for adjusting bandwidth overhead, a controller and a computer-readable storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a bandwidth overhead adjustment method, a controller, and a computer-readable storage medium, for improving the adjustment efficiency of bandwidth overhead. Background Art

[0003] In the actual application of Content Delivery Network (CDN) services (such as video, audio, online gaming, and website access), the number of user equipment (UE) accessing data streams simultaneously fluctuates dynamically due to various factors, which in turn causes changes in the real-time bandwidth overhead of the central lines carrying these data streams. For example, if a network operator implements a monthly 95% bandwidth billing standard, if the real-time bandwidth of a central line exceeds this 95% bandwidth, the bandwidth cost of the central line will increase.

[0004] The scheduling center of the CDN can divide each data stream into different heat levels (such as hot flow level, warm flow level and cold flow level) according to the number of UEs accessing the data stream at the same time, and the data streams belonging to the same heat level will be managed with the same scheduling strategy. The scheduling strategy of the data stream will directly affect the bandwidth overhead of the central line. Specifically, each heat level has its corresponding metric. When the number of UEs accessing the data stream at the same time matches a metric, the data stream will be divided into the heat level corresponding to the metric, and the scheduling strategy corresponding to the heat level will be executed. Therefore, the CDN administrator can adjust the metric of the domain name for different data streams, thereby affecting the heat level of the data stream of the domain name, and the scheduling strategy of the data stream will also change, thereby achieving the purpose of adjusting the bandwidth overhead of the central line.

[0005] Currently, the method of adjusting the measurement indicators of each popularity level is mainly by CDN managers adjusting the measurement indicators of domain names based on the current real-time bandwidth overhead of a single central line. This adjustment method is inefficient. Summary of the Invention

[0006] The present application provides a bandwidth overhead adjustment method, a controller, and a computer-readable storage medium, which are used to improve the adjustment efficiency of bandwidth overhead.

[0007] In a first aspect, the present application provides a method for adjusting bandwidth overhead. This method is used to adjust the real-time bandwidth overhead of N central lines, where N is an integer greater than 1. The N central lines may be some of the central lines in a CDN architecture, or all of the central lines in a CDN architecture. This bandwidth overhead adjustment method is executed by a controller in the CDN architecture.

[0008] First, the controller obtains the target bandwidth overhead for each of the N central links, thereby obtaining N target bandwidth overheads for the N central links. The target bandwidth overhead for each of the N central links can be the same or different, and this embodiment of the application is not limited thereto. The target bandwidth overhead for each central link indicates the desired real-time bandwidth overhead for that central link.

[0009] Next, the controller generates a threshold adjustment for the target domain. The data flow for the target domain is carried on at least one of the N central lines. This threshold adjustment is an adjustment to the target domain's metric, which is used to classify the target domain's data flow into multiple hotness levels. Data flows of different hotness levels use different scheduling policies, while data flows of the same hotness level share the same scheduling policy.

[0010] After generating the threshold adjustment, the controller first determines a target value for the threshold adjustment. This target value indicates the difference between the expected bandwidth overhead and the target bandwidth overhead for the N central links. The difference between the expected bandwidth overhead and the target bandwidth overhead for the N central links is based on the difference between the expected bandwidth overhead of each central link and its target bandwidth overhead. The expected bandwidth overhead for each central link is the expected real-time bandwidth overhead for that central link after the target threshold metric is updated with the threshold adjustment.

[0011] As can be seen from the above, the purpose of updating the metric according to the threshold adjustment amount is to make the real-time bandwidth overhead of the central line as close as possible to the target bandwidth overhead of the central line. In the embodiment of the present application, the target value of the threshold adjustment amount represents the difference between the real-time bandwidth overhead and the target bandwidth overhead of the N central lines when the metric is updated with the threshold adjustment amount. If the target value of the threshold adjustment amount meets the preset conditions, it means that when the metric is updated with the threshold adjustment amount, the real-time bandwidth overhead of the N central lines is sufficiently close to the target bandwidth overhead of the N central lines. Therefore, the controller updates the metric of the target domain name according to the threshold adjustment amount.

[0012] In this embodiment of the present application, when updating the metrics of the target domain name, the controller refers to the difference between the expected bandwidth overhead and the target bandwidth overhead of N central links. This makes the bandwidth overhead adjustment results of each central link predictable and controllable, improving the accuracy of the bandwidth overhead adjustment results and achieving a better adjustment effect. Furthermore, after the metrics of the target domain name are updated, the expected bandwidth overhead of the central link is as close as possible to the target bandwidth overhead, so that the real-time bandwidth overhead of the central link can balance the bandwidth overhead cost and the user experience of the UE when accessing the data stream of the central link.

[0013] On the other hand, the bandwidth overhead adjustment process in the embodiment of the present application is performed by the controller without manual operation, thereby improving the adjustment efficiency of the bandwidth overhead.

[0014] Based on the first aspect, in an optional embodiment, when the controller determines the target value of the threshold adjustment amount, the controller first determines the difference value of each central line, thereby obtaining N difference values ​​for the N central lines, each difference value being used to indicate the difference between the expected bandwidth overhead of a central line and the target bandwidth overhead of the central line. The N difference values ​​are then added together to obtain the target value of the threshold adjustment amount. Optionally, the difference between the expected bandwidth overhead and the target bandwidth overhead of each central line is directly proportional to the difference value of the central line. For example, the greater the difference between the expected bandwidth overhead and the target bandwidth overhead of a central line, the greater the difference value of the central line; the smaller the difference between the expected bandwidth overhead and the target bandwidth overhead of a central line, the smaller the difference value of the central line.

[0015] Based on the first aspect, in an optional implementation, the controller can combine the cost coefficient and the experience coefficient to determine the difference value of each central line. Specifically, the controller determines the difference between the expected bandwidth overhead of the central line and the target bandwidth overhead of the central line, and then scales the difference between the expected bandwidth overhead of the central line and the target bandwidth overhead of the central line using the cost coefficient and the experience coefficient of the central line, thereby obtaining the difference value of the central line. Among them, the cost coefficient is obtained based on the billing rules of the central line, and the value of the cost coefficient is greater than or equal to 0. The cost coefficient of each central line can be the same or different. For example, based on the billing rules of the central line, when the CDN service provider is more inclined to reduce the bandwidth overhead cost of the central line, the controller or CDN administrator can increase the value of the cost coefficient, thereby amplifying the difference value of the central line; the experience coefficient is obtained based on the bandwidth demand of the central line, and the value of the experience coefficient is greater than or equal to 0. The experience coefficient of each central line can be the same or different. For example, based on the bandwidth requirements of a central line, if the CDN service provider prefers to improve the bandwidth performance of accessing the central line to meet the user experience of the data stream carried by the central line, the controller or CDN administrator can lower the value of the experience coefficient, thereby reducing the variance of the central line. Thus, the controller combines the cost coefficient and the experience coefficient to determine the variance of each central line. This allows the variance of the central line to reflect the importance of the central line's bandwidth cost and bandwidth performance in the bandwidth cost adjustment process, thereby increasing flexibility in bandwidth cost adjustment.

[0016] Based on the first aspect, in an optional implementation, when the current real-time bandwidth overhead of the central line is greater than or equal to the target bandwidth overhead, in order to avoid excessive bandwidth overhead of the central line, the central line is currently more likely to reduce its real-time bandwidth overhead. In this case, the controller does not need to consider the experience coefficient of the central line, and only calculates the difference value of the central line based on the cost coefficient of the central line, thereby reducing the risk of the central line's bandwidth overhead continuing to increase. On the other hand, when the current real-time bandwidth overhead of the central line is less than the target bandwidth overhead, the central line is currently more likely to increase its real-time bandwidth overhead to meet the user experience of the data stream carried by the central line. In this case, the controller does not need to consider the cost coefficient of the central line, and only calculates the difference value of the central line based on the experience coefficient of the central line, thereby improving the bandwidth performance of the central line and improving the user experience of the data stream carried by the central line.

[0017] Based on the first aspect, in an optional implementation, the cost coefficient of the central link is greater than the experience coefficient of the central link. In this case, for the variance of the central link, the cost coefficient has a greater impact on the variance than the experience coefficient. That is, the importance of bandwidth overhead is greater than the importance of bandwidth performance. This ensures that after the controller updates the metric according to the threshold adjustment amount, the real-time bandwidth overhead of the central link is as close as possible to the target bandwidth overhead of the central link while remaining lower than the target bandwidth overhead of the central link. This ensures bandwidth performance while avoiding an increase in the bandwidth overhead cost of the central link.

[0018] Based on the first aspect, in one optional implementation, the real-time bandwidth overhead of the central line is the sum of the real-time bandwidth overheads of all data flows carried by the central line, and the expected bandwidth overhead of the central line is the sum of the expected bandwidth overheads of all data flows carried by the central line. Therefore, the expected bandwidth overhead of the central line includes the expected real-time bandwidth overhead of the target domain name's data flows on the central line after the metric is updated by the threshold adjustment amount.

[0019] Based on the first aspect, in an optional implementation, the controller generates M threshold adjustments for the target domain name and calculates a target value corresponding to each threshold adjustment, obtaining M target values ​​corresponding to the M threshold adjustments, where M is an integer greater than 1. A target threshold adjustment is then determined from the M threshold adjustments. The target value of the target threshold adjustment is the smallest of the M target values. In other words, when the metric is updated using the target threshold adjustment, the difference between the expected bandwidth overhead of the N central links and the target bandwidth overhead is the smallest among the M threshold adjustments.

[0020] Based on the first aspect, in an optional embodiment, the controller preconfigures a preset threshold value, which represents a threshold value for the difference between the expected bandwidth overhead of the N central links and the target bandwidth overhead. When a target value of the threshold adjustment amount is less than the preset threshold value, indicating that the difference between the expected bandwidth overhead of the N central links and the target bandwidth overhead meets the requirement when the metric is updated using the threshold adjustment amount, the controller then updates the metric of the target domain name according to the threshold adjustment amount.

[0021] Based on the first aspect, in one optional implementation, the target domain name is the domain name with the highest real-time bandwidth overhead carried by the N central lines. Specifically, as can be seen above, the data flow of the target domain name is carried on at least one of the N central lines. Therefore, the real-time bandwidth overhead of the data flow of the target domain name carried on each central line is summed to obtain the real-time bandwidth overhead of the target domain name. Since the target domain name has the highest real-time bandwidth overhead, when adjusting the target domain name's metric, the adjustment effect on the bandwidth overhead of the N central lines is more significant and more efficient.

[0022] Based on the first aspect, in an optional implementation, after the controller updates the metric of the target domain name according to the threshold adjustment amount, the controller classifies the data flow of the target domain name into a corresponding heat level using the updated metric.

[0023] Based on the first aspect, in an optional implementation, the controller uses the updated metrics to assign corresponding popularity levels to the data streams of the target domain. Next, the controller sends a label for the data stream to an edge node in the CDN architecture. The label indicates the current popularity level of the data stream of the target domain. This allows the edge node to execute a scheduling policy that matches the popularity level of the data stream.

[0024] Based on the first aspect, in an optional embodiment, the controller pre-configures an upper threshold and a lower threshold for the metric. When the threshold adjustment is applied to update the metric, the updated metric must be greater than the lower threshold and less than the upper threshold, thereby ensuring that the metric remains within a reasonable range.

[0025] Based on the first aspect, in an optional implementation, the metric of the target domain name is a range of the number of UEs accessing the data stream at the same time.

[0026] In a second aspect, the present application provides a controller, the controller comprising:

[0027] An acquiring unit, configured to acquire a target bandwidth overhead of each of the N central lines, where the target bandwidth overhead of each central line is a real-time bandwidth overhead that the central line expects to achieve, and N is an integer greater than 1;

[0028] a processing unit, configured to generate a threshold adjustment amount for a target domain name, wherein a data flow of the target domain name is carried on at least one of the N central lines, and the threshold adjustment amount is an adjustment amount for a metric of the target domain name, wherein the metric is used to classify the data flow of the target domain name into a plurality of heat levels;

[0029] The processing unit is further configured to determine a target value of the threshold adjustment amount, wherein the target value is used to indicate a difference between an expected bandwidth overhead of the N central links and a target bandwidth overhead, and the expected bandwidth overhead of each central link is an expected real-time bandwidth overhead of the central link after the metric is updated by the threshold adjustment amount;

[0030] The processing unit is further configured to update the measurement indicator according to the threshold adjustment amount when the target value of the threshold adjustment amount meets a preset condition.

[0031] Based on the second aspect, in an optional implementation manner, the processing unit is specifically configured to:

[0032] Determine a difference value for each central line to obtain N difference values ​​for the N central lines, each difference value being used to indicate a difference between an expected bandwidth overhead and a target bandwidth overhead of a central line;

[0033] The N difference values ​​are added together to obtain a target value of the threshold adjustment amount.

[0034] Based on the second aspect, in an optional implementation manner, the processing unit is specifically configured to:

[0035] The difference value of the central line is determined based on the cost coefficient and experience coefficient of each central line. The cost coefficient and experience coefficient are used to scale the difference between the expected bandwidth overhead and the target bandwidth overhead of the central line. The cost coefficient is obtained based on the billing rules of the central line, and the experience coefficient is obtained based on the bandwidth demand of the central line. The value of the cost coefficient is greater than or equal to 0, and the value of the experience coefficient is greater than or equal to 0.

[0036] Based on the second aspect, in an optional implementation manner, the processing unit is specifically configured to:

[0037] When the current real-time bandwidth cost of the central line is greater than or equal to the target bandwidth cost, determining a difference value of the central line based on a cost coefficient of the central line;

[0038] When the current real-time bandwidth overhead of the central line is less than the target bandwidth overhead, a difference value of the central line is determined based on the experience coefficient of the central line.

[0039] Based on the second aspect, in an optional implementation, the value of the cost coefficient is greater than the value of the experience coefficient.

[0040] Based on the second aspect, in an optional implementation, the expected bandwidth overhead of the central line includes the expected real-time bandwidth overhead of the data flow of the target domain name on the central line after the metric is updated by the threshold adjustment amount.

[0041] Based on the second aspect, in an optional implementation manner, the processing unit is specifically configured to:

[0042] Generate M threshold adjustment values ​​for the target domain name, where M is an integer greater than 1;

[0043] Obtaining M target values ​​of M threshold adjustment amounts;

[0044] Determine a target domain name adjustment amount, where the target value of the target domain name adjustment amount is the smallest one among the M target values;

[0045] Updates the metric by the target threshold adjustment amount.

[0046] Based on the second aspect, in an optional implementation manner, the processing unit is specifically configured to:

[0047] When the target value of the threshold adjustment amount is less than the preset threshold, the measurement indicator is updated according to the threshold adjustment amount.

[0048] Based on the second aspect, in an optional implementation manner, the target domain name is a domain name with the highest real-time bandwidth overhead carried by the N central lines.

[0049] Based on the second aspect, in an optional implementation manner, the processing unit is further configured to:

[0050] Based on the updated metrics, determine the popularity level of the data flow of the target domain name.

[0051] Based on the second aspect, in an optional implementation manner, the processing unit is further configured to:

[0052] The label of the data flow of the target domain name is sent to the edge node of the CDN. The label is used to indicate the popularity level of the data flow.

[0053] Based on the second aspect, in an optional implementation, the updated metric is greater than a lower threshold value for the metric and less than an upper threshold value for the metric.

[0054] Based on the second aspect, in an optional implementation manner, the measurement indicator includes a range of the number of user equipments UE accessing the data stream at the same time.

[0055] In a third aspect, the present application provides a controller comprising: a processor coupled to a memory, the memory being used to store instructions, and when the instructions are executed by the processor, the controller implements the method of the above-mentioned first aspect, or any possible implementation of the first aspect.

[0056] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having instructions stored thereon, which, when executed, enables a computer to execute the method in the above-mentioned first aspect or any possible implementation of the first aspect.

[0057] In a fifth aspect, an embodiment of the present application provides a computer program product, which stores computer-readable instructions. When the computer-readable instructions are executed by a processor, the method in the first aspect or any possible implementation of the first aspect is implemented.

[0058] In a sixth aspect, an embodiment of the present application provides a chip, comprising: a processor, the processor being coupled to a memory, the memory being used to store instructions, and when the instructions are executed by the processor, the chip implements the method in the above-mentioned first aspect, or any possible implementation of the first aspect.

[0059] Among them, the technical effects brought about by any implementation method of the second to sixth aspects can refer to the technical effects brought about by the implementation method of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0061] Figure 1 is a schematic diagram of classifying data streams into different heat levels based on different metrics;

[0062] FIG2 is a schematic diagram of a possible, non-limiting network architecture for adjusting bandwidth overhead in an embodiment of the present application;

[0063] FIG3 is a flow chart of a method for adjusting bandwidth overhead according to an embodiment of the present application;

[0064] FIG4 is a schematic diagram of a possible flow chart of a controller calculating a difference value of a central line in an embodiment of the present application;

[0065] FIG5 is a schematic diagram of a scenario in which a controller updates the heat level of a data stream in an embodiment of the present application;

[0066] FIG6 is a schematic diagram of a structure of a controller provided in an embodiment of the present application;

[0067] FIG7 is another structural diagram of a controller provided in an embodiment of the present application. DETAILED DESCRIPTION

[0068] Embodiments of the present application provide a bandwidth overhead adjustment method, a controller, and a computer-readable storage medium, for improving bandwidth overhead adjustment efficiency.

[0069] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation methods of the present application are only used to explain the specific embodiments of the present application and are not intended to limit the embodiments of the present application. It is known to those skilled in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0070] In the embodiments of the present application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0071] The terms "first," "second," "third," "fourth," etc. (if any) in the specification and claims of the present application and in the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential sequence. It should be understood that the numbers used in this way are interchangeable where appropriate, so that the embodiments of the present application described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or apparatus.

[0072] The following is an explanation of some nouns or terms used in the embodiments of the present application, which are also considered part of the content of the invention.

[0073] Content Delivery Network (CDN): A CDN is a distributed network built and deployed on a carrier network. It consists of servers in different regions. The primary function of a CDN is to cache resources from origin servers to edge servers in various locations. This allows users to obtain the resources they need from nearby edge servers, significantly reducing the access pressure on the origin server and improving the speed and stability of content access. Simply put, a CDN deploys edge servers in different locations and pre-stores the origin server's content (such as web pages, videos, or files) on these edge servers. When a user device (UE) requests content from the origin server, the CDN system intelligently selects the edge server closest to the user and delivers the content to the UE, significantly reducing the distance and time required for data transmission and improving the user experience. CDNs are widely used, particularly in the internet industry. Large websites, video platforms, and e-commerce platforms, for example, all employ CDN technology to optimize user experience and improve service quality. By using CDNs, these platforms ensure that users can quickly and reliably access their desired content, regardless of their location. In general, CDN, as an important network infrastructure, is widely used in various Internet business scenarios, such as website acceleration, online video, game distribution, software download or e-commerce, providing users with a faster and more stable content access experience. It plays an important role in improving service quality, reducing bandwidth costs and ensuring business continuity.

[0074] Edge bandwidth: Edge bandwidth primarily refers to the network connection bandwidth between CDN edge nodes and UEs. In a CDN architecture, edge nodes are typically deployed close to UEs to more quickly respond to UE requests and deliver content. Therefore, edge bandwidth directly impacts the CDN system's ability to provide services to UEs. Insufficient edge bandwidth can slow content delivery and negatively impact user experience.

[0075] Back-to-origin bandwidth: Back-to-origin bandwidth refers to the network connection bandwidth between CDN edge nodes and the origin server. When a UE requests content that is not in the CDN edge node's cache, the CDN edge node must retrieve the content from the origin server, which requires back-to-origin bandwidth. Back-to-origin bandwidth determines the speed at which CDN nodes can retrieve content from the origin server, which in turn affects the overall performance and responsiveness of the CDN system. Insufficient back-to-origin bandwidth may prevent CDN edge nodes from retrieving content from the origin server in a timely manner, impacting the user experience.

[0076] In practice, CDN providers will rationally configure edge and back-to-origin bandwidth based on factors such as network conditions, user demand, and business scale to ensure CDN system stability and efficiency. However, larger CDN edge and back-to-origin bandwidth is not necessarily better. Excessive bandwidth can lead to wasted resources and increased costs, while too little bandwidth may not meet user needs. Therefore, when configuring CDN edge and back-to-origin bandwidth, it is necessary to comprehensively consider multiple factors to achieve optimal performance and cost-effectiveness.

[0077] Bandwidth 95th Percentile: The Bandwidth 95th Percentile is a network billing and performance evaluation metric. It represents the 95th percentile of bandwidth usage, measured at regular intervals (e.g., every 5 minutes) over a statistical period (e.g., a month), sorted from highest to lowest. The Bandwidth 95th Percentile reflects the relatively rare occurrence of user network traffic exceeding this value; typically, only 5% of the time, this peak value is reached or exceeded. Different network operators may differ in how they calculate the Bandwidth 95th Percentile, and the specific calculation method may depend on the network operator's regulations. For network operators, using the Bandwidth 95th Percentile as a billing basis prevents customers from being charged for the maximum instantaneous bandwidth during the entire statistical period due to occasional short-term traffic spikes. Instead, customers only pay for the actual average bandwidth cost for the majority of their usage. This is a fair and cost-effective approach for businesses with fluctuating bandwidth needs. The Bandwidth 95th Percentile is also often used as a key reference for network planning, setting service-level agreements, and optimizing resource allocation.

[0078] Next, possible application scenarios involved in the embodiments of the present application are introduced.

[0079] In Content Delivery Network (CDN) services (such as video, audio, online gaming, and website access), bandwidth resource scheduling strategies directly impact user experience and network bandwidth costs. Bandwidth resource scheduling can be divided into two levels: one is edge bandwidth scheduling, which primarily allocates edge access sites to different domain names, allowing UEs to access the selected edge sites and obtain data streams. The other is back-to-source bandwidth scheduling, which primarily allocates central sites to different domain names, allowing UEs already connected to edge sites to access data streams back to the selected central sites.

[0080] Specifically, in CDN scenarios, a scheduling strategy refers to the decision-making mechanism that allocates UE access requests to the most appropriate CDN edge node based on factors such as the UE's request location, network conditions, node load, and availability. A reasonable scheduling strategy helps improve content delivery speed, reduce latency, optimize bandwidth utilization, and ensure high service availability and stability.

[0081] The CDN's scheduling center can classify data streams into different popularity levels (e.g., hot, warm, and cold) based on the number of UEs accessing the data stream at the same time. Data streams belonging to the same popularity level are managed using the same scheduling policy. The data stream scheduling policy directly impacts the bandwidth overhead of the central line. For example, in a live broadcast scenario, the popularity level of a domain's live stream depends on the number of viewers at the same time. During a live broadcast, the number of viewers at a given time often fluctuates over time, causing the stream's popularity level to change. Furthermore, the number of streamers carried on the central line also fluctuates in real time. Therefore, in live broadcast scenarios, the bandwidth overhead demanded by the central line is constantly changing. In general, the number of UEs accessing a data stream at the same time can change dynamically due to various factors, leading to changes in the real-time bandwidth overhead of the central line carrying the data stream. For example, if a network operator implements a monthly bandwidth 95% value, if the real-time bandwidth of a central line exceeds the monthly 95% value, the bandwidth cost of the central line will increase.

[0082] Specifically, each heat level has a corresponding metric. When the number of UEs accessing a data stream at the same time matches a certain metric, the data stream is classified as the heat level corresponding to that metric and the corresponding scheduling policy is implemented. Therefore, CDN administrators can adjust the metric for different domains for different data streams, thereby affecting the heat level of the domain's data stream. This will also change the data stream scheduling policy, thereby achieving the purpose of adjusting the bandwidth overhead of the central line.

[0083] For example, please refer to Figure 1, which is a schematic diagram of dividing data streams into different heat levels based on different metrics. In the scenario illustrated in Figure 1, the data stream is divided into two heat levels, cold stream and warm stream, based on the dual threshold rule. Specifically, each heat level corresponds to a set of dual thresholds, and each set of dual thresholds includes an upper threshold and a lower threshold, which means that only when the number of UEs accessing the data stream at the same time exceeds the upper threshold of the current heat level can it be upgraded to the next higher heat level; similarly, only when the number of UEs accessing the data stream at the same time is lower than the lower threshold of the current level will it be downgraded to the next lower level. The setting of dual thresholds ensures that the change of data streams between heat levels will not be too sensitive, but will only occur when certain threshold conditions are met, reducing frequent upgrades and downgrades due to short-term data fluctuations, helping to maintain the stability of the data stream heat level, and reducing unnecessary heat level adjustments.

[0084] Currently, CDN administrators primarily adjust metrics for each popularity level based on the current real-time bandwidth overhead of a single central line. However, in practice, a domain's data streams are often carried across multiple central lines. Therefore, when CDN administrators adjust a domain's metrics based on the current real-time bandwidth overhead of a single central line, the popularity level of the domain's data streams on other central lines will also change, making the real-time bandwidth overhead of these other central lines uncontrollable and unpredictable. Consequently, this adjustment method is less accurate and less effective.

[0085] In view of this, an embodiment of the present application provides a method for adjusting bandwidth overhead, a controller, and a computer-readable storage medium for improving the adjustment efficiency of bandwidth overhead. For ease of understanding, first, a possible, non-restrictive network architecture for the method for adjusting bandwidth overhead in an embodiment of the present application is introduced. Please refer to Figure 2, which is a schematic diagram of a possible, non-restrictive network architecture for the method for adjusting bandwidth overhead in an embodiment of the present application. In the scenario illustrated in Figure 2, the CDN network architecture includes four central lines (including central line 1, central line 2, central line 3, and central line 4 shown in Figure 2), and these four central lines can carry data streams from various domain names. In actual applications, a domain name often has multiple data streams, and each data stream is carried in a central line. The bandwidth curves of each domain name shown in Figure 2 represent the bandwidth overhead trend of all traffic of the domain name. As shown in Figure 2, all data flows for domain name 1 are carried on central lines 1, 2, 3, and 4, respectively; all data flows for domain name 2 are carried on central lines 1, 2, 3, and 4, respectively; and all data flows for domain name 3 are carried on central lines 1, 2, 3, and 4, respectively. This shows that each of these four central lines carries data flows from various domain names. The bandwidth curves for each central line in Figure 2 illustrate the bandwidth overhead of each central line after carrying traffic from various domain names.

[0086] The bandwidth cost adjustment method in the embodiment of the present application is used to adjust the real-time bandwidth cost of each central line so that the real-time bandwidth cost of the central line approaches or reaches the desired real-time bandwidth cost of the central line (i.e., the target bandwidth cost as exemplified in the embodiment of the present application). The dotted line portion of the bandwidth curve of the central line represents the target bandwidth cost of the central line. For example, taking the network operator's billing standard of a bandwidth monthly value of 95 as an example, the bandwidth monthly value of the central line can be used as the target bandwidth cost as exemplified in the embodiment of the present application. The bandwidth cost adjustment method in the embodiment of the present application is used to make the adjusted real-time bandwidth cost of the central line as close as possible to the bandwidth monthly value of the central line. When the real-time bandwidth cost of the central line is higher than the bandwidth monthly value of the central line, the bandwidth cost of the CDN service provider will increase; when the real-time bandwidth cost of the central line is lower than the bandwidth monthly value, the user experience of accessing the data stream will deteriorate. Therefore, adjusting the real-time bandwidth cost of the central line to be close to the bandwidth monthly value of the central line can balance the bandwidth cost and user experience of the central line.

[0087] Next, the method for adjusting the bandwidth overhead in the embodiment of the present application is introduced. Please refer to Figure 3, which is a flow chart of the method for adjusting the bandwidth overhead in the embodiment of the present application. The method for adjusting the bandwidth overhead in the embodiment of the present application takes the controller in the CDN architecture as an example of the execution subject to illustrate the method, but the present application does not limit the execution subject of the interactive illustration, nor does it limit the specific hardware form or software form of the controller. For example, the controller in Figure 3 can be a chip, chip system, or processor used to support the controller to implement the method; or, the controller can also be a logical node, logic module or software used to implement all or part of the controller functions. As shown in Figure 3, the method for adjusting the bandwidth overhead in the embodiment of the present application includes but is not limited to steps 101 to 104.

[0088] 101. The controller obtains the target bandwidth overheads of N core lines.

[0089] The bandwidth cost adjustment method provided in the embodiments of the present application is used to adjust the real-time bandwidth cost of N central lines, where N is an integer greater than 1. The N central lines may be some of the central lines in a CDN architecture, or may be all of the central lines in a CDN architecture. The bandwidth cost adjustment method is executed by a controller in the CDN architecture. In actual applications, the controller of the CDN architecture is used to manage and schedule the various central lines, edge lines, CDN edge nodes, CDN central nodes, and CDN origin stations in the CDN architecture.

[0090] It should be noted that "controller" is only a general term for devices that perform controller functions, and does not specifically refer to one or some devices. In actual applications, the device that performs the controller function may not be called a "controller", but may be replaced by other names, such as "dispatching center", "dispatching device", "control device" or "server", etc. There is no specific limitation here. In the embodiments of this application, only "controller" is used as an example for illustration.

[0091] First, the controller obtains the target bandwidth overhead for each of the N central links, thereby obtaining N target bandwidth overheads for the N central links. The target bandwidth overhead for each of the N central links can be the same or different, and this embodiment of the application is not limited thereto. The target bandwidth overhead for each central link indicates the desired real-time bandwidth overhead for that central link.

[0092] In practice, the target bandwidth cost for a central link can be set by the controller or CDN administrator. Optionally, the controller or CDN administrator can determine the target bandwidth cost for each central link based on the network operator's billing standards. For example, under a network operator's 95% bandwidth monthly billing standard, if the real-time bandwidth of a central link exceeds the 95% bandwidth monthly value for that central link, the bandwidth cost for that central link will increase. Therefore, in this example, the controller or CDN administrator can use the currently expected 95% bandwidth monthly value for each central link as the target bandwidth cost for that central link.

[0093] 102. The controller generates a threshold adjustment amount for the target domain name.

[0094] Next, the controller generates a threshold adjustment for the target domain name. The data flow of the target domain name is carried on at least one of the N central lines. The threshold adjustment is an adjustment of the metric of the target domain name, which is used to divide the data flow of the target domain name into multiple heat levels. Data flows of different heat levels use different scheduling strategies, while data flows of the same heat level share the same scheduling strategy. In the CDN scenario, the scheduling strategy refers to the decision-making mechanism that allocates UE access requests for data flows to the most appropriate CDN edge node based on factors such as the UE's location, network conditions, node load, and availability.

[0095] In practical applications, N central lines are used to carry data streams from various domain names. A domain name includes at least one data stream, and these data streams can be carried on at least one of the N central lines. Each domain name is associated with a metric that is used to classify the domain's data streams into multiple levels of popularity (e.g., hot stream level, warm stream level, and cold stream level).

[0096] Among them, the measurement indicators of different domain names are independent of each other, that is, the measurement indicators of each domain name can be the same or different. Therefore, when the measurement indicators of a certain domain name are adjusted, the measurement indicators of other domain names will not be affected. Next, one of the domain names carried by N centers is introduced as the target domain name exemplified in the embodiment of the present application. In actual applications, the target domain name can be part of the domain names carried by N central lines, that is, the controller executes the bandwidth overhead adjustment method in the embodiment of the present application for each domain name in the partial domain name; or, the target domain name can also be all domain names carried by N central lines, that is, the controller executes the bandwidth overhead adjustment method in the embodiment of the present application for each domain name in all domain names; or, the target domain name can be a collection of multiple domain names carried by N central lines, that is, the controller treats multiple domain names as a domain name group (target domain name), and then the controller configures the same threshold adjustment amount for each domain name in the domain name group, so that the measurement indicators of each domain name in the domain name group can be updated subsequently.

[0097] In one possible implementation, the target domain name is the domain name with the highest real-time bandwidth cost carried by the N central lines. Specifically, as can be seen above, the data flow of the target domain name is carried on at least one of the N central lines. Therefore, the real-time bandwidth cost of the data flow of the target domain name carried on each central line is added together to obtain the real-time bandwidth cost of the target domain name. Since the target domain name has the highest real-time bandwidth cost, when adjusting the target domain name's metric, the adjustment effect on the bandwidth cost of the N central lines is more significant and efficient.

[0098] In a possible implementation, the metric of the target domain name may be one or a combination of the following:

[0099] The range of the number of UEs accessing the data stream at the same time;

[0100] The data volume range of the data stream;

[0101] The frequency range in which data streams are accessed by the UE in a unit period.

[0102] It should be understood that the above-mentioned multiple measurement indicators are only exemplary descriptions of the measurement indicators in the embodiments of the present application. In actual applications, the measurement indicators of domain names can also be in other content forms, which are not specifically limited here.

[0103] For example, let's assume the target domain's metric is the number of UEs accessing a data stream simultaneously. Assuming the metric is (100, 1000), this means that if the number of UEs accessing a data stream simultaneously is less than 100, the data stream is considered a cold stream; if the number of UEs accessing a data stream simultaneously is greater than or equal to 100 but less than 1000, the data stream is considered a warm stream; and if the number of UEs accessing a data stream simultaneously is greater than or equal to 1000, the data stream is considered a hot stream. In this case, if the target domain includes data streams A, B, and C, and the number of UEs accessing data stream A simultaneously is 50, the number of UEs accessing data stream B simultaneously is 500, and the number of UEs accessing data stream C simultaneously is 1500, then based on the metric (100, 1000), data stream A is considered a cold stream, data stream B is considered a warm stream, and data stream C is considered a hot stream.

[0104] In the above example, the metric of the target domain name is in the form of a single threshold. Optionally, the metric of the target domain name can also be in the form of a dual threshold. Specifically, in the dual-threshold rule, each heat level corresponds to a set of dual thresholds, and each set of dual thresholds includes an upper threshold and a lower threshold, which means that only when the number of UEs accessing the data stream at the same time exceeds the upper threshold of the current heat level can it be upgraded to the next higher heat level; similarly, only when the number of UEs accessing the data stream at the same time is lower than the lower threshold of the current level will it be downgraded to the next lower level. The setting of dual thresholds ensures that the change of data streams between heat levels will not be too sensitive, but will only occur when certain threshold conditions are met, reducing frequent upgrades and downgrades due to short-term data fluctuations, helping to maintain the stability of the data stream heat level, and reducing unnecessary heat level adjustments.

[0105] 103. The controller determines a target value for the threshold adjustment amount.

[0106] When the real-time bandwidth overhead of a central link exceeds the target bandwidth overhead of that central link, bandwidth overhead costs increase; when the real-time bandwidth overhead of a central link falls below the target bandwidth overhead of that central link, the user experience of the data stream carried by that central link deteriorates. Therefore, in the implementation of this application, the purpose of updating the metric is to bring the real-time bandwidth overhead of the central link as close as possible to the target bandwidth overhead of the central link. Therefore, after generating the threshold adjustment amount, the controller does not immediately update the metric of the target threshold with the threshold adjustment amount. Instead, the controller first determines the target value of the threshold adjustment amount. The target value indicates the difference between the expected bandwidth overhead and the target bandwidth overhead of the N central links. The difference between the expected bandwidth overhead and the target bandwidth overhead of the N central links is based on the difference between the expected bandwidth overhead of each central link and the target bandwidth overhead of that central link. The expected bandwidth overhead of each central link is the expected real-time bandwidth overhead of that central link after the metric of the target threshold is updated with the threshold adjustment amount.

[0107] Optionally, the difference between the expected bandwidth overhead and the target bandwidth overhead of the N core links is directly proportional to the target value of the threshold adjustment. For example, the greater the difference between the expected bandwidth overhead and the target bandwidth overhead of the N core links, the larger the target value of the threshold adjustment; and the smaller the difference between the expected bandwidth overhead and the target bandwidth overhead of the N core links, the smaller the target value of the threshold adjustment.

[0108] Specifically, as can be seen above, in practical applications, a central line often carries different data streams from multiple domain names. Therefore, the real-time bandwidth overhead of the central line is the sum of the real-time bandwidth overheads of all data streams carried by the central line, and the expected bandwidth overhead of the central line is the sum of the expected bandwidth overheads of all data streams carried by the central line. Therefore, the expected bandwidth overhead of the central line includes the expected real-time bandwidth overhead of the target domain name's data stream on the central line after the metric is updated by the threshold adjustment amount.

[0109] Therefore, the greater the difference between the expected bandwidth overhead of each central link and the target bandwidth overhead of that central link, the greater the difference between the expected bandwidth overhead and the target bandwidth overhead of the N central links; the smaller the difference between the expected bandwidth overhead of each central link and the target bandwidth overhead of that central link, the smaller the difference between the expected bandwidth overhead and the target bandwidth overhead of the N central links. Thus, in this embodiment of the present application, the target value of the threshold adjustment amount represents the sum of the adjustment effects of the real-time bandwidth overhead of the N central links when the metric is updated using the threshold adjustment amount.

[0110] In one possible implementation, when the controller determines the target value of the threshold adjustment amount, the controller first determines the difference value for each central line, thereby obtaining N difference values ​​for the N central lines, each difference value indicating the difference between the expected bandwidth overhead of a central line and the target bandwidth overhead of the central line. These N difference values ​​are then added together to obtain the target value of the threshold adjustment amount. Optionally, the difference between the expected bandwidth overhead and the target bandwidth overhead of each central line is directly proportional to the difference value of the central line. For example, the greater the difference between the expected bandwidth overhead and the target bandwidth overhead of a central line, the greater the difference value for the central line; the smaller the difference between the expected bandwidth overhead and the target bandwidth overhead of a central line, the smaller the difference value for the central line.

[0111] For example, please refer to FIG4 , which is a schematic diagram of a possible process for the controller to calculate the difference value of a certain center line in an embodiment of the present application. As shown in FIG4 , a possible process for the controller to calculate the difference value of the center line includes:

[0112] 1031. The controller first calculates the back-to-source ratio of the target domain name at each heat level (total back-to-source bandwidth overhead of the domain name / total edge bandwidth overhead of the domain name) based on the historical bandwidth overhead of the target domain name's data flow on the edge line and the central line.

[0113] 1032. The controller calculates the sum of the expected back-to-source bandwidth costs of the target domain name (equivalent to the sum of the expected back-to-source bandwidth costs of the target domain name when all data streams of the target domain name are divided into various heat levels when the metric is updated with the threshold adjustment amount).

[0114] 1033. The controller calculates the expected real-time bandwidth overhead of the target domain name on a single central line.

[0115] Specifically, because the target domain's data stream may be distributed across multiple central lines, the controller can first calculate the real-time bandwidth overhead of the target domain's data stream and its weight on a single central line. The controller then multiplies the total expected back-to-source bandwidth overhead for the target domain by the weight of the target domain's data stream's real-time bandwidth overhead on each central line. This yields the expected real-time bandwidth overhead of the target domain's data stream on that central line after the metric is updated using the threshold adjustment.

[0116] 1034. The controller accumulates the sum of the expected real-time bandwidth costs of all domain names on the central line to obtain the expected bandwidth cost of the central line.

[0117] 1035. The controller compares the expected bandwidth overhead of the central line with the target bandwidth overhead of the central line to obtain a difference value of the central line.

[0118] It should be understood that the process of calculating the difference value of the center line shown in Figure 4 is only an exemplary description. In actual applications, the difference value of the center line can also be calculated in other ways, and the embodiments of the present application do not limit this.

[0119] In one possible implementation, the controller can determine the difference value of each central line in combination with the cost coefficient and the experience coefficient. Specifically, the controller determines the difference between the expected bandwidth overhead of the central line and the target bandwidth overhead of the central line, and then scales the difference between the expected bandwidth overhead of the central line and the target bandwidth overhead of the central line using the cost coefficient and the experience coefficient of the central line, thereby obtaining the difference value of the central line. Among them, the cost coefficient is obtained based on the billing rules of the central line, and the value of the cost coefficient is greater than or equal to 0. The cost coefficient of each central line can be the same or different. For example, based on the billing rules of the central line, when the CDN service provider is more inclined to reduce the bandwidth overhead cost of the central line, the controller or CDN administrator can increase the value of the cost coefficient, thereby amplifying the difference value of the central line; the experience coefficient is obtained based on the bandwidth demand of the central line, and the value of the experience coefficient is greater than or equal to 0. The experience coefficient of each central line can be the same or different. For example, based on the bandwidth requirements of a central line, if the CDN service provider prefers to improve the bandwidth performance of accessing the central line to meet the user experience of the data stream carried by the central line, the controller or CDN administrator can lower the value of the experience coefficient, thereby reducing the variance of the central line. Thus, the controller combines the cost coefficient and the experience coefficient to determine the variance of each central line. This allows the variance of the central line to reflect the importance of the central line's bandwidth cost and bandwidth performance in the bandwidth cost adjustment process, thereby increasing flexibility in bandwidth cost adjustment.

[0120] In one possible implementation, when the current real-time bandwidth overhead of the central line is greater than or equal to the target bandwidth overhead, in order to avoid the central line's bandwidth overhead being too high, the central line is currently more likely to reduce its real-time bandwidth overhead. At this time, the controller does not need to consider the experience coefficient of the central line, and only calculates the difference value of the central line based on the cost coefficient of the central line, thereby reducing the risk of the central line's bandwidth overhead continuing to increase. On the other hand, when the current real-time bandwidth overhead of the central line is less than the target bandwidth overhead, the central line is currently more likely to increase its real-time bandwidth overhead to meet the user experience of the data stream carried by the central line. At this time, the controller does not need to consider the cost coefficient of the central line, and only calculates the difference value of the central line based on the experience coefficient of the central line, thereby improving the bandwidth performance of the central line and improving the user experience of the data stream carried by the central line.

[0121] In one possible implementation, the cost coefficient of the central link is greater than the experience coefficient of the central link. In this case, the cost coefficient has a greater impact on the central link's variance than the experience coefficient. This means that bandwidth overhead is more important than bandwidth performance. This allows the controller to update the metric based on the threshold adjustment, ensuring that the real-time bandwidth overhead of the central link is as close to the central link's target bandwidth overhead as possible while remaining below the target bandwidth overhead. This ensures bandwidth performance while preventing increases in the central link's bandwidth overhead.

[0122] 104. If the target value of the threshold adjustment amount meets the preset condition, the controller updates the measurement indicator according to the threshold adjustment amount.

[0123] As can be seen from the above, the purpose of updating the metric according to the threshold adjustment amount is to make the real-time bandwidth overhead of the central line as close as possible to the target bandwidth overhead of the central line. In the embodiment of the present application, the target value of the threshold adjustment amount represents the difference between the real-time bandwidth overhead and the target bandwidth overhead of the N central lines when the metric is updated with the threshold adjustment amount. If the target value of the threshold adjustment amount meets the preset conditions, it means that when the metric is updated with the threshold adjustment amount, the real-time bandwidth overhead of the N central lines is sufficiently close to the target bandwidth overhead of the N central lines. Therefore, the controller updates the metric of the target domain name according to the threshold adjustment amount.

[0124] In this embodiment of the present application, when updating the metrics of the target domain name, the controller refers to the difference between the expected bandwidth overhead and the target bandwidth overhead of N central links. This makes the bandwidth overhead adjustment results of each central link predictable and controllable, improving the accuracy of the bandwidth overhead adjustment results and achieving a better adjustment effect. Furthermore, after the metrics of the target domain name are updated, the expected bandwidth overhead of the central link is as close as possible to the target bandwidth overhead, so that the real-time bandwidth overhead of the central link can balance the bandwidth overhead cost and the user experience of the UE when accessing the data stream of the central link.

[0125] On the other hand, the bandwidth overhead adjustment process in the embodiment of the present application is performed by the controller without manual operation, thereby improving the adjustment efficiency of the bandwidth overhead.

[0126] In one possible implementation, the controller pre-configures an upper threshold and a lower threshold for a metric. When the threshold adjustment is applied to update the metric, the updated metric must be greater than the lower threshold and less than the upper threshold, thereby ensuring that the metric remains within a reasonable range.

[0127] In practical applications, the controller can flexibly configure multiple preset conditions to verify whether the threshold adjustment amount meets the requirements. If the target value of the threshold adjustment amount meets the preset condition, the controller updates the metric according to the threshold adjustment amount. Next, two possible preset conditions provided in the embodiments of the present application are introduced respectively.

[0128] Preset condition 1: The controller preconfigures a threshold value representing the difference between the expected bandwidth overhead of the N central links and the target bandwidth overhead. When the target value of the threshold adjustment is less than the threshold value, the difference between the expected bandwidth overhead of the N central links and the target bandwidth overhead meets the requirement when the metric is updated using the threshold adjustment. The controller then updates the metric for the target domain name based on the threshold adjustment.

[0129] Precondition 2: In this scenario, the difference between the expected bandwidth cost and the target bandwidth cost of the N core links is directly proportional to the target value of the threshold adjustment. For example, the larger the difference between the expected bandwidth cost and the target bandwidth cost of the N core links, the larger the target value of the threshold adjustment; the smaller the difference between the expected bandwidth cost and the target bandwidth cost of the N core links, the smaller the target value of the threshold adjustment.

[0130] The controller generates M threshold adjustments for the target domain name and calculates the target value corresponding to each threshold adjustment, obtaining M target values ​​corresponding to the M threshold adjustments, where M is an integer greater than 1. For a description of calculating the target value of the threshold adjustment, please refer to the description of the aforementioned step 103, which will not be repeated here. Then, a target threshold adjustment is determined from the M threshold adjustments. The target value of the target threshold adjustment is the smallest of the M target values. In other words, when the metric is updated with the target threshold adjustment, the difference between the expected bandwidth overhead of the N central lines and the target bandwidth overhead is the smallest among the M threshold adjustments.

[0131] For ease of understanding, the following describes the process of determining the target threshold adjustment amount in an embodiment of the present application, taking the scenario of Preset Condition 2 as an example. In the scenario of Preset Condition 2, after the threshold adjustment amount is generated, the target value of each threshold adjustment amount is calculated using the following formulas (1) to (6).

[0132] First, the parameters in the following formulas (1) to (6) are introduced. The domain name is represented by D = {d1, d2, ..., d i ,…,d M}, the center line set is represented as C = {c1,c2,…,c j ,…,cN}.for The current real-time bandwidth overhead of a domain name is expressed as for The current real-time bandwidth overhead of the central line is expressed as The target bandwidth cost is expressed as The target bandwidth cost flag is S j , where if the current real-time bandwidth overhead of the central line Greater than or equal to the target bandwidth cost Then S j The value is 1, if the current real-time bandwidth overhead of the central line Less than target bandwidth overhead Then S j The value of is 0, and the cost coefficient is The experience coefficient is for and The current real-time bandwidth cost of the domain name on this central line is The weight is expressed as for After updating the metrics with the threshold adjustment, the expected back-to-origin bandwidth cost for this domain name is for After updating the metric by the threshold adjustment amount, the expected bandwidth cost of the central line is

[0133] for Each domain name is set with a threshold adjustment amount, and the upper limit of the metric is ub i , the lower limit of the measurement index is lb i , the metric before the update is td i , the updated metric is for The access bandwidth of each heat level is edge ij , the return bandwidth is return ij , define the return-to-source ratio as ratio ij =return ij / edge ij Obtain the historical access bandwidth overhead and back-to-source bandwidth overhead of the domain name under the hot flow scheduling strategy and cold flow scheduling strategy, and obtain the average hot back-to-source ratio through multiple sets of access bandwidth overhead and back-to-source bandwidth overhead. Compared with cold return Next, the controller obtains the updated metric of the domain name according to the following formulas (1) to (6):

[0134] Target value for threshold adjustment:

[0135] Furthermore, taking the live streaming scenario as an example, The controller divides the data stream into multiple audience levels according to the number of viewers, represented as S = {stage i1 ,stage i2 ,…,stage ij ,…,stage iL For example, [1,10), [10,20), [20,50), [50,100), …, [1000,2000), [2000,3000), [3000,above]. The controller can configure the above metrics at the boundaries of the above audience levels, for example, 10, 20, 50, 100, 1000, 2000, or 3000, so that the same audience level can be classified into the same heat level, ensuring that all data flows in the same audience level belong to the same scheduling strategy.

[0136] In one possible implementation, after the controller updates the metric of the target domain name according to the threshold adjustment amount, the controller uses the updated metric to divide the data flow of the target domain name into corresponding heat levels. Please refer to Figure 5, which is a schematic diagram of the scenario in which the controller updates the heat level of the data flow in an embodiment of the present application. As shown in Figure 5, after the controller executes the bandwidth overhead adjustment method provided in the embodiment of the present application, the controller uses the updated metric to divide the data flow of the target domain name into corresponding heat levels. Next, the controller sends a label of the data flow to the edge node in the CDN architecture, and the label is used to indicate the current heat level of the data flow of the target domain name. So that the edge node executes a scheduling strategy that matches the heat level of the data flow.

[0137] Accordingly, the embodiments of the present application also provide related devices for implementing the above-mentioned solutions. Specifically, please refer to Figure 6, which is a structural diagram of a controller provided in the embodiments of the present application. The controller can be a controller device; or, it can be a chip, chip system, or processor used to support the controller to implement the method; or, the controller can also be a logical node, logical module, or software used to implement all or part of the controller functions. As shown in Figure 6, the controller includes:

[0138] An acquiring unit 201 is configured to acquire a target bandwidth overhead of each of the N core lines, where the target bandwidth overhead of each core line is a real-time bandwidth overhead that the core line is expected to achieve, and N is an integer greater than 1.

[0139] Processing unit 202 is configured to generate a threshold adjustment value for a target domain name, where a data flow of the target domain name is carried on at least one of the N central lines, and the threshold adjustment value is an adjustment value for a metric of the target domain name, where the metric is used to classify the data flow of the target domain name into a plurality of heat levels;

[0140] The processing unit 202 is further configured to determine a target value for the threshold adjustment amount, where the target value indicates a difference between an expected bandwidth overhead of the N central links and a target bandwidth overhead, where the expected bandwidth overhead of each central link is the expected real-time bandwidth overhead of the central link after the metric is updated by the threshold adjustment amount.

[0141] The processing unit 202 is further configured to update the measurement indicator according to the threshold adjustment amount when the target value of the threshold adjustment amount meets a preset condition.

[0142] In a possible implementation, the processing unit 202 is specifically configured to:

[0143] Determine a difference value for each central line to obtain N difference values ​​for the N central lines, each difference value being used to indicate a difference between an expected bandwidth overhead and a target bandwidth overhead of a central line;

[0144] The N difference values ​​are added together to obtain a target value of the threshold adjustment amount.

[0145] In a possible implementation, the processing unit 202 is specifically configured to:

[0146] The difference value of the central line is determined based on the cost coefficient and experience coefficient of each central line. The cost coefficient and experience coefficient are used to scale the difference between the expected bandwidth overhead and the target bandwidth overhead of the central line. The cost coefficient is obtained based on the billing rules of the central line, and the experience coefficient is obtained based on the bandwidth demand of the central line. The value of the cost coefficient is greater than or equal to 0, and the value of the experience coefficient is greater than or equal to 0.

[0147] In a possible implementation, the processing unit 202 is specifically configured to:

[0148] When the current real-time bandwidth cost of the central line is greater than or equal to the target bandwidth cost, determining a difference value of the central line based on a cost coefficient of the central line;

[0149] When the current real-time bandwidth overhead of the central line is less than the target bandwidth overhead, a difference value of the central line is determined based on the experience coefficient of the central line.

[0150] In a possible implementation, the value of the cost coefficient is greater than the value of the experience coefficient.

[0151] In a possible implementation, the expected bandwidth overhead of the central line includes the expected real-time bandwidth overhead of the data flow of the target domain name on the central line after the metric is updated by the threshold adjustment amount.

[0152] In a possible implementation, the processing unit 202 is specifically configured to:

[0153] Generate M threshold adjustment values ​​for the target domain name, where M is an integer greater than 1;

[0154] Obtaining M target values ​​of M threshold adjustment amounts;

[0155] Determine a target domain name adjustment amount, where the target value of the target domain name adjustment amount is the smallest one among the M target values;

[0156] Updates the metric by the target threshold adjustment amount.

[0157] In a possible implementation, the processing unit 202 is specifically configured to:

[0158] When the target value of the threshold adjustment amount is less than the preset threshold, the measurement indicator is updated according to the threshold adjustment amount.

[0159] In a possible implementation, the target domain name is a domain name with the highest real-time bandwidth overhead carried by the N central lines.

[0160] In a possible implementation, the processing unit 202 is further configured to:

[0161] Based on the updated metrics, determine the popularity level of the data flow of the target domain name.

[0162] In a possible implementation, the processing unit 202 is further configured to:

[0163] The label of the data flow of the target domain name is sent to the edge node of the CDN. The label is used to indicate the popularity level of the data flow.

[0164] In a possible implementation, the updated metric is greater than a lower threshold value for the metric and less than an upper threshold value for the metric.

[0165] In a possible implementation, the metric includes a range of the number of user equipments UE accessing the data stream at the same time.

[0166] It should be noted that the information interaction, execution process, etc. between the modules / units in the controller are based on the same concept as the method embodiment corresponding to Figure 3 in this application. For specific contents, please refer to the description in the method embodiment shown above in this application, and will not be repeated here.

[0167] Please refer to Figure 7, which is a schematic diagram of the logical structure of a controller 30 provided in an embodiment of the present application. The controller 30 in Figure 7 can be deployed with the controller described in the embodiment corresponding to Figure 6 to implement the functions implemented by the controller in the embodiment corresponding to Figure 3. The controller 30 includes: a memory 301, a processor 302, a communication interface 303, and a bus 304. The memory 301, processor 302, and communication interface 303 are connected to each other via bus 304.

[0168] The memory 301 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 301 may store a program. When the program stored in the memory 301 is executed by the processor 302, the processor 302 and the communication interface 303 are configured to perform steps 101-104 of the above-described embodiment of the method for adjusting bandwidth overhead.

[0169] The processor 302 can be a central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any combination thereof, to execute relevant programs to implement one or more steps 101-104 of the embodiment of the method for adjusting bandwidth overhead in this application. The steps of the data processing method disclosed in the embodiment of the present application can be executed by a compiler and an executor, wherein the compiler and executor can be executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers, etc. The storage medium is located in the memory 301, and the processor 302 reads the information in the memory 301 and, in combination with its hardware, executes one or more steps 101-104 of the embodiment of the method for adjusting bandwidth overhead in this application.

[0170] The communication interface 303 uses a transceiver device such as, but not limited to, a transceiver to implement communication between the controller 30 and other devices or a communication network.

[0171] Bus 304 provides a pathway for transmitting information between the various components of computer device 30 (e.g., memory 301, processor 302, and communication interface 303). Bus 304 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, control buses, and so on. For ease of illustration, FIG7 shows only one thick line, but this does not imply that there is only one bus or only one type of bus.

[0172] It should be noted that the information interaction, execution process, etc. between the modules / units in the controller are based on the same concept as the method embodiment corresponding to Figure 3 in this application. For specific contents, please refer to the description in the method embodiment shown above in this application, and will not be repeated here.

[0173] The present application also provides a computer program product comprising instructions. The computer program product may be software or a program product comprising instructions that can be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, the computer program product causes the at least one computing device to perform the method described in the embodiment shown in FIG. 3 .

[0174] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned method for executing the embodiment described in Figure 3.

[0175] The communication device provided in the embodiment of the present application can specifically be a chip, which includes: a processing unit and a communication unit. The processing unit can be, for example, a processor, and the communication unit can be, for example, an input / output interface, a pin, or a circuit. The processing unit can execute computer-executable instructions stored in the storage unit to enable the chip to perform the method described in the embodiment shown in Figure 3 above. Optionally, the storage unit is a storage unit within the chip, such as a register, a cache, etc. The storage unit can also be a storage unit located outside the chip within the wireless access device, such as a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM), etc.

[0176] It should be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided in the embodiments of the present application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0177] Through the description of the above embodiments, it is clear to those skilled in the art that the embodiments of the present application can be implemented by means of software plus necessary general hardware, and of course can also be implemented by dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, all functions performed by computer programs can be easily implemented with corresponding hardware, and the specific hardware structures used to implement the same function can also be various, such as analog circuits, digital circuits, or application-specific circuits, etc. However, for the embodiments of the present application, software program implementation is a better implementation method in most cases. Based on such an understanding, the technical solutions of the embodiments of the present application are essentially or partly contributed to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer's floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, training equipment, or network equipment, etc.) to execute the methods described in each embodiment of the present application.

[0178] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0179] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a training device or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website, a computer, a training device or a data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

Claims

1. A method for adjusting bandwidth overhead, characterized in that: include: Obtain a target bandwidth overhead of each of the N central lines, where the target bandwidth overhead of each central line is a real-time bandwidth overhead expected to be achieved by the central line, and N is an integer greater than 1; Generating a threshold adjustment amount for a target domain name, where a data flow of the target domain name is carried on at least one of the N central lines, the threshold adjustment amount being an adjustment amount of a metric of the target domain name, where the metric is used to classify the data flow of the target domain name into a plurality of heat levels; Determining a target value for the threshold adjustment amount, wherein the target value is used to indicate a difference between an expected bandwidth overhead of the N central links and a target bandwidth overhead, the expected bandwidth overhead of each central link being an expected real-time bandwidth overhead of the central link after the metric is updated by the threshold adjustment amount; If the target value of the threshold adjustment amount meets a preset condition, the metric is updated according to the threshold adjustment amount.

2. The method according to claim 1, characterized in that Determining a target value of the threshold adjustment amount includes: Determine a difference value for each of the central lines to obtain N difference values ​​for the N central lines, each difference value being used to indicate a difference between an expected bandwidth overhead and a target bandwidth overhead of a central line; The N difference values ​​are added to obtain a target value of the threshold adjustment amount.

3. The method according to claim 2, characterized in that Determining a variance value for each of the center lines, including: A difference value of the central line is determined based on a cost coefficient and an experience coefficient of each central line, wherein the cost coefficient and the experience coefficient are used to scale the difference between the expected bandwidth overhead and the target bandwidth overhead of the central line. The cost coefficient is obtained based on the billing rule of the central line, and the experience coefficient is obtained based on the bandwidth requirement of the central line. The value of the cost coefficient is greater than or equal to 0, and the value of the experience coefficient is greater than or equal to 0.

4. The method according to claim 3, characterized in that The determining of the difference value of each central route based on the cost coefficient and the experience coefficient of each central route includes: If the current real-time bandwidth cost of the central line is greater than or equal to the target bandwidth cost, determining a difference value of the central line based on a cost coefficient of the central line; If the current real-time bandwidth overhead of the central line is less than the target bandwidth overhead, the difference value of the central line is determined based on the experience coefficient of the central line.

5. The method according to claim 3 or 4, characterized in that The value of the cost coefficient is greater than the value of the experience coefficient.

6. The method according to any one of claims 1 to 5, characterized in that The expected bandwidth overhead of the central line includes the expected real-time bandwidth overhead of the data flow of the target domain name on the central line after the metric indicator is updated with the threshold adjustment amount.

7. The method according to any one of claims 1 to 6, characterized in that Generating a threshold adjustment value for a target domain name includes: Generate M threshold adjustment values ​​for the target domain name, where M is an integer greater than 1; If the target value of the threshold adjustment amount satisfies a preset condition, updating the metric according to the threshold adjustment amount includes: Obtaining M target values ​​of the M threshold adjustment amounts; Determine a target domain name adjustment amount, wherein a target value of the target domain name adjustment amount is a minimum one of the M target values; The metric is updated according to the target threshold adjustment amount.

8. The method according to any one of claims 1 to 6, characterized in that If the target value of the threshold adjustment amount satisfies a preset condition, updating the metric according to the threshold adjustment amount includes: If the target value of the threshold adjustment amount is less than a preset threshold, the metric is updated according to the threshold adjustment amount.

9. The method according to any one of claims 1 to 8, characterized in that The target domain name is the domain name with the highest real-time bandwidth overhead carried by the N central lines.

10. The method according to any one of claims 1 to 9, characterized in that The method further comprises: Based on the updated metric, a popularity level corresponding to the data flow of the target domain name is determined.

11. The method according to claim 10, characterized in that The method further comprises: A label of the data flow of the target domain name is sent to an edge node of the CDN, where the label is used to indicate the popularity level of the data flow.

12. The method according to claims 1 to 11, characterized in that The updated metric is greater than a lower threshold for the metric and less than an upper threshold for the metric.

13. The method according to claims 1 to 12, characterized in that The metric includes a range of the number of user equipments UE accessing the data flow at the same time.

14. A controller, characterized in that: include: an acquiring unit, configured to acquire a target bandwidth overhead of each of the N central lines, where the target bandwidth overhead of each central line is a real-time bandwidth overhead expected to be achieved by the central line, and N is an integer greater than 1; a processing unit, configured to generate a threshold adjustment amount for a target domain name, wherein a data flow of the target domain name is carried on at least one of the N central lines, the threshold adjustment amount being an adjustment amount of a metric of the target domain name, the metric being used to classify the data flow of the target domain name into a plurality of heat levels; The processing unit is further configured to determine a target value of the threshold adjustment amount, wherein the target value is used to indicate a difference between an expected bandwidth overhead of the N central links and a target bandwidth overhead, and the expected bandwidth overhead of each central link is an expected real-time bandwidth overhead of the central link after the metric is updated by the threshold adjustment amount; The processing unit is further configured to update the measurement indicator according to the threshold adjustment amount when the target value of the threshold adjustment amount meets a preset condition.

15. The controller according to claim 14, characterized in that The processing unit is specifically configured to: Determine a difference value for each of the central lines to obtain N difference values ​​for the N central lines, each difference value being used to indicate a difference between an expected bandwidth overhead and a target bandwidth overhead of a central line; The N difference values ​​are added to obtain a target value of the threshold adjustment amount.

16. The controller according to claim 15, characterized in that The processing unit is specifically configured to: A difference value of the central line is determined based on a cost coefficient and an experience coefficient of each central line, wherein the cost coefficient and the experience coefficient are used to scale the difference between the expected bandwidth overhead and the target bandwidth overhead of the central line. The cost coefficient is obtained based on the billing rule of the central line, and the experience coefficient is obtained based on the bandwidth requirement of the central line. The value of the cost coefficient is greater than or equal to 0, and the value of the experience coefficient is greater than or equal to 0.

17. The controller according to claim 16, characterized in that The processing unit is specifically configured to: When the current real-time bandwidth cost of the central line is greater than or equal to the target bandwidth cost, determining a difference value of the central line based on a cost coefficient of the central line; When the current real-time bandwidth overhead of the central line is less than the target bandwidth overhead, the difference value of the central line is determined based on the experience coefficient of the central line.

18. The controller according to claim 16 or 17, characterized in that: The value of the cost coefficient is greater than the value of the experience coefficient.

19. The controller according to any one of claims 14 to 18, characterized in that The expected bandwidth overhead of the central line includes the expected real-time bandwidth overhead of the data flow of the target domain name on the central line after the metric indicator is updated with the threshold adjustment amount.

20. The controller according to any one of claims 14 to 19, characterized in that The processing unit is specifically configured to: Generate M threshold adjustment values ​​for the target domain name, where M is an integer greater than 1; Obtaining M target values ​​of the M threshold adjustment amounts; Determine a target domain name adjustment amount, wherein a target value of the target domain name adjustment amount is a minimum one of the M target values; The metric is updated according to the target threshold adjustment amount.

21. The controller according to any one of claims 14 to 19, characterized in that The processing unit is specifically configured to: When the target value of the threshold adjustment amount is less than a preset threshold, the measurement indicator is updated according to the threshold adjustment amount.

22. The controller according to any one of claims 14 to 21, characterized in that The target domain name is the domain name with the highest real-time bandwidth overhead carried by the N central lines.

23. The controller according to any one of claims 14 to 22, characterized in that The processing unit is further configured to: Based on the updated metric, a popularity level corresponding to the data flow of the target domain name is determined.

24. The controller according to claim 23, wherein: The processing unit is further configured to: A label of the data flow of the target domain name is sent to an edge node of the CDN, where the label is used to indicate the popularity level of the data flow.

25. The controller according to claims 14 to 24, characterized in that The updated metric is greater than a lower threshold for the metric and less than an upper threshold for the metric.

26. The controller according to claims 14 to 25, characterized in that The metric includes a range of the number of user equipments UE accessing the data flow at the same time.

27. A controller, characterized in that: comprising a processor coupled to a memory, The memory is used to store instructions; The processor is configured to execute instructions in the memory so that the controller performs the method according to any one of claims 1 to 13.

28. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 13 is implemented.

29. A computer program product, characterized in that The computer program product stores computer-readable instructions, and when the computer-readable instructions are executed by a processor, the method according to any one of claims 1 to 13 is implemented.

30. A chip, characterized in that: The chip includes a processor coupled to a memory. The memory is used to store instructions; The processor is configured to execute instructions in the memory, so that the chip executes the method according to any one of claims 1 to 13.

Images