A network traffic dynamic control method and system based on priority scheduling

Abstract

The application relates to a network traffic dynamic control method and system based on priority scheduling, which comprises the following steps: collecting real-time network traffic data packets and extracting real-time traffic feature vectors, generating a queue based on initial priority weight matching of a historical database; obtaining a basic dynamic adjustment factor by calculating a real-time load state, and generating a timeout risk compensation value according to the proportion of the queuing waiting time and the protocol timeout threshold of low-priority data packets, and superimposing the two to obtain a target priority weight; generating a scheduling instruction set according to the weight proportion and distributing the scheduling instruction set to network equipment for execution; finally, extracting an actual transmission delay according to the returned performance log, calculating the deviation value of the actual transmission delay and an expected delay to generate a weight update parameter, and feeding back the weight update parameter to the historical database to update the matching logic. The application takes into account the global link load balancing and the timeout retransmission risk prevention and control of low-priority traffic, and realizes the precision and adaptive dynamic optimization of the network traffic scheduling strategy.

Description

Technical Field

[0001] This application relates to the field of network communication and traffic management technology, and in particular to a method and system for dynamic control of network traffic based on priority scheduling. Background Technology

[0002] With the rapid development of internet technology and cloud computing, the types of data carried by modern networks have experienced explosive growth and high heterogeneity. They have evolved from traditional web browsing and file downloads to complex business forms encompassing high-definition video conferencing, cloud computing interaction, industrial IoT control, and virtual reality, all of which have stringent requirements for network transmission quality. In this complex network ecosystem, different service flows have vastly different demands for bandwidth resources and tolerance for transmission latency. To ensure the communication quality of core services under limited and dynamically fluctuating physical link bandwidth resources, priority-based flow control mechanisms have emerged and become a core means of network service quality management. This mechanism typically relies on the identification of data packet characteristics to allocate initial priority weights and then slices bandwidth resources according to the weight ratios to ensure that highly sensitive services can obtain transmission channels first, thereby maintaining the overall orderliness and basic efficiency of the network operation at a macro level.

[0003] However, in real-world, complex network environments, existing priority scheduling mechanisms reveal core flaws such as rigid and outdated underlying scheduling experience when faced with rapid iterations of network services and dynamic evolution of traffic patterns. Traditional flow control systems rely heavily on pre-configured static rules or fixed records in historical experience databases when assigning initial priority weights to data packets. This isolated matching mechanism lacks a deep understanding of actual transmission performance in real-world network environments and the ability to provide closed-loop feedback.

[0004] Furthermore, after bandwidth allocation, existing technologies often rely solely on macroscopic indicators such as packet loss rate for coarse-grained strategy evaluation, failing to quantify the deep scheduling errors caused by unreasonable initial weight allocation. Lacking a dynamic, self-evolving channel that binds microscopic delay deviations to specific traffic characteristics to reverse-correct historical scheduling rules, the underlying initial priority weight matching logic remains passive and rigid. It cannot scientifically iterate and optimize with fluctuations in network link status and subtle changes in service characteristics, making it highly susceptible to inaccurate initial weight allocation when facing complex and ever-changing network transmission demands. This leads to overall low network resource scheduling efficiency and degraded quality of critical services. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method and system for dynamic network traffic control based on priority scheduling.

[0006] Firstly, this application provides a method for dynamic network traffic control based on priority scheduling, employing the following technical solution:

[0007] Collect real-time network traffic data packets and extract their features to generate traffic feature vectors;

[0008] Based on the historical performance database, an initial priority weight is matched to the traffic feature vector, the initial priority weight is associated with the corresponding data packet that generated the traffic feature vector, and an initial traffic queue is generated based on the associated data packets.

[0009] Obtain the real-time load status of the current link and the queuing time of each data packet in the initial traffic queue, and calculate the basic dynamic adjustment factor based on the real-time load status;

[0010] For low-priority data packets in the initial traffic queue, the ratio of queuing time to a preset protocol timeout threshold is calculated to generate a timeout risk compensation value. This timeout risk compensation value is then added to the initial priority weight and combined with the basic dynamic adjustment factor to generate a target priority weight. For other data packets, the target priority weight is generated directly by combining the basic dynamic adjustment factor and the initial priority weight.

[0011] Based on the target priority weight, the available bandwidth resources within the current scheduling time window are divided according to the weight ratio, and a scheduling instruction set containing the bandwidth quota corresponding to each data packet is generated.

[0012] The scheduling instruction set is sent to the network device to execute traffic transmission, and the transmission performance log returned by the network device during the transmission process is received;

[0013] Extract the actual transmission delay from the transmission performance log, calculate the deviation between the actual transmission delay and the expected transmission delay, and generate weight update parameters based on the deviation.

[0014] The weight update parameters are fed back to the historical performance database to update the matching logic of the initial priority weights.

[0015] By adopting the above technical solution, network traffic control has achieved a leap from static priority to dynamic closed-loop optimization. Based on multi-dimensional traffic feature vectors, initial weights are matched using historical experience. Target weights are generated through dual adjustments of dynamic link load factors and low-priority timeout risk compensation. Bandwidth is dynamically allocated according to the weight ratio, and historical matching logic is iteratively optimized through transmission performance feedback. This technical solution reduces the invalid occupation of low-priority traffic, effectively improves bandwidth utilization, reduces the latency of critical flows to prioritize high-sensitivity services, enhances network adaptability, and avoids resource scarcity and retransmission storms caused by low-priority traffic not being scheduled for extended periods through timeout risk compensation. Ultimately, it achieves the goal of refined and intelligent scheduling of network resources.

[0016] Secondly, this application provides a network traffic dynamic control system based on priority scheduling, which adopts the following technical solution:

[0017] The traffic feature extraction module is used to collect real-time network traffic data packets and extract features to generate traffic feature vectors;

[0018] The initial priority matching module is used to match initial priority weights to the traffic feature vector based on the historical performance database, associate the initial priority weights with the corresponding data packets that generated the traffic feature vector, and generate an initial traffic queue based on the associated data packets.

[0019] The dynamic adjustment factor calculation module is used to obtain the real-time load status of the current link and the queuing waiting time of each data packet in the initial traffic queue, and calculate the basic dynamic adjustment factor based on the real-time load status.

[0020] The target priority weight generation module is used to calculate the ratio of queuing time to a preset protocol timeout threshold for low-priority data packets in the initial traffic queue, generate a timeout risk compensation value, add the timeout risk compensation value to the initial priority weight, and generate a target priority weight by combining it with the basic dynamic adjustment factor; for other data packets, the target priority weight is generated directly by combining the basic dynamic adjustment factor and the initial priority weight.

[0021] The bandwidth quota scheduling module is used to divide the available bandwidth resources within the current scheduling time window according to the target priority weight and the weight ratio, and generate a scheduling instruction set containing the bandwidth quota corresponding to each data packet.

[0022] The scheduling execution and log receiving module is used to send the scheduling instruction set to the network device to execute traffic transmission, and to receive the transmission performance log returned by the network device during the transmission process;

[0023] The weight update parameter generation module is used to extract the actual transmission delay from the transmission performance log, calculate the deviation between the actual transmission delay and the expected transmission delay, and generate weight update parameters based on the deviation.

[0024] The weight matching logic update module is used to feed back the weight update parameters to the historical performance database to update the matching logic of the initial priority weight.

[0025] Thirdly, this application provides a computer-readable storage medium, which adopts the following technical solution:

[0026] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as in any of the methods in the first aspect.

[0027] In summary, this application includes at least one of the following beneficial technical effects: by accurately anchoring the initial weights through multi-dimensional feature vectors combined with historical experience, the macro-level dynamic adjustment factor based on real-time link load is superimposed with the micro-level compensation value for timeout risk of low-priority data packets. While ensuring low-latency transmission of highly sensitive services, it effectively curbs the protocol retransmission avalanche effect triggered by long-term resource squeezing of low-priority traffic. By using the refined deviation between the actual transmission latency and the dynamically expected latency to drive the continuous iteration of historical matching logic, it not only improves the refined configuration efficiency of the entire network bandwidth resources and the overall transmission stability, but also achieves the organic unity of absolute fairness and relative efficiency in scheduling. Furthermore, it endows the network scheduling system with intelligent vitality for adaptive error correction and continuous evolution in the face of complex and ever-changing business evolution. Attached Figure Description

[0028] Figure 1 This is a first flowchart of a priority-based network traffic dynamic control method according to one embodiment of this application.

[0029] Figure 2 This is a second flowchart illustrating a priority-based network traffic dynamic control method according to one embodiment of this application.

[0030] Figure 3 This is a third flowchart illustrating a priority-based network traffic dynamic control method according to one embodiment of this application.

[0031] Figure 4 This is a schematic diagram of the fourth process of a priority-based network traffic dynamic control method according to one embodiment of this application.

[0032] Figure 5 This is a fifth flowchart of a priority-based network traffic dynamic control method according to one embodiment of this application.

