Gateway data transmission control method and system based on improved token bucket method

Abstract

The invention provides a gateway data transmission control method and system based on an improved token bucket method. According to the method, a traditional token bucket flow limiting method is improved by introducing a parameter self-optimization mechanism, a burst flow self-adaptive adjustment mechanism and a multi-node cooperative control mechanism. The method comprises the following steps: firstly, generating tokens according to a specified frequency and distributing the tokens to token buckets, and requesting to perform access control according to token acquisition conditions by a client; dividing the data into a plurality of independent data groups, queuing and processing the data groups in corresponding token buckets, and solving the optimal token bucket capacity and issuing rate to minimize data processing delay by analyzing the arrival rate and queuing probability of data packets; when a single-channel or group-level burst traffic event is detected, the token bucket rate and capacity are automatically adjusted to achieve traffic limiting adaptation and cooperative stabilization. According to the invention, system load balance and rate convergence can be maintained under a high concurrency condition, time delay and jitter caused by flow fluctuation can be substantially reduced, and continuity of data transmission and gateway scheduling efficiency can be improved.

Description

Technical Field

[0001] This disclosure relates to the fields of computer network and Internet of Things communication technology, and in particular to a data transmission control method and system based on an improved token bucket algorithm for gateway devices, which can be used for rate limiting management, traffic scheduling and real-time transmission performance optimization of distributed network nodes. Background Technology

[0002] With the widespread adoption of distributed computing and edge networks, gateway devices play a crucial role in real-time transmission and traffic distribution between different data sources. Due to the highly volatile and sudden nature of network load, traditional fixed-parameter token bucket rate limiting algorithms often exhibit lag in response to high concurrency or sudden surges, leading to excessively long data queues or uneven bandwidth utilization. While some improved algorithms can partially mitigate traffic surges through multi-level rate limiting or fixed-ratio adjustments, they still cannot achieve adaptive optimization based on instantaneous load changes, nor can they establish a unified rate control strategy across multiple nodes. Therefore, a dynamic rate limiting method with self-learning and collaborative adjustment capabilities is needed, enabling token parameters to adjust in real-time according to changes in traffic characteristics to maintain stable transmission performance in complex network environments. Summary of the Invention

[0003] This disclosure provides a gateway data transmission control method and system based on an improved token bucket approach. This disclosure introduces load feedback-based parameter self-optimization, sliding window-based burst traffic adaptive adjustment, and a multi-node collaborative rate-capacity consistency control mechanism on top of traditional token bucket rate limiting, to improve the system's dynamic response and global stability under complex traffic environments.

[0004] This disclosure provides the following technical solution: According to a first aspect of this disclosure, a gateway data transmission control method based on an improved token bucket method is provided. The method improves the token bucket method by introducing parameter self-optimization, burst traffic adaptive adjustment, and multi-node collaborative control mechanisms. The method includes the following steps:

[0005] Generate a specified number of tokens into the token bucket at a specified frequency; if the token bucket is full, discard the tokens.

[0006] The client requests the gateway to access and transmit data. The gateway determines whether the current request is exempt from rate limiting. If so, it accesses directly; otherwise, the gateway attempts to obtain a token from the token bucket.

[0007] If obtaining the token fails, the request is rejected; otherwise, the request is allowed to access the target service as intended.

[0008] The permission request to access the target service for its intended purpose includes the following steps:

[0009] The data to be transmitted is divided into multiple independent data groups, each data group includes several data packets, and each data group is assigned to a corresponding token bucket for independent processing;

[0010] For each data packet in a data group, determine its arrival time and length information, and calculate the departure time of the data packet in the corresponding token bucket based on the processing status of the previous data packet of the same length.

[0011] The token bucket issues tokens to the allocated data groups, determines the transmission rate based on the arrival rate of data packets and the queuing probability, and calculates the optimal token bucket capacity and token sending rate to minimize data processing time. Then, it performs queue reshaping on the multiple data packets that the token bucket needs to process.

[0012] The arrival rate of each token bucket is monitored for sudden traffic events. When a single-channel or group-level sudden traffic event is detected, the token issuance rate and capacity parameters of the corresponding token bucket are dynamically adjusted to achieve adaptive reduction and collaborative flow limiting control of sudden traffic.

[0013] According to a second aspect of this disclosure, a gateway data transmission control system based on an improved token bucket method is provided. The system is used to perform the method described above and includes: a token management module, a request processing module, a data processing module, a parameter optimization module, and a traffic adjustment module. Attached Figure Description

[0014] The present disclosure will now be described in more detail with reference to embodiments and the accompanying drawings. Wherein:

[0015] Figure 1 A block diagram of a gateway data transmission control system 10 based on an improved token bucket method is shown.

[0016] Figure 2 A flowchart of a gateway data transmission control method 200 based on an improved token bucket method is shown.

[0017] Figure 3 This diagram illustrates the operating environment in which method 200 in an embodiment of the present invention performs rate limiting and redistribution of multi-queue data through multiple token buckets and overflow buckets.

[0018] Figure 4 A flowchart of a method 300 for accessing a target service for an intended purpose according to an embodiment of the present disclosure is shown.

[0019] Figure 5 The diagram illustrates the dynamic changes and parameter timing of a single token bucket data packet queue under the first selection condition scenario.

[0020] Figure 6The diagram illustrates the dynamic changes and parameter timing of a single token bucket data packet queue under the second selection condition scenario.

[0021] Figure 7 The diagram illustrates the dynamic changes and parameter timing of a single token bucket data packet queue under the third selection condition scenario.

[0022] Figure 8 The diagram illustrates the dynamic changes and parameter timing of a single token bucket data packet queue under the fourth selection condition scenario.

[0023] Figure 9 A flowchart of a method 400 for solving the optimal token bucket capacity and token sending rate and then performing queue reshaping is shown.

[0024] Figure 10 This is a schematic diagram illustrating the relationship between the average waiting time variation of method 400 obtained according to embodiments of this disclosure under conditions of joint optimization of different token bucket capacities and token issuance rates.

[0025] Figure 11 A flowchart of a method 500 for detecting burst traffic events and adaptively adjusting token bucket parameters according to an embodiment of the present disclosure is shown.

[0026] Figure 12 A schematic diagram of the token bucket's token transmission volume per unit time under different group coordination coefficients is shown in method 500 according to an embodiment of the present disclosure.

[0027] Figure 13 The adaptive adjustment and smoothing feedback process of data arrival rate and token issuance rate under different burst phases of method 500 is shown.

[0028] Figure 14 A flowchart is shown of a method 600 for jointly adjusting the rate and capacity of each token bucket within a group when multiple token buckets experience a coordinated burst, according to an embodiment of this disclosure.

[0029] Figure 15 A schematic diagram of a multi-node rate phase mapping vector and its cooperative synthesis result S(t) in method 600 according to an embodiment of the present disclosure is shown.

[0030] Figure 16 The dynamic convergence process based on a global cooperative equilibrium point in method 600 according to an embodiment of this disclosure is illustrated.

[0031] Figure 17 A schematic diagram is shown of the continuous adjustment of parameters within a sliding time window and the synchronous updating of the window boundary period in method 600 according to an embodiment of the present disclosure. Detailed Implementation

[0032] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this disclosure.

[0033] In existing gateway data transmission systems, the traditional token bucket method typically performs rate limiting control with a fixed token generation rate and capacity threshold to suppress sudden access requests or network congestion. However, because this method lacks dynamic adaptability, when network load fluctuates rapidly or multiple data sources arrive simultaneously, the system struggles to adjust the issuance rate and token capacity in a timely manner, easily leading to increased request rejection rates or decreased resource utilization, thus affecting overall data transmission performance.

