Resource scheduling method, system and device based on fttrb multi-user comprehensive perception and medium

Abstract

The application discloses a kind of based on FTTRB multi-user comprehensive perception resource scheduling method, system, equipment and medium, it is related to data processing technical field, method includes: the service type and standard time delay sensitivity of user terminal are acquired, bandwidth demand sequence is acquired;Target bandwidth demand is acquired, and the comprehensive weight to be handled is acquired;Bandwidth volatility is acquired, target time delay sensitivity is acquired, cutting proportion is acquired, and according to cutting proportion and total scheduling bandwidth, guarantee bandwidth and elastic bandwidth are acquired;According to the first scheduling proportion of the comprehensive weight to be handled of the service type of the user terminal corresponding to the target time delay sensitivity of multiple exceeding preset threshold value, the second scheduling proportion of the comprehensive weight to be handled of the service type of all user terminal is acquired, guarantee bandwidth is scheduled according to the first scheduling proportion, and elastic bandwidth is scheduled according to the second scheduling proportion.The application has the advantages of dynamic correction, double-pool resource isolation and weight proportion scheduling.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a resource scheduling method, system, device, and medium based on FTTRB multi-user integrated perception. Background Technology

[0002] In multi-user shared network scenarios of Fiber to the Room (FTTRB), existing resource scheduling methods typically allocate bandwidth based on the static priority of services, without fully considering the dynamic fluctuation characteristics of latency-sensitive services and the fairness contradiction in multi-service mixed scenarios.

[0003] Specifically, fixed priority mechanisms (such as those based solely on preset latency sensitivity levels 1-5) cannot detect real-time business fluctuations. For example, if video conferencing services are still scheduled at the preset level 5 during periods of sudden high traffic, it will crowd out other highly sensitive services; conversely, if low-sensitivity services (such as cloud backup) are handled at level 1 during sudden traffic surges, data loss will occur, but existing methods lack the ability to dynamically adjust sensitivity. Furthermore, bandwidth scheduling does not differentiate between guaranteed and elastic needs, leading to bandwidth idleness due to fixed peak scheduling for fluctuating services (such as periodic peak downloads) and redundant scheduling for stable services (such as continuously low-traffic IoT devices) crowding out resources for highly sensitive services. Additionally, a single weight calculation method (such as based solely on service type) cannot coordinate resource competition among highly sensitive services, especially when multiple services simultaneously trigger high-sensitivity states; static scheduling can easily cause delays in critical services (such as real-time medical monitoring) due to weight calculation errors. Most importantly, in some cases, there is a conflict between the time-varying characteristics of bandwidth fluctuations and the rigid classification of business sensitivity. For example, user A's video conference (preset level 5) only requires 2Mbps during the stable period, but suddenly increases to 10Mbps during the fluctuating period. Existing methods may either over-schedule and waste resources, or under-schedule and cause lag. If user B's cloud backup (preset level 1) suddenly experiences 20Mbps of traffic during background transmission, it will directly preempt the link and cause high-sensitivity service delays. Summary of the Invention

[0004] To address the technical problems in existing technologies, such as the lack of dynamic sensitivity correction based on fluctuation awareness and weighted dual-bandwidth pool scheduling mechanisms, which makes it difficult to accurately identify truly sensitive services, establish elastic resource isolation, and execute hierarchical proportional scheduling, ultimately leading to unreliable latency for critical services, limited throughput for non-critical services, and a significant decline in overall network efficiency and user experience in FTTRB multi-user scenarios, this invention provides a resource scheduling method, system, device, and medium based on FTTRB multi-user comprehensive awareness.

[0005] A resource scheduling method based on FTTRB multi-user comprehensive awareness includes: acquiring the service types of multiple user terminals and the standard latency sensitivity corresponding to the service types, and acquiring the bandwidth demand sequence of each user terminal's service type within a preset processing period before the current time; acquiring the target bandwidth demand of the user terminal's service type based on the bandwidth demand sequence of the user terminal's service type, and acquiring the unprocessed comprehensive weight of the user terminal's service type based on the target bandwidth demand and standard latency sensitivity of the user terminal's service type; acquiring the bandwidth volatility of the user terminal's service type based on the bandwidth demand sequence of the user terminal's service type, and acquiring the target latency sensitivity of the user terminal's service type based on the bandwidth volatility and standard latency sensitivity of the user terminal's service type, acquiring the segmentation ratio based on the proportion of target latency sensitivity exceeding a preset threshold, and acquiring guaranteed bandwidth and elastic bandwidth based on the segmentation ratio and total scheduling bandwidth; acquiring a first scheduling ratio based on the unprocessed comprehensive weight of the service types of multiple user terminals corresponding to target latency sensitivity exceeding the preset threshold, acquiring a second scheduling ratio based on the unprocessed comprehensive weight of all user terminals' service types, scheduling guaranteed bandwidth based on the first scheduling ratio of the user terminal's service type, and scheduling elastic bandwidth based on the second scheduling ratio of the user terminal's service type.

[0006] Optionally, obtaining the target bandwidth requirement for the user terminal's service type based on the bandwidth requirement sequence of the user terminal's service type includes: obtaining the relative change between adjacent bandwidth requirements in the bandwidth requirement sequence; accumulating all relative changes in the bandwidth requirement sequence and dividing by the number of relative changes in the bandwidth requirement sequence to obtain the average change; and adding the last bandwidth requirement in the bandwidth requirement sequence to the average change to obtain the target bandwidth requirement.

[0007] Optionally, obtaining the unprocessed comprehensive weight of the user terminal's service type based on the target bandwidth requirement and standard latency sensitivity of the user terminal's service type includes: multiplying the target bandwidth requirement and standard latency sensitivity of the user terminal's service type to obtain the unprocessed comprehensive weight of the user terminal's service type.

[0008] Optionally, obtaining the bandwidth volatility of the user terminal's service type based on the bandwidth demand sequence of the user terminal's service type includes: obtaining the average value of all bandwidth demands in the bandwidth demand sequence and using it as the average bandwidth demand; obtaining the absolute change between adjacent bandwidth demands in the bandwidth demand sequence; dividing multiple absolute changes in the bandwidth demand sequence by the average bandwidth demand of the bandwidth demand sequence to obtain multiple bandwidth change ratios; and using the maximum value among the multiple bandwidth change ratios corresponding to the bandwidth demand sequence as the bandwidth volatility.