[0033] Figure 6 This is a schematic diagram of the sixth process of a priority-based network traffic dynamic control method according to one embodiment of this application.

[0034] Figure 7 This is a schematic diagram of the seventh process of a priority-based network traffic dynamic control method according to one embodiment of this application.

[0035] Figure 8 This is the eighth flowchart of a priority-based network traffic dynamic control method according to one embodiment of this application. Detailed Implementation

[0036] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-8 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0037] This application discloses a method for dynamic control of network traffic based on priority scheduling.

[0038] Reference Figure 1 A method for dynamic network traffic control based on priority scheduling, the specific method includes:

[0039] Step S101: Collect real-time network traffic data packets and extract features to generate traffic feature vectors;

[0040] The process involves parsing the network and transport layer headers of data packets to extract the five-tuple information (source IP, destination IP, source port, destination port, and transport layer protocol type). This is the fundamental element that uniquely identifies a network session and can distinguish between different service flows (such as video conferencing and file downloading). At the same time, the packet length (reflecting the amount of data transmitted in a single transaction) and arrival time interval (reflecting the burst characteristics of traffic, such as short-interval dense packets which may be real-time streams) are extracted.

[0041] Furthermore, after identifying the application layer protocol type (such as HTTP, FTP, RTSP), the latency sensitivity level (such as high sensitivity for video streaming and low sensitivity for email transmission) and bandwidth requirement level (such as high bandwidth requirement for downloading and low bandwidth requirement for instant messaging) of the data packet are determined through a pre-configured protocol type mapping table.

[0042] Finally, the above five-tuple, packet length, arrival time interval, latency sensitivity level, and bandwidth requirement level are combined into a traffic feature vector to achieve a full-dimensional digital representation of traffic "identity-form-business attributes," solving the problem that traditional single-dimensional (such as classification by port only) classification cannot adapt to complex network scenarios.

[0043] Step S102: Match initial priority weights to traffic feature vectors based on historical performance database, associate the initial priority weights with the corresponding data packets that generate traffic feature vectors, and generate initial traffic queues based on the associated data packets.

[0044] The historical performance database stores the correlation data between past traffic feature vectors and actual transmission performance (such as latency, bandwidth utilization, and packet loss rate). When the system extracts and generates new traffic feature vectors from data packets, the system finds the historical traffic record with the closest features in the database through similarity matching (such as cosine similarity calculation) and assigns the initial priority weight (weight value based on historical performance optimization) corresponding to the record to the new traffic.

[0045] Subsequently, all data packets are sorted in descending order of their initial priority weights to generate an initial traffic queue. This mechanism avoids the blindness of relying entirely on real-time calculations. Especially for newly emerging traffic types, the initial priority can be quickly located by leveraging optimization experience from similar historical traffic types, reducing performance fluctuations during the initial scheduling phase.

[0046] Step S103: Obtain the real-time load status of the current link and the queuing time of each data packet in the initial traffic queue, and calculate the basic dynamic adjustment factor based on the real-time load status.

[0047] This step aims to quantify and dynamically adjust requirements by comparing link load with historical benchmarks, providing a global basis for adjusting priority weights.

[0048] First, the real-time load status includes the current link bandwidth utilization (the proportion of bandwidth used to total bandwidth) and transmission delay (the time from when a data packet is enqueued to when it begins transmission). These two metrics directly reflect the degree of link congestion. At the same time, the queuing time of each data packet is obtained from the initial traffic queue (the cumulative time from when it entered the queue to the current moment).

[0049] Next, historical baseline bandwidth utilization and historical baseline transmission delay (i.e., the load reference value of this type of traffic under ideal conditions) associated with the current traffic feature vector are extracted from the historical performance database. The first ratio (current bandwidth utilization / historical baseline bandwidth utilization) and the second ratio (current transmission delay / historical baseline transmission delay) are calculated, and a basic dynamic adjustment factor is generated by weighted summation (e.g., bandwidth utilization ratio weighted at 0.6, transmission delay ratio weighted at 0.4).

[0050] Understandably, when the current load is higher than the historical baseline (ratio > 1), the basic dynamic adjustment factor increases, indicating that congestion needs to be alleviated by increasing the weight of high-priority traffic; conversely, the factor decreases to avoid excessive resource contention and achieve dynamic adaptation between load and priority.

[0051] Step S104: For low-priority data packets in the initial traffic queue, calculate the ratio of queuing time to the preset protocol timeout threshold to generate a timeout risk compensation value, add the timeout risk compensation value to the initial priority weight, and combine it with the basic dynamic adjustment factor to generate the target priority weight; for other data packets, directly combine the basic dynamic adjustment factor and the initial priority weight to generate the target priority weight.

[0052] This step focuses on preventing timeout risks for low-priority traffic, balancing fairness and network stability through a compensation mechanism, and combining global load adjustment with local risk compensation to form the target priority weight that ultimately guides resource allocation.

[0053] Specifically, firstly, data packets with initial priority weights lower than a preset weight threshold (i.e., low-priority data packets) are filtered to avoid excessive intervention in high-priority traffic. Secondly, the maximum retransmission timeout corresponding to the transport layer protocol of the data packet is queried from a pre-configured protocol parameter library and used as the protocol timeout threshold (e.g., 200ms-500ms for TCP). This is the maximum allowed waiting time specified by the protocol; exceeding the timeout will trigger retransmission and exacerbate congestion. The protocol parameter library contains a pre-configured mapping relationship between transport layer protocols and maximum retransmission timeout times.

[0054] Next, the proportion of queuing time to the protocol timeout threshold is calculated. If the proportion exceeds the pre-configured safety proportion threshold (e.g., 80%), it indicates that the traffic is close to the timeout risk threshold. At this time, the excess part (proportion - safety threshold) is converted into a timeout risk compensation value through a linear mapping function (e.g., if it exceeds 10%, the compensation value is 0.1); if it does not exceed the threshold, the compensation value is zero.

[0055] Understandably, if low-priority traffic is queued for a long time and approaches timeout, it may cause an avalanche effect due to retransmission. The compensation value reduces the probability of timeout by temporarily increasing its priority (adding to the subsequent weights), and only intervenes when the risk is high to avoid abusing compensation resources.

[0056] Subsequently, the timeout risk compensation value calculated for low-priority data packets (only valid for this type of data packet) is added to the basic dynamic adjustment factor, that is: target priority weight = initial priority weight × basic dynamic adjustment factor + timeout risk compensation value.

[0057] Understandably, this superposition logic embodies the dual correction that this application aims to achieve: the basic dynamic adjustment factor adjusts the priority benchmark of all traffic from the perspective of the overall link load, while the compensation value locally raises the priority of specific low-priority traffic from the perspective of individual timeout risk. The combination of the two makes the priority weight reflect both the macro network status and the urgency of micro traffic, avoiding the limitations of a single adjustment dimension.

[0058] In addition, for data packets whose initial priority weight is not lower than the preset weight threshold (i.e., other data packets), the target priority weight can be obtained by directly multiplying the initial priority weight by the basic dynamic adjustment factor.

[0059] Step S105: Based on the target priority weight, the available bandwidth resources within the current scheduling time window are divided according to the weight ratio, and a scheduling instruction set containing the bandwidth quota corresponding to each data packet is generated.

[0060] This step achieves dynamic bandwidth allocation through a weight-resource linear mapping, with the core principle being resource allocation based on contribution. First, the current scheduling time window duration is dynamically adjusted based on link load volatility (the standard deviation of real-time load): when load volatility is high (e.g., greater than a pre-configured link load volatility threshold), the current scheduling time window is shortened to the first duration (e.g., 10ms) to improve response speed; when load volatility is low (less than or equal to the link load volatility threshold), the current scheduling time window is extended to the second duration (e.g., 50ms) to reduce scheduling overhead.

[0061] Subsequently, the total available bandwidth resources within the current scheduling time window are obtained, the target priority weight of each data packet is calculated as a percentage of the total weight, the total bandwidth is allocated to each data packet according to this percentage (e.g., if the weight percentage is 30%, then 30% of the bandwidth is allocated), and a bandwidth quota instruction is generated.

[0062] Finally, the packet identification information (such as the 5-tuple hash value) and the corresponding bandwidth quota are encapsulated to form a scheduling instruction set. This mechanism ensures that high-weight traffic gets more bandwidth, while adapting to network fluctuations through dynamic time windows and improving resource allocation efficiency.

[0063] Step S106: Send the scheduling instruction set to the network device to execute traffic transmission, and receive the transmission performance log returned by the network device during the transmission process;

[0064] Specifically, the scheduling instruction set is issued to network devices such as routers and switches through network management interfaces (such as SNMP and NETCONF). The devices schedule the transmission of data packets according to the bandwidth quota in the instruction (such as token bucket shaping and queue scheduling).

[0065] During transmission, the device records transmission performance logs, including key indicators such as actual transmission latency (time from dequeue to receiver confirmation), number of packet losses, and number of retransmissions. After execution, the logs are returned to the system to ensure that the system obtains the execution results in a real network environment, rather than theoretical calculations, thus laying the foundation for subsequent deviation analysis.