[0034] With the development of IoT and cloud-edge collaborative architecture, data transmission scenarios are becoming increasingly complex, with dynamic interactions between network nodes involving multiple paths, rates, and traffic sources. To achieve stable, low-latency data transmission in this environment, gateway systems urgently need rate optimization mechanisms based on real-time load feedback, as well as dynamic control capabilities to handle sudden traffic surges and multi-node collaboration. This disclosure introduces parameter self-optimization, sliding time window burst detection, and multi-node consistency control mechanisms into the traditional token bucket rate limiting model, constructing a gateway data transmission control system capable of adaptively adjusting rate and capacity to achieve efficient, stable, and intelligent data scheduling under high concurrency conditions.

[0035] To more accurately describe the concept of this disclosure, the following is combined with Figure 1 A sample system according to embodiments of the present disclosure is described in detail. Figure 1 A structural diagram of a gateway data transmission control system 10 based on an improved token bucket method is shown, which is used to execute the gateway data transmission method of claim 1 to achieve adaptive adjustment of data transmission rate and token bucket capacity.

[0036] The system 10 includes a token management module 101. The token management module 101 generates a specified number of tokens into a token bucket at a specified frequency, and discards newly added tokens when the token bucket capacity reaches its limit, thereby maintaining a dynamic balance between the token generation rate and capacity. In some embodiments, the token management module 101 can periodically generate tokens through a configurable rate generation unit and trigger a discard mechanism when a preset capacity threshold is reached to prevent sudden congestion caused by excessive tokens.

[0037] System 10 also includes a request processing module 102. The request processing module 102 receives access requests from clients and determines whether they are rate-limit-free requests. If a rate-limit-free request is received, direct access is allowed; if not, the token management module 101 is invoked to attempt to obtain a token, and the request is rejected if there are insufficient tokens. In some embodiments, the request processing module 102 can be configured with a determination strategy, such as determination conditions based on user type or service priority, to implement differentiated access control.

[0038] System 10 also includes a data processing module 103. The data processing module 103 is used to divide the data to be transmitted into multiple independent data groups, each data group containing several data packets. This module can calculate the corresponding departure time based on the arrival time and length information of each data packet, thereby achieving independent queuing and transmission of the data groups. In some embodiments, the data processing module 103 can combine timestamp and packet length detection logic to improve the accuracy of timing calculations.

[0039] System 10 also includes a parameter optimization module 104. The parameter optimization module 104 determines the transmission rate based on the arrival rate and queuing probability of data packets, and calculates the optimal token bucket capacity and token sending rate to minimize data processing time. In some embodiments, the parameter optimization module 104 may execute a dynamic adjustment method based on minimizing waiting time to achieve adaptive rate allocation and capacity optimization.

[0040] System 10 also includes a flow regulation module 105. The flow regulation module 105 monitors changes in the arrival rate of each token bucket to detect sudden traffic events. When a single-channel or group-level burst is detected, the flow regulation module 105 dynamically adjusts the token issuance rate and capacity parameters of the corresponding token bucket to achieve adaptive reduction and coordinated flow limiting of the burst traffic. In this embodiment, the flow regulation module 105 can combine a sliding time window and variance threshold method for real-time detection to ensure the system maintains transmission stability under high-concurrency scenarios.

[0041] In some embodiments, the modules in system 10 can be logically interconnected through bus or message queue communication. Specifically, the token management module 101 and the request processing module 102 work together to complete traffic access control; the data processing module 103 and the parameter optimization module 104 form a dynamic feedback link to achieve continuous optimization of rate and capacity; and the traffic adjustment module 105 can further perform rate limiting and burst correction globally, thereby achieving overall adaptive regulation.

[0042] In some embodiments, such as Figure 1As shown, system 10 may also include a collaborative control module 106. The collaborative control module 106 is used to jointly adjust the rate and capacity of each token bucket within the group when multiple token buckets experience simultaneous collaborative bursts. By introducing rate phase mapping and parameter feedback mechanisms, the collaborative control module 106 can establish dynamic coupling relationships among multiple nodes (or multiple token buckets) to achieve synchronous convergence and balanced control of global rate-capacity parameters.

[0043] In this embodiment, the collaborative control module 106 can calculate the collaborative adjustment factor within the group in real time based on the current rate offset and burst correlation coefficient of each token bucket, and perform consistent adjustment on adjacent token buckets to reduce local rate oscillations. This module can trigger the collaborative adjustment process when the system detects a group-level burst traffic event, and maintain balanced operation of the entire system under multi-channel concurrency conditions by adjusting the issuance rate and capacity ratio of each token bucket.

[0044] Furthermore, the cooperative control module 106 can form a closed-loop feedback structure with the flow regulation module 105 to continuously evaluate global rate differences and phase consistency within a sliding time window. Through periodic parameter updates and cooperative feedback, the system can suppress overload fluctuations within the group while ensuring stable transmission rates, thereby improving the overall network coordination and dynamic stability.

[0045] Figure 2 A flowchart of a gateway data transmission control method 200 based on an improved token bucket method is shown. Method 200 can be implemented in, for example... Figure 1 In the system 10 shown, the method can be executed collaboratively by the request processing module 102 and the token management module 101 in the system 10, or it can be jointly implemented in control logic by the parameter optimization module 104 and the flow regulation module 105 in the system 10. In some embodiments, all steps of the method can be completed by software logic instructions in the internal processing unit of the system 10, or by hardware circuits and firmware in collaboration. For ease of understanding, the following will be combined with Figure 2 Each step of the method disclosed herein is described in detail.

[0046] According to the method 200 of the present disclosure, based on the traditional token bucket rate limiting mechanism, the method introduces parameter self-optimization, burst traffic adaptive adjustment and multi-node collaborative control mechanism to achieve fine-grained scheduling and stable control of gateway data flow under different load scenarios, thereby effectively reducing request latency in high-concurrency environments.

[0047] like Figure 3As shown, in one embodiment, method 200 further includes a multi-token bucket rate limiting and queue scheduling process. This process consists of multiple parallel token buckets (token bucket 1, token bucket 2, ..., token bucket M) and corresponding input data queues (queue 1 to queue N). Each token bucket corresponds to an independent data group channel to achieve parallel rate limiting and bandwidth balancing control. It should be noted that each input data queue corresponds to a transmission data group, and each transmission data group contains multiple data packets to be transmitted.

[0048] In this embodiment, data from different sources or different service types can enter different queues (queue 1 to queue N) and be allocated to corresponding token buckets for processing. Each token bucket issues tokens at a set rate to control the transmission rate of the corresponding data group. If the instantaneous load of a bucket is too high or tokens are piling up, the overflowing tokens will be automatically imported into the upper-level overflow bucket to achieve resource reallocation and dynamic balancing at the group level, thereby avoiding local congestion and maintaining a stable output of overall traffic.

[0049] like Figure 3 As shown, the entire rate limiting and adjustment process consists of an input queue, a token bucket, and an overflow bucket, used to achieve multi-level data scheduling and bandwidth shaping. The input queue is used to buffer data packets to be processed, each token bucket is responsible for issuing tokens and controlling the rate per unit time, and the overflow bucket acts as a global buffer unit to absorb instantaneous overload and coordinate the rate differences between token buckets. Through this multi-level rate limiting mechanism, this invention can achieve burst traffic suppression and adaptive resource allocation in complex network environments, effectively improving the stability of gateway data transmission and overall throughput performance.

[0050] In some embodiments, in step 201, the gateway generates a specified number of tokens at a preset frequency and injects them into a token bucket. When the token bucket reaches its capacity limit, newly added tokens are automatically discarded to maintain a dynamic balance in the number of tokens. For example, tokens can be generated at millisecond intervals via a timed task triggered by a timer, ensuring a smooth allocation of bandwidth resources over time.