[0009] Optionally, the target latency sensitivity of the user terminal's service type, obtained based on the bandwidth volatility and standard latency sensitivity of the user terminal's service type, is expressed as follows: ;in, For the target latency sensitivity of the service type of the i-th user terminal, For the standard latency sensitivity of the service type of the i-th user terminal, For adjustable latency sensitivity, Let be the bandwidth fluctuation rate of the service type of the i-th user terminal.

[0010] Optionally, obtaining the guaranteed bandwidth and elastic bandwidth based on the sharding ratio and the total scheduling bandwidth includes: multiplying the sharding ratio and the total scheduling bandwidth to obtain the guaranteed bandwidth; and subtracting the guaranteed bandwidth from the total scheduling bandwidth to obtain the elastic bandwidth.

[0011] Optionally, obtaining the first scheduling ratio based on the pending comprehensive weights of the service types of user terminals corresponding to multiple target latency sensitivities exceeding a preset threshold includes: obtaining a first weight sum based on the pending comprehensive weights of the service types of user terminals corresponding to multiple target latency sensitivities exceeding a preset threshold; dividing the pending comprehensive weight of the service type of the j-th target latency sensitivity corresponding to the j-th target latency sensitivity by the first weight sum to obtain the first scheduling ratio of the service type of the j-th target latency sensitivity corresponding to the j-th target latency sensitivity.

[0012] A resource scheduling system based on FTTRB multi-user comprehensive awareness is also provided. The system includes: an acquisition module, used to acquire the service types of multiple user terminals and the corresponding standard latency sensitivity of each service type, and to acquire the bandwidth demand sequence of each user terminal's service type within a preset processing period before the current time; a first data processing module, used to acquire the target bandwidth demand of each user terminal's service type based on the bandwidth demand sequence of the user terminal's service type, and to acquire the pending comprehensive weight of the user terminal's service type based on the target bandwidth demand and standard latency sensitivity of the user terminal's service type; and a second data processing module, used to acquire the bandwidth demand of each user terminal's service type based on the bandwidth demand sequence of the user terminal's service type. The system has a wide volatility range and obtains the target latency sensitivity of the user terminal's service type based on the bandwidth volatility and standard latency sensitivity of the user terminal's service type. It also obtains the slicing ratio based on the proportion of target latency sensitivity exceeding a preset threshold, and obtains guaranteed bandwidth and elastic bandwidth based on the slicing ratio and total scheduling bandwidth. The resource scheduling module is used to obtain a first scheduling ratio based on the pending comprehensive weight of the service types of user terminals corresponding to multiple target latency sensitivities exceeding a preset threshold, obtain a second scheduling ratio based on the pending comprehensive weight of the service types of all user terminals, schedule guaranteed bandwidth based on the first scheduling ratio of the user terminal's service type, and schedule elastic bandwidth based on the second scheduling ratio of the user terminal's service type.

[0013] An electronic device is also provided, comprising: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement a resource scheduling method based on FTTRB multi-user integrated awareness.

[0014] A non-transitory computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements a resource scheduling method based on FTTRB multi-user integrated awareness.

[0015] The beneficial effects of this invention are reflected in:

[0016] The entire resource scheduling method based on FTTRB multi-user comprehensive awareness dynamically adjusts the target latency sensitivity based on historical fluctuation characteristics, breaking through the limitations of static hierarchical classification, accurately identifying truly high-sensitivity services (such as dynamic upgrades of cloud backup under sudden traffic surges), while fluctuation perception predicts service risks, avoiding cascading delays caused by low-sensitivity sudden surges preempting links; furthermore, combined with a dual bandwidth pool (guaranteed pool + elastic pool) dynamically segmented by the proportion of services exceeding the threshold, a physically isolated resource layer is established for critical services. When the proportion of high-sensitivity services decreases, the elastic pool is automatically expanded, releasing idle resources for non-critical services (such as software updates) to obtain basic throughput guarantees according to weight, solving the bandwidth idleness problem caused by peak reservation; furthermore, fluctuation perception predicts service risks, avoiding cascading delays caused by low-sensitivity sudden surges preempting links (such as cloud backup impacting medical monitoring). Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0018] Figure 1 This is a partial flowchart of S1 and S2 of the resource scheduling method S1 and S2 based on FTTRB multi-user integrated awareness of the present invention.

[0019] Figure 2 This is a partial flowchart of S3 in the resource scheduling method based on FTTRB multi-user integrated awareness of the present invention.

[0020] Figure 3 This is a partial flowchart of S4 in the resource scheduling method based on FTTRB multi-user integrated awareness of the present invention.

[0021] Figure 4 This is a schematic diagram illustrating the steps of the resource scheduling method based on FTTRB multi-user integrated awareness according to the present invention;

[0022] Figure 5 This is a schematic diagram of some steps in S2 of the resource scheduling method based on FTTRB multi-user integrated awareness in this invention;

[0023] Figure 6 This is a schematic diagram of a portion of step S3 in the resource scheduling method based on FTTRB multi-user integrated awareness of the present invention;

[0024] Figure 7 This is a schematic diagram of another part of the steps in S3 of the resource scheduling method based on FTTRB multi-user integrated awareness in this invention.

[0025] Figure 8 This is a schematic diagram of a portion of step S4 in the resource scheduling method based on FTTRB multi-user integrated awareness of the present invention;

[0026] Figure 9 This is a block diagram illustrating an electronic device according to an embodiment of the present invention.

[0027] Figure label:

[0028] 700 - Electronic device; 701 - Processor; 702 - Memory; 703 - Multimedia component; 704 - I / O interface; 705 - Communication component. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0030] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0031] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] like Figures 1 to 4 As shown, a resource scheduling method based on FTTRB multi-user comprehensive awareness is provided. In one implementation, the method includes:

[0033] S1. Obtain the service types of multiple user terminals and the standard latency sensitivity corresponding to the service types, and obtain the bandwidth requirement sequence of each user terminal's service type within the preset processing period before the current time.

[0034] S2. Obtain the target bandwidth requirement of the user terminal's service type based on the bandwidth requirement sequence of the user terminal's service type, and obtain the unprocessed comprehensive weight of the user terminal's service type based on the target bandwidth requirement of the user terminal's service type and the standard latency sensitivity.

[0035] S3. Obtain the bandwidth fluctuation rate of the user terminal's service type based on the bandwidth demand sequence of the user terminal's service type, and obtain the target latency sensitivity of the user terminal's service type based on the bandwidth fluctuation rate and standard latency sensitivity of the user terminal's service type, and obtain the slicing ratio based on the proportion of target latency sensitivity exceeding the preset threshold, and obtain the guaranteed bandwidth and elastic bandwidth based on the slicing ratio and the total scheduling bandwidth.

[0036] S4. Obtain a first scheduling ratio based on the comprehensive weight of the service types of user terminals corresponding to multiple target latency sensitivity exceeding the preset threshold, obtain a second scheduling ratio based on the comprehensive weight of the service types of all user terminals, schedule guaranteed bandwidth based on the first scheduling ratio of the service types of user terminals, and schedule elastic bandwidth based on the second scheduling ratio of the service types of user terminals.

[0037] In this embodiment, it should be noted that in S1, the service type and standard latency sensitivity are first identified, identifying the currently active service type and its corresponding inherent quality of service requirements for each user terminal connected to the FTTRB network. Here, "service type" is an abstract classification of network traffic characteristics, such as video conferencing, real-time gaming, online medical monitoring, high-definition video on demand, web browsing, background cloud backup, software update downloads, etc. Each service type has its inherent latency sensitivity characteristics. To address the rigidity of existing technologies that rely solely on preset, static priority scheduling (i.e., standard latency sensitivity), a classification system based on arbitrarily set latency sensitivity levels can be implemented. For example, the standard latency sensitivity for each service type can be graded from 1 to 5. The standard latency sensitivity for each service type represents the minimum latency guarantee level required to ensure the core user experience of that service type under ideal and stable conditions. For instance, user A's ongoing "video conferencing" service is classified as this type and assigned the highest level, "Level 5," of standard latency sensitivity, meaning it has extremely low tolerance for network transmission latency. Meanwhile, user B's background "cloud backup" service is identified as this type and assigned the lowest level, "Level 1," of standard latency sensitivity, indicating that it is not sensitive to latency and that even large latency fluctuations will generally not affect the final completion of its backup task.

[0038] Furthermore, historical bandwidth demand sequences are collected to obtain the bandwidth demand sequence for each identified service type of each user terminal within a preset processing period prior to the current moment. The length of the preset processing period is freely set, such as a few minutes or even tens of minutes. Within this period, the network bandwidth required by the service at each time point (or sampling point) is recorded at a certain sampling frequency (such as per second or per few seconds), ultimately forming a historical bandwidth demand sequence arranged in chronological order. The value of this sequence lies in its characterization of the actual resource consumption pattern and dynamic characteristics of a specific service over a recent period. It not only records the relatively stable bandwidth consumption level of the service during the "stable period" (e.g., the low bandwidth demand of user A's video conference when no one is speaking), but more importantly, it captures the inevitable fluctuations during service operation (which is precisely the key conflict point pointed out in the background technology), such as the sudden high bandwidth demand (peak) generated by user A's video conference when screen sharing is enabled, multiple people speak simultaneously, or high-definition video transitions, or the instantaneous surge in traffic that user B's cloud backup experiences when starting transmission or encountering large file blocks. This fluctuation information is completely recorded in the historical sequence. Obtaining this sequence is the raw data foundation upon which subsequent calculations of target bandwidth requirements and bandwidth volatility depend.

[0039] In S2, building upon the detailed historical bandwidth demand sequence obtained in S1, the target bandwidth demand required for each user terminal's specific service type in the upcoming scheduling cycle is derived from this historical fluctuation data. Specifically, S2 performs a sophisticated trend analysis on the bandwidth demand sequence provided by S1. First, it focuses on the magnitude of bandwidth demand changes (i.e., relative changes) between adjacent sampling points in the sequence, capturing the instantaneous dynamic changes of the service at each time interval; for example, for a video conferencing service, the sequence may record the demand value per second within a minute. These values ​​may fluctuate within a small range, but will show significant jumps at specific moments (such as when screen sharing is enabled). Next (S22), the average value of these adjacent magnitudes of change (average change) is calculated; this average value is not a simple arithmetic average, but reflects the overall trend direction and average intensity of the service's demand changes in the most recent preset period; a positive average change indicates that the service's bandwidth demand is generally trending upward; a negative value indicates a downward trend; and a value close to zero indicates relative stability. Finally, this average change is combined with the latest measured bandwidth demand value (the last bandwidth demand) in the service sequence. By superimposing the average change value, which represents the "possible direction of future change," onto the latest demand value of the "current actual state," the predicted target bandwidth demand is obtained.

[0040] Furthermore, a comprehensive weight for each service type is generated. The goal is to provide a quantifiable "importance" metric for network resource scheduling. This metric must comprehensively consider two key dimensions: the objective demand of the service for network resources (i.e., the target bandwidth demand calculated by S2) and the service's subjective sensitivity to service quality (especially latency) (i.e., the standard latency sensitivity obtained by S1). Specifically, a direct and effective fusion method is adopted: multiplying the target bandwidth demand by the standard latency sensitivity. This achieves amplified priority for resource demand. A large target bandwidth demand for a service means it consumes more shared resources. In a resource-constrained network, the scheduler needs to recognize this behavior. Even for low-sensitivity services, if their demand is large and completely ignored, it may momentarily block the link (e.g., a sudden 20Mbps burst in user B's cloud backup). Therefore, it needs to occupy a basic weight share. A high standard latency sensitivity for a service means it has stringent requirements for the timeliness of data transmission; latency will significantly degrade the user experience (e.g., user A's video conference stuttering). Even if the demand for such services is low (during a stable period), priority should still be given to ensuring their minimum bandwidth and low-latency pathways. The result of multiplication (the overall weight to be processed) amplifies the impact of these two factors, quantifying the overall urgency of a service's network resource supply under the current forecast state: high sensitivity and high demand (such as sudden high-traffic video conferencing) will receive a very high weight, strongly requiring resource guarantees; low sensitivity but high demand (such as sudden large file downloads) will receive a medium weight, indicating that its resource consumption is large but still flexible; high sensitivity but low demand (such as IoT monitoring during a stable period) will also receive a basic but relatively high weight, ensuring its low-latency pathways; low sensitivity and low demand (such as standby software updates) will have the lowest weight.

[0041] In S3, the limitations of the static standard latency sensitivity preset in S1 are overcome. Based on the traffic fluctuation characteristics exhibited in the actual operation of the business, the latency guarantee level (i.e., target latency sensitivity) that the business actually needs is dynamically evaluated and corrected. In this way, the business can accurately identify which businesses really need high-priority network resource guarantees at the moment, thereby solving the problem that the static sensitivity described in the background technology cannot respond to real-time fluctuations.

[0042] Specifically, the bandwidth volatility is first calculated for each service type using the historical bandwidth demand sequence provided by S1. This calculation process is crucial for a deep understanding of service traffic behavior. Specifically: 1) First, the average bandwidth demand of the sequence is calculated, representing the baseline consumption level of the service; 2) Then, the absolute change in bandwidth demand for each pair of adjacent sampling points in the sequence is calculated, capturing the instantaneous change in bandwidth demand over time (whether a sudden increase or decrease); 3) Next, these absolute instantaneous changes are normalized to the service's own average bandwidth level, resulting in a series of bandwidth change ratios. This eliminates the influence of differences in baseline demand for different services and more purely reflects the instability of its traffic pattern (i.e., the magnitude of the fluctuation relative to its own baseline); 4) Finally, the maximum value among these normalized fluctuation ratios is taken as the bandwidth volatility of the service. The selection of this maximum value is extremely critical, as it identifies the most severe instantaneous fluctuation intensity exhibited by the service in the recent period, representing the most unstable and potentially catastrophic risk peak in the service's traffic pattern. For example, a video conferencing service with stable demand most of the time but experiencing a sudden 50% surge in demand will have significantly higher volatility than a backend backup service with moderate demand and a maximum fluctuation of only 5%. This volatility quantifies the intensity of a service's potential resource risk.