[0066] Step S107: Extract the actual transmission delay from the transmission performance log, calculate the deviation between the actual transmission delay and the expected transmission delay, and generate weight update parameters based on the deviation.

[0067] Specifically, the actual transmission latency is first extracted from the transmission performance logs, then the expected transmission latency is obtained, and the deviation between the actual and expected latency (actual - expected) is calculated. The deviation values ​​of all data packets within the current scheduling time window are then statistically analyzed, and the overall deviation is quantified using the root mean square error (RMSE). If the RMSE is greater than the pre-configured error tolerance threshold (e.g., 20ms), a weight penalty coefficient (reflecting the direction and intensity of the weight's influence on the deviation) is calculated according to the pre-configured deviation-penalty mapping relationship and used as a weight update parameter. It can be understood that the larger the deviation, the more significant the penalty coefficient, pointing to the direction of weight adjustment (e.g., high deviation corresponds to high weight that needs to be reduced), achieving precise tracing of "effect-cause".

[0068] In some embodiments, the step of obtaining the expected transmission delay includes: querying a delay level mapping table based on the delay sensitivity level in the traffic feature vector to obtain the expected transmission delay baseline value (e.g., 50ms for high delay sensitivity), and correcting the expected transmission delay baseline value in combination with the link transmission delay in the real-time load status (e.g., if the current delay is 10ms, it is expected to be adjusted to 60ms) to obtain the dynamic expected transmission delay.

[0069] Step S108: Feed back the weight update parameters to the historical performance database to update the matching logic of the initial priority weights.

[0070] In this process, after feeding back the weight update parameters (such as the penalty coefficient) to the historical performance database, the system extracts the target traffic feature vector (i.e. the traffic feature that caused the high deviation) associated with the deviation, applies the penalty coefficient to adjust the initial priority weight associated with it (e.g., the original weight of 0.8 is adjusted to 0.6), and overwrites and stores the updated "feature vector-weight" association mapping relationship.

[0071] This mechanism enables the historical database to continuously absorb new experiences, avoiding matching failures caused by static historical data. For example, if the latency of a certain type of traffic increases due to protocol upgrades, the system will gradually reduce its initial weight through multiple deviation feedbacks, achieving self-evolution of "practice-learning-optimization".

[0072] The above implementation achieves a leap from static priority to dynamic closed-loop optimization in network traffic control. Based on multi-dimensional traffic feature vectors, it matches initial weights using historical experience. Target weights are generated through dual adjustments of dynamic link load factors and low-priority timeout risk compensation. Bandwidth is dynamically allocated according to the weight ratio, and historical matching logic is iteratively optimized through transmission performance feedback. This technical solution reduces the invalid occupation of low-priority traffic, effectively improves bandwidth utilization, reduces critical flow latency to prioritize high-sensitivity services, enhances network adaptability, and avoids resource scarcity and retransmission storms caused by low-priority traffic not being scheduled for extended periods through timeout risk compensation. Ultimately, it achieves the goal of refined and intelligent scheduling of network resources.

[0073] Reference Figure 2 As one implementation of step S103, the step of calculating the basic dynamic adjustment factor based on real-time load status includes:

[0074] Step S201: Extract the current link bandwidth utilization and current transmission delay from the real-time load status as current performance indicators;

[0075] In complex network environments, relying solely on bandwidth utilization may overlook the hidden congestion caused by micro-bursts (such as high latency caused by idle bandwidth but queue backlog), while focusing only on latency may fail to distinguish between link failures and normal business peaks.

[0076] In this embodiment, the current link bandwidth utilization rate refers to the percentage of bandwidth used relative to the total bandwidth, directly reflecting the capacity saturation of the physical link (e.g., a 100Mbps link using 90Mbps has a utilization rate of 90%); the current transmission latency refers to the average time it takes for a data packet to travel from entering the queue to completing forwarding, accurately depicting the micro-state of node processing capacity and queue pressure. Unifying these two into current performance indicators essentially establishes a dual-dimensional "capacity-efficiency" coordinate system, providing a comprehensive basis for subsequent dynamic adjustments that considers both macro-level load and micro-level congestion, avoiding misjudgments of a single indicator that cause scheduling strategies to deviate from actual needs.

[0077] Step S202: Obtain the historical baseline bandwidth utilization and historical baseline transmission delay corresponding to the traffic feature vector in the historical performance database, and combine them to generate historical baseline data;

[0078] Among them, the normal load characteristics of different traffic types in the network (such as large file downloads, instant messaging, and video streaming) differ significantly: download services naturally have high bandwidth utilization but low latency sensitivity, while voice calls require extremely low latency but have limited bandwidth consumption. Judging congestion solely based on current performance indicators may misjudge normal business peaks as abnormal ones.

[0079] In this embodiment, the historical performance database stores ideal operating state records corresponding to various traffic feature vectors (such as quintuples, application layer protocols, latency sensitivity, etc.). The system extracts the load reference value of the specific type of traffic that performed well or was in an ideal state in the past by accurately matching the associated records of the current traffic feature vector in the historical performance database. The historical baseline bandwidth utilization and historical baseline transmission delay are combined to generate historical baseline data. In essence, this defines a normal level line with high business relevance for the real-time status of the current link, and establishes a scientific reference system for subsequently measuring the deviation of the current status.

[0080] Step S203: Based on the current performance indicators and historical benchmark data, calculate the first ratio of the current link bandwidth utilization to the historical benchmark bandwidth utilization, and calculate the second ratio of the current transmission delay to the historical benchmark transmission delay.

[0081] The difference between the current bandwidth utilization rate (e.g., 90%) and the historical benchmark (e.g., 60%) (30%) cannot reflect the differences in business characteristics (a 30% increase may be normal for download services, but abnormal for voice services).

[0082] Therefore, by calculating the first ratio (current bandwidth utilization / historical baseline bandwidth utilization) and the second ratio (current transmission delay / historical baseline transmission delay), the absolute values ​​are transformed into dimensionless relative multiples: if the first ratio is 1.5, it indicates that the current bandwidth is 1.5 times the historical baseline, showing an overload trend; if the second ratio is 0.8, the delay is lower than the historical baseline, and the link is smooth. This transformation cleverly eliminates the differences in the inherent attributes of different services, mapping all traffic to a unified fluctuation space with "historical baseline as 1," so that subsequent fusion calculations are not affected by service types and focus on the horizontal comparison of the degree of deviation.

[0083] Step S204: Obtain the pre-configured load weight coefficient and delay weight coefficient, and perform a weighted summation of the first ratio and the second ratio to generate a performance comparison value;

[0084] In the embodiments of this application, the load weight coefficient and the latency weight coefficient are predefined adjustment parameters (such as a latency weight of 0.8 and a bandwidth weight of 0.2 in a video private network; the opposite is true for download services), reflecting the weight of the two types of indicators on network quality in a specific scenario.

[0085] The performance comparison value is generated by summing the first ratio multiplied by the load weight coefficient and the second ratio multiplied by the latency weight coefficient. For example, if a video service currently has a bandwidth ratio of 1.2 (slightly exceeding historical load) and a latency ratio of 1.5 (significantly deteriorating latency), and the latency weight is 0.8 and the bandwidth weight is 0.2, then the performance comparison value = 1.2 × 0.2 + 1.5 × 0.8 = 1.44, highlighting the dominant impact of latency degradation. This mechanism allows network administrators to dynamically adjust the weights based on service priorities. The generated performance comparison value is a comprehensive scalar indicator that integrates service-specific benchmarks, real-time capacity pressure, and queuing latency degradation trends. This indicator highly condenses the overall congestion situation of the current link relative to an ideal state in a single numerical form.

[0086] Step S205: Input the performance comparison value into the pre-configured dynamic correction model, and adjust the performance comparison value through the dynamic correction model to generate a basic dynamic adjustment factor.

[0087] Specifically, the dynamic correction model can adopt the Long Short-Term Memory (LSTM) network model. Since the network load has strong time correlation (such as the continuous high pressure often following a burst of traffic), LSTM, as an improved version of recurrent neural network, can capture long-term dependencies in time series through gating mechanism, and is suitable for predicting the load trend within a preset time (such as 50ms).

[0088] In this embodiment, the system inputs the current performance comparison value and historical load sequences (such as utilization over the past 10 time windows) into the LSTM model, and outputs a future load trend prediction result (such as "bandwidth utilization will increase by 20% in the next 50ms" or "latency will stabilize"). Based on the prediction result, the performance comparison value is scaled proportionally: if the predicted load increases, the performance comparison value is amplified (e.g., multiplied by 1.2) to make the basic dynamic adjustment factor more sensitive, proactively increasing the weight of high-priority traffic to prevent congestion; if the predicted load decreases, the performance comparison value is reduced (e.g., multiplied by 0.8) to avoid over-adjustment leading to resource waste. For example, a performance comparison value of 1.32, after predicting "load will increase," is scaled to 1.58 as the final basic dynamic adjustment factor. This mechanism upgrades adjustment from reactive response to proactive prediction, improving network adaptability.

[0089] In the above implementation, the current load is quantified using real-time link bandwidth utilization and transmission delay as core indicators. The reference validity is ensured by associating with historical benchmark data of similar traffic. The deviation is comprehensively analyzed by weighted summation of two ratios. Then, the load trend is predicted and dynamically corrected by a dynamic correction model. Finally, a basic dynamic adjustment factor that reflects both the current state and future changes is generated, so that subsequent traffic priority adjustment is more accurate and timely, providing a scientific core basis for the dynamic optimization and scheduling of network resources.

[0090] Reference Figure 3 As one implementation of step S104, the step of calculating the ratio of queuing waiting time to a preset protocol timeout threshold to generate a timeout risk compensation value for low-priority data packets in the initial traffic queue whose initial priority weight is lower than a preset weight threshold includes:

[0091] Step S301: For low-priority data packets whose initial priority weight is lower than a preset weight threshold, obtain the corresponding queuing time and the type of transport layer protocol to which they belong;

[0092] Low-priority data packets specifically refer to data packets whose initial priority weight is lower than the preset weight threshold. These data packets are easily delayed in regular scheduling and pose a risk of triggering protocol retransmission due to long queuing.

[0093] In this embodiment, obtaining the queuing time (the cumulative duration from entering the queue to the current moment) is to quantify the latency pressure already borne by the data packet; the longer the waiting time, the higher the accumulated risk of timeout. Simultaneously, extracting the transport layer protocol type (such as TCP, UDP, SCTP) is because the timeout control mechanisms of different protocols have fundamental differences: TCP ensures reliable transmission through the "Maximum Retransmission Timeout (RTO)," while UDP itself has no retransmission mechanism but may be constrained by application layer protocols.

[0094] Step S302: Query the pre-configured protocol parameter library to obtain the maximum retransmission timeout time corresponding to the transport layer protocol type as the preset protocol timeout threshold;

[0095] The protocol parameter library is a pre-configured set of mapping relationships. Its core content is the association between "transport layer protocol type → maximum retransmission timeout". This timeout threshold is not a fixed value, but is periodically updated based on real-time network latency data (e.g., adjusted every 5 minutes according to the current link average latency).

[0096] Specifically, the maximum retransmission timeout (typically 200ms-500ms in TCP, depending on the estimated round-trip time (RTT)) is the maximum time allowed for data packets to queue, as specified by the transport layer protocol. Failure to transmit within this threshold may trigger a retransmission (TCP) or an application layer timeout (e.g., an HTTP request). In this embodiment, a standardized timeout upper limit is locked by the protocol type to avoid violating the protocol design intent due to custom thresholds. Simultaneously, a dynamic update mechanism allows the threshold to adapt to changes in the network environment (e.g., appropriately relaxing the timeout threshold in high-latency networks), preventing the risk of misjudgment or overcompensation caused by static thresholds.

[0097] Step S303: Calculate the ratio between the queuing waiting time and the preset protocol timeout threshold;

[0098] This method quantifies the relative relationship between waiting time and allowed timeout, transforming the abstract accumulation of risk into a comparable numerical indicator. First, the original ratio (queue waiting time ÷ protocol timeout threshold) is calculated. For example, if the queue waiting time for a TCP packet is 160ms and the protocol timeout threshold is 200ms, then the original ratio is 0.8.

[0099] In addition, when the original ratio value is greater than or equal to the pre-configured safety ratio threshold (e.g., 0.8), the difference between the original ratio value and the safety ratio threshold is calculated as the effective risk ratio (e.g., if the original ratio value is equal to 0.8 in the example above, the effective ratio is 0; if the waiting time is 200ms, the original ratio is 1.0 and the effective ratio is 0.2).

[0100] Understandably, a safety ratio threshold (e.g., 80%) serves as a dividing line for determining whether a risk is approaching a critical point. Below the threshold, data packets are still within a "safe waiting period" and require no additional intervention; above the threshold, the excess portion represents the actual risk increment that needs compensation. By using a proportional relationship rather than absolute duration, the impact of differences in timeout thresholds across different protocols can be eliminated (e.g., the timeout threshold for download traffic may be much larger than that for instant messaging), achieving a unified risk measurement across protocols.

[0101] Step S304: Input the proportional relationship into the pre-configured risk mapping function for nonlinear mapping calculation to generate the timeout risk compensation value.

[0102] The risk mapping function is a composite function combining a piecewise compensation function and a machine learning model. First, the piecewise compensation function processes the proportional relationship. When the proportional relationship is in the first interval (e.g., ≤ safety threshold), a zero-value compensation is output (no intervention required). When it is in the second interval (e.g., safety threshold < proportional relationship ≤ 1.2 times threshold), a linear function is applied to generate a compensation value (risk increases linearly with the proportional relationship). When it is in the third interval (e.g., > 1.2 times threshold), an exponential function is applied to generate a compensation value (risk increases rapidly, requiring strong intervention).

[0103] Next, the function is dynamically optimized through a gradient boosting decision tree model. The specific steps include: collecting a dataset of timeout interruption events of low-priority traffic in the historical network environment (including the correlation between the proportion and the interruption result), training the gradient boosting decision tree model to establish the correlation rules between the proportion and the interruption probability, and then mapping the interruption probability to compensation value weights (e.g., an interruption probability of 10% corresponds to a compensation value of 0.1).

[0104] For example, if the ratio of a certain data packet is 1.5 (third interval), the exponential function may map it to a compensation value of 0.5, which, when added to the priority weight, increases its scheduling chance. Understandably, the piecewise function balances computational efficiency and risk sensitivity, while the machine learning model optimizes the mapping accuracy through historical experience, avoiding the subjectivity of manual settings.

[0105] In the above implementation, low-priority data packets are locked and their transport layer protocol types are identified. A compliant timeout threshold is obtained by relying on a dynamically updated protocol parameter library. The relative accumulation of waiting time and risk is quantified by a proportional relationship. Then, an accurate timeout risk compensation value is generated by a risk mapping function that combines a segmented compensation function with a machine learning model.

[0106] In practical applications, this technical solution not only avoids the avalanche effect of low-priority traffic triggering retransmission storms due to long-term queuing, but also balances the rationality of compensation and computational efficiency through dynamic thresholds and segmented mapping, ultimately improving the stability and fairness of the network under high-load scenarios.

[0107] Reference Figure 4 As one implementation of step S105, the step of dividing the available bandwidth resources within the current scheduling time window according to the target priority weight and the weight ratio, and generating a scheduling instruction set containing the bandwidth quota corresponding to each data packet, includes:

[0108] Step S401: Obtain the available bandwidth resources within the current scheduling time window and the target priority weight of each data packet in the initial traffic queue;

[0109] The current scheduling time window is a bandwidth allocation period that is dynamically adjusted based on the link load volatility: when the link load volatility is high (such as a sudden surge in traffic), the duration is shortened (e.g., 10ms) to improve response speed, and when the volatility is low, the duration is extended (e.g., 50ms) to reduce scheduling overhead. Its essence is to balance the flexibility of dynamic adjustment with the economy of scheduling overhead.

[0110] In this embodiment, the steps for obtaining available bandwidth resources include: first, calling a real-time network monitoring interface (such as SNMP) to obtain the physical available bandwidth of the link; then, using a Long Short-Term Memory (LSTM) network model to predict the bandwidth fluctuation trend within the current time window (e.g., a 20% bandwidth drop due to a sudden video stream burst in the next 10ms); and using the bandwidth corrected by the prediction result as the dynamic available bandwidth resource to avoid the disconnect between static bandwidth values ​​and actual available resources. The target priority weight reflects the comprehensive priority of data packets in the current network state.

[0111] Step S402: Calculate the sum of the target priority weights of each data packet, and obtain the weight ratio of each data packet based on the target priority weights;

[0112] First, the total target priority weights of all data packets within the current scheduling time window are calculated. For example, if there are three data packets within the time window with target priority weights of 0.8, 0.6, and 0.4 respectively, the total weight is 1.8. Then, the target priority weight of each individual data packet is divided by this total to generate a weight percentage. For example, the first data packet has a weight percentage of 44.4%, the second has a weight percentage of 33.3%, and the third has a weight percentage of 22.2%.

[0113] Understandably, absolute weight only reflects the priority of a single data packet, while weight percentage reflects its relative importance within the total traffic to be scheduled. A higher percentage means that the data packet contributes more to network performance (such as low latency and high bandwidth requirements) and should receive more bandwidth resources. By allocating resources based on percentage rather than absolute weight, the allocation logic can be kept clear due to changes in the total weight (such as the addition of high-priority data packets), ensuring that resource allocation is always linked to relative priority and maintaining the fairness and stability of scheduling.

[0114] Step S403: Allocate available bandwidth resources to each data packet according to the weight ratio and generate bandwidth quota instructions;

[0115] In this embodiment, the available bandwidth resources are multiplied by the weight ratio of each data packet to obtain the initial bandwidth quota for each data packet (for example, if the available bandwidth is 100Mbps and the weight ratio of a certain data packet is 30%, then the initial quota is 30Mbps). Based on the latency sensitivity level of each data packet, the bandwidth quota fine-tuning strategy (or dynamic resource reallocation algorithm) is applied to adjust the initial bandwidth quota and generate the final bandwidth quota instruction.

[0116] Specifically, in the bandwidth quota fine-tuning step, the latency sensitivity level of each data packet is first detected (such as the level determined based on the application layer protocol type, such as video streams being highly sensitive). When the level exceeds the preset sensitivity threshold (such as the high sensitivity threshold), the bandwidth quota ratio of the data packet is increased (such as from 30% to 40%), and the final bandwidth quota instruction is generated.

[0117] Understandably, weighting ensures that high-priority traffic receives basic resources, while latency sensitivity levels identify latency-sensitive critical services (such as telemedicine and real-time control). Additional quotas are added to prevent these services from exceeding latency limits due to insufficient weighting, achieving a dual optimization of priority protection and service attribute adaptation. For example, a highly sensitive data packet with a moderate weighting might receive more resources than its initial quota after adjustment, prioritizing its transmission quality.

[0118] Step S404: Encapsulate the identification information of each data packet and the bandwidth quota instruction to generate a scheduling instruction set.

[0119] Among them, the identification information of the data packet must uniquely correspond to the traffic to be scheduled, such as the five-tuple hash value (source IP, destination IP, source port, destination port, and hash code of the transport layer protocol), or through the application layer session ID identifier, to ensure that the network device can accurately identify the target data packet.

[0120] Next, the identification information is bound to the corresponding bandwidth quota instruction (such as "allocate 30Mbps bandwidth to packet A (identifier X)") to form a structured scheduling instruction set. This instruction set must conform to the protocol format supported by the network device (such as OpenFlow flow table entries, CLI command sets). After being issued through the management interface (such as NETCONF), the device can schedule packets according to the instructions (such as token bucket shaping, queue priority marking).

[0121] In the above implementation, the allocation period is defined by a dynamic scheduling time window, the available bandwidth resources are predicted and corrected by combining the LSTM model, the relative proportion is calculated based on the target priority weight to ensure fair allocation, additional allocation is provided for high latency-sensitive data packets to ensure critical services, and finally, the identifier and quota are encapsulated to generate an executable scheduling instruction set.

[0122] In practical applications, this technical solution improves bandwidth utilization, reduces critical flow latency, enhances network adaptability, and ensures the effective implementation of the allocation scheme through precise identification and encapsulation, providing core support for efficient network traffic transmission.

[0123] Reference Figure 5 As one implementation of the current scheduling time window, the steps for determining the current scheduling time window include:

[0124] Step S501: Extract link load volatility from real-time load status;

[0125] Specifically, while real-time load status provides current bandwidth usage, it fails to reflect trends. For example, a link might have a stable overall utilization rate of 50%, but in reality, it might be experiencing dramatic fluctuations from 10% to 90%, which can easily lead to momentary packet loss. Link load volatility quantifies this instability by calculating the standard deviation or rate of change of load data within adjacent time slices.

[0126] Step S502: Determine whether the link load volatility is greater than the preset volatility threshold; if yes, proceed to step S503; otherwise, proceed to step S504.

[0127] The preset volatility threshold is a critical value pre-set based on network hardware performance and service requirements. By comparing the real-time extracted volatility with this threshold, the system can quickly determine the current health status of the network. If the volatility exceeds this preset threshold, it indicates that the network is in an unstable state, possibly caused by micro-burst traffic, and the original scheduling rhythm may have failed; conversely, it indicates that the links are operating smoothly and suitable for regular scheduling arrangements. This binary judgment logic is simple and has extremely low overhead, providing a clear basis for subsequently adopting different control strategies.

[0128] Step S503: Calculate the negative time adjustment amount based on the comparison result between the link load volatility and the preset volatility threshold;

[0129] In the case of a branch with severe link fluctuations, the system generates a negative time adjustment. The principle is that high fluctuations mean that queue length and bandwidth availability can be unpredictably reversed in an instant. At this time, it is necessary to increase the frequency of system sampling and the density of control command issuance by compressing the scheduling time window, so as to quickly rearrange the queue with higher time resolution to prevent congestion from worsening.

[0130] Step S504: Calculate the positive time adjustment amount based on the comparison result between the link load volatility and the preset volatility threshold;

[0131] In the case of a stable link branch, the system generates a positive time adjustment amount because excessively frequent scheduling will not only waste the processing resources of network devices, but also reduce the effective throughput of the link by frequently interrupting the transmission of long-flow data.

[0132] It should be noted that, whether positive or negative, the adjustment amount is not a fixed value, but strictly depends on the deviation between the two in the comparison results. The more extreme the fluctuation, the greater the adjustment. This design of proportional allocation on demand ensures the accuracy and restraint of time window expansion and contraction.

[0133] Step S505: Obtain the pre-configured basic time window duration, and add the negative or positive time adjustment amount to the basic time window duration to generate the current scheduling time window.

[0134] The pre-configured base time window duration is an optimal static value set under ideal network conditions, taking into account both device processing capacity and transmission efficiency. It serves as a benchmark, ensuring that the scheduling cycle does not deviate too far from a reasonable range. By adding the calculated adjustment amount to this base value, the system achieves dynamic scaling of the time window.

[0135] Understandably, this mechanism utilizes a base duration to ensure system stability (preventing the system from crashing due to the time window being compressed or lengthened indefinitely), while also incorporating dynamic adjustment capabilities to adapt to real-time network changes. The resulting current scheduling time window can balance response speed and system overhead.

[0136] In the above implementation, the scheduling time granularity can be automatically adjusted according to the real-time fluctuation of the network. When the network fluctuates drastically, the response speed and control accuracy can be improved by shortening the time window. When the network is stable, the equipment overhead can be reduced and the transmission efficiency can be improved by extending the time window. Thus, while ensuring network stability, the optimal balance between system resource consumption and scheduling real-time performance is achieved.

[0137] Reference Figure 6 As one implementation of step S107, the steps of extracting the actual transmission delay from the transmission performance log, calculating the deviation between the actual transmission delay and the expected transmission delay, and generating weight update parameters based on the deviation include:

[0138] Step S601: Extract the identification information of each data packet and the corresponding actual transmission delay from the transmission performance log returned by the network device;

[0139] Among them, the transmission performance log is the execution result recorded by network devices (such as routers and switches) after executing scheduling instructions, which includes key indicators during the data packet transmission process (such as actual transmission delay, number of packet losses, and number of retransmissions). Identification information is information that uniquely identifies data packets (such as "five-tuple hash value" or "application layer session ID"), and is used to associate other attributes of data packets (such as traffic feature vector and priority weight); actual transmission delay is the average time taken for a data packet to go from dequeue to acknowledgment at the receiving end, which directly reflects the true efficiency of network transmission.

[0140] Step S602: Obtain the traffic feature vector of the corresponding data packet based on the identification information, query the pre-configured delay level mapping table, and obtain the baseline expected delay according to the delay sensitivity level in the traffic feature vector.

[0141] The traffic feature vector is a multi-dimensional set of attributes, including a five-tuple of information, packet length, arrival time interval, latency sensitivity level (determined based on the application layer protocol type, such as high sensitivity for video streaming and low sensitivity for email transmission), and bandwidth requirement level. The identification information is used to associate the current data packet with historically generated traffic feature vectors (e.g., through hash mapping).

[0142] In this embodiment, the latency level mapping table consists of pre-configured association rules that map latency sensitivity levels to baseline expected latency (e.g., high sensitivity corresponds to 50ms, medium sensitivity to 100ms, and low sensitivity to 200ms). It is understood that the reasonable latency varies for different types of traffic (e.g., real-time video streams are more sensitive to latency). Matching latency sensitivity levels to baseline expected latency provides a reference standard that aligns with business attributes for subsequent deviation calculations.

[0143] Step S603: Obtain the real-time link status data of the current link and calculate the link delay correction value. Add the link delay correction value to the baseline expected delay to generate the expected transmission delay.

[0144] Real-time link status data includes metrics such as current link transmission latency, reflecting the link's real-time processing capabilities (e.g., latency increases caused by burst traffic). The link latency correction value is an adjustment calculated based on the real-time link status data (e.g., if the current link latency is 10ms higher than the historical baseline, the correction value is +10ms). This correction value is then added to the baseline expected latency (e.g., baseline 50ms + correction 10ms = 60ms) to generate the dynamic expected transmission latency.

[0145] Understandably, the baseline expected latency is a static reference based on historical experience or business attributes, while the real-time link latency is a current dynamic constraint. Adding correction values ​​can make the expected value more in line with the reasonable latency under the current network conditions, avoiding discrepancies between the expected and actual latency caused by temporary link congestion.

[0146] Step S604: For each data packet, calculate the difference between the actual transmission delay and the expected transmission delay to generate the original deviation value. Apply the sliding window algorithm to statistically analyze the original deviation values ​​of all data packets in each historical scheduling time window to generate a set of deviation values.

[0147] By directly subtracting the actual transmission delay from the expected transmission delay, the system can intuitively quantify the quality of each scheduling action. A positive value represents delay degradation caused by scheduling failure, while a negative value represents scheduling that is better than expected. However, random glitches caused by micro-bursts or single packet loss and retransmission are inevitable in network transmission. If the system parameters are modified directly based on the original deviation value of a single instance, it will cause the entire scheduling system to oscillate violently or even collapse.

[0148] Therefore, by introducing a sliding window algorithm, a fixed-width window is defined on the time axis. As time progresses, the algorithm continuously absorbs the latest original deviation values ​​within the scheduling time window while discarding the oldest data, thus generating a set of deviation values ​​containing time-series information. This statistical mechanism not only effectively smooths out transient anomalies but also fully preserves the cumulative evolution trend of recent scheduling deviations, providing a reliable data source with high signal-to-noise ratio and temporal continuity for subsequent model analysis.

[0149] Step S605: Input the set of deviation values ​​into the pre-configured adaptive learning model to predict the error contribution of the set of deviation values ​​to the initial priority weight allocation in the historical performance database.

[0150] Among them, the adaptive learning model can adopt the Long Short-Term Memory (LSTM) network model. After inputting the set of deviation values, the adaptive learning model can accurately extract the fluctuation impact absorbed by the subsequent dynamic adjustment process by deeply mining the hidden temporal patterns and distribution characteristics in the set of deviation values ​​and combining the massive prior knowledge in the historical performance database. It can also specifically predict the error proportion caused by the unreasonable setting of the initial priority weights, i.e., the error contribution.

[0151] Step S606: Generate weight penalty coefficients based on error contribution and use them as weight update parameters.

[0152] When the error contribution exceeds the preset tolerance threshold, the weight reduction magnitude (reflecting the degree to which the initial weight needs to be reduced) is calculated through the pre-configured weight decay function; the weight reduction magnitude is multiplied by the basic penalty factor to generate a dynamic weight penalty coefficient.

[0153] Next, this weight penalty coefficient is set as a weight update parameter and fed back to the database. In essence, this is a targeted and proportional downgrade penalty for the erroneous matching rules that cause deviations in the system. This forces the historical performance database to correct its matching logic before the start of the next scheduling cycle, ensuring that the entire network traffic control system can achieve a continuous spiral increase in performance through continuous self-correction.

[0154] In the above implementation, based on real data from transmission performance logs, a baseline expected latency is obtained by associating traffic feature vectors with identification information. This is combined with real-time link state corrections to generate dynamic expected values. Individual deviations are calculated and aggregated across a set of periods. Then, an LSTM model is used to trace the error contribution of the initial weights, ultimately generating precise weight penalty coefficients as update parameters. In practical applications, this technical solution enables the matching logic of the historical performance database to continuously absorb new experience, improving the accuracy of subsequent traffic scheduling and ultimately achieving closed-loop optimization of network transmission performance.

[0155] Reference Figure 7As one implementation of step S108, the step of feeding back the weight update parameters to the historical performance database to update the matching logic of the initial priority weights includes:

[0156] Step S701: Receive the weight update parameters and the associated traffic feature vector;

[0157] Among them, the weight update parameter reflects the performance deviation after specific traffic scheduling, and the associated traffic feature vector is the unique digital identifier of the traffic (including a multi-dimensional vector containing a 5-tuple, packet length, arrival interval, delay sensitivity level, and bandwidth requirement level).

[0158] Specifically, upon receiving the data, it is necessary to first verify the validity range of the weight update parameters (e.g., whether the penalty coefficient is in the range of [-1,1]). If the value exceeds the preset valid threshold (e.g., absolute value > 1), an exception handling mechanism is triggered (e.g., truncation to threshold boundary value or discarding of exception parameters) to generate standardized update parameters.

[0159] Step S702: Using the traffic feature vector as a query index, retrieve and extract the initial priority weight record that matches the traffic feature vector from the historical performance database.

[0160] The historical performance database stores the associated records of "traffic feature vector - initial priority weight", which are derived from the accumulation of past traffic scheduling experience (such as the historical optimal weight of a certain type of video stream).

[0161] Specifically, using traffic feature vectors as query indexes essentially leverages the uniqueness of their multidimensional attributes (such as a combination of a 5-tuple hash value and a latency sensitivity level) to retrieve the most matching initial priority weight record using a similarity matching algorithm (such as cosine similarity to calculate the angle between vectors). For example, if the current traffic feature vector is "TCP protocol + video stream (high latency sensitivity) + packet length 1200 bytes", the system will match the "historical video stream record" in the database with the closest features and extract its associated initial weight (such as 0.8).

[0162] Step S703: Obtain the historical weight sequence associated with the initial priority weight record stored in the historical performance database, perform incremental learning operation based on the historical weight sequence and weight update parameters, and generate the updated priority weight;

[0163] Among them, the historical weight sequence is a set of past weight records associated with the current traffic feature vector (such as the weight values ​​of the last 30 schedulings: 0.7→0.8→0.75), reflecting the evolution trajectory of this type of weight.

[0164] Specifically, the steps for performing incremental learning operations include: calling the sliding time window algorithm to filter the weight records of the same type of traffic feature vectors in the historical performance database (e.g., only retaining the records of the same protocol and sensitivity level in the last 10 times) and excluding outdated data; applying the gradient boosting decision tree model to analyze the deviation pattern between the weight update parameters (e.g., the penalty coefficient -0.2) and the historical records (e.g., the deviation is greatest when the weight is 0.8) and generating a weight correction coefficient (e.g., -0.15).

[0165] Finally, the correction factor is applied to the latest value of the historical weight sequence (e.g., 0.8 + (-0.15) = 0.65) to generate the updated priority weights. Understandably, incremental learning only adjusts the parts related to the current bias, preserving the trend of the historical sequence (e.g., a slow decline rather than a sharp drop), making the weight updates both adaptive and stable.

[0166] Step S704: Bind the updated priority weights to the traffic feature vectors, generate new mapping records and replace the initial priority weight records to reconstruct the weight matching logic of the historical performance database.

[0167] Specifically, the updated priority weights are bound to the traffic feature vectors to generate new mapping records (such as "feature vector X → weight 0.65"), replacing the original initial priority weight records in the database (such as "feature vector X → weight 0.8").

[0168] Specifically, during the reconstructing of weight matching, the traffic feature vectors are dynamically clustered based on the K-means algorithm (e.g., clustered according to latency sensitivity and bandwidth requirements) to divide the database into sub-modules. New mapping records are synchronized to the index nodes of the corresponding sub-modules, and the mapping relationship table between feature vectors and weight values ​​is updated. If the addition of weights causes the cluster center shift to exceed the tolerance value (e.g., the mean vector distance within a cluster increases by 20%), the cluster partitions are recalculated and the data is migrated.

[0169] Understandably, by dividing the data into sub-modules through clustering, subsequent queries can focus on specific clusters (such as high-sensitivity traffic clusters), improving retrieval efficiency. In addition, dynamically updating the mapping relationship table ensures that the database always reflects the latest experience, achieving a self-iterative process of "practice-learning-optimization".

[0170] In the above implementation, the binding input of weight update parameters and traffic feature vectors ensures targeted adjustment. The historical baseline is locked by feature vector index retrieval. The incremental update weights are generated by combining historical weight sequences with incremental learning operations (sliding window filtering, gradient boosting decision tree correction). Finally, the database logic is reconstructed by mapping record replacement and clustering sub-modules.

[0171] In practical applications, this technical solution solves the shortcomings of traditional static databases, such as the solidification of experience and inefficient querying. It enables the weight matching logic to continuously absorb new experience (such as adjusting the initial priority of differential weights) and optimize the storage structure (clustering partitioning improves efficiency). This provides increasingly accurate historical references for the dynamic scheduling of network traffic, ultimately achieving closed-loop optimization of transmission performance and long-term network self-adaptation.

[0172] Reference Figure 8 As a further implementation of the network traffic dynamic control method, after step S108, which feeds back the weight update parameters to the historical performance database to update the matching logic of the initial priority weights, the method further includes:

[0173] Step S801: Obtain multiple historical traffic feature vectors and corresponding historical priority weights stored in the historical performance database, and construct a feature-weight association graph.

[0174] Understandably, in traditional database retrieval mechanisms, each parameter update after traffic scheduling only covers the specific characteristics of the current data packet in isolation, lacking the ability to explore the potential connections between similar business flows in the feature space.

[0175] In this embodiment, the system treats each historical traffic feature vector (e.g., a vector containing dimensions such as quintuples, packet length, and latency sensitivity) as a node in the graph, and uses the historical priority weight corresponding to the vector as the node's attribute. Next, the system calculates the distance between any two nodes in the feature space (e.g., using cosine similarity or Euclidean distance), and connects nodes with a distance less than a preset threshold using edges. For example, historically, "video conferencing traffic (high latency sensitivity)" and "VoIP voice traffic (high latency sensitivity)" may differ in their quintuples, but they are highly similar in the latency sensitivity dimension, and therefore will be closely connected in the graph.

[0176] Step S802: Obtain the weight update parameters and associated traffic feature vectors generated in this feedback, and filter out the set of target neighbor nodes that meet the preset similarity conditions in the feature-weight association graph.

[0177] The network system generates weight update parameters based on actual transmission delay deviations. These parameters reveal the scheduling irrationality of the current associated traffic feature vector under specific network conditions. Since network traffic is typically clustered and homogeneous in its services, other historical traffic that is close to the current feature vector in the multidimensional feature space is highly likely to expose the same scheduling defects when faced with the same link state.

[0178] Therefore, the system sets a pre-defined similarity condition (e.g., cosine similarity must be greater than 0.95) as a screening threshold, and performs spatial distance measurement in the association graph to accurately isolate nodes with highly compatible features into a target neighbor node set. For example, if the currently penalized stream is a "1080P stream from a certain video website," then "720P streams from the same website" or "other video streams of the same type" may be included in the set due to feature similarity. The system thus identifies a group of traffic with the same potential risk characteristics, preventing them from experiencing the same scheduling errors in the future.

[0179] Step S803: Calculate the neighbor weight adjustment amount based on the weight update parameters, and add the neighbor weight adjustment amount to the historical priority weight corresponding to each graph node in the target neighbor node set for updating, thereby generating the updated neighbor node weights.

[0180] Although the target neighbor nodes are similar to the current problem traffic, they are not exactly the same. Directly applying the exact same weights to update the parameters will lead to overfitting.

[0181] Therefore, when calculating the neighbor weight adjustment, the system introduces a decay factor based on feature distance. For example, a node with a feature distance of 0.05 from the problematic traffic node (extremely similar) receives a 100% adjustment; a node with a distance of 0.1 (relatively similar) receives an 80% adjustment. Assuming the original weight update parameter is -0.2 (down by 0.2), then the weight of extremely similar nodes is reduced by 0.2, and the weight of relatively similar nodes is reduced by 0.16. The system then adds this decayed neighbor weight adjustment to the historical priority weights of these nodes. This mechanism ensures that the correction is proportional to the degree of similarity, both conveying lessons learned and maintaining the precision of the weights.

[0182] Step S804: Detect the weight fluctuation of each graph node in the target neighbor node set before and after the update, and generate a feature drift detection template based on the weight fluctuation and the number of pre-configured historical fluctuation records.

[0183] Under normal circumstances, the weights of graph nodes gradually converge as the network is optimized. However, if a node (such as a node representing an older version of a P2P protocol) is frequently updated in a short period of time, and the weight fluctuates greatly before and after the update (e.g., it drops sharply from 0.8 to 0.2 and then rises back to 0.7), this often means that the traffic characteristics represented by the node are outdated, and there is a feature drift in the network that the node cannot accurately describe (e.g., the P2P protocol has upgraded its encryption method).

[0184] At this point, the system can combine the pre-configured number of historical fluctuation records (such as fluctuations exceeding the threshold for 5 consecutive cycles) to filter out these long-term unstable nodes, extract the feature vectors of these nodes and combine them into a feature drift detection template. This template describes the new traffic features in the current system's knowledge blind spots, providing the system with a tool to actively identify unknown evolution trends in the network.

[0185] Step S805: Send the feature drift detection template to the pre-configured network edge nodes and receive the edge traffic sample feature set returned by the network edge nodes;

[0186] In particular, because the records in the central database are always lagging behind, they are essentially lagging records of past traffic and cannot proactively detect new types of traffic emerging at the forefront of the network.

[0187] Therefore, the system distributes the feature drift detection template generated in the previous step to network edge nodes located at the network ingress. Edge nodes have full visibility into all traffic and use the feature rules in the template (such as "finding TCP flows with unusual source ports and abnormal packet length distributions") to perform matching and deep packet inspection on local real-time traffic. Once a match is successful, the edge nodes extract detailed edge traffic sample feature sets of these suspicious traffic and return them to the central system. For example, if an edge node discovers a large number of new traffic patterns matching the template, it collects these features and sends them back to the center. This transforms the system from passively waiting for faults to occur to proactively collecting evidence.

[0188] Step S806: Based on the edge traffic sample feature set, identify new graph nodes that meet the pre-configured new node conditions in the feature-weight association graph, and write the new graph nodes into the feature-weight association graph.

[0189] After receiving the feature set of edge traffic samples, the central system performs a similarity search on the existing feature-weight association graph. If the similarity between the sample features and all existing nodes in the graph is lower than the pre-configured new node conditions (e.g., similarity less than 0.3), it indicates that this is a completely unknown traffic type that the existing knowledge base cannot cover. The system then instantiates these samples as new graph nodes, assigns them an initial priority weight based on general rules, and formally writes them into the graph.

[0190] For example, the system identifies a new type of AR real-time interactive traffic, adds it to the graph as a new node, and sets its initial weight to high priority. This not only gives these new types of traffic a legitimate identity in the system, but also provides a complete logical link entry for their subsequent participation in initial priority weight matching, receiving dynamic adjustment factors, and future closed-loop feedback. This empowers the scheduling system with the ability to discover itself, learn itself, and continuously evolve.

[0191] In the above implementation, the construction of a feature-weight association graph transforms isolated matching records into global knowledge. Based on the correction of specific feature nodes according to the time delay deviation, the optimization experience is smoothly generalized to the target neighbor nodes using similarity screening and decay mechanisms, effectively breaking the bottleneck of local lag caused by the inability of experience to be transferred laterally. At the same time, the scheme further observes the high-frequency fluctuations of nodes in the experience generalization process and combines historical records to understand the drift trend of underlying features. With the help of the issued detection templates, the edge nodes are driven to actively verify, and the physically confirmed new traffic patterns are automatically instantiated into new graph nodes. This fundamentally breaks the cognitive barrier of the static experience base, enabling the underlying scheduling and matching logic to have the ability to dynamically expand and continuously iterate with the evolution of network services. This realizes a fundamental leap in network priority scheduling strategy from passive response to active prediction and from static matching to unsupervised self-evolution.

[0192] This application also discloses a network traffic dynamic control system based on priority scheduling.

[0193] A priority-based network traffic dynamic control system, specifically comprising:

[0194] The traffic feature extraction module is used to collect real-time network traffic data packets and extract features to generate traffic feature vectors;

[0195] The initial priority matching module is used to match initial priority weights to traffic feature vectors based on historical performance databases, associate the initial priority weights with the corresponding data packets that generate traffic feature vectors, and generate an initial traffic queue based on the associated data packets.

[0196] The dynamic adjustment factor calculation module is used to obtain the real-time load status of the current link and the queuing time of each data packet in the initial traffic queue, and calculate the basic dynamic adjustment factor based on the real-time load status.

[0197] The target priority weight generation module is used to calculate the ratio of queuing time to a preset protocol timeout threshold for low-priority data packets in the initial traffic queue, generate a timeout risk compensation value, add the timeout risk compensation value to the initial priority weight, and generate the target priority weight by combining it with the basic dynamic adjustment factor; for other data packets, the target priority weight is generated directly by combining the basic dynamic adjustment factor and the initial priority weight.

[0198] The bandwidth quota scheduling module is used to divide the available bandwidth resources within the current scheduling time window according to the target priority weight and the weight ratio, and generate a scheduling instruction set containing the bandwidth quota corresponding to each data packet.

[0199] The scheduling execution and log receiving module is used to send the scheduling instruction set to the network device to execute traffic transmission, and to receive the transmission performance log returned by the network device during the transmission process;

[0200] The weight update parameter generation module is used to extract the actual transmission delay from the transmission performance log, calculate the deviation between the actual transmission delay and the expected transmission delay, and generate weight update parameters based on the deviation.

[0201] The weight matching logic update module is used to feed back the weight update parameters to the historical performance database to update the matching logic of the initial priority weights.

[0202] The network traffic dynamic control system based on priority scheduling according to the embodiments of this application can implement any of the above methods, and the specific working process of each module in the system can refer to the corresponding process in the above method embodiments.

[0203] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and in actual implementation there may be other division methods, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0204] This application also discloses a computer-readable storage medium.