[0051] In step 202, the client sends an access request and transmits data to the gateway. The gateway first determines whether the request is a rate-limit-free type (such as a high-priority request like a system health check or authentication login). If it is a rate-limit-free request, it is allowed directly; otherwise, it invokes the token management logic to attempt to obtain the corresponding number of tokens from the token bucket to determine whether further access is permitted.

[0052] In step 203, if token acquisition fails, it indicates that there are not enough tokens in the current bucket, and the gateway will reject the access request. For example, the gateway can inform the client to wait or retry by returning a status code or using a queue delay response mechanism; if token acquisition is successful, proceed to step 204.

[0053] In step 204, the request is allowed to access the target service as intended. At this point, the data stream will be allocated to the corresponding token bucket channel, and dynamically adjusted by the subsequent parameter self-optimization and burst detection module to ensure the continuity and balance of the overall transmission process.

[0054] As described above, the method 200 provided in this disclosure establishes a hierarchical token bucket management and dynamic adjustment mechanism on the gateway side, enabling the system to achieve adaptive rate limiting and collaborative control in complex network environments such as high load and burst traffic, ensuring that the gateway can maintain stable throughput performance and low latency response under multi-node collaboration conditions.

[0055] Figure 4 A flowchart of a method 300 for accessing a target service for an intended purpose according to an embodiment of the present disclosure is shown.

[0056] In step 301, the transmitted data is divided into N groups. The nth group of transmitted data is Each group of transmitted data is independent and non-overlapping: n=1,2,…,N; each group of transmitted data contains a data stream consisting of I data packets, therefore… ,in, Transmit the i-th data packet in the n-th data group; each token bucket transmits multiple data groups, and the m-th token bucket is represented as... , m=1,2,…,M; the time when the i-th data packet of the n-th data group arrives at the m-th token bucket is Let the initial token sending volume per unit time for the m-th token bucket be . That is, the token sending rate ;

[0057] The token bucket number is the one to which the nth set of data is processed and transmitted. A mapping function for the token bucket number corresponding to the nth data group; ,and Then the i-th data packet in the n-th data group arrives at the corresponding location in the n-th data group. The arrival time of each token bucket is .

[0058] By setting the binary indicator allocation coefficient This allows the data in the nth data group to be allocated to the unique token bucket. ; This means that if the nth data set is processed by the mth token bucket, then... Otherwise, it is 0;

[0059] In step 302, the real-time length of the data in the i-th data packet of the n-th transmission data group is... The index of the nearest preceding data packet with the same data length to the i-th data packet is defined as... ;

[0060] , that is to say The meaning, It is a supremum function, that is, it takes the least upper bound of the independent variable, in which ( The meaning of ) is that the length of the p-th data packet in a total of I data packets is the same as the length of the i-th data packet, and the p-th data packet is sent before the i-th data packet. If tokens are issued by a token bucket to process transmissions, then let the index of the i-th data packet be... ;

[0061] Based on this, calculate the number of packets that leave the i-th packet. The moment of a token bucket :

[0062] ;

[0063] Token bucket for processing the nth group of transmitted data The number of available tokens when allocating a token to the i-th packet after the i⊝1-th packet has left. Let i⊝1 be the departure time of the first data packet (i.e., the previous data packet of the same length). The departure time of the (i-1)th data packet;

[0064] for The selection of calculation formulas under four different scenarios, and the selection conditions. As a token-supplemented threshold, it is the numerator in the left-hand addendum. This represents the total number of tokens required for the current packet minus the number of tokens currently remaining in the bucket, i.e., the number of tokens still needing to be generated. The numerator is divided by... Then we obtain the time required to replenish these tokens. After the left-hand side is calculated, we add , indicating that this replenishment process must be performed after the previous token use. Therefore, the sum gives the earliest time that the next packet of the same length can be processed. This is the baseline moment for calculating the token replenishment threshold.

[0065] Figures 5 to 8 The graph shows the dynamic changes of the system queue under four selection scenarios, along with the time series positions of the parameters at each moment. The yellow line in the graph represents the cumulative number of arriving data packets. That is, from the initial time to time t (real time), the th The total number of packets received by each token bucket represents the input stream strength. The blue line represents the cumulative number of outgoing packets. , that is, the total number of packets from the initial time to time t that have completed the counter token and left, representing The rate at which each token bucket processes output packets. The solid green line represents the instantaneous queue length. , , indicating the first The number of packets queued in a token bucket, i.e., the load.

[0066] For the first scenario, when it meets the following conditions... and When, it indicates the first The token bucket has enough tokens and is in an idle or low-load state. That is, when the current packet arrives, the previous packet has not completely departed and the token bucket already has enough tokens, so it can be processed and departed immediately. Figure 5 In the middle, the yellow line represents the cumulative arrival. The cumulative departures represented by blue Rising almost simultaneously It only fluctuates briefly before returning to stability; that is, it only exists in a queue waiting for processing during a few short periods of time. After 15ms That is, after a brief fluctuation, the first Data packets arriving within the first token bucket do not need to wait; at this point, the first... The token bucket is under low load, and the waiting time is... .

[0067] For the second scenario, when it meets the following conditions... ,and When, it indicates the first Data transmission within each token bucket is in a state where data packets need to be queued and processed after they arrive. That is, although the current packet (the i-th data packet) arrives after the previous packet (the (i-1)-th data packet) has left, the corresponding tokens have not yet been fully replenished. Each token bucket needs to wait until the tokens are generated before processing. Figure 6 In the middle, the solid yellow line represents the cumulative number of arriving data packets. The cumulative arrivals, represented by the blue line, precede the arrivals on the vertical axis. The occurrence (i.e., a certain degree of packet queuing and waiting for processing within the token bucket) and the cumulative arrival volume The yellow line represents a certain delay in the arrival of data packets (approximately 11ms-15ms) before rising and reaching its peak at 15ms. Similarly, it also occurred within the 17.5ms-20ms timeframe. This reflects the queue accumulation process, indicating that the arrival of the i-th data packet predates the time when it was issued a usable token. It doesn't appear until 20ms later. This means that data packets arrive and are sent immediately, without waiting or queuing.

[0068] For the third scenario, when it meets the following conditions... ,and When, it indicates the first Data transmission within a token bucket is in a state where the previous packet has been occupied for a considerable time, indicating a transmission delay for the i-th packet. The current packet arrives before the previous packet has left (represented by the blue dashed line). The system is either overloaded or in a busy state, and newly arriving data packets must queue and wait for the previous packet to complete. This indicates the previous packet's transmission time has exceeded the token replenishment threshold. Figure 7 In the middle, the yellow solid line represents Above the blue solid line during the 11ms-20ms period. Furthermore, the value was higher than the blue solid line during the 20ms-25ms period, resulting in the cumulative arrivals exceeding the cumulative departures during both periods, thus causing the queue length to increase during these two periods. , Overall, the system latency increases in a step-like manner during these two periods, reflecting a continuous increase in queue length. The system latency is mainly caused by queue congestion.

[0069] For the fourth scenario, when it meets the following conditions... and When, it indicates the first Data transmission within a token bucket is in a state of token issuance lag. In this situation, the current packet arrives too early and the system is under continuous high load, requiring the previous token replenishment process to complete before a token can be issued. Figure 8 Cumulative arrivals In the 11ms-13ms range, it is higher than the area represented by the blue solid line. And the yellow solid line represents At 13ms, the packet size suddenly increased to 3 packets, represented by the solid blue line. The queue length remained at 1 packet for the 10ms-16ms period, then suddenly increased to 2 packets at 16ms, thus increasing the queue length. The curve exhibits a boss structure between 11ms and 20ms, and remains stable between 11ms and 13ms. =1, held for 13ms-16ms =At point 2, it remains at point 1 for 16ms-20ms, and only reaches its target after a 20ms delay. This indicates that the token issuance rate becomes the bottleneck factor in this scenario. (The output value...) This equals the token replenishment threshold, reflecting the relationship with the token issuance rate. It has a direct control effect on transmission delay.