[0043] Furthermore, the calculated bandwidth volatility is used to dynamically adjust the preset standard latency sensitivity. Even if a service is preset to a low sensitivity level (e.g., cloud backup is preset to level 1), if its bandwidth volatility is high (e.g., a sudden need for large amounts of transmission), its resource contention during volatility events actually constitutes a real-time threat to highly sensitive services (increased risk of data delay or loss). Therefore, its perceived sensitivity needs to be increased. Similarly, for a service preset to high sensitivity (e.g., video playback is preset to level 4), if the volatility is low during stable periods, its required actual protection level can remain relatively stable. The adjusted result is called the target latency sensitivity. It is based on the standard value and volatility, combined with an adjustable variable (the adjustable variable in the formula) for improvement (the higher the volatility, the greater the potential improvement, but there is an upper limit). For example, if User B's sudden cloud backup (preset level 1, high volatility) occurs, its target latency sensitivity will be dynamically increased (e.g., to level 3) to remind this "low-sensitivity" service that it is potentially disruptive at this moment; while if User A's video playback occurs during a stable low-volatility period (preset level 4), its target latency sensitivity will remain at level 4.

[0044] Furthermore, based on the results of the aforementioned dynamic perception (target latency sensitivity), the limited total scheduling bandwidth resources are physically segmented to form two major resource domains: a guaranteed bandwidth pool and an elastic bandwidth pool, achieving elastic resource isolation. The segmentation logic is as follows: A preset threshold is set; generally, the preset threshold is 0.8 times the maximum value of the latency sensitivity level. For example, if latency sensitivity is defined as level 5 (maximum), then the preset threshold is level 4. Only services with a target latency sensitivity of level 4 or higher are considered high-security-requirement services. S3 calculates the proportion (ratio) of all services in the current network whose target latency sensitivity exceeds this threshold. This proportion (segmentation ratio) is significant because it reflects in real-time how many services (and their importance) are dynamically determined to truly require strict bandwidth supply and low latency (genuinely sensitive services) in the current network environment. A higher proportion means greater pressure on the network for high-security-requirement services. Then, based on this dynamically changing segmentation ratio (representing the intensity of security requirements), the total bandwidth resources are segmented.