[0205] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as any of the above-described methods for dynamic network traffic control based on priority scheduling.

[0206] The computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device; the program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0207] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for dynamic network traffic control based on priority scheduling, characterized in that, The control method includes: Collect real-time network traffic data packets and extract their features to generate traffic feature vectors; Based on the historical performance database, an initial priority weight is matched to the traffic feature vector, the initial priority weight is associated with the corresponding data packet that generated the traffic feature vector, and an initial traffic queue is generated based on the associated data packets. Obtain the real-time load status of the current link and the queuing time of each data packet in the initial traffic queue, and calculate the basic dynamic adjustment factor based on the real-time load status; For low-priority data packets in the initial traffic queue, the ratio of queuing time to a preset protocol timeout threshold is calculated to generate a timeout risk compensation value. This timeout risk compensation value is then added to the initial priority weight and combined with the basic dynamic adjustment factor to generate a target priority weight. For other data packets, the target priority weight is generated directly by combining the basic dynamic adjustment factor and the initial priority weight. Based on the target priority weight, the available bandwidth resources within the current scheduling time window are divided according to the weight ratio, and a scheduling instruction set containing the bandwidth quota corresponding to each data packet is generated. The scheduling instruction set is sent to the network device to execute traffic transmission, and the transmission performance log returned by the network device during the transmission process is received; Extract the actual transmission delay from the transmission performance log, calculate the deviation between the actual transmission delay and the expected transmission delay, and generate weight update parameters based on the deviation. The weight update parameters are fed back to the historical performance database to update the matching logic of the initial priority weights.