[0070] It should be noted that in Figures 5 to 8 In some sections, the lines have the same value in either the numerical or horizontal direction. To avoid unclear visual representation due to overlapping lines, a slight misalignment is introduced, for example, in... Figure 6 , Figure 8 The overlapping of the black solid line and green dashed line in the vertical direction, representing the token issuance threshold and the increase in the cumulative instantaneous value of departure, is shown as a slight offset on the left and right sides of 20ms. This does not indicate a difference in the timing of the three lines, but rather that they appear at the same moment.

[0071] In step 303, a token bucket is allocated to the transmitted data to distribute tokens, thereby performing queue reshaping and transmission rate control on the group of transmitted data; the token bucket to which the nth group of transmitted data is allocated... Tokens are sent to the data stream consisting of I data packets contained therein. token bucket The token capacity is ;

[0072] When the i-th data packet in the nth data group is in the... Queuing occurs at the entrance of each token bucket, with an arrival rate of [missing information]. It conforms to a Poisson distribution; the i-th data packet is in the i-th... The probability of receiving a token and leaving at the token bucket exit. ; It conforms to an exponential distribution.

[0073] Based on the calculated departure times of the i data packets Arrival time Find the optimal token bucket size that minimizes data processing time. And the optimal token transmission amount per unit time for the nth group of data is .

[0074] In some embodiments, step 304 is used to implement dynamic adaptive adjustment and collaborative rate limiting control based on burst traffic detection. The traffic adjustment module 105 of system 10 monitors the change in the arrival rate of data packets in real time within the time window of each token bucket. When the rate variance is detected to exceed a preset threshold, it is determined that a burst traffic event has occurred in the token bucket.

[0075] For a single token bucket experiencing a sudden surge, the system automatically adjusts its token issuance rate and bucket capacity based on the surge intensity to reduce queue backlog caused by short-term peaks, and gradually reverts to the original parameters after load recovery. If multiple token buckets are detected to experience simultaneous surges within the same time period, the system coordinates the amount of overflow tokens collected from the overflow bucket and adjusts the token issuance rate and capacity of each token bucket processing data packets in the data group to achieve group-wide coordinated regulation. This involves rate reduction for high-load buckets and token compensation for low-load buckets to balance the overall load of the group and suppress global congestion.

[0076] Through this dynamic peak shaving and collaborative rate limiting mechanism, the system can maintain a stable data transmission rate under high concurrency and sudden surge scenarios, and achieve adaptive resource allocation and global traffic balance among token buckets.

[0077] This application, based on the traditional token bucket rate limiting mechanism, introduces parameter self-optimization, burst traffic adaptive adjustment, and multi-node collaborative control mechanisms to achieve dynamic rate limiting and fine-grained adjustment of data transmission in high-concurrency network environments. Compared with existing static rate limiting schemes, this method can quickly identify single-channel or group-level burst events when traffic load changes abruptly, and automatically complete the adaptive correction of token issuance rate and capacity parameters within a sliding time window period, effectively suppressing the sharp increase in queue length and improving the system's real-time response capability to traffic surges. Simultaneously, by introducing feedback smoothing and collaborative adjustment mechanisms, the token issuance trajectory remains continuously controllable in the time domain, avoiding oscillations and repeated tuning in traditional rate adjustment, significantly reducing latency fluctuations and rate jitter. Furthermore, collaborative control among multiple token buckets achieves rate-capacity consistency optimization across nodes, enabling each node to maintain global load balance and synchronous stability under burst scenarios, thereby balancing latency reduction and convergence and throughput balance across different time periods in dynamic network environments. This disclosure can protect and schedule system resources under high concurrency and burst traffic conditions.

[0078] Figure 9 A flowchart of a method 400 for solving the optimal token bucket capacity and token sending rate and then performing queue reshaping is shown.

[0079] In step 401, the average packet length in the nth data group is: ;

[0080] Furthermore, the first The probability of a token bucket exiting and completing the token distribution process before leaving. : ;

[0081] like Larger tokens result in faster token issuance and shorter waiting times; if... If the token size is too small, the token issuance rate will be slow, leading to queue accumulation, long waiting times, and increased latency.

[0082] For the i-th data packet in the n-th data group, in the... The arrival rate of each token bucket is determined by the arrival time. The arrival rate is estimated by using the observation window: ;

[0083] Therefore, the i-th data packet is obtained at the i-th position. The token bucket is processed at a rate of ;

[0084] In step 402, the first is defined The total processing capacity of the token buckets is :

[0085] ;

[0086] according to Calculate the first The probability of a token bucket being idle : ρ is abbreviation; calculation of the first The probability that there are k data packets in a token bucket is : k=1,2,…,K-1;

[0087] And define the first The probability of a token bucket being congested is ;

[0088] Furthermore, when ρ≠1, the th... The total number of packets waiting and being processed in the token buckets, i.e., the number of packets in the first token bucket. Load of token buckets :

[0089] ;

[0090] In step 403, according to the first Load of token buckets Calculate the first Packet queue length per token bucket :

[0091] ;

[0092] In step 404, according to the first step of step 402 The probability of token bucket congestion And the i-th data packet obtained in step 401 at the... The arrival rate of each token bucket Calculate the i-th data packet in the i-th... The effective arrival rate of each token bucket is ;

[0093] In step 405, in some embodiments, the overall latency characteristic parameter is the value of the i-th data packet at the i-th data packet in ... The average waiting time in each token bucket is calculated based on the above steps to obtain the final waiting time of the i-th data packet in the i-th token bucket. Average wait time per token bucket: ;

[0094] In step 406 (S36), the I data packets of the nth data group are constructed in the first step. Optimal average processing time for token buckets:

[0095] ;

[0096] Then, the optimal token bucket capacity with the shortest data processing time can be obtained. And the optimal token transmission amount per unit time for the nth group of data is .

[0097] In some embodiments, during the solution process of step 406, it is further specified that the i-th data packet is in the i-th... The token bucket is processed at a rate of The constraints are solved under load balancing conditions, i.e., under boundary constraints. and At the same time, limit Solve under the constraints of load balancing.

[0098] In some embodiments, token bucket capacity The unit is the number of tokens, the number of tokens sent per unit of time. The unit is tokens per second, where each token corresponds to one transmittable data packet. This setting is suitable for communication scenarios where data packets are the basic unit of transmission.

[0099] In other embodiments, The unit is bytes, and The unit is bytes per second; in some other embodiments, The unit is bit, and The unit is bits per second (bit / s). This metric can be used to reflect the system's flow regulation capability at the byte or bit level when each token represents a fixed amount of data.

[0100] Figure 10 The diagram shows the token transmission volume in different units of time. and different token bucket capacities Under the given conditions, the trend of the average waiting time W(b,r) is observed. Figure 10 Each curve corresponds to a different token transmission volume r per unit time (e.g., r = 1.10, 1.40, 1.80, 2.20, 2.80), and the horizontal axis represents the token bucket capacity. (Constraint b≥2), the vertical axis represents the average waiting time W(b,r). Figure 10 middle The unit is the number of tokens, in units; The unit is tokens per second; therefore, the vertical axis... The unit is seconds.

[0101] from Figure 10 As can be seen, when the token issuance rate r is low (e.g., r=1.10), the average waiting time W increases with the token bucket capacity. A significant increase indicates severe token backlog and prolonged data queue waiting time under low-rate conditions; while when When the value is increased to 2.80, the curve flattens out and remains within a low waiting time range. Specifically, the red marker in the lower left corner (b...) * =2, r * =2.80) corresponds to the optimal solution under the constraint b≥2, and its average waiting time W * =0.454, which is the global minimum point (W). * For W * (abbreviation of (b,r)). This point reflects the limitation on the minimum token bucket capacity b. min =2 and the upper limit of speed r max Under these conditions, the shortest average processing latency can be obtained through joint parameter optimization.