[0045] In this way, instead of fixing a certain percentage in advance (such as 30% for protection), the size of the protection pool is adjusted in real time based on the dynamically sensed proportion of current high-sensitivity services. When multiple services in the network simultaneously enter a high-fluctuation, high-sensitivity state (such as multiple users simultaneously starting a video conference and entering a heated discussion), the proportion of protection bandwidth will be automatically increased to ensure that there are enough "dedicated lane" resources to absolutely prioritize the low-latency needs of these services. When there are fewer high-sensitivity services, the protection pool will be reduced accordingly, releasing more resources to the elastic pool and improving the overall resource utilization. The elastic bandwidth pool then becomes a "normal lane" resource shared by all other services (including target sensitivity services whose level is below the threshold after dynamic adjustment, as well as those services that are preset to be low-sensitivity). The existence of this pool solves the problem that low-sensitivity service burst traffic (such as user B's cloud backup) has nowhere to go and can only occupy critical channels, and also provides the possibility of throughput protection for non-critical services during off-peak periods. The existence of the protection pool establishes a resource safety zone for high-sensitivity services, isolating the bandwidth impact risk that may be caused by competition within the elastic pool.

[0046] In S4, firstly, all services with latency sensitivity exceeding a preset threshold are identified (these services are the service targets of the guaranteed bandwidth pool). Then, the total unprocessed comprehensive weight of these high-guarantee-demand services is calculated (called the first weight sum). Next, for each high-guarantee-demand service in the set, its unprocessed comprehensive weight is calculated as a proportion of this first weight sum. This proportion is the first scheduling ratio, which quantifies the relative share of guaranteed resources that the high-sensitivity service should receive within the entire group of high-sensitivity services. For example, if service X has a very high comprehensive weight (reflecting its high sensitivity and high demand), while service Y has a medium comprehensive weight, then the first scheduling ratio for service X will be significantly higher than that for service Y. This means that service X will be allocated a larger share of resources in the guaranteed bandwidth pool.

[0047] Furthermore, S4 allocates and schedules the total resources of the guaranteed bandwidth pool proportionally based on the calculated first scheduling ratio. The guaranteed bandwidth allocated to each high-demand service is equal to the total size of the guaranteed bandwidth pool multiplied by the first scheduling ratio for that service. In this way, the total resource volume of the guaranteed bandwidth pool is fixed during scheduling, and resources within the pool are strictly scheduled according to weighted ratios, unaffected by traffic fluctuations from other services outside the pool. The scheduling process only involves weighted competition and proportional allocation within the high-sensitivity service group, completely isolating it from traffic competition and fluctuations from other services in the elastic bandwidth pool. For example, even if a non-critical service in the elastic bandwidth pool (such as a sudden cloud backup) generates a huge traffic demand, it cannot encroach on the guaranteed bandwidth share already allocated to high-sensitivity service A (such as real-time medical monitoring). Service A receives a fixed amount of guaranteed bandwidth resources corresponding to its weighted ratio.

[0048] Furthermore, unlike the dedicated and prioritized scheduling of the guaranteed bandwidth pool, the scheduling target of the elastic bandwidth pool is all service types. S4 again utilizes the pending comprehensive weights calculated by S2, this time covering all user terminal service types, and calculates the sum of the pending comprehensive weights for all these services (called the second weight sum). Then, for each service (regardless of its target sensitivity), the proportion of its pending comprehensive weight to this second weight sum is calculated. This proportion is the second scheduling ratio. It represents the relative share of elastic resources that the service should receive among all active services in the entire network, based on its overall urgency (demand size + sensitivity). Then, S4, according to the calculated second scheduling ratio, proportionally allocates the total resources of the elastic bandwidth pool to all services (including those highly sensitive services that have already received guaranteed bandwidth scheduling, if they simultaneously make additional demands). The scheduling rule is: elastic bandwidth available to each service = total size of the elastic bandwidth pool * the second scheduling ratio of that service.

[0049] Through this hierarchical proportional scheduling under the dual-pool structure (Guaranteed Pool: dedicated to the first scheduling ratio; Elastic Pool: shared by the second scheduling ratio), S4 ultimately achieves: the minimum latency of highly sensitive critical services is strictly guaranteed, while non-critical services can also obtain improved throughput based on their overall urgency within the limits allowed by overall network resources, thereby solving the multiple technical problems defined in the background technology. S1-S4 constitute a complete closed-loop resource scheduling based on dynamic awareness and weighted integration.

[0050] In summary, the resource scheduling method based on FTTRB multi-user comprehensive awareness dynamically adjusts the target latency sensitivity based on historical fluctuation characteristics, breaking through the limitations of static hierarchical classification, accurately identifying truly high-sensitivity services (such as dynamic upgrades of cloud backup under sudden traffic surges), while fluctuation perception predicts service risks, avoiding cascading delays caused by low-sensitivity sudden surges preempting links; furthermore, combined with a dual-bandwidth pool (guaranteed pool + elastic pool) dynamically segmented by the proportion of services exceeding the threshold, a physically isolated resource layer is established for critical services. When the proportion of high-sensitivity services decreases, the elastic pool is automatically expanded, releasing idle resources for non-critical services (such as software updates) to obtain basic throughput guarantees according to weight, solving the bandwidth idleness problem caused by peak reservation; furthermore, fluctuation perception predicts service risks, avoiding cascading delays caused by low-sensitivity sudden surges preempting links (such as cloud backup impacting medical monitoring).

[0051] like Figure 5 As shown, in one embodiment, obtaining the target bandwidth requirement of the user terminal's service type according to the bandwidth requirement sequence of the user terminal's service type in S2 includes:

[0052] S21. Obtain the relative change between adjacent bandwidth demands in the bandwidth demand sequence;

[0053] S22. Accumulate all relative changes in the bandwidth demand sequence and divide by the number of relative changes in the bandwidth demand sequence to obtain the average change.

[0054] S23. Add the last bandwidth demand in the bandwidth demand sequence to the average change to obtain the target bandwidth demand.

[0055] In this embodiment, it should be noted that in S21, basic processing is performed on the historical bandwidth demand sequence provided in S1, focusing on identifying the bandwidth demand changes at each adjacent time point in the sequence. Specifically, the relative change (difference) in bandwidth values ​​between two adjacent sampling points is calculated. This aims to accurately capture the micro-level, short-term fluctuations in service traffic, such as the sudden increase in demand during a video conference due to a user turning on their camera within a single second. These changes record the instantaneous dynamic characteristics of the service at a very small time scale, providing raw data input for subsequent assessment of the overall trend direction.

[0056] In S22, based on the multiple adjacent relative changes calculated in S21, this step performs statistical analysis. The relative changes between all sampling points are summed and then divided by the total number of these changes (i.e., the number of adjacent point pairs in the sequence). The resulting average change represents the overall average direction and intensity of demand change for this business within the preset period in S1. For example, a sequence that experiences a continuous small increase followed by a large jump may have a positive average change, indicating an overall upward trend. This step aggregates discrete instantaneous fluctuations into a trend-based quantitative indicator, solving the problem that existing methods cannot predict sudden changes.

[0057] In step S23, the results of the first two steps are combined for prediction. The latest measured value in the bandwidth demand sequence (the demand at the last sampling point) is taken, representing the current real-time state of the service. The average change calculated in S22 (representing the predicted future average change trend) is superimposed on this latest measured value. The result of the superposition is the target bandwidth demand. The design philosophy is: future demand ≈ current demand + recent average change trend. This prediction method can respond more intelligently to changes in the service. For example, for video conferencing services, when a significant positive (upward trend) recent average change is detected, the predicted value will be higher than the current value but usually lower than the historical peak, thus avoiding bandwidth idleness caused by the existing fixed peak allocation.

[0058] like Figure 5 As shown, in one implementation, the process of obtaining the unprocessed comprehensive weight of the user terminal's service type in S2 based on the target bandwidth requirement and standard latency sensitivity of the user terminal's service type includes:

[0059] S24. Multiply the target bandwidth requirement and standard latency sensitivity of the user terminal's service type to obtain the overall weight to be processed for the user terminal's service type.

[0060] In this implementation, it should be noted that in S24, the prediction results of S2 (target bandwidth requirement) and the basic classification attributes of S1 (standard latency sensitivity) are strategically integrated. Multiplication is applied directly to these two values ​​to generate the comprehensive weight to be processed. This multiplication operation achieves a double amplification effect: on the one hand, a large target bandwidth requirement indicates that the service consumes more resources (objective demand), and its weight is amplified; on the other hand, a high standard latency sensitivity indicates that the service has a low tolerance for latency (subjective priority), and its weight is also amplified. Thus, highly sensitive and high-demand services (such as video conferencing with sudden traffic surges) will have a much higher weight than low-sensitive and low-demand services (such as standby updates), accurately quantifying the urgency of their comprehensive resource acquisition and providing a core basis for fair proportional scheduling in S4.

[0061] like Figure 6As shown, in one embodiment, obtaining the bandwidth fluctuation rate of the user terminal's service type based on the bandwidth demand sequence of the user terminal's service type in S3 includes:

[0062] S31. Obtain the average value of all bandwidth demands in the bandwidth demand sequence and use it as the average bandwidth demand.

[0063] S32. Obtain the absolute change between adjacent bandwidth demands in the bandwidth demand sequence;

[0064] S33. Divide multiple absolute changes in the bandwidth demand sequence by the average bandwidth demand of the bandwidth demand sequence to obtain multiple bandwidth change ratios.

[0065] S34. Take the maximum value among the multiple bandwidth change ratios corresponding to the bandwidth demand sequence as the bandwidth volatility.

[0066] In this embodiment, it should be noted that in S31, the arithmetic mean of the demand values ​​of all sampling points in the historical bandwidth demand sequence is calculated, which is called the average bandwidth demand. This value represents the steady-state demand baseline of the service within a preset period and serves as the reference standard for subsequent fluctuation analysis. For example, the average demand of video conferencing services during the stable speaking phase is much lower than that during the screen switching phase; this step establishes its benchmark value. This constitutes the normalization basis for volatility calculation.

[0067] In step S32, each pair of adjacent sampling points in the sequence is traversed, and the absolute difference between the bandwidth requirements of the two points is calculated (ignoring directionality). This step precisely quantifies the intensity of instantaneous traffic surges in a continuous time segment. For example, the surge in traffic during the transmission of new file blocks in a cloud backup service is recorded to detect potential resource impact risks.

[0068] In S33 China, each absolute change calculated in S32 is divided by the average bandwidth demand obtained in S31 to generate a set of bandwidth change ratios. This operation eliminates the impact of differences in the traffic base of different services, making the volatility of different services comparable. For example, a sudden surge in video conferencing traffic of 20% (relative to its average) is equivalent to a surge in cloud backup traffic of 50% (relative to its larger average), both mapped to high ratio values.

[0069] In S34, the maximum value among all bandwidth change percentages generated in S33 is selected as the final bandwidth volatility rate. This design focuses on the most extreme abrupt changes in the service over a historical period, avoiding the smoothing effect of averaging on instantaneous peaks. For example, a brief 50% surge in demand for video conferencing will be identified (instead of its average 10% fluctuation), ensuring a keen awareness of impactful traffic from highly sensitive services. This value is directly input into the S3 sensitivity dynamic correction expression.

[0070] In one implementation, the target latency sensitivity of the user terminal's service type, obtained in S3 based on the bandwidth fluctuation rate and standard latency sensitivity of the user terminal's service type, is expressed as follows:

[0071] ;in,

[0072] For the target latency sensitivity of the service type of the i-th user terminal, For the standard latency sensitivity of the service type of the i-th user terminal, For adjustable latency sensitivity, Let be the bandwidth fluctuation rate of the service type of the i-th user terminal.

[0073] In this embodiment, it should be noted that, The logic for retaining the baseline value retains the preset value. (e.g., video conferencing = 5, cloud backup = 1) serves as the computing foundation, ensuring that the inherent priorities of the business are not disrupted. Directly replacing them with dynamic values ​​would cause low-sensitivity businesses (such as IoT monitoring) to incorrectly preempt high-sensitivity resources during sudden fluctuations.

[0074] Furthermore, Linear correction addresses data loss caused by sudden traffic spikes in low-sensitivity services and performance issues in high-sensitivity services. Volatility amplification: The higher the value (e.g., during sudden traffic surges in cloud backups), the better. ), Dynamic correction item A higher value for a given value forcibly increases the target sensitivity (e.g., from 1 to 3). Risk quantification: The actual threat level of a business to resources is positively correlated with the intensity of its sudden occurrence, for example: (Weak volatility) → Correction amount ≈ 0, (Strong fluctuations) → Significantly improve target sensitivity. As a level lever, it increases during congestion (strengthening correction) or decreases during idle periods (avoiding overreaction). Generally, The value is 0.4 times the total number of levels in the standard latency sensitivity classification. For example, if the standard latency sensitivity is divided into 5 levels, .