2. The network traffic dynamic control method based on priority scheduling according to claim 1, characterized in that, The steps for calculating the basic dynamic adjustment factor based on the real-time load status include: Extract the current link bandwidth utilization and current transmission latency from the real-time load status as current performance indicators; Obtain the historical baseline bandwidth utilization and historical baseline transmission delay corresponding to the traffic feature vector in the historical performance database, and combine them to generate historical baseline data; Based on the current performance metrics and the historical baseline data, calculate a first ratio of the current link bandwidth utilization to the historical baseline bandwidth utilization, and calculate a second ratio of the current transmission delay to the historical baseline transmission delay; Obtain the pre-configured load weight coefficient and latency weight coefficient, and perform a weighted sum of the first ratio and the second ratio to generate a performance comparison value; The performance comparison value is input into a pre-configured dynamic correction model, and the performance comparison value is adjusted by the dynamic correction model to generate the basic dynamic adjustment factor.

3. The network traffic dynamic control method based on priority scheduling according to claim 1, characterized in that, The steps for calculating the ratio of queuing time to a preset protocol timeout threshold to generate a timeout risk compensation value for low-priority data packets in the initial traffic queue include: For low-priority data packets whose initial priority weight is lower than a preset weight threshold, obtain the corresponding queuing time and the type of transport layer protocol to which they belong; Query the pre-configured protocol parameter library to obtain the maximum retransmission timeout time corresponding to the transport layer protocol type as the preset protocol timeout threshold; Calculate the ratio between the queuing time and the preset protocol timeout threshold; The proportional relationship is input into a pre-configured risk mapping function for nonlinear mapping calculation to generate the timeout risk compensation value.