[0102] This result shows that, under the load balancing constraint ρ≈1, the token bucket capacity... There is a non-linear cooperative relationship with the token issuance rate r: when Too small a value will cause queue congestion, while Excessive size leads to cumulative delays; only the optimal combination (b) can achieve this. * r * Minimize the waiting time W(b,r) at point ).

[0103] Therefore, the method 400 of the present invention achieves optimization under engineering constraints b by constructing a two-parameter optimization model of W(b,r). min ≤b≤b max With r min ≤r≤r maxThis method finds the optimal solution under different conditions, thereby achieving dynamic adaptive adjustment of the token issuance rate and bucket capacity without increasing system complexity. Compared with the traditional fixed-parameter token bucket algorithm, this method can automatically optimize during both burst and stable transmission phases, significantly reducing average waiting latency and improving overall throughput efficiency.

[0104] By establishing and solving the above optimization model, the method of this invention can significantly reduce the average latency under different traffic conditions. Experimental results show that under dual-parameter constraints, the average latency can be reduced by about 40%, effectively improving the real-time performance of data transmission. Under the load balancing constraint ρ≈1, the system can maintain stable operation, avoiding long-term queue backlog and resource waste in the token bucket, thereby achieving a dynamic balance between rate and capacity. This optimization process requires no manual intervention and can automatically adjust parameters according to the actual traffic distribution, exhibiting good adaptability. Compared with the traditional rate limiting method using fixed bucket capacity and constant token rate, the method 400 of this disclosure, by introducing a joint optimization and balancing constraint mechanism, extends the static rate limiting model into a dynamically optimized control framework, realizing the transformation of the token bucket mechanism from passive adjustment to active optimization, thereby significantly improving the stability and overall throughput performance of the gateway data transmission system.

[0105] In some other embodiments, the joint optimization adjustment process incorporates a closed-loop adjustment mechanism based on token bucket load feedback. This mechanism monitors the load of each token bucket in real time. With network congestion probability π k Dynamically adjust the token bucket capacity. Related to token issuance rate This ensures the system maintains steady-state operation under varying traffic conditions. During operation, the system first calculates the instantaneous load of each token bucket at the current moment. With expected load The deviation is analyzed, and the trend of parameter changes is determined by combining the congestion probability πk. When a persistent congestion trend is detected, the token sending volume per unit time is automatically reduced. To suppress the data inflow rate; conversely, when the system is under low load, to moderately increase it. or expand To fully utilize bandwidth resources. This adjustment process is performed within a continuous time window, enabling... and The solution no longer relies on a fixed threshold, but is updated in real time through a feedback loop, forming an adaptive dynamic optimization mechanism. Unlike traditional static threshold open-loop control, the closed-loop optimization disclosed herein can automatically correct control parameters according to the system operating state, thereby significantly improving the network's response sensitivity and steady-state performance, ensuring stable data transmission efficiency under high concurrency and burst load conditions.

[0106] Figure 11 A flowchart of a method 500 for detecting burst traffic events and adaptively adjusting token bucket parameters according to an embodiment of the present disclosure is shown.

[0107] In step 501, the sliding time window construction and real-time observation system is the m-th token bucket. Constructing a sliding time window This is used to record the data arrival rate of the m-th token bucket at time t within the specified time period. With distribution rate Within each window, the average arrival rate is calculated. With instantaneous variance :

[0108] ; ;

[0109] For the s-th sampling time t s (t) s ∈W u When ), the token flows into the m-th token bucket. The instantaneous data packet arrival rate; S is the time window length; s = u - S + 1, s = u - S + 2, ..., u;

[0110] when Exceeding the set threshold At that time, the m-th token bucket is determined to have experienced a sudden traffic event.

[0111] In step 502, based on the calculation result of step 501, the m-th token bucket is calculated in the u-th sliding time window W. u Sudden intensity coefficient within :

[0112] ;

[0113] , In the sliding time window W u Internal arrival rate The maximum and minimum values ​​should be noted, within the sliding time window of any adjustment cycle. , All remain unchanged; when When the m-th token bucket is found to have local burst traffic, it is determined that the m-th token bucket has a local burst of traffic.

[0114] Furthermore, for the adjacent token bucket group consisting of G token buckets adjacent to the m-th token bucket... Calculate the correlation coefficient of sudden outbreaks in the group : ;

[0115] To be in the sliding time window W u The arithmetic mean of the instantaneous arrival rates of all token buckets observed within the container;

[0116] like If so, it is judged as a group-level sudden traffic event, and coordinated traffic limiting needs to be implemented.

[0117] In step 503, in some embodiments, for a single-channel burst of traffic triggered by only one token bucket, the system determines the burst strength based on the burst intensity. By dynamically adjusting its issuance rate and capacity, the (u+1)th sliding time window W is obtained. u+1 The number of tokens sent per unit time in the m-th token bucket With token capacity :

[0118] ; ;

[0119] in, , W represents the u-th sliding time window. u The number of tokens sent and the token capacity of the m-th token bucket per unit time; , These are the first and second adjustment factors for rate and capacity, respectively. , The (u+1)th sliding time window also represents the next adjustment cycle; Burst strength coefficient for a single token bucket The maximum reference value is used to limit the dynamic adjustment of the sudden intensity within the normalized interval [0,1].

[0120] In other embodiments, coordinated regulation is used for group-time events where multiple buckets simultaneously trigger local bursts of traffic:

[0121] ;

[0122] ;

[0123] in, , The i-th token bucket in the (u+1)-th sliding time window W under a burst traffic event in the group are respectively u+1 The token issuance rate and token capacity updated using the Inner Canon dynamic adaptive method; , and These are the coordination coefficients of the first group, the second group, and the third group, respectively, used to balance rate coupling and capacity peak shaving within the group; Used to control the burst correlation coefficient of each token bucket within the group.

[0124] The suppression amplitude, i.e. the rate reduction intensity, is generally =0.15~0.35; Used to control the impact of rate averaging compensation terms between groups, preventing excessive reduction from leading to resource idleness, generally =0.05~0.20; This is used to control the synchronous reduction ratio of token capacity in each bucket within a group, affecting the smoothness of peak shaving. =0.10~0.30; Represents the sudden correlation coefficient of the group. The normalized upper limit is used to standardize the comparison of the suddenness of a group.

[0125] like Figure 12 As shown, the effects of three group coordination coefficients (γ1, γ2, γ3) on rate suppression and recovery processes in burst flow response are illustrated. Figure 12 The gray area indicates the interval of sudden events; the blue curve represents that when γ1=0.25, γ2=0, γ3=0, that is, only the first group coordination coefficient γ1 exists at this time. The system only performs sudden traffic suppression and does not perform equalization compensation for traffic changes or smooth adjustment of the capacity of multiple token buckets. Under this condition, the suppression effect of token sending rate is reflected, with fast response but large reduction.

[0126] The green dashed line represents the addition of an average compensation term γ2=0.10 and γ3=0 to the condition of rate suppression term γ1=0.25. This shows that, compared to the condition of the blue curve, adding an average compensation term can achieve balanced compensation characteristics, thus gently suppressing the changes in burst flow and making the recovery phase smoother. This prevents resource idleness caused by excessive suppression of burst flow. However, the adjustment and recovery of bucket capacity is not smooth.

[0127] The purple dotted line represents a further constraint on γ3=0.20 based on γ1=0.25 and γ2=0.10. This allows for a smoother adjustment of the bucket capacity compared to the green dashed line, which only adjusts the token sending rate, resulting in a slower output recovery and a more stable system. The orange curve represents the burst traffic variation curve without adjustment by the group coordination coefficients (γ1, γ2, γ3). It is evident that the group token bucket without these coefficients exhibits significant burst traffic peaks during data transmission.