[0075] Furthermore, The upper bound limit is set to prevent overreactions caused by drastic fluctuations in a single business function. The maximum valid value is 1 (e.g., when (Calculated as 1). To prevent ultra-high frequency fluctuations (such as instantaneous fluctuations). Over-amplifying the correction items can lead to an artificially high level of target sensitivity, while ensuring the baseline resources for highly sensitive businesses are protected.

[0076] like Figure 7As shown, in one embodiment, obtaining the guaranteed bandwidth and elastic bandwidth based on the cutting ratio and total scheduling bandwidth in S3 includes:

[0077] S35. Multiply the cutting ratio and the total scheduling bandwidth to obtain the guaranteed bandwidth;

[0078] S36. Subtract the guaranteed bandwidth from the total scheduling bandwidth to obtain the elastic bandwidth.

[0079] In this embodiment, it should be noted that in S35, the cutting ratio (the proportion of highly sensitive services) determined in S3 is multiplied by the total scheduling bandwidth to obtain the capacity of the guaranteed bandwidth pool. The capacity of this pool fluctuates with the real-time network status: when multiple services experience high fluctuations simultaneously (such as multiple users collectively entering data sharing for video conferencing), the ratio increases and the guaranteed pool is automatically expanded.

[0080] In S36, the total scheduled bandwidth is subtracted from the guaranteed bandwidth generated in S35 to obtain the elastic bandwidth pool capacity. This pool and the guaranteed pool form a complementary dynamic relationship: when highly sensitive services decrease, the proportion of the guaranteed pool decreases, and the elastic pool automatically expands. For example, after a nighttime video conference, the expanded elastic pool absorbs non-critical service traffic such as cloud backups, improving resource utilization.

[0081] like Figure 8 As shown, in one embodiment, obtaining the first scheduling ratio in S4 based on the pending comprehensive weight of the service types of user terminals corresponding to multiple target latency sensitivity values ​​exceeding a preset threshold includes:

[0082] S41. Obtain the first weight sum based on the pending comprehensive weight of the service types of user terminals corresponding to multiple target latency sensitivity exceeding the preset threshold;

[0083] S42. Divide the unprocessed comprehensive weight of the service type of the user terminal corresponding to the j-th target latency sensitivity that exceeds the preset threshold by the first weight sum, and obtain the first scheduling ratio of the service type of the user terminal corresponding to the j-th target latency sensitivity that exceeds the preset threshold.

[0084] In this embodiment, it should be noted that in S41, the overall weights of all services whose target latency sensitivity exceeds a preset threshold are aggregated to form a first weighted sum. This operation essentially constructs a resource demand base for the high-security-demand group, laying the denominator basis for subsequent proportional allocation. For example, when multiple video conferencing and medical monitoring services are simultaneously determined to be highly sensitive, their weights are accumulated to quantify the overall security demand intensity of the group.

[0085] In S42, the j-th target latency sensitivity exceeding the preset threshold is represented as any single target latency sensitivity exceeding the preset threshold, where j is a positive integer and not greater than the number of target latency sensitivities exceeding the preset threshold. The unprocessed comprehensive weight of a single highly sensitive service (j-th) is divided by the sum of the first weights calculated in S41 to generate its dedicated first scheduling ratio. This ratio dynamically reflects the relative resource demand intensity of the service within the highly sensitive group: the larger the weight, the higher the ratio. For example, a video conference with a sudden surge in traffic (weight 10) receives a higher scheduling ratio than stable medical monitoring (weight 3).

[0086] A resource scheduling system based on FTTRB multi-user integrated awareness is also provided, the system comprising:

[0087] The acquisition module is used to acquire the service types of multiple user terminals and the standard latency sensitivity corresponding to the service types, and to acquire the bandwidth requirement sequence of each user terminal's service type within the preset processing period before the current time.

[0088] The first data processing module is used to obtain the target bandwidth requirement of the user terminal's service type according to the bandwidth requirement sequence of the user terminal's service type, and to obtain the unprocessed comprehensive weight of the user terminal's service type according to the target bandwidth requirement of the user terminal's service type and the standard latency sensitivity.

[0089] The second data processing module is used to obtain the bandwidth fluctuation rate of the user terminal's service type according to the bandwidth demand sequence of the user terminal's service type, and to obtain the target latency sensitivity of the user terminal's service type according to the bandwidth fluctuation rate and standard latency sensitivity of the user terminal's service type, and to obtain the cutting ratio according to the proportion of target latency sensitivity exceeding the preset threshold, and to obtain the guaranteed bandwidth and elastic bandwidth according to the cutting ratio and the total scheduling bandwidth.

[0090] The resource scheduling module is used to obtain a first scheduling ratio based on the unprocessed comprehensive weight of the service types of user terminals corresponding to multiple target latency sensitivity exceeding a preset threshold, obtain a second scheduling ratio based on the unprocessed comprehensive weight of the service types of all user terminals, schedule guaranteed bandwidth based on the first scheduling ratio of the service types of user terminals, and schedule elastic bandwidth based on the second scheduling ratio of the service types of user terminals.

[0091] In this embodiment, it should be noted that the specific method of performing the operation in the above-mentioned resource scheduling system based on FTTRB multi-user comprehensive awareness has been described in detail in the embodiments of the resource scheduling method based on FTTRB multi-user comprehensive awareness, and will not be elaborated here.

[0092] Figure 9This is a block diagram of an electronic device according to an exemplary embodiment, illustrating a resource scheduling method based on FTTRB multi-user integrated awareness. Figure 9 As shown, the electronic device 700 may include: a processor 701 and a memory 702. The electronic device 700 may also include one or more of a multimedia component 703, an I / O interface 704 (input / output interface), and a communication component 705.

[0093] The processor 701 controls the overall operation of the electronic device 700 to complete all or part of the steps in the aforementioned resource scheduling method based on FTTRB multi-user integrated awareness. The memory 702 stores various types of data to support the operation of the electronic device 700. This data may include, for example, instructions for any application or method operating on the electronic device 700, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 702 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 702 or transmitted via communication component 705. The audio component also includes at least one speaker for outputting audio signals. I / O interface 704 provides an interface between processor 701 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 705 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0094] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the resource scheduling method based on FTTRB multi-user integrated perception described above.