4. The network traffic dynamic control method based on priority scheduling according to claim 1, characterized in that, Based on the target priority weight, the steps of dividing the available bandwidth resources within the current scheduling time window according to the weight ratio and generating a scheduling instruction set containing the bandwidth quota corresponding to each data packet include: Obtain the available bandwidth resources within the current scheduling time window and the target priority weight of each data packet in the initial traffic queue; Calculate the sum of the target priority weights of each data packet, and obtain the weight percentage of each data packet based on the target priority weights; Based on the weight ratio, the available bandwidth resources are allocated to each data packet, and a bandwidth quota instruction is generated. The scheduling instruction set is generated by encapsulating the identification information of each data packet with the bandwidth quota instruction.

5. The network traffic dynamic control method based on priority scheduling according to claim 4, characterized in that, The steps for determining the current scheduling time window include: Extract link load volatility from the real-time load status; Determine whether the link load volatility is greater than a preset volatility threshold; If so, the negative time adjustment amount is calculated based on the comparison result between the link load volatility and the preset volatility threshold; If not, the positive time adjustment amount is calculated based on the comparison result between the link load volatility and the preset volatility threshold; Obtain the pre-configured base time window duration, and add the negative time adjustment amount or the positive time adjustment amount to the base time window duration to generate the current scheduling time window.