[0128] In step 504, to prevent rate oscillations caused by frequent fluctuations, a feedback smoothing coefficient is introduced to perform a moving average feedback adjustment on the token transmission volume and token capacity per unit time of the (u+1)th sliding time window and the uth sliding time window, so as to obtain the token transmission volume per unit time of the mth token bucket in the (u+1)th sliding time window after smoothing adjustment. With token capacity :

[0129] ;

[0130] ;

[0131] Where ω is the feedback smoothing coefficient, used to control and adjust the response speed. .when Exceeding the token sending limit threshold range ,or Exceeding the token capacity limit threshold range At that time, threshold constraint correction is performed to ensure stability.

[0132] In step 505, adaptive collaborative rate limiting is implemented. The global token bucket parameter set is updated by combining the results of single-bucket adaptive and group collaborative methods. :

[0133] .

[0134] like Figure 13 As shown, during the sliding time window detection process, the system first identifies local changes in burst traffic and then executes corresponding adaptive adjustment strategies after detecting different types of burst events. Specifically, within the first gray shaded area (corresponding to a time interval of 33–48 seconds), the orange curve... A sharp rise occurs but is short-lived; the blue curve represents... A rapid response accompanied by strong jitter, while the green curve... This manifests as a gradual and smooth convergence. This change process indicates that the sudden response at this stage is concentrated on a single channel, and system 10 mainly relies on the sudden intensity coefficient. Dynamic flow limiting is implemented to quickly reduce localized surges in traffic.

[0135] Within the second gray shaded area (corresponding to time 63–78 seconds), the orange curve... It exhibits higher peak values ​​and longer durations, represented by the blue curve. The peak-shaving action is relatively gentle, and the gap between the green curve and the blue line widens, reflecting the delayed adjustment effect of the smoothing feedback. During this stage, system 10 detected the burst correlation coefficient of the group. Exceeding the threshold The event is identified as a group-level burst traffic event, and the collaborative adjustment mechanism of the group coordination coefficient γ1–γ3 is activated to achieve coordinated adjustment of rate and capacity among multiple channel token buckets, thereby avoiding the superposition and amplification effect of burst traffic within the group.

[0136] ]like Figure 13 As shown, the orange curve represents the arrival rate. The arrival rate spikes in two gray areas: in the first area, it rapidly increases from approximately 50-60 packets / s before a traffic burst to a peak of approximately 75 packets / s; in the second area, the peak during a traffic burst can reach approximately 85 packets / s. If fixed rate limiting parameters are maintained, the peak periods will cause a rapid accumulation of packets in the queue, while the trough periods will result in tokens in the token bucket going unused, making it difficult to simultaneously minimize latency and maximize throughput when forwarding each packet during a traffic burst.

[0137] During the two traffic bursts, the blue curve represents... The system can promptly adjust and roughly align with the peak shape of the orange line: increasing to approximately 70 packets / s near the first peak and to approximately 75-76 packets / s at the second peak, significantly alleviating instantaneous congestion during peak periods; it then quickly drops back during troughs, avoiding maintaining excessively high quotas under low load. Meanwhile, the blue line exhibits significant jitter, especially at the edges of rises and falls, with the rate oscillating between 1-2 packets / s, easily inducing queuing delay jitter and frequent parameter switching. This indicates that the rapid adaptive adjustment in step 503 is necessary, but compared to the moving average represented by the green dashed line and the feedback smoothing... For example, simply performing step 503 would amplify the high-frequency noise into control fluctuations.

[0138] The green dashed line represents the moving average and feedback smoothing after steps 504-505. The blue curve represents the result of processing only in step 503. In comparison, the green dashed line represents During the two bursts, the phase and amplitude remained approximately the same as the orange line, but the peaks were slightly lower and the edges smoother: the first peak was approximately 68-69 packets / s, and the second peak was approximately 74-75 packets / s. A safety margin slightly higher than the arrival rate was maintained during the troughs, and the high-frequency jaggedness of the blue curve was almost eliminated. Therefore, continuing with steps 504-505 after step 503, compared to performing only step 503, avoids the fluctuations in instantaneous queueing caused by being forced to revert after exceeding the target value during rate adjustment. Furthermore, it reduces repeated rate adjustments during the recovery phase. Thus, fewer delay jitters and parameter switching times are achieved compared to not performing moving averages and feedback smoothing. This indicates that steps 504-505 further process the data after step 503, ensuring a faster adjustment response while making the system operation more stable and controllable.

[0139] In the first gray area (single-channel burst situation), step 503 promptly increases the rate within the bucket, suppressing queue spikes. Steps 504-505 further smooth the output, making the rate trajectory before and after the peak continuous and controllable, reducing the oscillations at the end of the burst. In the second gray area (group burst situation), step 503 ensures that the detection and response adjustment of burst traffic are almost simultaneous. Combined with the smoothing and threshold constraints of steps 504-505, the token issuance rate and capacity can be adaptively corrected within a sliding window period. This enables each bucket to converge collaboratively around the target quota, avoiding cascading congestion caused by excessive following by individual buckets. Consequently, regardless of whether it is a single-channel burst scenario or a group traffic burst scenario, the peak latency of the traffic burst is significantly reduced after processing by method 500, the resource utilization in the valley segment is more balanced, and the rate trajectory across the window is continuous and the boundaries are controlled.

[0140] By performing burst traffic detection in steps 501-502, and upon detecting a traffic burst, rapid adaptation is performed in step 503, followed by smoothing and constraint in steps 504-505. This ensures that the token issuance trajectory keeps pace with large-scale changes in arrival rate without over-responding to transient noise. Compared to traditional token buckets with fixed parameters or schemes that only adjust thresholds once, the method 500 of this disclosure couples rapid optimization with stable convergence, balancing fast response and stable operation. It significantly reduces latency jitter and parameter jitter frequency, supporting low-latency and high-throughput transmission under different burst patterns. Simultaneously, it introduces time-domain consistency adjustment and group coordination for token bucket rate limiting.

[0141] Figure 14 A flowchart is shown of a method 600 for jointly adjusting the rate and capacity of each token bucket within a group when multiple token buckets experience a coordinated burst, according to an embodiment of this disclosure.

[0142] Method 600 performs globally consistent and coordinated adjustment of the rate and capacity parameters of each token bucket, constructing a distributed multi-node coordinated rate-capacity control model. Global stable equilibrium is achieved through rate phase mapping, coordinated benefit evaluation, and parameter coupling feedback. In Method 600, a node refers to a logical control unit in the system that performs token issuance and data scheduling. In some embodiments, the logical control unit is the coordinated control module 106 in system 10. Each node can be configured with at least one token bucket to perform rate shaping and rate limiting control on a specified data group. When system 10 enters the multi-node coordinated control phase of Method 600, the token buckets achieve global coordination and consistency adjustment through a rate phase mapping function. Therefore, a node in this phase can be regarded as an abstract representation and control agent of the token bucket.

[0143] In step 601, rate phase mapping and multi-node state vector construction are performed.

[0144] The number of tokens sent per unit time in the m-th token bucket Mapped to periodic state variables :

[0145] ;

[0146] in, This is a local rate offset used to reflect load differences; ;

[0147] Establish a multi-node state vector: ;

[0148] A cooperative distribution relationship used to represent the token issuance rate status of each token bucket. is the amplitude weighting factor, used to represent the effective participation weight of the m-th token bucket in the global cooperative signal or synthetic field E(t); Alternatively, it can be calculated based on the proportion of the tokens sent per unit time in the m-th token bucket to the total tokens sent per unit time in all token buckets, i.e. .like Figure 15 As shown, each colored arrow represents a complex vector of a node. Its length is determined by The decision, the direction is determined by The decision is made. Vectors from different nodes are superimposed on the complex plane (real axis - imaginary axis) to form the red vector. This represents the global cooperative state of the system. When the phases tend to be consistent, these vectors tend to superimpose in the same direction, making... The magnitude reaches its maximum (i.e., the system exhibits the strongest coordination). If the phases are dispersed, some vectors cancel each other out, causing... As the modulus decreases, the system's synergy declines.