[0095] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided. When executed by a processor, these program instructions implement the steps of the above-described FTTRB-based multi-user integrated awareness resource scheduling method. For example, the computer-readable storage medium may be the memory 702 including the program instructions, which may be executed by the processor 701 of the electronic device 700 to complete the above-described FTTRB-based multi-user integrated awareness resource scheduling method.

[0096] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for executing the above-described FTTRB-based multi-user integrated awareness resource scheduling method when executed by the programmable device.

[0097] The preferred embodiments of the present disclosure have been described in detail above with reference to the accompanying drawings. However, the present disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of the present disclosure, various simple modifications can be made to the technical solutions of the present disclosure, and these simple modifications all fall within the protection scope of the present disclosure.

[0098] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0099] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A method for resource scheduling based on FTTRB multi-user comprehensive perception, characterized in that, The method comprises the following steps: obtaining the service type of each user terminal and the standard time delay sensitivity corresponding to the service type, and obtaining the bandwidth demand sequence of the service type of each user terminal within a preset processing period before the current time; obtaining the target bandwidth demand of the service type of the user terminal according to the bandwidth demand sequence of the service type of the user terminal, and obtaining the to-be-processed comprehensive weight of the service type of the user terminal according to the target bandwidth demand of the service type of the user terminal and the standard time delay sensitivity; obtaining the bandwidth fluctuation rate of the service type of the user terminal according to the bandwidth demand sequence of the service type of the user terminal, obtaining the target time delay sensitivity of the service type of the user terminal according to the bandwidth fluctuation rate of the service type of the user terminal and the standard time delay sensitivity, obtaining the cutting proportion according to the proportion of the target time delay sensitivity exceeding the preset threshold, and obtaining the guarantee bandwidth and the elastic bandwidth according to the cutting proportion and the total scheduling bandwidth; obtaining the first scheduling proportion according to the to-be-processed comprehensive weight of the service type of the user terminal corresponding to the multiple target time delay sensitivities exceeding the preset threshold, obtaining the second scheduling proportion according to the to-be-processed comprehensive weight of the service type of all user terminals, scheduling the guarantee bandwidth according to the first scheduling proportion of the service type of the user terminal, and scheduling the elastic bandwidth according to the second scheduling proportion of the service type of the user terminal.