6. The network traffic dynamic control method based on priority scheduling according to claim 1, characterized in that, The steps of extracting the actual transmission delay from the transmission performance log, calculating the deviation between the actual transmission delay and the expected transmission delay, and generating weight update parameters based on the deviation include: Extract the identification information of each data packet and the corresponding actual transmission delay from the transmission performance log returned by the network device; Based on the identification information, obtain the traffic feature vector of the corresponding data packet, query the pre-configured delay level mapping table, and obtain the baseline expected latency according to the delay sensitivity level in the traffic feature vector; Obtain the real-time link status data of the current link and calculate the link delay correction value. Add the link delay correction value to the baseline expected delay to generate the expected transmission delay. For each data packet, the difference between the actual transmission delay and the expected transmission delay is calculated to generate an original deviation value. The sliding window algorithm is then applied to statistically analyze the original deviation values ​​of all data packets within each historical scheduling time window to generate a set of deviation values. The set of deviation values ​​is input into a pre-configured adaptive learning model to predict the error contribution of the set of deviation values ​​to the initial priority weight allocation in the historical performance database. A weight penalty coefficient is generated based on the error contribution and used as the weight update parameter.

7. The network traffic dynamic control method based on priority scheduling according to claim 6, characterized in that, The steps of feeding back the weight update parameters to the historical performance database to update the matching logic of the initial priority weights include: Receive weight update parameters and associated traffic feature vectors; Using the traffic feature vector as a query index, the initial priority weight record that matches the traffic feature vector is retrieved and extracted from the historical performance database. Obtain the historical weight sequence associated with the initial priority weight record stored in the historical performance database, and perform incremental learning operation based on the historical weight sequence and the weight update parameters to generate the updated priority weight; The updated priority weights are bound to the traffic feature vectors to generate new mapping records and replace the initial priority weight records, thereby reconstructing the weight matching logic of the historical performance database.