[0149] in, For the m-th token bucket node H m The local state vector at time t; for The abbreviation of, which is , , and The vector after normalization;

[0150] Therefore, after, , ;

[0151] In step 602, the collaborative benefit function construction and rate coupling modeling define the collaborative benefit function for each token bucket node:

[0152] ;

[0153] in, Let be the rate utilization coefficient for the m-th token bucket. , ;

[0154] To balance the penalty factor, , Basic penalty factor, ; , These are the packet queue length and the maximum packet queue length threshold for the m-th token bucket, respectively. For the amplitude limiting constraint function:

[0155] ;

[0156] Its function is to control variables Restricted to a specified range Inside;

[0157] For the cooperative coupling strength, ∈[0.1,0.4]. This is a reference value for the number of tokens sent in the m-th token bucket per unit time. In one embodiment of the present invention, to reduce implementation complexity and improve readability, after method 500 is completed, method 600 uses the average arrival rate of the sliding time window. The arrival rate is directly used as the input to the collaborative benefit function, and a reference value related to the token issuance rate is set as... This ensures stability while achieving consistent and coordinated adjustment of the rate and capacity of each node, with δ=0.05~0.20 (retaining a small amount of redundancy to avoid boundary jitter).

[0158] The coupling weight between nodes is denoted as W. In the embodiments of this disclosure, the coupling weight W between the m-th token bucket and the j-th token bucket is... mj The weights are determined based on a comprehensive analysis of node topology, physical or logical distance, and the correlation of flow changes within the sliding time window. When two nodes are in the same control domain and have the same flow trend, their weights are assigned higher values ​​(0.7–1.0); when there is no direct communication between nodes or their changes are unrelated, their weights are assigned lower values ​​(0–0.4). The weight matrix, after symmetry and normalization, is used in the multi-node collaborative optimization process.

[0159] In step 603, the collaborative dynamic evolution model establishes dynamic evolution equations based on the rate-benefit relationship of each node:

[0160] ;

[0161] The first equation describes the amount of tokens issued per unit time, r. m The adaptive change; the second equation describes the phase (i.e., the velocity state phase of the node) θ. m The dynamic cooperative evolution of the nodes. This equation describes the cooperative change process of rate adjustment and phase synchronization among the nodes.

[0162] The number of tokens sent per unit time for the j-th token bucket Periodic state variables obtained by mapping Specifically, it can be obtained according to the calculation formula in step 601; j=1,2,…,M; j≠m;

[0163] Let be the natural phase shift rate of the m-th token bucket. r m The current token issuance rate for the m-th node. The value varies with the number of tokens sent per unit time. The frequency of the system changes and is dynamically adjusted, typically ranging from 0.5 to 1.5 times the average frequency of the system, to characterize the rhythm differences of different nodes in the process of coordinated and consistent evolution. This is the rate-phase coupling gain coefficient. , This is a global scaling constant (typically 0.1–0.3), and therefore, ;

[0164] In step 604, the global cooperative equilibrium point solution defines the global stability function:

[0165] ;

[0166] When satisfied , At this point, a global collaborative equilibrium point is reached, and the token sending rate and bucket capacity of each token bucket tend to be balanced. Figure 16 The dynamic convergence process based on the global cooperative equilibrium point is illustrated. The system exhibits a stable function. The potential energy function is derived from two variables in the gradient flow evolution equation. and Describe the rate and phase evolution trends of each node (token bucket).

[0167] Figure 16 The solid line V(t) (dark blue) represents the change of the system's overall potential energy over time, exhibiting a monotonically decreasing trend and eventually tending towards a stable minimum, indicating that the system achieves stable convergence in the Lyapunov sense; the dashed line R(t) represents the global phase order. Its value increases over time and gradually approaches 1, indicating that the phase synchronization and rate consistency among the token buckets are consistent. Figure 16 In order to simultaneously represent the time-varying gradient flow evolution and In this case, both were scaled up proportionally by 4 times after being taken as a model. And 4... Take the negative value, and then display it in relation to 4. The synchronous comparison situation.

[0168] As can be seen from the curve trend, the system exhibits significant rate differences and phase discrepancies in the initial stage. As time progresses, the interactions between the nodes in the coupling term... Under the influence of various factors, the system gradually coordinates and eventually reaches a state of coordinated equilibrium, whereby all nodes simultaneously satisfy the desired conditions. and This result verifies that the global cooperative equilibrium point is determined through the potential energy function. Descending to and The convergence criterion is based on the potential energy function. It provides a measurable global monotonic decline indicator, avoiding oscillations and instability caused by relying solely on experience-based parameter tuning. It also measures the token issuance volume per unit time. and the phase corresponding to its mapping and coupling weights Through the global stable function By placing them within the same potential energy framework constraint, we can ultimately ensure that the equilibrium point obtained from the solution corresponds to... and It is a consistent and reproducible point, and through The rate deviation of the constraint term converges to the equilibrium point, through This item increases the token issuance rate of each token bucket. The goal is to achieve phase consistency, thereby suppressing overload and maintaining synchronization. Ultimately, the convergence of the two indices achieves rate and phase consistency, suppressing local oscillations and enabling multiple token buckets to achieve synchronized adjustment at the group level. This also provides convergence targets and global constraints for the t-scale continuous feedback in step 605 and the subsequent u-scale periodic summary output of parameter set updates. Overload refers to the state in which the instantaneous load of a token bucket or channel (such as the arrival rate of data packets, queue length Q(t), or token issuance rate r) exceeds its set or stable operating limit. Figure 16 The overall process demonstrates a decrease in overall situational performance and an increase in collaborative orderliness, verifying the effectiveness of the proposed method in achieving stable, coordinated, and adaptive evolution in multi-token bucket systems.

[0169] Figure 16 The time unit is in seconds (s), which represents the evolution time scale of the system under continuous updates in a sliding window. It can be adjusted to the millisecond level according to the gateway data refresh cycle.

[0170] In step 605, dynamic coupling feedback and parameter coordinated adjustment are introduced when the system detects local rate deviation or load imbalance: ;

[0171] Coordinated regulation is achieved through rate feedback between neighboring nodes, enabling the system to remain stable and consistent under sudden traffic and load disturbances. η is the coupling learning coefficient, meaning its magnitude represents the sensitivity of the rate-phase coupling strength between the m-th token and the j-th token bucket to the update at the next time step; c The larger the value of η, the more intense the system's coupling adjustment, resulting in a faster response but also greater oscillations; c The smaller the value, the smoother the system response but the slower the convergence; For stable networks or moderately sudden scenarios: η c =0.05~0.10; For high-instability or strongly correlated scenarios: η c =0.15~0.25; exceeding 0.3, the system is prone to coupled oscillations ( (unstable), therefore η c Set at Within the range.