2. The resource scheduling method based on FTTRB multi-user comprehensive perception according to claim 1, characterized in that, The method comprises the following steps: obtaining the relative change amount between adjacent bandwidth demands in the bandwidth demand sequence; accumulating all the relative change amounts in the bandwidth demand sequence and dividing by the number of the relative change amounts in the bandwidth demand sequence to obtain the average change amount; adding the last bandwidth demand in the bandwidth demand sequence to the average change amount to obtain the target bandwidth demand. 3.The method of claim 1, wherein, The method comprises the following steps: multiplying the target bandwidth demand of the service type of the user terminal and the standard time delay sensitivity to obtain the to-be-processed comprehensive weight of the service type of the user terminal.

4. The method of claim 1, wherein, The method comprises the following steps: obtaining the average value of all the bandwidth demands in the bandwidth demand sequence as the average bandwidth demand; obtaining the absolute change amount between adjacent bandwidth demands in the bandwidth demand sequence; dividing the multiple absolute change amounts in the bandwidth demand sequence by the average bandwidth demand of the bandwidth demand sequence to obtain the multiple bandwidth change proportions; taking the maximum value of the multiple bandwidth change proportions corresponding to the bandwidth demand sequence as the bandwidth fluctuation rate.

5. The method of claim 1, wherein, The method comprises the following steps: ; wherein, a target latency sensitivity for a service type of the i-th user terminal, a standard latency sensitivity for a service type of the i-th user terminal, a latency sensitivity adjustability, a bandwidth fluctuation rate for a service type of the i-th user terminal.

6. The method of claim 1, wherein, The method comprises the following steps: multiplying the cutting proportion and the total scheduling bandwidth to obtain the guarantee bandwidth; subtracting the guarantee bandwidth from the total scheduling bandwidth to obtain the elastic bandwidth.

7. The method of claim 1, wherein, The method comprises the following steps: According to the first weight sum of the to-be-processed comprehensive weights of the service types of the user terminals corresponding to the target delay sensitivities exceeding the preset threshold, a first scheduling proportion is obtained. The to-be-processed comprehensive weight of the service type of the jth user terminal corresponding to the target delay sensitivity exceeding the preset threshold is divided by the first weight sum, and a first scheduling proportion of the service type of the jth user terminal corresponding to the target delay sensitivity exceeding the preset threshold is obtained.

8. A resource scheduling system based on FTTRB multi-user comprehensive perception, characterized in that, The system comprises: The acquisition module is configured to acquire the service types of the user terminals and the standard delay sensitivities corresponding to the service types, and acquire a bandwidth demand sequence of each service type of the user terminals within a preset processing period before a current time; The first data processing module is configured to acquire a target bandwidth demand of the service type of the user terminal according to the bandwidth demand sequence of the service type of the user terminal, and acquire a to-be-processed comprehensive weight of the service type of the user terminal according to the target bandwidth demand of the service type of the user terminal and the standard delay sensitivity; The second data processing module is configured to acquire a bandwidth fluctuation rate of the service type of the user terminal according to the bandwidth demand sequence of the service type of the user terminal, acquire a target delay sensitivity of the service type of the user terminal according to the bandwidth fluctuation rate of the service type of the user terminal and the standard delay sensitivity, acquire a cutting proportion according to a proportion of the target delay sensitivities exceeding the preset threshold, and acquire a guarantee bandwidth and an elastic bandwidth according to the cutting proportion and a total scheduling bandwidth; The resource scheduling module is configured to acquire a first scheduling proportion according to the to-be-processed comprehensive weights of the service types of the user terminals corresponding to the target delay sensitivities exceeding the preset threshold, acquire a second scheduling proportion according to the to-be-processed comprehensive weights of the service types of all the user terminals, schedule the guarantee bandwidth according to the first scheduling proportion of the service type of the user terminal, and schedule the elastic bandwidth according to the second scheduling proportion of the service type of the user terminal.

9. An electronic device, comprising: The system comprises: A memory having a computer program stored thereon; A processor configured to execute the computer program in the memory to implement the resource scheduling method based on FTTRB multi-user comprehensive perception according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the resource scheduling method based on FTTRB multi-user comprehensive perception according to any one of claims 1 to 7.

Images