8. A network traffic dynamic control method based on priority scheduling according to any one of claims 1 to 7, characterized in that, After the step of feeding back the weight update parameters to the historical performance database to update the matching logic of the initial priority weights, the method further includes: Obtain multiple historical traffic feature vectors and their corresponding historical priority weights stored in the historical performance database, and construct a feature-weight association graph; Obtain the weight update parameters and associated traffic feature vectors generated in this feedback, and filter out the set of target neighbor nodes that meet the preset similarity conditions in the feature-weight association graph; Based on the weight update parameters, the neighbor weight adjustment amount is calculated, and the neighbor weight adjustment amount is superimposed on the historical priority weights corresponding to each graph node in the target neighbor node set for updating, thereby generating the updated neighbor node weights. The weight fluctuation of each graph node in the target neighbor node set before and after the update is detected, and a feature drift detection template is generated based on the weight fluctuation and the number of pre-configured historical fluctuation records. The feature drift detection template is sent to the pre-configured network edge nodes, and the edge traffic sample feature set returned by the network edge nodes is received. Based on the edge traffic sample feature set, new graph nodes that meet the pre-configured new node conditions are identified in the feature-weight association graph, and the new graph nodes are written into the feature-weight association graph.

9. A network traffic dynamic control system based on priority scheduling, characterized in that, The control system includes: The traffic feature extraction module is used to collect real-time network traffic data packets and extract features to generate traffic feature vectors; The initial priority matching module is used to match initial priority weights to the traffic feature vector based on the historical performance database, associate the initial priority weights with the corresponding data packets that generated the traffic feature vector, and generate an initial traffic queue based on the associated data packets. The dynamic adjustment factor calculation module is used to obtain the real-time load status of the current link and the queuing waiting time of each data packet in the initial traffic queue, and calculate the basic dynamic adjustment factor based on the real-time load status. The target priority weight generation module is used to calculate the ratio of queuing time to a preset protocol timeout threshold for low-priority data packets in the initial traffic queue, generate a timeout risk compensation value, add the timeout risk compensation value to the initial priority weight, and generate a target priority weight by combining it with the basic dynamic adjustment factor; for other data packets, the target priority weight is generated directly by combining the basic dynamic adjustment factor and the initial priority weight. The bandwidth quota scheduling module is used to divide the available bandwidth resources within the current scheduling time window according to the target priority weight and the weight ratio, and generate a scheduling instruction set containing the bandwidth quota corresponding to each data packet. The scheduling execution and log receiving module is used to send the scheduling instruction set to the network device to execute traffic transmission, and to receive the transmission performance log returned by the network device during the transmission process; The weight update parameter generation module is used to extract the actual transmission delay from the transmission performance log, calculate the deviation between the actual transmission delay and the expected transmission delay, and generate weight update parameters based on the deviation. The weight matching logic update module is used to feed back the weight update parameters to the historical performance database to update the matching logic of the initial priority weight.

10. A computer-readable storage medium, characterized in that: The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 8.

Images