[0172] The dynamic coupling feedback mechanism expression in step 605 represents a phase difference-driven adaptive weight update; when the rate mapping between node m and node j corresponds to the phase difference... When the value is large, the tanh value approaches ±1. Significant increases or decreases occur; when the corresponding phases of the rate mappings of the m-th token bucket and the j-th token bucket are almost synchronized ( ≈ When the tanh value is close to 0, the change in coupling weights tends to zero. This leads to the updated parameter set. And output:

[0173] ;in These are the updated globally optimal parameters under a multi-node (i.e., multiple token buckets) collaborative load balancing system. It should be noted that... , It is a variable that changes with the sliding time window index u; each window W u This represents a discrete adjustment period (equivalent to a system sampling period); and within each period (e.g., the u-th period), r m (t), θ m (t), W mj (t) and others change dynamically with continuous time t.

[0174] like Figure 17 As shown, step 605 operates on a continuous time scale. In each sliding time window The dynamic feedback process continues to execute internally. Variables during this stage... , , All times A continuous function is used to reflect the phase changes, rate adjustment, and weight coupling state of each token bucket in real time. When time... Evolved to the window boundary (i.e. After a certain time, system 10 will update the continuous feedback results in the window according to the updated parameter set. Perform periodic summaries and parameter set outputs to form a sliding window index. The discrete parameter set of the independent variable Therefore, step 605 is responsible for continuous dynamic adjustment within the window (fast timescale control), while step S56 is responsible for discrete global parameter synchronization at the window boundaries (slow timescale update). Together, they form a dynamic coupling mechanism with fast and slow timescales: at the continuous timescale t, the system achieves real-time response and dynamic adjustment through step 605; at the sliding window scale u, the system obtains the updated parameter set... The updated global optimal parameters within the system achieve periodic stable output and synchronization with global parameters. Method 600 enables multi-token bucket data transmission to maintain coordination between rapid changes and periodic updates, thereby achieving stable and efficient collaborative control of multi-token bucket data transmission in the time domain.

[0175] While the foregoing examples illustrate the principles of exemplary embodiments in one or more specific applications, those skilled in the art will understand that many modifications can be made to the form, usage, and implementation details without exercising inventive capacity and without departing from the principles and concepts of this disclosure. Therefore, this disclosure is not intended to be limiting except as limited by the following claims.

Claims

1. A gateway data transmission control method based on an improved token bucket method, the method improves the token bucket method by introducing a parameter self-optimization, burst traffic self-adaptive adjustment and multi-node collaborative control mechanism, characterized in that, The method comprises the following steps: Generating a specified number of tokens into the token bucket at a specified frequency, and discarding the tokens if the token bucket is full; The client requests the gateway to access and transmit data, and the gateway determines whether the current request is exempt from flow control, if yes, it directly accesses, if not, the gateway attempts to obtain tokens from the token bucket; If the token acquisition is unsuccessful, the request is rejected; otherwise, the request is allowed to access the target service as expected; The method for allowing the request to access the target service as expected comprises the following steps: Divide the data to be transmitted into multiple independent data groups, each data group comprising a plurality of data packets, and allocate each data group to a corresponding token bucket for independent processing; For each data packet in each data group, determine its arrival time and length information, and calculate the departure time of the data packet in the corresponding token bucket according to the processing of the previous data packet of the same length; The token bucket executes token issuance for the allocated data group, determines the transmission rate according to the arrival rate and the waiting queue probability of the data packet, and calculates the optimal token bucket capacity and token sending rate for minimizing the data processing time, and then performs queue shaping on the multiple data packets to be processed by the token bucket; Detect burst traffic events for the arrival rate of each token bucket, and dynamically adjust the token issuance rate and capacity parameters of the corresponding token bucket when a single-channel or group-level burst traffic event is detected, to realize adaptive reduction and collaborative flow control of the burst traffic.

2. The method of claim 1, wherein, Solving the optimal token bucket capacity and token sending rate for queue shaping comprises the following steps: Statistically analyze the overall characteristics of the data group to obtain an index reflecting the transmission law; Model the processing capacity of the token bucket based on the index to indicate its operating state under different loads; Analyze the queuing relationship of the data stream according to the operating state to determine the traffic distribution trend of the token bucket; Evaluate the effectiveness of data transmission in combination with the traffic distribution trend to reflect the dynamic processing capacity of the token bucket; Derive overall time delay characteristic parameters based on the dynamic processing capacity as a basis for performance optimization; Through joint optimization and adjustment of the token allocation strategy and bucket capacity parameters, transmission time delay minimization and optimal configuration are realized.

3. The method of claim 2, wherein, The joint optimization and adjustment is a global search under load balancing constraints to determine the optimal combination of data processing time in the capacity and rate parameter space.

4. The method of claim 2, wherein, The joint optimization and adjustment is a closed-loop adjustment based on the load feedback of the token bucket to dynamically correct the token capacity and issuance rate according to the real-time congestion state, realizing self-steady-state optimization of the system.

5. The method of claim 1, wherein, Detecting burst traffic events and adaptively adjusting token bucket parameters comprises the following steps: Establish a sliding time window for each token bucket, and observe and statistically analyze the arrival rate and issuance rate of the token bucket within the window to identify instantaneous fluctuation characteristics; Calculate a burst intensity index based on the observation results, and determine whether there is a local or group-level burst traffic event by analyzing the correlation between adjacent token buckets; When a single-channel burst traffic is detected, dynamically adjust the rate and capacity of the corresponding token bucket according to the burst intensity to realize adaptive flow control. When multiple token buckets are detected to have a coordinated burst, the rates and capacities of the token buckets in the group are jointly adjusted according to group burst correlation to balance local traffic load; The parameters are iteratively updated between sliding time windows to enable adaptive update of burst traffic identification and adjustment in continuous time domain.

6. The method of claim 5, wherein, The joint adjustment of multiple token buckets in a coordinated burst is balanced by presetting multiple coordination coefficients to balance the rate reduction, resource compensation and capacity synchronization between the token buckets, so as to realize standardized feedback regulation and continuous self-optimization across sliding time windows.

7. The method of claim 5, wherein, The joint adjustment of the rates and capacities of the token buckets in the group when multiple token buckets have a coordinated burst comprises: Mapping the sending rates of the token buckets to phases and constructing a multi-node state vector for representing the rate-capacity consistency relationship across nodes; Establishing a coordination benefit function and introducing a coupling weight between nodes to comprehensively evaluate the single-node benefit and group coordination benefit; Based on the rate-phase coupling relationship, a continuous-time coordinated dynamic evolution model is constructed to describe the linkage process of rate adjustment and phase synchronization; A global stability criterion is defined, and the coordinated equilibrium point is obtained based on the criterion, so that the node rate and phase converge under the potential energy descent constraint; In the sliding time window, the dynamic coupling feedback self-adjusts the coupling weight, so that the system maintains phase alignment and rate consistency under burst and disturbance, and updates and outputs the parameter set.

8. A gateway data transmission control system based on an improved token bucket method, characterized in that, The system is used to execute the method of claim 1, comprising: A token management module for generating a specified number of tokens at a specified frequency into the token bucket, and discarding the newly added tokens when the token bucket capacity reaches the upper limit, to maintain the dynamic balance of token generation rate and capacity; A request processing module for receiving client access requests and determining whether they are exempt from rate limiting requests, if they are exempt from rate limiting requests, directly releasing them, if they are not exempt from rate limiting requests, calling the token management module to try to obtain tokens, and rejecting the request when the tokens are insufficient; A data processing module for dividing the data to be transmitted into multiple independent data groups, and calculating the corresponding departure time according to the arrival time and length information of the data packets, to realize independent queuing and transmission of the data groups; A parameter optimization module for determining the transmission rate according to the arrival rate and queuing probability of the data packets, and obtaining the optimal token bucket capacity and token sending rate for minimizing the data processing time; A flow regulation module for monitoring the arrival rate change of each token bucket, detecting burst traffic events, and dynamically adjusting the token issuance rate and capacity parameters of the token bucket when detecting single-channel or group-level burst.

9. The gateway data transmission control system based on the improved token bucket method according to claim 8, characterized in that, It also includes a coordination control module for jointly adjusting the rates and capacities of the token buckets in the group when multiple token buckets have a coordinated burst, and realizing global convergence and synchronization of token sending rates and bucket capacities between multiple token buckets through rate-phase mapping and parameter feedback.

Images