A method and system for detecting and limiting abnormal traffic of a cellular internet of things core network

Abstract

This application relates to the field of communication network technology, and in particular to a method and system for abnormal traffic detection and rate limiting in a cellular Internet of Things (IoT) core network. The method includes: acquiring traffic rate data in the uplink and downlink directions of a target interface, and smoothing them to obtain a smoothed traffic rate; performing independent surge detection on the smoothed traffic rate to identify a traffic surge event; acquiring the original sampled packets corresponding to the traffic surge event and determining the traffic object and traffic contribution corresponding to each traffic feature dimension; determining the cumulative traffic contribution based on the corresponding traffic contribution for each traffic feature dimension, and determining a rate limiting strategy based on the cumulative traffic contribution and a preset contribution threshold, and issuing a rate limiting command to the forwarding plane for rate limiting; continuously monitoring the traffic rate in the direction corresponding to the traffic surge event after rate limiting, and gradually releasing the rate limiting according to a preset release step size after the traffic rate meets the preset exit conditions and is confirmed by multiple consecutive sampling windows.

Description

Technical Field

[0001] This application relates to the field of communication network technology, and in particular to a method and system for abnormal traffic detection and rate limiting in a cellular Internet of Things core network. Background Technology

[0002] In numerous fields such as mobile communications and cellular IoT, the core network, as a crucial network infrastructure connecting terminal devices, wireless access networks, and service platforms, needs to handle a large volume of uplink and downlink data traffic generated by these devices. With the increasing number of cellular IoT terminals and the diversification of terminal service types, the traffic carried by the core network interface typically exhibits characteristics of suddenness, dynamism, and multi-source nature. For example, in situations involving concentrated IoT terminal online deployments, concentrated service access, continuous data transmission from abnormal terminals, or concentrated access to the same service platform by terminals, the traffic on the core network interface may experience a significant surge within a short period. Therefore, it is usually necessary to continuously monitor the traffic rate of the core network interface and promptly limit the rate when an abnormal traffic surge is detected to prevent abnormal traffic from further consuming network resources and affecting other normal services.

[0003] Current methods for handling abnormal traffic in cellular IoT core networks primarily rely on comparing interface traffic rates with preset thresholds to detect anomalies, and then limiting the overall interface traffic rate once the detected traffic exceeds the threshold. These solutions typically directly apply threshold judgments to real-time collected traffic rates; when the traffic rate at a given sampling moment exceeds the preset threshold, anomaly handling is triggered. For example, patent application CN106790050A provides an abnormal traffic detection method and system, patent application CN111935145A provides a hardware-independent method and system for implementing network traffic security analysis, and patent application CN117336068A provides a data packet processing method, apparatus, and device based on gateway devices. However, core network interface traffic itself exhibits strong instantaneous fluctuations. Instantaneous traffic spikes within a single sampling window may cause the traffic rate to briefly exceed the threshold, leading the system to misinterpret normal instantaneous traffic fluctuations as abnormal traffic surges. Furthermore, the patterns of uplink and downlink traffic changes are not entirely identical. Using a uniform traffic baseline and detection conditions makes it difficult to accurately reflect the actual traffic status in different directions, thus easily leading to false alarms or missed alarms. Moreover, existing abnormal traffic handling solutions for cellular IoT core networks struggle to simultaneously ensure accurate detection of abnormal traffic surges and effective location of abnormal traffic sources, and after rate limiting is implemented, it is difficult to dynamically adjust the rate limiting strategy based on traffic changes. Summary of the Invention

[0004] (a) Technical problems to be solved In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides a method and system for abnormal traffic detection and rate limiting in cellular Internet of Things core networks, which solves the technical problems in the prior art of being unable to accurately identify abnormal traffic surges, being unable to accurately determine the source of abnormal traffic, and being unable to adapt to traffic changes after rate limiting.

[0005] (II) Technical Solution To achieve the above objectives, the main technical solutions adopted in this application include: Firstly, this application provides a method for abnormal traffic detection and rate limiting in a cellular IoT core network, including: The uplink and downlink traffic rate data of the target interface are obtained respectively, and the traffic rate data is smoothed to obtain the smoothed traffic rate in the corresponding direction. Based on the historical flow baselines and surge entry thresholds corresponding to the uplink and downlink directions, independent surge detection is performed on the smooth flow rate in the corresponding directions, and a flow surge event is determined when the surge condition is met in multiple consecutive sampling windows in the corresponding direction. Obtain the original sampled packets corresponding to the traffic surge event, and analyze multiple traffic feature dimensions in parallel based on the original sampled packets to determine the traffic object and traffic contribution corresponding to each traffic feature dimension; For each of the traffic characteristic dimensions, the cumulative traffic contribution is determined according to the corresponding traffic contribution, and based on the comparison result of the cumulative traffic contribution and the preset contribution threshold, the rate limiting strategy corresponding to the traffic surge event is determined, and the rate limiting command corresponding to the rate limiting strategy is sent to the forwarding plane of the target interface for rate limiting. The flow rate in the direction corresponding to the flow surge event after the rate limit is continuously monitored, and the rate limit is gradually lifted according to the preset release step size after the flow rate meets the preset exit condition and is confirmed by multiple consecutive sampling windows.

[0006] Optionally, the uplink and downlink traffic rate data of the target interface are acquired separately, and the traffic rate data is smoothed to obtain the smoothed traffic rate for the corresponding direction, specifically including: The original flow rates of the target interface in the uplink and downlink directions in the current sampling window are obtained respectively. Based on the original flow rate of the current sampling window and the smoothed flow rate of the corresponding direction in the previous sampling window, the original flow rate of the current sampling window is processed by exponential weighted moving average according to a preset smoothing coefficient to obtain the smoothed flow rate of the corresponding direction in the current sampling window. The smooth flow rate is determined according to the following formula: ; Where Rs(t) is the smoothed flow rate in the direction corresponding to the t-th sampling window, and R(t) is the original flow rate in the direction corresponding to the t-th sampling window. Let α be the smoothed flow rate in the direction corresponding to the (t-1)th sampling window, where α is a preset smoothing coefficient and 0 < α < 1.

[0007] Optionally, based on the historical traffic baselines and surge entry thresholds corresponding to the uplink and downlink directions, independent surge detection is performed on the smoothed traffic rate in the corresponding directions. A traffic surge event is determined when the surge condition is met for multiple consecutive sampling windows in the corresponding direction. Specifically, this includes: The smooth flow rate corresponding to the uplink direction is compared with the historical flow baseline and the sudden entry threshold corresponding to the uplink direction, and the smooth flow rate corresponding to the downlink direction is compared with the historical flow baseline and the sudden entry threshold corresponding to the downlink direction, respectively. If the smooth flow rate corresponding to the upward direction satisfies the upward surge condition in multiple consecutive sampling windows, the flow surge event in the upward direction is determined. If the smooth flow rate corresponding to the downlink direction satisfies the downlink surge condition for multiple consecutive sampling windows, the downlink flow surge event is determined. The surge conditions include uplink surge conditions and downlink surge conditions; the uplink surge condition is that the smooth flow rate corresponding to the uplink direction is greater than or equal to the product of the historical flow baseline corresponding to the uplink direction and the surge entry threshold corresponding to the uplink direction; the downlink surge condition is that the smooth flow rate corresponding to the downlink direction is greater than or equal to the product of the historical flow baseline corresponding to the downlink direction and the surge entry threshold corresponding to the downlink direction.

[0008] Optionally, the original sampled packets corresponding to the traffic surge event are obtained, and multiple traffic feature dimensions are analyzed in parallel based on the original sampled packets to determine the traffic object and traffic contribution corresponding to each traffic feature dimension, specifically including: Obtain the original sampled packets within the sampling time window corresponding to the traffic surge event, and perform parallel statistics on multiple traffic feature dimensions based on the same batch of original sampled packets to determine the traffic object corresponding to each traffic feature dimension; Obtain the current traffic and historical traffic baseline corresponding to each traffic object, and determine the traffic increment corresponding to each traffic object based on the difference between the current traffic and the historical traffic baseline. Based on the traffic increment corresponding to each of the traffic objects, the traffic contribution of each of the traffic objects is determined.

[0009] Optionally, for each of the traffic characteristic dimensions, a cumulative traffic contribution is determined based on the corresponding traffic contribution, and based on the comparison result of the cumulative traffic contribution and a preset contribution threshold, a rate limiting strategy corresponding to the traffic surge event is determined, and the rate limiting command corresponding to the rate limiting strategy is sent to the forwarding plane of the target interface for rate limiting, specifically including: For each of the aforementioned traffic feature dimensions, the traffic objects corresponding to the traffic feature dimensions are sorted according to their corresponding traffic contribution. Then, traffic objects are selected sequentially from the sorted traffic objects, and the sum of the traffic contribution corresponding to the selected traffic objects is calculated to obtain the cumulative traffic contribution. Determine whether there is a situation where the cumulative traffic contribution corresponding to the traffic feature dimension reaches a preset contribution threshold; In the absence of a traffic feature dimension in which the cumulative traffic contribution reaches the preset contribution threshold, the rate limiting strategy is determined to be an overall interface rate limiting strategy. The overall interface rate limiting strategy is to limit the overall traffic in the direction corresponding to the target interface to within a preset multiple of the historical traffic baseline in the direction corresponding to the traffic surge event. If there is a traffic feature dimension where the cumulative traffic contribution reaches the preset contribution threshold, the rate limiting strategy is determined to be an interface object rate limiting strategy. The interface object rate limiting strategy is to limit the rate limiting object set according to the corresponding rate limiting level and the minimum bandwidth. The rate limiting object set is determined based on the traffic objects that have reached the preset contribution threshold, and the rate limiting level and the minimum bandwidth are predetermined based on the traffic surge event. A corresponding rate limiting instruction is generated based on the overall rate limiting policy of the interface or the rate limiting policy of the interface object, and the rate limiting instruction is sent to the forwarding plane of the target interface so that the forwarding plane of the target interface performs rate limiting according to the rate limiting instruction.

[0010] Optionally, the set of rate-limiting objects is determined based on the method by which traffic objects reach the preset contribution threshold, specifically including: When the cumulative traffic contribution corresponding to at least one of the traffic feature dimensions reaches the preset contribution threshold, the minimum number of traffic objects required to make the cumulative traffic contribution reach the preset contribution threshold for each of the traffic feature dimensions is determined, and the traffic feature dimension with the smallest required number of traffic objects is determined as the target traffic feature dimension. The traffic objects that make the cumulative traffic contribution reach the preset contribution threshold in the target traffic feature dimension are determined as the initial rate-limiting object set; when there are multiple traffic feature dimensions with the same minimum number of traffic objects, the traffic feature dimension with the higher cumulative traffic contribution is determined as the target traffic feature dimension. The initial speed limit object set and the target traffic feature dimension determined this time are compared with the initial speed limit object set and the target traffic feature dimension determined in the previous time, respectively. If the initial speed limit object set determined this time is inconsistent with the initial speed limit object set determined in the previous time, or if the target flow feature dimension determined this time is inconsistent with the target flow feature dimension determined in the previous time, the initial speed limit object set and the target flow feature dimension shall be re-determined in the next sampling period. If the initial rate-limiting object set determined this time is consistent with the initial rate-limiting object set determined previously, and the target traffic feature dimension determined this time is consistent with the target traffic feature dimension determined previously, then the initial rate-limiting object set determined this time is determined as the rate-limiting object set, and the rate-limiting instruction is generated according to the rate-limiting object set and sent to the forwarding plane of the target interface.

[0011] Optionally, the flow rate in the direction corresponding to the flow surge event after the rate limit is applied is continuously monitored, and after the flow rate meets the preset exit condition and is confirmed by multiple consecutive sampling windows, the rate limit is gradually lifted according to a preset release step size, specifically including: Continuously acquire the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and compare the flow rate with the historical flow baseline and preset exit threshold in the direction corresponding to the flow surge event; If the flow rate in the direction corresponding to the flow surge event is less than or equal to the product of the historical flow baseline in the direction corresponding to the flow surge event and the preset exit threshold, it is determined that the direction corresponding to the flow surge event meets the exit condition. If the exit condition is met in multiple consecutive sampling windows in the direction corresponding to the traffic surge event, it is determined that the rate limit exit condition is met, and the current rate limit is reduced according to the preset release step size to gradually remove the rate limit on the set of rate limit objects. Each time the current rate limit is reduced according to the preset release step size, the flow rate in the direction corresponding to the flow surge event continues to be monitored, and if the flow rate meets the exit condition, the current rate limit is reduced according to the preset release step size until the rate limit on the set of rate-limited objects is lifted.

[0012] Optionally, the method further includes continuously monitoring the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and the method also includes: The flow rate in the direction corresponding to the flow surge event after the speed limit is compared with the historical flow baseline in the direction corresponding to the flow surge event and the surge entry threshold; If the flow rate in the direction corresponding to the flow surge event after the rate limit is set still meets the surge condition for multiple consecutive sampling windows, it is determined that the rate limit upgrade condition is met, and the rate limit strategy of the interface object is adjusted to expand the set of rate limit objects or increase the rate limit level. A rate-limiting instruction is generated based on the adjusted rate-limiting policy of the interface object, and the rate-limiting instruction is sent to the forwarding plane of the target interface for rate limiting.

[0013] Optionally, if the rate limiting upgrade conditions are met, the rate limiting strategy of the interface object is adjusted, specifically including: Reacquire the original sampled packets within the sampling time window corresponding to the rate limit upgrade condition, and perform parallel statistics on multiple traffic feature dimensions based on the reacquired original sampled packets to redetermine the traffic object and traffic contribution corresponding to each traffic feature dimension. Based on the traffic objects and traffic contribution corresponding to each of the redefined traffic feature dimensions, the initial set of rate-limiting objects and the target traffic feature dimensions are redefined. If there is a traffic object in the newly determined initial set of speed limit objects that is not included in the currently effective set of speed limit objects, the traffic object is added to the currently effective set of speed limit objects to expand the set of speed limit objects. If the newly determined initial set of speed-limited objects is consistent with the currently effective set of speed-limited objects, the speed limit level is increased, and the speed limit of the set of speed-limited objects is applied according to the increased speed limit level and the minimum bandwidth.

[0014] On the other hand, this application also provides a cellular IoT core network abnormal traffic detection and rate limiting system, including: at least one processor; and at least one memory communicatively connected to the processor, wherein the memory stores program instructions executable by the processor, and the processor can execute the cellular IoT core network abnormal traffic detection and rate limiting method as described above by calling the program instructions.

[0015] (III) Beneficial Effects The cellular IoT core network abnormal traffic detection and rate limiting method and system of this application acquires and smooths the uplink and downlink traffic rate data of the target interface, combines them with the corresponding historical traffic baselines to detect abnormal traffic surges, and confirms abnormal traffic events by satisfying threshold conditions through multiple consecutive sampling windows. This reduces the impact of instantaneous traffic fluctuations on abnormal detection results and improves the accuracy of abnormal traffic surge detection. Furthermore, after confirming the abnormal traffic event, multiple traffic feature dimensions are analyzed in parallel based on the corresponding original sampling data to determine the contribution of different traffic objects and determine the rate limiting object and rate limiting strategy accordingly. This effectively locates the source of abnormal traffic and reduces unnecessary overall rate limiting. At the same time, the status of abnormal traffic events is continuously monitored after rate limiting is executed, and rate limiting is gradually lifted according to a preset release step size when the exit conditions are met. This allows the rate limiting process to adapt to changes in abnormal traffic, reducing the impact of rate limiting on normal service traffic, thereby improving the accuracy, reliability, and flexibility of the abnormal traffic detection and rate limiting process in the cellular IoT core network. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an abnormal traffic detection and rate limiting method for a cellular Internet of Things core network according to an embodiment of this application; Figure 2 This is a flowchart illustrating the process of determining a rate-limiting policy corresponding to a traffic surge event according to one embodiment of this application; Figure 3 This is a flowchart of the process for determining a set of speed-limiting objects according to one embodiment of this application. Detailed Implementation

[0017] To better explain and facilitate understanding of this application, the following detailed description of the application is provided in conjunction with the accompanying drawings and specific embodiments.

[0018] In related technologies, abnormal traffic detection and rate limiting in cellular IoT core networks can be mainly categorized into three types: The first type is anomaly detection schemes based on fixed thresholds or single traffic indicators. These schemes typically collect the traffic rate of the target interface in the core network in real time and compare the current traffic rate with a pre-set fixed threshold. When the traffic rate exceeds the fixed threshold, it is determined that there is abnormal traffic on the target interface, and further rate limiting is triggered. However, cellular IoT core networks aggregate a large number of IoT terminals, and their service traffic is easily affected by strong synchronous behaviors such as concentrated terminal online events, periodic reporting, and concentrated access. This can lead to sudden increases in interface traffic far exceeding normal levels within a short period, and the traffic change patterns in the uplink and downlink directions are usually different. If a fixed threshold or a method that does not distinguish between traffic directions is used for anomaly detection, it is difficult to adapt to the historical traffic characteristics of different directions. At the same time, instantaneous traffic spikes in a single sampling window may also trigger anomaly detection, easily mistaking normal short-term fluctuations for abnormal surges, causing false alarms and unnecessary rate limiting.

[0019] The second type of solution is based on a single dimension or a sequential drill-down approach to pinpoint the root cause of abnormal traffic. This approach typically detects a surge in interface traffic and performs statistical analysis based on a single traffic characteristic dimension, such as protocol type, application type, port, source IP, or destination IP. It then identifies the abnormal traffic object based on the statistical results, or drills down sequentially according to pre-defined levels such as protocol, application, port, and IP to gradually narrow down the abnormal traffic range. However, the causes of traffic surges in cellular IoT scenarios are highly complex. Abnormal traffic may manifest as a single protocol spreading to a large number of traffic objects, or multiple protocols and ports pointing to a small number of destination IPs. A single dimension is insufficient to fully reflect the formation of abnormal traffic, while a fixed, progressive drill-down approach may disperse the traffic contribution of the true root cause in earlier dimensions, thus overlooking the actual dominant traffic object. Furthermore, even when obtaining statistical results from multiple dimensions, existing solutions typically lack mechanisms for correlation analysis of statistical results from different dimensions. This makes it difficult to automatically determine which traffic objects should be restricted, easily degenerating into a process of simply providing abnormal traffic statistics and requiring manual determination of rate-limiting objects, resulting in a disconnect between abnormal traffic detection and actual handling.

[0020] The third type is a solution that directly applies fixed rate limiting or lifts rate limiting all at once upon detecting abnormal traffic. This solution typically applies a fixed percentage rate limit to the entire interface or pre-specified traffic objects after confirming abnormal interface traffic, and lifts the rate limit once the traffic drops to a preset level. While this approach can suppress the impact of sudden traffic surges on the core network forwarding plane to some extent, it lacks a dynamic decision-making mechanism that matches the rate limiting objects and the degree of rate limiting with the contribution of abnormal traffic and the severity of the surge. When abnormal traffic is contributed by only a small number of traffic objects, rate limiting the entire interface can easily affect normal services, while when abnormal traffic is highly dispersed, limiting only a small number of objects is insufficient to effectively suppress the surge in traffic. Furthermore, existing rate limiting solutions often lack a guaranteed bandwidth and a mechanism for confirming multiple consecutive sampling windows. When the traffic rate is near the rate limiting entry or exit threshold, it is prone to repeated triggering and lifting of rate limiting due to normal traffic fluctuations, resulting in inconsistent handling. Moreover, immediately lifting the rate limit completely after the abnormal traffic initially decreases may cause the still-present abnormal traffic to surge onto the interface again, thus reducing the stability of traffic handling.

[0021] To address this, this application provides a method and system for abnormal traffic detection and rate limiting in a cellular IoT core network. By acquiring and smoothing the uplink and downlink traffic rate data of the target interface, and independently detecting traffic surges in both directions based on the historical traffic baselines and surge entry thresholds corresponding to the uplink and downlink directions respectively, a traffic surge event is determined only when the surge condition is met in multiple consecutive sampling windows. This enables the identification of uplink and downlink anomaly sources for strong synchronization burst scenarios in cellular IoT, reducing misjudgments caused by instantaneous traffic fluctuations.

[0022] Furthermore, after identifying a traffic surge event, this application obtains the original sampled packets corresponding to the traffic surge event and analyzes multiple traffic feature dimensions such as protocol, application, port, source IP, and destination IP in parallel based on the same batch of original sampled packets. It then determines the traffic object and traffic contribution corresponding to each traffic feature dimension, avoiding the omission of the true root cause due to using a single dimension or progressive drill-down method. Based on this, it performs correlation analysis based on the traffic contribution corresponding to different traffic feature dimensions, and determines the minimum sufficient rate-limiting set that can reach the preset contribution level and requires a small number of rate-limiting objects by comparing the cumulative traffic contribution with a preset contribution threshold. This automatically identifies the dominant traffic object from the multi-dimensional analysis results, combining the location of the abnormal traffic root cause with the selection of actual rate-limiting objects, improving the accuracy and relevance of rate-limiting decisions.

[0023] Furthermore, this application determines the corresponding rate-limiting strategy based on the identified traffic objects and their cumulative traffic contribution, and issues the rate-limiting command to the forwarding plane of the target interface for rate limiting, thus forming an automated closed loop of detection, root cause analysis, rate-limiting decision-making, and rate-limiting execution. Simultaneously, by setting a minimum bandwidth guarantee for rate-limited objects, it avoids completely blocking abnormal traffic objects, thereby suppressing sudden traffic surges and reducing the impact on the continuity of related services. In addition, this application continuously monitors the traffic rate in the corresponding direction after rate limiting, and further expands the rate-limited objects or increases the rate-limiting level if the traffic still meets the surge conditions, thereby dynamically adjusting the handling intensity based on the actual rate-limiting effect.

[0024] Finally, this application does not immediately and completely release the rate limit after the first decrease in traffic. Instead, it gradually releases the rate limit according to a preset release step size after the traffic rate meets the preset exit conditions and is confirmed by multiple consecutive sampling windows. This gives the rate limit level the characteristic of fast entry and slow exit, reducing decision jitter caused by traffic fluctuations near the entry and exit thresholds, and avoiding premature rate limit release before abnormal traffic has completely subsided. Therefore, this application can form a complete closed loop from bidirectional independent surge detection, multi-dimensional parallel root cause localization, minimum sufficient rate limit set decision, graded rate limiting to feedback adjustment and gradient release. While improving the accuracy of abnormal traffic detection in the cellular IoT core network, it achieves precise, stable, and gradual handling of abnormal traffic, reducing the impact of sudden traffic on the core network forwarding plane, and balancing the effect of abnormal traffic suppression with the continuity of normal services.

[0025] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application can be understood more clearly and thoroughly, and that the scope of this application can be fully conveyed to those skilled in the art.

[0026] Figure 1 This is a flowchart illustrating a method for abnormal traffic detection and rate limiting in a cellular IoT core network according to an embodiment of this application. Figure 1 As shown, the abnormal traffic detection and rate limiting method for the cellular IoT core network includes: S1. Obtain the uplink and downlink traffic rate data of the target interface respectively, and smooth the traffic rate data to obtain the smoothed traffic rate in the corresponding direction. Specifically, the smooth flow rate obtained in the corresponding direction in this embodiment includes: The original flow rates of the target interface in the uplink and downlink directions in the current sampling window are obtained respectively. Based on the original flow rate of the current sampling window and the smoothed flow rate of the corresponding direction in the previous sampling window, the original flow rate of the current sampling window is processed by exponential weighted moving average according to a preset smoothing coefficient to obtain the smoothed flow rate of the corresponding direction in the current sampling window. The smooth flow rate is determined according to the following formula: ; Where Rs(t) is the smoothed flow rate in the direction corresponding to the t-th sampling window, and R(t) is the original flow rate in the direction corresponding to the t-th sampling window. Let α be the smoothed flow rate in the direction corresponding to the (t-1)th sampling window, and let α be a preset smoothing coefficient, where 0 < α < 1. In a specific embodiment of this application, α can be set to 0.3. In this case, the weight of the original flow rate of the current sampling window in the smoothing calculation is 0.3, while the weight of the smoothed flow rate of the previous sampling window is 0.7. This allows the smoothing result to respond to continuous flow changes while reducing the impact of instantaneous flow spikes in a single sampling window.

[0027] In a specific application scenario of this application, the abnormal traffic detection and rate limiting method for the cellular IoT core network can be applied to cellular IoT scenarios such as smart parks, smart water management, smart meters, and environmental monitoring. For example, in a smart water management scenario, a large number of water meters, pressure sensors, flow sensors, and valve controllers installed in different areas are connected to the core network via cellular IoT and transmit data to the service platform through the Packet Data Network Gateway (PGW) or User Plane Function (UPF) in the core network. When a large number of IoT terminals simultaneously report data according to the same timing period at a certain moment, a significant traffic surge may occur at the target interface of the core network. For example, under normal circumstances, only a small number of terminals report data per second, but at a certain hour, a large number of terminals simultaneously send water meter readings to the cloud service platform, resulting in a much higher uplink traffic than normal at the target interface in a very short period of time. At the same time, when the service platform sends control commands, parameter update commands, or time synchronization information to a large number of IoT terminals, a significant downlink traffic surge may also occur. Therefore, this application processes the traffic of the target interface separately in the uplink and downlink directions so that abnormal surge detection can be performed separately for traffic changes in different directions.

[0028] Specifically, the traffic acquisition module can sample the target interface according to a pre-set sampling period, using the time interval between two adjacent sampling moments as a sampling window. For example, the sampling window can be set to 1 second, meaning that every second, the actual data volume transmitted by the target interface in the uplink and downlink directions is counted, and the original traffic rate of the current sampling window is calculated based on the data volume and the sampling window duration. It should be noted that this application does not require different sampling periods for the uplink and downlink directions. In one embodiment, the uplink and downlink directions can use the same sampling window for synchronous sampling, so that the uplink and downlink traffic rates obtained at the same time can be used for subsequent anomaly detection in the corresponding directions.

[0029] For example, suppose a cellular IoT core network has a target interface rated bandwidth of 1Gbps and is currently in normal operation. The traffic acquisition module collects uplink and downlink traffic in 1-second sampling windows. For a certain continuous sampling period, the raw uplink traffic rates in the current sampling window are 100Mbps, 105Mbps, 110Mbps, 300Mbps, and 120Mbps, respectively, while the raw downlink traffic rates are 200Mbps, 205Mbps, 210Mbps, 215Mbps, and 500Mbps, respectively. It can be seen that in the fourth sampling window, the uplink traffic rate suddenly reaches 300Mbps, and then quickly drops to 120Mbps in the fifth sampling window; similarly, the downlink traffic rate suddenly reaches 500Mbps in the fifth sampling window. This sudden and significant change could be due to a genuine surge in abnormal traffic, or it could be a short-term traffic spike caused by normal business activities such as simultaneous reporting from a large number of IoT terminals or batch distribution from the service platform. Therefore, directly comparing the raw traffic rate with subsequent surge thresholds is easily affected by the instantaneous fluctuations within a single sampling window.

[0030] To mitigate the impact of instantaneous flow fluctuations on subsequent surge detection, this application applies an exponentially weighted moving average (EWMA) to the raw flow rate obtained in the current sampling window. Specifically, for the uplink direction of the target interface, after obtaining the raw flow rate of the current sampling window, the raw flow rate of the current sampling window is weighted by the smoothed flow rate corresponding to the uplink direction of the previous sampling window using a preset smoothing coefficient to obtain the uplink smoothed flow rate of the current sampling window. For the downlink direction, the same method is used, based on the downlink raw flow rate of the current sampling window and the downlink smoothed flow rate corresponding to the previous sampling window, to obtain the downlink smoothed flow rate of the current sampling window. In other words, the uplink direction maintains an independent smoothing process, and the downlink direction also maintains an independent smoothing process; the two are not used interchangeably.

[0031] Taking the uplink direction in the smart water management scenario as an example, assuming the original uplink flow rate of the first sampling window is 100 Mbps, then at the initial moment, the original flow rate of the first sampling window can be directly used as its smoothed flow rate, i.e., Rs(1) = 100 Mbps. When the original uplink flow rate of the second sampling window is 105 Mbps, with α = 0.3, the smoothed flow rate of the current sampling window is 0.3 × 105 + 0.7 × 100 = 101.5 Mbps. When the original uplink flow rate of the third sampling window is 110 Mbps, its smoothed flow rate is 0.3 × 110 + 0.7 × 101.5 = 104.05 Mbps. At this time, although the original uplink flow rate has gradually increased from 100 Mbps to 110 Mbps, the smoothed flow rate only increases from 100 Mbps to 104.05 Mbps, indicating that the smoothing process can reflect the flow changes more stably.

[0032] Furthermore, assuming that the original uplink traffic rate suddenly increases to 300 Mbps in the fourth sampling window due to a large number of IoT terminals simultaneously reporting data, the smoothed uplink traffic rate for the fourth sampling window, calculated using the above formula, is 0.3 × 300 + 0.7 × 104.05 = 162.835 Mbps. It can be seen that although the original traffic rate suddenly increases from 110 Mbps to 300 Mbps, after smoothing, the smoothed traffic rate does not jump directly to 300 Mbps, but rather changes to approximately 162.84 Mbps. Subsequently, assuming that the original uplink traffic rate in the fifth sampling window decreases back to 120 Mbps, the smoothed uplink traffic rate for the fifth sampling window is 0.3 × 120 + 0.7 × 162.835 = 149.9845 Mbps. Therefore, when a significant flow spike occurs only once in a sampling window, the spike will not be fully transmitted to the smoothed result. Instead, it will be reflected gradually through exponential weighting, thus avoiding the immediate and drastic changes in subsequent abnormal surge detections due to a single instantaneous flow change.

[0033] Similarly, the smoothing process described above can be performed independently for the downlink direction. For example, suppose the smoothed downlink traffic rate in the previous sampling window was 210 Mbps, and in the current sampling window, due to the service platform centrally sending data to a large number of IoT terminals, the original downlink traffic rate in the current sampling window suddenly reaches 500 Mbps. With α=0.3, the smoothed downlink traffic rate in the current sampling window is 0.3×500+0.7×210=297 Mbps. Therefore, even if the original downlink traffic suddenly reaches 500 Mbps within a single sampling window, the smoothed downlink traffic rate will not directly use 500 Mbps as the basis for subsequent anomaly detection, but will instead combine the previous downlink traffic changes to obtain a smoothed result of 297 Mbps.

[0034] It is important to note that the smoothing process described in this application does not involve merging uplink and downlink traffic before performing a unified smoothing. Instead, it maintains corresponding historical smoothing results separately for the uplink and downlink directions. For example, smoothed traffic rates for the uplink and downlink directions can be maintained separately. The current smoothed value for the uplink direction is determined solely by the current original traffic rate for the uplink direction and the smoothed value of the previous sampling window for the uplink direction, and the current smoothed value for the downlink direction is determined solely by the current original traffic rate for the downlink direction and the smoothed value of the previous sampling window for the downlink direction. This avoids abnormal traffic changes in one direction from interfering with anomaly detection in the other direction, providing a stable data foundation for subsequent surge detection using the historical uplink and downlink traffic baselines respectively.

[0035] S2. Based on the historical traffic baselines and surge entry thresholds corresponding to the uplink and downlink directions respectively, perform independent surge detection on the smoothed traffic rate in the corresponding directions, and determine the traffic surge event when the surge condition is met in multiple consecutive sampling windows in the corresponding direction, specifically including: The smooth flow rate corresponding to the uplink direction is compared with the historical flow baseline and the sudden entry threshold corresponding to the uplink direction, and the smooth flow rate corresponding to the downlink direction is compared with the historical flow baseline and the sudden entry threshold corresponding to the downlink direction, respectively. The historical traffic baseline is used to characterize the historical normal traffic level of the target interface in the corresponding traffic direction. For example, the historical traffic baseline for the uplink direction and the historical traffic baseline for the downlink direction can be obtained by statistically analyzing the traffic rate data within multiple normal operating time windows of the target interface. The historical traffic baseline can be maintained as historical traffic data is updated, thus reflecting the normal traffic level of the target interface in the corresponding direction. It should be noted that the historical traffic baseline for the uplink direction and the historical traffic baseline for the downlink direction are maintained independently, and changes in traffic in the uplink direction will not directly change the historical traffic baseline for the downlink direction.

[0036] The surge entry threshold is used to characterize the level at which the current smooth flow rate reaches a point where a significant surge relative to the historical normal flow level in the corresponding direction can be considered. The surge entry threshold can be expressed as a multiple, i.e., by multiplying the historical flow baseline in the corresponding direction by the surge entry threshold, the entry threshold for judging a flow surge in that direction is obtained. For example, the surge entry threshold for the uplink direction can be set to 2.0, meaning that when the smooth flow rate in the uplink direction reaches twice the historical flow baseline in the uplink direction, the current sampling window is considered to meet the uplink surge condition; the surge entry threshold for the downlink direction can be set to 2.5, meaning that when the smooth flow rate in the downlink direction reaches 2.5 times the historical flow baseline in the downlink direction, the current sampling window is considered to meet the downlink surge condition. Different surge entry thresholds can be set for the uplink and downlink directions based on their respective historical flow fluctuation characteristics, rather than requiring the use of the same multiple.

[0037] If the smooth flow rate corresponding to the upward direction satisfies the upward surge condition in multiple consecutive sampling windows, the flow surge event in the upward direction is determined. In one embodiment of this application, since the causes and patterns of uplink and downlink traffic in the cellular IoT core network may differ—for example, in a smart water management scenario, when a large number of IoT terminals such as water meters and pressure sensors simultaneously report data to the service platform, the increase is mainly reflected in uplink traffic; while when the service platform simultaneously sends control commands, parameter update information, or time synchronization information to a large number of terminals, the increase is mainly reflected in downlink traffic—this application does not merge uplink and downlink traffic for unified judgment. Instead, it maintains historical traffic baselines and surge thresholds for the uplink and downlink directions separately, and determines whether a surge in traffic has occurred in each direction.

[0038] Specifically, if the smoothed flow rate in the uplink direction is greater than or equal to the product of the historical flow baseline in the uplink direction and the surge entry threshold in the uplink direction, then the current sampling window is considered to meet the uplink surge condition. In other words, the uplink surge condition can be understood as: the current smoothed uplink flow rate has reached a preset multiple of the historical normal uplink flow level.

[0039] For example, assuming the normal uplink traffic of a smart water management core network interface is approximately 100Mbps, and the historical traffic baseline for the uplink direction is determined to be 100Mbps based on historical data, and the uplink surge threshold is set to 2.0, then the corresponding uplink surge threshold is 200Mbps. When the smoothed uplink traffic rate obtained after step S1 for a certain sampling window is 180Mbps, since 180Mbps is less than 200Mbps, the current sampling window does not meet the uplink surge condition. When the smoothed uplink traffic rate of a subsequent sampling window reaches 220Mbps, since 220Mbps is greater than 200Mbps, the current sampling window meets the uplink surge condition. Therefore, it can be seen that this application does not determine whether the uplink traffic exceeds a fixed value directly related to the interface's rated bandwidth, but rather whether the current uplink traffic has reached a preset surge level relative to the interface's own historical normal level.

[0040] If the smooth flow rate corresponding to the downlink direction satisfies the downlink surge condition for multiple consecutive sampling windows, the downlink flow surge event is determined. For example, in the smart water management scenario described above, assuming the normal downlink traffic from the business platform to the IoT terminal is 200 Mbps, and the historical traffic baseline for the downlink direction is determined to be 200 Mbps based on historical data, and the downlink surge threshold is set to 2.5, then the corresponding downlink surge threshold is 500 Mbps. When the smoothed downlink traffic rate obtained in the current sampling window is 450 Mbps, since 450 Mbps is less than 500 Mbps, the current sampling window does not meet the downlink surge condition. When the smoothed downlink traffic rate in subsequent sampling windows reaches 520 Mbps, then the current sampling window is considered to meet the downlink surge condition. Therefore, even if the uplink direction remains at a normal level at the same time, the surge judgment in the uplink direction will not be affected by changes in the downlink traffic.

[0041] The surge conditions include uplink surge conditions and downlink surge conditions; the uplink surge condition is that the smooth flow rate corresponding to the uplink direction is greater than or equal to the product of the historical flow baseline corresponding to the uplink direction and the surge entry threshold corresponding to the uplink direction; the downlink surge condition is that the smooth flow rate corresponding to the downlink direction is greater than or equal to the product of the historical flow baseline corresponding to the downlink direction and the surge entry threshold corresponding to the downlink direction.

[0042] Furthermore, to avoid instantaneous flow spikes in a single sampling window being directly identified as flow surge events, this application does not immediately determine a flow surge event when the surge condition is first met in a sampling window. Instead, it establishes a confirmation mechanism across multiple consecutive sampling windows. Specifically, a flow surge event in that direction is only determined if the smooth flow rate in that direction meets the surge condition in multiple consecutive sampling windows. If any sampling window fails to meet the surge condition in that direction during the continuous confirmation process, the flow surge event in that direction can be determined not to have occurred, and subsequent flow acquisition and detection can continue.

[0043] For example, assuming the historical upstream traffic baseline is 100 Mbps and the upstream surge threshold is 2.0, the upstream surge threshold is 200 Mbps, and the number of consecutive confirmation windows is set to 3. Within a certain time period, the smoothed traffic rates obtained in five consecutive upstream sampling windows are 220 Mbps, 230 Mbps, 250 Mbps, 180 Mbps, and 240 Mbps, respectively. Since the smoothed traffic rates in the first three sampling windows are all greater than 200 Mbps, the upstream surge condition is met for all three consecutive sampling windows, and an upstream traffic surge event can be confirmed. Although the fourth sampling window drops to 180 Mbps, the traffic surge event has already been confirmed, and the subsequent process of acquiring the original sampled packets and analyzing multi-dimensional traffic characteristics can proceed.

[0044] For example, suppose the number of consecutive confirmation windows is also 3, and the smoothed traffic rates of the five consecutive uplink sampling windows within a certain time period are 220Mbps, 230Mbps, 180Mbps, 250Mbps, and 260Mbps, respectively. Although the smoothed traffic rates of the 1st, 2nd, 4th, and 5th sampling windows all exceed 200Mbps, the 3rd sampling window drops to 180Mbps, which does not meet the uplink surge condition. Therefore, there is no situation where all three consecutive sampling windows meet the uplink surge condition. In this case, we cannot determine that an uplink traffic surge event has occurred simply because there are multiple instances exceeding the threshold in the above five sampling windows. Instead, we continue to collect traffic data and conduct subsequent detection. This confirmation method using multiple consecutive sampling windows can avoid misjudging single-point or short-term traffic peaks caused by factors such as concentrated terminal online arrivals, short-term service requests, or instantaneous network jitter as traffic surge events requiring rate limiting.

[0045] Furthermore, assuming that in the aforementioned smart water management application scenario, a large number of water meter terminals perform periodic data reporting every hour on the hour. Under normal circumstances, the historical upstream traffic baseline is 100 Mbps, the upstream surge threshold is 2.0, and the corresponding surge threshold is 200 Mbps. At a certain hour, due to the simultaneous data reporting by a large number of terminals, the smoothed upstream traffic rate for three consecutive sampling windows reaches 230 Mbps, 260 Mbps, and 280 Mbps, respectively. Since all three sampling windows reach or exceed 200 Mbps, an upstream traffic surge event is determined to have occurred. At this time, this application further obtains the original sampled packets corresponding to the traffic surge event and performs parallel analysis on multiple traffic characteristic dimensions such as protocol, application, port, source IP, and destination IP to further determine the dominant traffic object causing the upstream traffic surge and its traffic contribution.

[0046] On the other hand, assuming the service platform does not send data to a large number of terminals at the same time, the smooth downlink traffic rate remains at, for example, around 210 Mbps. The historical downlink traffic baseline is 200 Mbps, the surge threshold is 2.5, and the corresponding downlink surge threshold is 500 Mbps. Since 210 Mbps does not reach 500 Mbps, even if an uplink traffic surge event is confirmed, a downlink traffic surge event will not be simultaneously determined. In this case, only the uplink traffic can proceed with the subsequent root cause analysis and rate limiting process, while the downlink continues to be monitored independently based on its own historical traffic baseline and surge threshold.

[0047] S3. Obtain the original sampled packets corresponding to the traffic surge event, and analyze multiple traffic feature dimensions in parallel based on the original sampled packets to determine the traffic objects and traffic contribution corresponding to each traffic feature dimension, specifically including: Obtain the original sampled packets within the sampling time window corresponding to the traffic surge event, and perform parallel statistics on multiple traffic feature dimensions based on the same batch of original sampled packets to determine the traffic object corresponding to each traffic feature dimension; For example, in a smart water cellular IoT application scenario, suppose the UPF target interface in a core network is responsible for aggregating data reports from a large number of water meter terminals. In step S2 above, based on the historical flow baseline and surge threshold corresponding to the uplink direction, an uplink flow surge event is determined to have occurred during a certain period. Assuming the sampling time window corresponding to this flow surge event is from 10:00:00 to 10:00:05, step S3 can obtain the raw sampled packets collected within this 5-second sampling time window, for example, obtaining 1 million raw uplink sampled packets. It should be noted that the raw sampled packets are used here, not the smoothed flow rate in step S1. The smoothed flow rate in step S1 is mainly used to determine whether a flow surge has occurred, while the raw sampled packets in step S3 are used to further analyze the specific flow object causing the flow surge.

[0048] Obtain the current traffic and historical traffic baseline corresponding to each traffic object, and determine the traffic increment corresponding to each traffic object based on the difference between the current traffic and the historical traffic baseline. Assuming that after obtaining the aforementioned 1 million original sampled packets, this application does not follow a progressive path of first analyzing the protocol, then analyzing the application from a specific protocol, then analyzing the port from a specific application, and finally analyzing the IP, for root cause localization, but instead performs parallel statistical analysis of multiple traffic feature dimensions based on the same batch of original sampled packets. In a specific embodiment of this application, the multiple traffic feature dimensions include at least the protocol dimension, application dimension, port dimension, source IP dimension, and destination IP dimension. That is to say, the same original sampled packet can participate in the statistical analysis of the above multiple dimensions simultaneously. For example, for an MQTT data packet sent from an IoT water meter terminal to a business platform, the protocol type, application type, port information, source IP, and destination IP can be extracted from the packet and accumulated into the statistical results of the corresponding dimensions.

[0049] Taking the protocol dimension as an example, the original sampled packets within the sampling time window can be classified and statistically analyzed according to protocol type to determine the traffic objects and their traffic rates corresponding to protocols such as MQTT, DNS, NTP, TCP, and UDP. For example, within the aforementioned 5-second sampling time window, statistics show that the current traffic rate corresponding to the MQTT protocol is 800Mbps, the current traffic rate corresponding to the DNS protocol is 50Mbps, the current traffic rate corresponding to the NTP protocol is 20Mbps, and the total traffic rate corresponding to other protocols is 30Mbps. Therefore, MQTT, DNS, NTP, and other protocol categories can be identified as the traffic objects corresponding to the protocol dimension. Simultaneously, at the application dimension, statistics can be performed based on the application type corresponding to the original sampled packets. For example, the original sampled packets may include traffic corresponding to different applications such as water meter data reporting applications, equipment management applications, and remote control applications, thereby obtaining the traffic objects and current traffic corresponding to each application. At the port dimension, statistics can be performed according to source port, destination port, or predefined port classification rules to obtain the traffic objects corresponding to different ports. At the source IP level, statistics can be compiled based on the source IP addresses of different IoT terminals to identify which terminals generated significant uplink traffic. At the destination IP level, statistics can be compiled based on the destination IP addresses of different business servers or platform servers to identify which target servers the surge in traffic primarily flows to. Therefore, for the same batch of original sampled packets, this application can simultaneously obtain statistical results across multiple dimensions. For example, in one specific embodiment, the following statistical results can be obtained: at the protocol level, MQTT is the primary traffic object; at the application level, the water meter data reporting application is the primary traffic object; at the port level, port 1883 is the primary traffic object; at the source IP level, some terminal source IPs generate significantly higher traffic; at the destination IP level, a large amount of traffic points to a specific business platform server. These statistical results are not obtained by progressively narrowing the packet range, but rather by statistically analyzing the same batch of original sampled packets separately, thus preserving strong characteristics across different dimensions simultaneously.

[0050] After identifying the traffic objects corresponding to each traffic characteristic dimension, this application further determines the current traffic and historical traffic baseline for each traffic object. The current traffic characterizes the actual traffic level generated by the corresponding traffic object within the sampling time window corresponding to the current traffic surge event; the historical traffic baseline characterizes the traffic level of the traffic object under historical normal operating conditions. By simultaneously obtaining the current traffic and the historical traffic baseline, it avoids judging whether an object is an abnormal traffic object solely based on the current traffic volume. This is because some traffic objects, although currently experiencing high traffic, may have maintained a consistently high normal traffic level over a long period and may not necessarily be the primary source of the current traffic surge. For example, in the protocol dimension, assuming the MQTT protocol's traffic rate is 800 Mbps within the current sampling time window, and the historical traffic baseline for the MQTT protocol is determined to be 300 Mbps based on historical normal operating data, then the traffic increment for the MQTT protocol is 800 Mbps. 300Mbps = 500Mbps. For example, if the current DNS protocol traffic is 50Mbps and its historical baseline traffic is 40Mbps, then the corresponding traffic increase for the DNS protocol is only 10Mbps. This shows that although both MQTT and DNS have a certain amount of current traffic, MQTT's increase relative to its historical normal level is more significant. Therefore, MQTT is more likely the dominant factor in this traffic surge.

[0051] For traffic characteristic dimensions such as protocols, applications, and ports, which are relatively limited in number and relatively stable, a corresponding historical traffic baseline can be maintained for each category. For example, separate historical traffic baselines can be maintained for the MQTT protocol, DNS protocol, and NTP protocol; similarly, separate historical traffic baselines can be maintained for different applications and different ports. In this way, when a traffic surge occurs, the current traffic for each category can be directly compared with its corresponding historical traffic baseline.

[0052] For traffic characteristic dimensions such as source IPs and destination IPs, which exhibit dynamic changes, it's impossible to maintain a complete historical traffic baseline for all possible IP addresses in advance. Therefore, the corresponding historical traffic baseline can be determined by combining it with historical high-contribution object records. For example, for a newly added source IP that has never appeared in the historical high-contribution object record before, its historical traffic baseline can be set to 0. In this case, if the source IP generates a large current traffic during the current traffic surge event, all of that current traffic can be used as the traffic increment corresponding to that source IP. For source IPs that have already appeared in the historical high-contribution object record, their historical traffic baseline can be determined based on their average traffic within the historical window. The destination IP can also have its historical traffic baseline determined in the same way.

[0053] After obtaining the current traffic and historical traffic baseline for each traffic object, the corresponding traffic increment is further determined based on the difference between the current traffic and the historical traffic baseline. Specifically, for any traffic object in any traffic feature dimension, the increase in the current traffic of that traffic object relative to its historical traffic baseline can be taken as the traffic increment for that traffic object. For example, if a source IP currently has a traffic of 100Mbps and its historical traffic baseline is 20Mbps, then the traffic increment for that source IP is 80Mbps; if another source IP currently has a traffic of 50Mbps and its historical traffic baseline is 45Mbps, then the traffic increment for that source IP is only 5Mbps. This allows for a more accurate reflection of the actual increase in traffic contributed by different traffic objects to the current traffic surge.

[0054] Based on the traffic increment corresponding to each of the traffic objects, the traffic contribution of each of the traffic objects is determined.

[0055] In one specific embodiment, for the same traffic characteristic dimension, the traffic increment corresponding to a certain traffic object can be compared with the total traffic increment of all traffic objects in that dimension to determine the traffic contribution ratio of that traffic object in the corresponding dimension. For example, in the protocol dimension, assuming the traffic increment corresponding to the MQTT protocol is 500Mbps, the traffic increment corresponding to the DNS protocol is 10Mbps, the traffic increment corresponding to the NTP protocol is 5Mbps, and the total traffic increment corresponding to other protocols is 15Mbps, then the total traffic increment of the protocol dimension is 530Mbps. The traffic contribution of the MQTT protocol is approximately 500÷530×100%=94.34%, and the traffic contribution of the DNS protocol is approximately 1.89%. Therefore, it can be determined that the MQTT protocol is the main traffic object in the protocol dimension.

[0056] For example, at the source IP level, suppose multiple source IPs were identified during this traffic surge. Source IP1 currently has a traffic of 150Mbps and a historical traffic baseline of 20Mbps, so its traffic increase is 130Mbps; source IP2 currently has a traffic of 100Mbps and a historical traffic baseline of 30Mbps, so its traffic increase is 70Mbps; source IP3 currently has a traffic of 80Mbps and a historical traffic baseline of 40Mbps, so its traffic increase is 40Mbps; and the combined traffic increase of the other source IPs is 60Mbps. Therefore, the total traffic increase at the source IP level is 300Mbps. In this case, source IP1's traffic contribution is 130 ÷ 300 × 100% = 43.33%, source IP2's is 70 ÷ 300 × 100% = 23.33%, and source IP3's is 40 ÷ 300 × 100% = 13.33%. Therefore, source IP1 is the source IP that contributed the most to this traffic surge.

[0057] It should be noted that the purpose of determining traffic contribution in this application is not merely to simply sort traffic objects, but to provide a basis for subsequent multi-dimensional correlation decisions and the determination of the minimum sufficient rate limit set. For example, in the protocol dimension, it may be found that the MQTT protocol contribution reaches over 90%, while in the destination IP dimension, a certain business platform's destination IP contribution reaches over 85%; at the same time, the source IP dimension may show that multiple IoT terminals contributed a portion of the new traffic. In this case, if only a single dimension is used for analysis, only partial conclusions such as "MQTT protocol abnormal" or "some source IPs abnormal" may be obtained; however, by obtaining traffic objects and contribution rates of multiple dimensions in parallel based on the same batch of original sampled packets, this application can provide a more complete distribution of traffic characteristics for subsequent correlation analysis.

[0058] Furthermore, in typical strong synchronous burst scenarios of cellular IoT, there may be cross-correspondences between traffic objects of different dimensions. For example, a large number of water meter terminals simultaneously use the MQTT protocol and send data to the same service platform destination IP through the same 1883 port. In this case, if a progressive drill-down approach of "protocol → application → port → IP" is adopted, it may be found at the protocol layer that the proportion of MQTT traffic is high, thus focusing subsequent analysis on MQTT traffic and failing to discover the small number of destination IPs that are truly suitable for rate limiting in a timely manner. However, this application, by performing parallel statistical analysis on the protocol, application, port, source IP, and destination IP of the same batch of original sampled packets, and further calculating the contribution based on the traffic increment of each traffic object, can simultaneously obtain strong features of the above multiple dimensions, providing a basis for subsequently selecting a minimum sufficient rate-limiting set with a small number of required rate-limiting objects that can cover a preset proportion of burst traffic.

[0059] Therefore, through the aforementioned step S3, this application achieves a further focus on "whether a traffic surge occurred" rather than "which traffic objects caused the traffic surge and how much new traffic each traffic object contributed." Specifically, step S2 uses the smoothed traffic rate and the historical traffic baseline in the corresponding direction to determine whether a traffic surge has occurred. Step S3 returns to the original sampled packets within the sampling time window corresponding to the traffic surge event, using the original packets as a unified data basis to analyze multiple traffic characteristic dimensions in parallel. The traffic increment is obtained through the difference between the current traffic and the historical traffic baseline, and the traffic contribution is determined based on the traffic increment. This avoids the loss of specific traffic object information in the smoothed traffic data and avoids repeatedly capturing packets for different dimensions, providing accurate, unified, and correlated basic data for subsequent determination of the minimum sufficient rate limit set, rate limit level decision-making, and targeted rate limit execution.

[0060] S4. For each of the aforementioned traffic characteristic dimensions, determine the cumulative traffic contribution based on the corresponding traffic contribution degree, and based on the comparison result of the cumulative traffic contribution degree and the preset contribution threshold, determine the rate limiting strategy corresponding to the traffic surge event, and issue the rate limiting command corresponding to the rate limiting strategy to the forwarding plane of the target interface for rate limiting, such as... Figure 2 As shown, it specifically includes: For each of the aforementioned traffic feature dimensions, the traffic objects corresponding to the traffic feature dimensions are sorted according to their corresponding traffic contribution. Then, traffic objects are selected sequentially from the sorted traffic objects, and the sum of the traffic contribution corresponding to the selected traffic objects is calculated to obtain the cumulative traffic contribution. For example, in a surge of uplink traffic in a cellular IoT core network, step S3 can determine the corresponding traffic objects and their traffic contribution based on traffic characteristic dimensions such as protocol, application, port, source IP, and destination IP. Assume that in the protocol dimension, the traffic contribution of the MQTT protocol is 72%, the DNS protocol is 8%, the NTP protocol is 5%, and other protocols contribute 15%; in the source IP dimension, the traffic contributions of source IP1, source IP2, source IP3, source IP4, and other source IPs are 35%, 18%, 10%, 6%, and 31%, respectively. In this case, the traffic objects can be sorted from highest to lowest traffic contribution, prioritizing those with larger traffic surges in the subsequent rate-limiting object selection process. After sorting, for each traffic characteristic dimension, traffic objects are selected sequentially from the sorted traffic objects according to the sorting order, and the traffic contribution of the selected traffic objects is accumulated to obtain the cumulative traffic contribution. For example, a contribution threshold of 70% can be preset. For the protocol dimension, MQTT is selected first, with a cumulative traffic contribution of 72%, already reaching the preset contribution threshold of 70%. Therefore, selecting only one MQTT traffic object is sufficient to meet the preset traffic coverage requirement. For the source IP dimension, source IP1 is selected first, with a cumulative traffic contribution of 35%. Selecting source IP2 brings the contribution to 53%, source IP3 to 63%, and source IP4 to 69%, still below 70%. At this point, another source IP object needs to be selected to achieve a cumulative traffic contribution of 70% or more. Therefore, it can be determined that multiple source IP objects are needed to cover the preset proportion of sudden traffic increases.

[0061] Through the above processing, the number of traffic objects required to reach the preset contribution threshold and the corresponding cumulative traffic contribution can be determined for each traffic characteristic dimension. It should be noted that the preset contribution threshold here represents the proportion of surge traffic that should be covered by the rate-limiting objects. It can be set according to actual network management needs, for example, to 70%. A higher preset contribution threshold usually requires more traffic objects to be included in the rate-limiting object set, thus covering more surge traffic; a lower preset contribution threshold reduces the number of rate-limiting objects, but may not cover a large proportion of surge traffic. Therefore, by setting a preset contribution threshold, a balance can be struck between the degree of abnormal traffic coverage and the number of rate-limiting objects.

[0062] Determine whether there is a situation where the cumulative traffic contribution corresponding to the traffic feature dimension reaches a preset contribution threshold; In the absence of a traffic feature dimension in which the cumulative traffic contribution reaches the preset contribution threshold, the rate limiting strategy is determined to be an overall interface rate limiting strategy. The overall interface rate limiting strategy is to limit the overall traffic in the direction corresponding to the target interface to within a preset multiple of the historical traffic baseline in the direction corresponding to the traffic surge event. If selecting and accumulating traffic objects across various traffic characteristic dimensions fails to reach the preset contribution threshold, it indicates that the surge in traffic is not concentrated on a single type or a few prominent traffic objects. For example, assuming a preset contribution threshold of 70%, the MQTT protocol, which has the highest contribution at the protocol level, only accounts for 45%, the DNS protocol for 20%, and the NTP protocol for 10%. Even accumulating the top-ranked objects would not reach 70%. At the source IP level, the cumulative contribution of the top-ranked source IPs only reaches 55%, and at the destination IP level, the cumulative contribution of the top-ranked destination IPs only reaches 60%. In this case, forcibly selecting one or a few objects for rate limiting may not effectively control the traffic surge, as the surge is already quite dispersed.

[0063] Therefore, in the absence of traffic characteristic dimensions where the cumulative traffic contribution reaches a preset contribution threshold, this application adopts an overall interface rate limiting strategy. This means that instead of object-level rate limiting for a specific protocol, application, port, source IP, or destination IP, the overall traffic in the direction corresponding to the target interface experiencing a traffic surge is limited. For example, assuming the current surge is in uplink traffic with a historical baseline of 100Mbps, a baseline multiple of 1.2 for the overall rate limiting can be preset. In this way, the overall interface rate limiting strategy can limit the overall uplink traffic of the target interface to within 120Mbps. Thus, even if a single traffic object with a sufficiently high contribution cannot be located, the scale of abnormal traffic can be controlled through overall interface rate limiting, preventing the traffic surge from continuing to put excessive pressure on the core network forwarding plane.

[0064] If there is a traffic feature dimension where the cumulative traffic contribution reaches the preset contribution threshold, the rate limiting strategy is determined to be an interface object rate limiting strategy. The interface object rate limiting strategy is to limit the rate limiting object set according to the corresponding rate limiting level and the minimum bandwidth. The rate limiting object set is determined based on the traffic objects that have reached the preset contribution threshold, and the rate limiting level and the minimum bandwidth are predetermined based on the traffic surge event. In detail, if at least one traffic characteristic dimension can reach a preset contribution threshold through a limited number of traffic objects, it indicates that the traffic surge can find a highly concentrated abnormal traffic object in at least one traffic characteristic dimension. In this case, it is not necessary to directly limit all traffic on the target interface, but to prioritize rate limiting for traffic objects that can cover the main surge traffic. This avoids uniformly rate limiting the normal IoT business traffic on the entire interface when the abnormal traffic is concentrated in only a few objects.

[0065] For example, suppose the surge in uplink traffic is mainly caused by a large number of IoT water meters reporting data simultaneously. Analysis at the protocol level reveals that MQTT contributed 72% of the new traffic; analysis at the source IP level shows that the top-ranking source IPs collectively contributed 75% of the new traffic; and analysis at the destination IP level shows that the destination IP corresponding to a specific business server contributed 82% of the new traffic. In this case, multiple traffic characteristic dimensions all reach the preset contribution threshold of 70%, indicating that the surge in traffic has a significant target concentration. Therefore, we can further determine the set of rate-limiting objects from the traffic characteristic dimensions and their traffic objects that reach the preset contribution threshold, rather than directly restricting the entire target interface.

[0066] In some embodiments, the number of traffic objects required to reach a preset contribution threshold can be used as an important basis for selecting the rate-limiting object set. For example, suppose that only one object needs to be selected for the protocol dimension, namely the MQTT protocol, to achieve a cumulative traffic contribution of 72%; five source IPs need to be selected for the source IP dimension to achieve 70%; and only one destination IP needs to be selected for the destination IP dimension to achieve 82%. In this case, compared to limiting five source IP objects, rate limiting for the MQTT protocol or the destination IP can cover a larger proportion of the surge traffic with fewer rate-limiting objects. Therefore, traffic feature dimensions with fewer traffic objects required to reach the preset contribution threshold can be preferentially selected, and the traffic objects selected for reaching the preset contribution threshold under that traffic feature dimension can be used as the rate-limiting object set. Thus, a minimum sufficient rate-limiting set that covers the main abnormal traffic with fewer rate-limiting objects can be formed.

[0067] For example, in a specific scenario, the uplink traffic of a target interface in a cellular IoT core network is normally around 100Mbps, but during this surge, the uplink traffic reached 300Mbps, an increase of approximately 200Mbps compared to the historical traffic baseline. S3 analysis revealed that the traffic increment corresponding to the MQTT object in the protocol dimension was 150Mbps, contributing 75% of the traffic. In the source IP dimension, three objects (source IP1, source IP2, and source IP3) were needed to achieve a cumulative traffic contribution of 72%. In the destination IP dimension, the traffic increment corresponding to a single object (destination IP1) was 170Mbps, contributing 85% of the traffic. Since only one object (destination IP1) was needed to cover 85% of the surged traffic, and this coverage exceeded the preset contribution threshold of 70%, destination IP1 could be selected as the object in the rate-limiting object set. In this case, rate limiting was no longer applied to the entire target interface, but rather to the traffic corresponding to destination IP1, controlling the main surged traffic while preserving as much normal service traffic as possible for other destination IPs.

[0068] After identifying traffic characteristic dimensions that can reach a preset contribution threshold, the interface object rate limiting strategy is further determined. This strategy does not simply block all traffic from selected objects; instead, it applies appropriate rate limiting to the set of objects based on a pre-determined rate limiting level and minimum bandwidth for the current traffic surge. The rate limiting level reflects the severity of the traffic surge; for example, different levels such as observation, mild, moderate, and severe rate limiting can be preset. The corresponding rate limiting level can be determined based on the deviation of the traffic rate corresponding to the traffic surge from the historical traffic baseline. For example, a lower rate limiting level can be used when the traffic rate is only slightly above the surge threshold; a higher rate limiting level can be used when the traffic rate is significantly higher than the historical traffic baseline and the duration is long.

[0069] The safety margin is used to prevent the traffic of the target device from being completely blocked. For example, if a destination IP1's traffic rate was 170Mbps before the rate limit was set, and a moderate rate limit is determined based on the current traffic surge, a corresponding safety margin is set for this rate limit. Assuming the safety margin is 10% of the traffic before the rate limit, at least approximately 17Mbps of bandwidth is reserved for the destination IP1 to continue transmitting data. In this case, the traffic of the destination IP1 is not directly limited to 0, but rather, while controlling its surge in traffic, it is still allowed to maintain a minimum level of business communication, thereby reducing the risk that related IoT services will be unable to communicate normally due to the complete blocking of the abnormal target.

[0070] A corresponding rate limiting instruction is generated based on the overall rate limiting policy of the interface or the rate limiting policy of the interface object, and the rate limiting instruction is sent to the forwarding plane of the target interface so that the forwarding plane of the target interface performs rate limiting according to the rate limiting instruction.

[0071] In this embodiment, the forwarding plane can be a user plane forwarding device in the cellular IoT core network or a network node that performs traffic forwarding functions, such as a PGW, UPF, or SR. For the overall interface rate limiting strategy, the generated rate limiting instruction can be used to specify the overall maximum allowed traffic rate of the target interface and its corresponding direction; for the interface object rate limiting strategy, the generated rate limiting instruction can further carry parameters such as the set of rate limiting objects, the rate limiting level corresponding to each rate limiting object, and the minimum bandwidth, so that the forwarding plane can perform differentiated rate limiting according to the specified objects.

[0072] For example, in the scenario of rate limiting for the target IP1 mentioned above, a rate limiting command can be generated, including information such as "target interface identifier, downlink or uplink direction, target IP1, rate limiting level, rate limiting rate, and guaranteed bandwidth," and then sent to the forwarding plane corresponding to the target interface. Upon receiving the rate limiting command, the forwarding plane can identify the matching traffic based on the target IP1 and limit the traffic rate in the direction corresponding to that target IP1 according to the rate limiting command, while reserving a corresponding guaranteed bandwidth for that target. For other traffic that does not match the target IP1, there is no need to limit it according to the rate limiting rules for that target, thus achieving precise control over abnormal main traffic.

[0073] Therefore, this application, through the processing steps of "traffic object sorting—cumulative contribution calculation—contribution threshold judgment—rate limiting strategy selection—rate limiting command issuance," further transforms the traffic contribution obtained in step S3 into a directly executable rate limiting strategy. When a surge in traffic is concentrated in a small number of traffic objects, an interface object rate limiting strategy is adopted to cover the main surge in traffic with fewer rate-limited objects; when the surge in traffic is dispersed and it is impossible to determine traffic objects with sufficient contribution, an overall interface rate limiting strategy is adopted as a fallback. This avoids the problem of directly implementing coarse-grained overall rate limiting after only detecting traffic anomalies in existing technologies, and minimizes the impact on normal IoT service traffic while controlling abnormal traffic in the core network.

[0074] S5. Continuously monitor the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and after the flow rate meets the preset exit condition and is confirmed by multiple consecutive sampling windows, gradually release the rate limit according to the preset release step size, specifically including: Continuously acquire the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and compare the flow rate with the historical flow baseline and preset exit threshold in the direction corresponding to the flow surge event; If the flow rate in the direction corresponding to the flow surge event is less than or equal to the product of the historical flow baseline in the direction corresponding to the flow surge event and the preset exit threshold, it is determined that the direction corresponding to the flow surge event meets the exit condition. If the exit condition is met in multiple consecutive sampling windows in the direction corresponding to the traffic surge event, it is determined that the rate limit exit condition is met, and the current rate limit is reduced according to the preset release step size to gradually remove the rate limit on the set of rate limit objects. Each time the current rate limit is reduced according to the preset release step size, the flow rate in the direction corresponding to the flow surge event continues to be monitored, and if the flow rate meets the exit condition, the current rate limit is reduced according to the preset release step size until the rate limit on the set of rate-limited objects is lifted.

[0075] For example, suppose the current event is an uplink traffic surge on the target interface. The historical uplink traffic baseline for this target interface is 100 Mbps, and the multiple corresponding to the traffic surge threshold is 2.0. That is, when the smooth uplink traffic rate reaches 200 Mbps for multiple consecutive sampling windows, a traffic surge event is determined to have occurred. After rate limiting is performed in S4, assuming the multiple corresponding to the preset exit threshold is set to 1.2, the traffic rate corresponding to the exit threshold is 100 Mbps × 1.2 = 120 Mbps. At this time, the uplink traffic rate is continuously acquired during the rate limiting process, and the acquired traffic rate is compared with 120 Mbps. When the uplink traffic rate in a certain sampling window drops to 120 Mbps or below, it can be determined that the sampling window meets the exit condition.

[0076] It should be noted that this application does not immediately lift the rate limiting after the exit condition is met in a single sampling window. Instead, it requires that the exit condition be met only after multiple consecutive sampling windows in the direction corresponding to the traffic surge event. The reason for this setting is that traffic in cellular IoT scenarios has strong suddenness and volatility. Even if the abnormal traffic has started to decrease, it may increase again in a short period of time due to terminal retransmission, centralized reporting by devices, or batch distribution of backend services. If the decision to exit the rate limiting is based solely on the traffic value of a single sampling window, there may be repeated switching phenomena such as lifting the rate limiting as soon as the traffic decreases, then the traffic immediately increases again after lifting, and then the rate limiting is triggered again.

[0077] For example, using an upstream historical traffic baseline of 100Mbps and an exit threshold of 120Mbps as an example, the rate limit is only allowed to exit after three consecutive sampling windows meet the exit conditions. Assume the consecutive sampling window traffic rates after rate limiting are 110Mbps, 115Mbps, 130Mbps, 112Mbps, 108Mbps, and 105Mbps respectively. The first window's 110Mbps is less than 120Mbps, meeting the exit condition; the second window's 115Mbps also meets the exit condition; however, the third window's 130Mbps exceeds 120Mbps, so the first three windows do not form three consecutive windows that meet the exit condition, and the rate limit exit condition cannot be determined. Then, the fourth window's 112Mbps, the fifth window's 108Mbps, and the sixth window's 105Mbps all meet the exit condition. Only when all three sampling windows meet the exit condition can the rate limit be released.

[0078] The aforementioned multi-sampling-window confirmation mechanism effectively provides further confirmation of the rate-limit exit conditions. For example, if the flow rate drops below the exit threshold in a certain sampling window, but exceeds the exit threshold again in the next sampling window, it indicates that the flow surge may not have truly subsided. In this case, the current rate limit level should be maintained instead of immediately lifting the rate limit. Only when the flow rate remains below the exit threshold for multiple consecutive sampling windows can the current flow surge be considered to have stabilized, and the subsequent rate-limit release process can begin. This reduces false releases caused by instantaneous flow drops and improves the stability of rate-limit status judgment.

[0079] After confirming that the exit conditions are met for multiple consecutive sampling windows, this application does not lift all rate limits at once. Instead, it gradually reduces the current rate limit level according to a preset release step size to gradually lift the rate limits on the set of rate-limited objects. The preset release step size specifies the release magnitude each time the rate limit is lifted. For example, it can reduce the rate limit level step by step according to a fixed percentage of the current rate limit, a fixed bandwidth value, or a pre-set level step size. The specific release step size can be pre-configured based on network interface capacity, service type, and historical fluctuations in abnormal traffic.

[0080] For example, suppose step S4 determines that a certain destination IP's corresponding rate-limited object set needs to be rate-limited at a severe rate-limiting level. After rate limiting, the maximum allowed traffic rate of this destination IP is restricted to 50Mbps, while the normal traffic level of this destination IP before rate limiting is approximately 100Mbps. Assuming the preset release step size is an increase of 20Mbps each time, after multiple consecutive sampling windows confirm that the exit condition is met, the allowed traffic rate of the rate-limited object can be increased from 50Mbps to 70Mbps first, instead of immediately restoring it to 100Mbps. In this case, it actually only reduces the current rate-limiting level, but does not completely remove the rate limit.

[0081] After initially reducing the current rate limit by a preset release step size, the system continues to acquire the traffic rate in the direction corresponding to the traffic surge event and reassess whether the current traffic rate meets the exit conditions. Assuming the exit threshold remains 120Mbps, after the first release, if the traffic rates in the direction corresponding to the target interface are 105Mbps, 110Mbps, and 115Mbps respectively, and none of these three consecutive sampling windows exceed 120Mbps, then the current rate limit can be reduced again by the preset release step size. For example, the allowed traffic rate can be further increased from 70Mbps to 90Mbps. At this point, the system does not immediately revert to a completely unrestricted state but continues to monitor the traffic after the release.

[0082] For example, after the second release, assuming the traffic rate changes sequentially to 108Mbps, 112Mbps, and 118Mbps, and the exit conditions are still met for multiple consecutive sampling windows, the release can continue according to the preset release step size, further increasing the allowed traffic rate from 90Mbps to 100Mbps. At this point, if 100Mbps has reached the target rate for lifting the rate limit on that object, the rate limit can be lifted, restoring normal traffic transmission. This forms a gradual recovery process: confirming abnormal traffic decrease—releasing a portion of the rate limit—re-monitoring—re-confirming—continuing to release.

[0083] Furthermore, during the gradual release process, if the traffic increases again and exceeds the preset exit threshold after a rate-limited release, the next release will not be executed; instead, the current rate-limited level will be maintained. For example, after the first release, if the traffic rate in the direction corresponding to the target interface increases from 110Mbps to 135Mbps, while the exit threshold is 120Mbps, then the sampling window no longer meets the exit condition. At this time, subsequent rate-limited releases can be paused, and traffic changes can continue to be monitored. If subsequent traffic meets the exit condition again for multiple consecutive sampling windows, the current rate-limited level can be reduced again according to the preset release step size; if the traffic continues to increase and meets the traffic surge condition again, the traffic object analysis and rate-limiting strategy can be readjusted in conjunction with steps S3 and S4.

[0084] For example, in a sudden surge in uplink traffic, the historical uplink traffic baseline of the target interface is 100Mbps, the entry threshold is 200Mbps, and the exit threshold is 120Mbps. Step S4 implements rate limiting for a batch of abnormal source IPs. After a period of rate limiting, the uplink traffic drops from 300Mbps to 110Mbps and remains below 120Mbps for three consecutive sampling windows, thus entering a gradual release phase. After the first release, the traffic recovers to 115Mbps; continued monitoring still meets the exit conditions, so it is released again. After the second release, due to some IoT terminals re-reporting, the traffic suddenly rises to 180Mbps. Since 180Mbps exceeds the 120Mbps exit threshold, subsequent releases are paused, and the current rate limiting level is maintained. Subsequently, if the traffic stabilizes and decreases again and remains below 120Mbps for several consecutive sampling windows, it is released again according to the preset release step size. This avoids lifting the rate limit too quickly before the abnormal traffic is completely eliminated.

[0085] From a control logic perspective, this application establishes a clear fast-in, slow-out rate-limiting control mechanism. When a traffic surge occurs, it can quickly enter a rate-limiting state to promptly control the impact of abnormal traffic on the core network interface. After the abnormal traffic decreases, the rate-limiting is gradually lifted through an exit threshold, confirmation via multiple consecutive sampling windows, and a preset release step size, ensuring that the rate-limiting state is not immediately lifted due to a short-term decrease in traffic. Especially in situations where cellular IoT terminals have periodic reporting, batch retransmissions, and synchronous communication, this method can effectively reduce the jitter caused by frequent entry and exit of the rate-limiting state.

[0086] Furthermore, the exit threshold can be set below the traffic level corresponding to the surge entry threshold. For example, assuming the historical traffic baseline is 100Mbps, the surge entry threshold is twice the historical traffic baseline, i.e., 200Mbps, while the exit threshold is 1.2 times the historical traffic baseline, i.e., 120Mbps. Thus, when the traffic gradually increases from a normal state and reaches 200Mbps, it can enter a rate-limiting state; after rate limiting, even if the traffic drops to 150Mbps, although this is significantly lower than the 200Mbps entry threshold, it will not be immediately lifted because 150Mbps is still higher than the 120Mbps exit threshold. Only when the traffic further decreases to 120Mbps or below, and remains at this level for multiple consecutive sampling windows, is the release phase allowed. This creates a certain threshold interval between entry and exit, thereby preventing repeated triggering and lifting of rate limiting when traffic fluctuates around the entry threshold.

[0087] Therefore, this application continuously monitors the traffic rate after rate limiting and employs a processing method of exit threshold judgment—confirmation through multiple consecutive sampling windows—gradual release according to a preset release step size—continued monitoring after release. This allows the rate limiting policy to dynamically exit based on the actual changes in traffic surge events, rather than using a coarse-grained approach of releasing the rate limit all at once. On the one hand, it ensures that abnormal traffic is continuously controlled before releasing the rate limit; on the other hand, it can promptly detect a resurgence in traffic during the release process and pause the release, thereby reducing network jitter caused by frequent switching of the rate limiting policy. It also gradually restores the communication bandwidth of normal IoT services while ensuring stable traffic on the core network interface, ultimately achieving a closed-loop process between abnormal traffic detection, rate limiting control, and rate limiting release.

[0088] In some embodiments of this application, such as Figure 3 As shown, the set of rate-limiting objects is determined based on the number of traffic objects that reach the preset contribution threshold, specifically including: When the cumulative traffic contribution corresponding to at least one of the traffic feature dimensions reaches the preset contribution threshold, the minimum number of traffic objects required to make the cumulative traffic contribution reach the preset contribution threshold for each of the traffic feature dimensions is determined, and the traffic feature dimension with the smallest required number of traffic objects is determined as the target traffic feature dimension. For example, suppose the uplink traffic of a target interface in a cellular IoT core network is normally around 100Mbps. In this instance, due to a large number of IoT water meters simultaneously reporting data, the uplink traffic suddenly surges to 300Mbps. S2 has already determined that an uplink traffic surge event has occurred based on historical traffic baselines and surge entry thresholds. S3 further analyzes the original sampled packets corresponding to this surge event, simultaneously statistically analyzing multiple traffic characteristic dimensions such as protocol, application, port, source IP, and destination IP. Assuming a pre-set contribution threshold of 70%, the desired final rate-limiting target should cover at least 70% of the newly added traffic in this surge.

[0089] At the protocol level, assuming the MQTT protocol contributes 62% of traffic, the DNS protocol contributes 8%, the NTP protocol contributes 5%, and other protocols contribute 25%. After sorting by traffic contribution from highest to lowest, the MQTT protocol is selected first, at which point the cumulative traffic contribution is 62%, not yet reaching 70%. Continuing with the DNS protocol, the cumulative traffic contribution reaches 70%. Therefore, at least two traffic objects, MQTT and DNS, need to be selected at the protocol level to reach the preset contribution threshold.

[0090] In the application dimension, assuming the flow contribution of the water meter periodic data reporting application is 55%, the flow contribution of the equipment management application is 9%, the flow contribution of the remote control application is 6%, and the flow contribution of other applications is 30%, then, first selecting the water meter periodic data reporting application, the cumulative contribution is 55%; continuing to select the equipment management application, the cumulative contribution is 64%; continuing to select the remote control application, the cumulative contribution reaches 70%. Therefore, at least three flow objects need to be selected in the application dimension.

[0091] At the port level, assuming port 1883 contributes 73% of the traffic and other ports contribute 27%, since the cumulative traffic contribution of a single traffic object at port 1883 has reached 73%, only one traffic object is needed at the port level to reach the preset contribution threshold.

[0092] In the source IP dimension, assuming the top-ranked source IP1, source IP2, source IP3, and source IP4 contribute 32%, 18%, 12%, and 9% of traffic respectively, the cumulative contribution after selecting source IP1 and source IP2 is 50%, after selecting source IP3 it reaches 62%, and after selecting source IP4 it reaches 71%. Therefore, at least four traffic objects are needed in the source IP dimension to reach the preset contribution threshold of 70%.

[0093] In the destination IP dimension, assuming that the traffic contribution of destination IP1 is 82%, and the traffic contribution of the other destination IPs is a total of 18%. Since a single traffic object for destination IP1 can achieve a cumulative traffic contribution of 82%, the minimum number of traffic objects required for the destination IP dimension is 1.

[0094] Based on the above calculations, we can see that the protocol dimension requires 2 traffic objects, the application dimension requires 3 traffic objects, the port dimension requires 1 traffic object, the source IP dimension requires 4 traffic objects, and the destination IP dimension requires 1 traffic object. At this point, we can observe that both the port and destination IP dimensions only require 1 traffic object to reach the preset contribution threshold of 70%. Therefore, both are candidate dimensions that can cover the main surge in traffic with the fewest number of objects.

[0095] When multiple traffic feature dimensions have the same minimum number of traffic objects, this application further compares the cumulative traffic contribution of these traffic feature dimensions and determines the traffic feature dimension with the higher cumulative traffic contribution as the target traffic feature dimension. For example, the port dimension only requires selecting one object, port 1883, with a cumulative traffic contribution of 73%; the destination IP dimension only requires selecting one object, destination IP1, with a cumulative traffic contribution of 82%. Since both dimensions require a minimum number of traffic objects of 1, their cumulative traffic contributions are further compared, and the destination IP dimension is ultimately determined as the target traffic feature dimension, with destination IP1 being determined as the initial rate-limiting object set.

[0096] The approach of prioritizing the fewest traffic objects and further comparing cumulative traffic contribution is designed to ensure that the rate-limiting strategy uses as few rate-limiting objects as possible while guaranteeing that the selected objects can cover a large proportion of the surge traffic. For example, if one dimension requires limiting 5 source IPs to cover 70% of the surge traffic, while another dimension only needs to limit 1 destination IP to cover 82% of the surge traffic, then clearly, rate-limiting the destination IP will achieve control over the main surge traffic with fewer rate-limiting objects. This reduces the number of rate-limiting rules that need to be maintained on the forwarding plane and also minimizes the impact on normal business traffic unrelated to abnormal objects.

[0097] The traffic objects that make the cumulative traffic contribution reach the preset contribution threshold in the target traffic feature dimension are determined as the initial rate-limiting object set; when there are multiple traffic feature dimensions with the same minimum number of traffic objects, the traffic feature dimension with the higher cumulative traffic contribution is determined as the target traffic feature dimension. For example, in the destination IP dimension mentioned above, the traffic contribution of destination IP1 has already reached 82%. Therefore, only destination IP1 needs to be included in the initial rate-limiting object set, without needing to add other destination IPs to the rate-limiting object set. As another example, if the contribution of destination IP1 is only 45%, destination IP2's contribution is 20%, and destination IP3's contribution is 12%, then destination IP1, destination IP2, and destination IP3 need to be selected sequentially to achieve a cumulative contribution of 77%. In this case, the initial rate-limiting object set includes destination IP1, destination IP2, and destination IP3.

[0098] The initial speed limit object set and the target traffic feature dimension determined this time are compared with the initial speed limit object set and the target traffic feature dimension determined in the previous time, respectively. In detail, after determining the target traffic characteristic dimension, the traffic objects within that dimension that contribute a cumulative traffic value to a preset contribution threshold are selected as the initial rate-limiting object set. For example, in the aforementioned destination IP dimension, the traffic contribution of destination IP1 has already reached 82%, so only destination IP1 needs to be included in the initial rate-limiting object set, without needing to add other destination IPs. As another example, if destination IP1's contribution is only 45%, destination IP2's contribution is 20%, and destination IP3's contribution is 12%, then destination IP1, destination IP2, and destination IP3 need to be selected sequentially to achieve a cumulative contribution of 77%. In this case, the initial rate-limiting object set includes destination IP1, destination IP2, and destination IP3.

[0099] After determining the initial set of rate-limiting objects, this application does not immediately distribute this initial set of rate-limiting objects to the forwarding plane. Instead, it further compares the newly determined initial set of rate-limiting objects and the target traffic characteristic dimensions with the previously determined initial set of rate-limiting objects and the target traffic characteristic dimensions. The previous determination result can be understood as the candidate result for rate-limiting decisions obtained after analyzing traffic objects for the same traffic surge event in the previous sampling period. By comparing the two determination results, it is possible to determine whether the currently identified abnormal traffic objects are persistent, thereby avoiding immediate changes in the rate-limiting strategy due to instantaneous traffic changes within a sampling window.

[0100] For example, suppose that in the first sampling period, the destination IP dimension is determined to be the target traffic characteristic dimension through analysis, and destination IP1 is identified as the initial rate-limiting object set. At this point, a rate-limiting command is not immediately issued for destination IP1; instead, the analysis waits for the next sampling period to re-analyze the original sampled packets corresponding to the surge event. Suppose that in the second sampling period, due to changes in the reporting time of some terminals, the traffic contribution of destination IP1 decreases, while the traffic contribution of port 1883 increases, resulting in the current calculation result being port dimension as the target traffic characteristic dimension and port 1883 as the initial rate-limiting object set. Since the target traffic characteristic dimension has changed from the destination IP dimension to the port dimension, and the initial rate-limiting object set has also changed, it is considered that the current rate-limiting object selection result has not been confirmed by consecutive sampling periods. Therefore, a new rate-limiting command is not immediately issued based on the result of the second sampling period; instead, the initial rate-limiting object set and target traffic characteristic dimension are re-determined in the next sampling period.

[0101] If the initial speed limit object set determined this time is inconsistent with the initial speed limit object set determined in the previous time, or if the target flow feature dimension determined this time is inconsistent with the target flow feature dimension determined in the previous time, the initial speed limit object set and the target flow feature dimension shall be re-determined in the next sampling period. If the initial rate-limiting object set determined this time is consistent with the initial rate-limiting object set determined previously, and the target traffic feature dimension determined this time is consistent with the target traffic feature dimension determined previously, then the initial rate-limiting object set determined this time is determined as the rate-limiting object set, and the rate-limiting instruction is generated according to the rate-limiting object set and sent to the forwarding plane of the target interface.

[0102] For example, suppose that in the third sampling period, by analyzing the raw sampled packets acquired in this period, the destination IP traffic characteristic dimension is determined to be the target traffic characteristic dimension, and destination IP1 is determined to be the traffic object required to reach the preset contribution threshold for cumulative traffic contribution. Since the target traffic characteristic dimension determined in the second sampling period was the port traffic characteristic dimension, and port 1883 was determined to be the corresponding traffic object, the target traffic characteristic dimension and traffic object determined in the third sampling period are different from those determined in the second sampling period. In this case, destination IP1 determined in the third sampling period cannot be directly used as the final rate-limiting object. Instead, the target traffic characteristic dimension and the corresponding initial rate-limiting object set are re-determined in the next sampling period.

[0103] Further assuming that in the fourth sampling period, analysis of the new original sampled packets confirms that the destination IP traffic characteristic dimension remains the same as the target traffic characteristic dimension, and that destination IP1 is identified as the traffic object required to reach the preset contribution threshold for cumulative traffic contribution; and in the fifth sampling period, after analysis in the same manner, the destination IP traffic characteristic dimension remains the same as the target traffic characteristic dimension, and destination IP1 is still identified as the corresponding traffic object. At this point, the target traffic characteristic dimension determined in the fourth and fifth sampling periods remains consistent, and the initial rate-limiting object set determined in both sampling periods also remains consistent. Therefore, it can be considered that destination IP1 has a high traffic contribution throughout the continuous sampling periods, and its identification as the main source of traffic surge in this event has good stability. At this point, destination IP1 can be identified as the traffic object in the final rate-limiting object set, and a rate-limiting command for destination IP1 can be generated based on the predetermined rate-limiting level and minimum bandwidth.

[0104] To further illustrate the consistency confirmation process described above, suppose that after a traffic surge event occurs, in the first sampling period, analysis of the original sampled packets determines that the destination IP traffic feature dimension can reach the preset contribution threshold with the minimum number of traffic objects, and destination IP1 is identified as the traffic object required to reach the preset contribution threshold for cumulative traffic contribution. In the second sampling period, due to changes in the packet transmission times of different IoT terminals, the traffic contribution corresponding to destination IP1 decreases, while the traffic contribution corresponding to destination IP2 increases. Therefore, after reselecting the traffic feature dimension based on the traffic contribution in the second sampling period, the destination IP traffic feature dimension is still identified as the target traffic feature dimension, but destination IP2 is identified as the traffic object required to reach the preset contribution threshold for cumulative traffic contribution. Since the initial rate-limiting object sets determined in the first and second sampling periods are inconsistent, destination IP2 identified in the second sampling period cannot be directly determined as the final rate-limiting object; confirmation is required in the next sampling period.

[0105] Suppose that in the third sampling period, the traffic corresponding to destination IP1 increases again. Based on traffic contribution calculation, destination IP1 is again identified as the traffic object required to reach the preset contribution threshold for cumulative traffic contribution, and the traffic characteristic dimension of destination IP is still determined as the target traffic characteristic dimension. In the fourth sampling period, the traffic characteristic dimension of destination IP is still determined as the target traffic characteristic dimension, and destination IP1 is again identified as the traffic object required to reach the preset contribution threshold for cumulative traffic contribution. In this case, although the initial rate-limiting object set is different in the second and third sampling periods, continuous analysis in subsequent sampling periods shows that destination IP1 exhibits a high traffic contribution again in multiple sampling periods. Therefore, after meeting the preset consistency confirmation conditions, destination IP1 can be determined as the final rate-limiting object.

[0106] Without the aforementioned consistency judgment mechanism across sampling periods, the system might directly modify the rate-limiting policy based on instantaneous traffic changes in different sampling periods. For example, after determining that destination IP1 is the primary traffic target in the first sampling period, rate-limiting is immediately applied to destination IP1. In the second sampling period, due to a decrease in the instantaneous traffic of destination IP1, destination IP2 is determined to be the primary traffic target, and the rate-limiting for destination IP1 is immediately revoked and a rate-limiting for destination IP2 is established. In the third sampling period, after the traffic of destination IP1 increases again, rate-limiting is reapplied to destination IP1. In this case, the forwarding plane needs to frequently add, delete, or modify rate-limiting rules, which not only increases the rule processing burden on the forwarding plane but may also cause the rate-limiting state to switch repeatedly with instantaneous traffic changes, resulting in rate-limiting policy jitter.

[0107] By adopting the consistency confirmation mechanism of this application, when the initial rate-limiting object set determined in the current instance is inconsistent with the previously determined initial rate-limiting object set, the rate-limiting rules are not immediately updated based on the current determination result. Instead, traffic object analysis is re-performed in the next sampling period. For example, if destination IP1 was previously determined to be a traffic object in the initial rate-limiting object set, while destination IP2 is determined to be a traffic object in the current initial rate-limiting object set, this indicates a change in the current rate-limiting object selection result. In this case, the original rate-limiting policy is not revoked, nor is a new rate-limiting policy immediately established for destination IP2. Instead, the original sampled packets of the next sampling period are obtained, and the initial rate-limiting object set is re-determined. In this way, accidental object changes caused by factors such as changes in terminal packet sending time and short-term traffic fluctuations can be filtered out.

[0108] Furthermore, this application compares not only whether the initial rate-limiting object set is consistent, but also whether the target traffic feature dimensions are consistent. For example, in the first sampling period, by analyzing the traffic contribution corresponding to each traffic feature dimension, it is determined that the minimum number of traffic objects required for the source IP traffic feature dimension to reach the preset contribution threshold is achieved. Therefore, the source IP traffic feature dimension is determined as the target traffic feature dimension, and source IP1 and source IP2 are determined as traffic objects in the initial rate-limiting object set. In the second sampling period, since the traffic generated by multiple IoT terminals is concentrated on accessing the same business server, the traffic contribution corresponding to the destination IP traffic feature dimension is significantly increased. Thus, the destination IP traffic feature dimension is determined as the target traffic feature dimension, and destination IP1 is determined as a traffic object in the initial rate-limiting object set. At this point, even if some traffic objects in source IP1 and source IP2 still have a high traffic contribution, since the target traffic feature dimension has changed from the source IP traffic feature dimension to the destination IP traffic feature dimension, the rate-limiting decision cannot be directly considered stable and needs to be confirmed in the next sampling period.

[0109] The reason for simultaneously comparing the initial rate-limiting object set and the target traffic feature dimension is that the rate-limiting granularity and network meaning corresponding to different traffic feature dimensions are not the same. The source IP traffic feature dimension is used to characterize the IoT terminal or terminal address that generates the traffic. When abnormal traffic is mainly generated by a small number of IoT terminals, rate limiting based on the source IP can directly limit the source of abnormal traffic. On the other hand, the destination IP traffic feature dimension is used to characterize the business server or business node that receives the traffic. When multiple IoT terminals have different source IPs, or even use different protocols or ports, but their traffic ultimately accesses the same destination IP, rate limiting based on that destination IP can use a single traffic object to cover the sudden surge in traffic from multiple IoT terminals. Therefore, if only the traffic objects are compared without comparing the target traffic feature dimension, it may be impossible to accurately determine whether the actual rate-limiting granularity has stabilized.

[0110] For example, suppose that in the first sampling period, both source IP1 and source IP2 generate high traffic, so that selecting only source IP1 and source IP2 as the source IP traffic feature dimension is sufficient to reach the preset contribution threshold of 70% for the cumulative traffic contribution. Therefore, the source IP traffic feature dimension is determined as the target traffic feature dimension, and source IP1 and source IP2 are determined as the initial rate-limiting object set. In the second sampling period, due to more IoT terminals sending data to the business server simultaneously, the traffic contribution corresponding to destination IP1 reaches 82%, so that only destination IP1 as the destination IP traffic feature dimension is needed to reach the preset contribution threshold. Therefore, the destination IP traffic feature dimension is determined as the target traffic feature dimension, and destination IP1 is determined as the initial rate-limiting object set. Although there are objects with high traffic in both sampling periods, the change in the target traffic feature dimension indicates a change in the way abnormal traffic is concentrated. In this case, it is not advisable to directly issue a new rate-limiting command, but to continue sampling for confirmation.

[0111] When the initial rate-limiting object set determined this time is consistent with the initial rate-limiting object set determined in the previous time, and the target traffic feature dimension determined this time is also consistent with the target traffic feature dimension determined in the previous time, it indicates that within the continuous sampling period, the same traffic objects under the same traffic feature dimension can maintain a high traffic contribution, thus it can be considered that the current rate-limiting decision has good stability. For example, in the first and second sampling periods, the destination IP traffic feature dimension is determined to be the target traffic feature dimension, and destination IP1 and destination IP2 are determined to be the traffic objects required to make the cumulative traffic contribution reach the preset contribution threshold. Then, destination IP1 and destination IP2 can be determined as the final rate-limiting object set, and the corresponding rate-limiting instruction can be generated based on this rate-limiting object set.

[0112] In a specific cellular IoT water meter data reporting scenario, assume a large number of water meters connect to the core network via the cellular network and send water usage data to the business server at the same time each day. A single concentrated reporting session causes a sudden surge in uplink traffic to the target interface. In the first sampling period, analysis of the original sampled packets determines that the traffic contribution of destination IP1 is 76%, and the minimum number of traffic objects required for the destination IP's traffic feature dimension is determined to be 1. Therefore, the destination IP's traffic feature dimension is chosen as the target traffic feature dimension, and destination IP1 is selected as the traffic object in the initial rate-limiting object set. In the second sampling period, the traffic contribution of destination IP1 further reaches 79%. After re-analysis, the destination IP's traffic feature dimension is still chosen as the target traffic feature dimension, and destination IP1 is still selected as the traffic object in the initial rate-limiting object set. Since the target traffic feature dimension and the initial rate-limiting object set remain consistent for two consecutive sampling periods, it can be determined that destination IP1 has a consistently high traffic contribution. At this point, destination IP1 can be selected as the final rate-limiting object set, and a rate-limiting command is generated for destination IP1.

[0113] Furthermore, when generating rate-limiting instructions, information such as the target interface's interface identifier, traffic direction, target traffic characteristic dimension, the final determined set of rate-limiting objects, the rate-limiting level, and the guaranteed bandwidth can be written into the rate-limiting instruction. For example, in the above-mentioned centralized water meter reporting scenario, a rate-limiting instruction can be generated targeting the uplink direction of the target interface, the destination IP traffic characteristic dimension, and the destination IP1, and the corresponding rate-limiting level and guaranteed bandwidth can be further specified in the rate-limiting instruction. After receiving the rate-limiting instruction, the forwarding plane of the target interface can identify the traffic with the destination IP as destination IP1 based on the destination IP traffic characteristic dimension, and implement rate-limiting on this part of the traffic according to the specified rate-limiting level, while retaining the corresponding guaranteed bandwidth, without needing to uniformly limit all IoT traffic in the uplink direction of the target interface.

[0114] Therefore, this application does not immediately change the rate-limiting strategy based on the current traffic contribution calculation result in each sampling period. Instead, it first selects the target traffic feature dimension based on the minimum number of traffic objects, then determines the initial rate-limiting object set that can reach the preset contribution threshold under the target traffic feature dimension, and confirms the continuity of the target traffic feature dimension and the initial rate-limiting object set by comparing it with the previous determination result. Only when both are consistent is the initial rate-limiting object set determined as the final rate-limiting object set and a rate-limiting command is issued to the forwarding plane; if either changes, the current rate-limiting decision is suspended and re-determined in the next sampling period. This allows the final rate-limiting strategy to be based on continuous and stable traffic anomaly characteristics, avoiding frequent changes in rate-limiting objects or rate-limiting dimensions due to short-term traffic fluctuations, thereby reducing frequent switching of forwarding plane rate-limiting rules and improving the stability and reliability of anomaly traffic rate limiting.

[0115] Optionally, in some embodiments of this application, the method further includes continuously monitoring the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and the method also includes: The flow rate in the direction corresponding to the flow surge event after the speed limit is compared with the historical flow baseline in the direction corresponding to the flow surge event and the surge entry threshold; If the flow rate in the direction corresponding to the flow surge event after the rate limit is set still meets the surge condition for multiple consecutive sampling windows, it is determined that the rate limit upgrade condition is met, and the rate limit strategy of the interface object is adjusted to expand the set of rate limit objects or increase the rate limit level. A rate-limiting instruction is generated based on the adjusted rate-limiting policy of the interface object, and the rate-limiting instruction is sent to the forwarding plane of the target interface for rate limiting.

[0116] Next, a detailed example will be provided. Assume the historical traffic baseline for the target interface's uplink direction is 100Mbps, and the pre-set surge threshold is twice the historical traffic baseline; therefore, the corresponding surge threshold is 200Mbps. In step S4, by performing multi-dimensional analysis on the original sampled packets corresponding to the traffic surge event, the destination IP traffic characteristic dimension is determined as the target traffic characteristic dimension, and destination IP1 and destination IP2 are identified as the rate-limiting object set. Assume that a moderate rate-limiting level is adopted based on the severity of this traffic surge event, and corresponding rate limits are implemented for destination IP1 and destination IP2.

[0117] After implementing the aforementioned rate limiting, the uplink traffic rate of the target interface continues to be monitored. Assume that in the consecutive sampling windows after rate limiting, the uplink traffic rates are 215Mbps, 225Mbps, and 230Mbps, respectively. Since the traffic rates in all three sampling windows exceed the 200Mbps surge threshold, the surge condition is still met in all three consecutive sampling windows. This indicates that even though moderate rate limiting has been implemented for destination IP1 and destination IP2, the current traffic surge has not been effectively controlled; therefore, the rate limiting escalation condition is met.

[0118] It's important to note that this application does not immediately escalate the rate limit level upon detecting a traffic surge exceeding the threshold again in a single sampling window after rate limiting. Confirmation is still required across multiple consecutive sampling windows. For example, in the scenario described above, if the traffic rates after rate limiting are 215Mbps, 185Mbps, and 220Mbps respectively, although the first and third sampling windows exceed 200Mbps, the second sampling window has already dropped to 185Mbps, failing to meet the surge condition. Therefore, the traffic surge cannot be considered to have persisted across multiple consecutive sampling windows, and a rate limit escalation will not be immediately triggered. This continuous sampling window confirmation method avoids frequent rate limit escalations due to instantaneous traffic fluctuations within a single sampling window.

[0119] Once the conditions for rate limiting upgrade are met, the current rate limiting strategy for the interface object can be further adjusted. Specifically, the rate limiting intensity can be increased by expanding the set of rate-limited objects or raising the current rate limiting level. The method used for adjustment can be determined based on the current distribution of traffic objects and the coverage of the current rate-limited objects for sudden traffic surges.

[0120] In one scenario, the rate-limiting object set can be expanded. For example, during the initial rate-limiting object selection, the cumulative traffic contribution of destination IP1 and destination IP2 has reached a preset contribution threshold, such as 72%, so destination IP1 and destination IP2 are selected as the rate-limiting object set. However, after implementing rate limiting, the overall uplink traffic still exceeds the surge threshold for multiple consecutive sampling windows, indicating that limiting only destination IP1 and destination IP2 is insufficient to control abnormal traffic within the normal range. At this point, the current traffic can be re-analyzed, revealing a significant increase in traffic from destination IP3, which, along with destination IP1 and destination IP2, forms a substantial source of surge traffic. Therefore, destination IP3 can be further added to the original rate-limiting object set, making the new rate-limiting object set include destination IP1, destination IP2, and destination IP3. A new rate-limiting instruction can then be generated based on the adjusted interface object rate-limiting strategy.

[0121] For example, during the initial rate limiting, the surge in traffic corresponding to destination IP1 is 120Mbps, and the surge in traffic corresponding to destination IP2 is 70Mbps, together covering 72% of the surge. After rate limiting is implemented, due to a further increase in traffic corresponding to destination IP3, destination IP3 generates another 50Mbps surge, keeping the overall traffic on the target interface between 220Mbps and 240Mbps. At this point, although destination IP1 and destination IP2 are still subject to rate limiting, the new major surge in traffic has shifted to destination IP3. Therefore, simply tightening the rate limiting on destination IP1 and destination IP2 may not effectively control the new surge in traffic. In this case, adding destination IP3 to the rate-limiting target set can expand the coverage of abnormal traffic, allowing the rate limiting policy to continue controlling the major surge in traffic.

[0122] In another scenario, the current rate limiting level can be increased. For example, suppose that destination IP1 and destination IP2 in the rate limiting object set already cover more than 80% of the current surge in traffic, and traffic object analysis reveals that the main surge in traffic is still concentrated on these two destination IPs, while the contribution of other traffic objects is relatively low. In this case, expanding the rate limiting object set will not significantly improve the coverage of abnormal traffic. In this situation, the current rate limiting object set can be kept unchanged, while increasing the rate limiting level corresponding to destination IP1 and destination IP2. For example, when a light rate limiting level was initially used, destination IP1 and destination IP2 were allowed to maintain relatively high traffic rates. After several consecutive sampling windows still meet the surge conditions, the rate limiting level can be adjusted from a light rate limiting level to a moderate rate limiting level, further reducing the allowed traffic rates corresponding to destination IP1 and destination IP2, thereby enhancing the control capability for abnormal traffic.

[0123] For example, suppose the historical uplink traffic baseline of the target interface is 100Mbps, and the surge threshold is 200Mbps. After implementing mild rate limiting, the traffic corresponding to destination IP1 and destination IP2 still causes the overall uplink traffic of the target interface to reach 215Mbps, 225Mbps, and 230Mbps for three consecutive sampling windows. Further analysis reveals that approximately 85% of the traffic still originates from destination IP1 and destination IP2, while the contribution of other traffic objects is relatively low. In this case, it can be considered that the main source of abnormal traffic has not changed. The problem is not that the range of rate limiting objects is too small, but rather that the current rate limiting level is insufficient. Therefore, without changing the set of rate limiting objects, the rate limiting level corresponding to destination IP1 and destination IP2 can be directly increased from mild to moderate, and a new rate limiting command can be generated and issued to the forwarding plane of the target interface.

[0124] In some embodiments, multiple consecutive rate limiting levels can be preset according to the severity of the traffic surge, and the rate limiting can be increased step by step according to the rate limiting escalation process. For example, an observation level, a mild rate limiting level, a moderate rate limiting level, and a severe rate limiting level can be set. When a traffic surge is detected for the first time and the rate limiting target is identified, a mild rate limiting level can be applied first; if the traffic still exceeds the surge entry threshold for multiple consecutive sampling windows after rate limiting, the rate limiting level is escalated to a moderate rate limiting level; if the traffic still continues to exceed the surge entry threshold after escalating to a moderate rate limiting level, the rate limiting level is further escalated to a severe rate limiting level. By gradually increasing the rate limiting level, the rate limiting intensity can be matched with the duration of the traffic surge, rather than directly applying the highest intensity rate limiting method as soon as an anomaly is detected.

[0125] For example, the historical baseline uplink traffic on the target interface of a cellular IoT core network is 100Mbps, and the surge threshold is 200Mbps. When the first traffic surge is detected, the uplink traffic on the target interface reaches 240Mbps. The system identifies destination IP1 and destination IP2 as the primary sources of abnormal traffic and applies a light rate limiting level. After rate limiting, if the traffic drops to 150Mbps, 160Mbps, and 170Mbps in multiple consecutive sampling windows, it is below the 200Mbps surge threshold. Therefore, there is no need to upgrade the current rate limiting level, and monitoring can continue according to the current rate limiting strategy. Conversely, if the traffic after rate limiting remains at 215Mbps, 220Mbps, and 225Mbps, it indicates that the light rate limiting is insufficient to control the abnormal traffic. In this case, the rate limiting level can be increased to a medium rate limiting level.

[0126] Furthermore, assuming that after upgrading to a moderate rate limiting level, the uplink traffic on the target interface still reaches 210Mbps, 218Mbps, and 215Mbps for multiple consecutive sampling windows, and the main abnormal traffic remains concentrated on the original destination IP1 and destination IP2, then the rate limiting upgrade conditions can be met again, and the rate limiting level can be further increased to a severe rate limiting level. At this point, by progressively increasing the rate limiting intensity, control can be dynamically strengthened according to the persistence of abnormal traffic, giving the rate limiting strategy feedback adjustment capabilities.

[0127] It's important to note that expanding the set of rate-limited objects and increasing the rate-limit level are tailored to different abnormal traffic patterns. Expanding the rate-limited object set is more suitable when abnormal traffic persists after rate limiting, and new major sources of abnormal traffic gradually expand beyond the original rate-limited object set. Conversely, increasing the rate-limit level is more appropriate when abnormal traffic remains primarily concentrated within the current rate-limited object set, and the current rate-limiting intensity is insufficient to control it within the target range. By selecting the appropriate adjustment method based on the specific changes in abnormal traffic, simply raising the rate-limit level can be avoided.

[0128] For example, suppose destination IP1 is initially identified as the primary rate-limiting target, and a moderate rate limit is applied to it. After rate limiting, the traffic to destination IP1 has decreased significantly, but because a large number of other IoT devices have begun sending data to destination IP2, the overall traffic to the target interface continues to exceed the surge threshold. In this case, increasing the rate limit level for destination IP1 will not solve the main problem, because the new abnormal traffic has shifted to destination IP2. Therefore, a new traffic object analysis can be performed, and destination IP2 can be added to the rate-limiting target set. Conversely, if destination IP1 continues to generate a large amount of traffic after rate limiting, and the contributions of destination IP2 and other targets are relatively low, then destination IP1 can remain as the rate-limiting target, and its rate limit level can be further increased.

[0129] After determining the adjusted rate limiting policy for the interface objects, a new rate limiting instruction is generated based on the adjusted set of rate-limited objects or rate limiting level, and then sent to the forwarding plane of the target interface. For example, when it is necessary to expand the set of rate-limited objects, the new rate limiting instruction can add destination IP3 to the existing destination IP1 and destination IP2, and specify the rate limiting level and guaranteed bandwidth for each rate-limited object respectively; when it is necessary to increase the rate limiting level, the new rate limiting instruction can keep destination IP1 and destination IP2 unchanged, but adjust their corresponding rate limiting level from light rate limiting level to medium rate limiting level, and determine the corresponding allowed traffic rate and guaranteed bandwidth based on the new rate limiting level.

[0130] After receiving the adjusted rate-limiting command, the forwarding plane of the target interface can update the current rate-limiting rules based on the new rate-limiting object set and the new rate-limiting level, and continue to apply rate-limiting to the corresponding traffic according to the updated rate-limiting strategy. After the update, it continues to acquire the rate-limited traffic rate and re-determines whether the traffic still meets the surge condition for multiple consecutive sampling windows. If it still meets the condition, it can perform a rate-limiting upgrade again; if the traffic has fallen below the surge entry threshold, it will not continue to upgrade, but will enter normal monitoring state, and determine whether the subsequent gradual release condition is met according to the exit threshold.

[0131] Therefore, this embodiment establishes a dynamic feedback adjustment mechanism corresponding to the rate-limiting release process. When the traffic after rate limiting still meets the surge condition for multiple consecutive sampling windows, the original rate-limiting strategy is not simply maintained. Instead, based on the current distribution of abnormal traffic, the rate limiting is further strengthened by expanding the set of rate-limiting objects or increasing the rate-limiting level. When the traffic after rate limiting no longer meets the surge condition, the rate-limiting upgrade is stopped, and subsequent exit conditions determine whether to gradually lift the rate limit. This enables the rate-limiting strategy to be dynamically adjusted according to the actual traffic changes after rate limiting, achieving a closed-loop adjustment process of enhanced control when the abnormality continues, stopped upgrading when the abnormality is alleviated, and gradually released when the abnormality continues to recover, thereby improving the adaptability and stability of abnormal traffic control in the cellular IoT core network.

[0132] Specifically, in this embodiment of the application, when the rate limiting upgrade conditions are met, the rate limiting strategy of the interface object is adjusted, including: Reacquire the original sampled packets within the sampling time window corresponding to the rate limit upgrade condition, and perform parallel statistics on multiple traffic feature dimensions based on the reacquired original sampled packets to redetermine the traffic object and traffic contribution corresponding to each traffic feature dimension. Based on the traffic objects and traffic contribution corresponding to each of the redefined traffic feature dimensions, the initial set of rate-limiting objects and the target traffic feature dimensions are redefined. If there is a traffic object in the newly determined initial set of speed limit objects that is not included in the currently effective set of speed limit objects, the traffic object is added to the currently effective set of speed limit objects to expand the set of speed limit objects. If the newly determined initial set of speed-limited objects is consistent with the currently effective set of speed-limited objects, the speed limit level is increased, and the speed limit of the set of speed-limited objects is applied according to the increased speed limit level and the minimum bandwidth.

[0133] In detail, in some embodiments of this application, after determining that the rate limiting upgrade conditions are met, the rate limiting intensity is not directly increased for the currently effective rate limiting object set. Instead, the original sampled packets within the sampling time window corresponding to the rate limiting upgrade conditions are reacquired, and based on the reacquired original sampled packets, parallel statistics are performed on multiple traffic feature dimensions such as protocol, application, port, source IP, and destination IP to redetermine the traffic objects and traffic contribution corresponding to each of the traffic feature dimensions. The reason for this setting is that the traffic composition of a traffic surge event may change after a rate limiting process. For example, the initial rate limiting objects mainly target two destination IPs. After the rate limiting is executed, the original abnormal traffic may be suppressed, but traffic on other destination IPs, source IPs, or other ports that were not rate-limited may further become the main source of traffic. Therefore, re-performing statistics on multiple traffic feature dimensions before the rate limiting upgrade can avoid continuing to rate limit based on the changed traffic composition, thereby enabling subsequent rate limiting upgrades to be implemented based on the current actual abnormal traffic sources.

[0134] For example, assuming the historical traffic baseline for the target interface's uplink direction is 100Mbps, and the traffic rate corresponding to the sudden increase threshold is 200Mbps, a traffic surge event is determined when the smoothed traffic rate for multiple consecutive sampling windows in the uplink direction exceeds 200Mbps. Subsequently, based on the statistical results of the original sampled packets, destination IP1 and destination IP2 in the destination IP traffic feature dimension are identified as the main sources of abnormal traffic. Destination IP1 contributes 42% of the traffic, and destination IP2 contributes 30%, with their combined contribution reaching 72%, exceeding the preset contribution threshold of 70%. Since destination IP1 and destination IP2 alone reach the preset contribution threshold, the destination IP traffic feature dimension is determined as the target traffic feature dimension, and destination IP1 and destination IP2 are identified as the initial rate-limiting object set. After confirming the aforementioned rate-limiting object set and anti-jitter confirmation, destination IP1 and destination IP2 are determined as the currently effective rate-limiting object set, and corresponding rate limits are applied to destination IP1 and destination IP2. After implementing the above rate limits, the uplink traffic rate continues to be monitored. Assume the traffic rate after rate limiting is 215Mbps, 225Mbps, and 230Mbps in three consecutive sampling windows. Since the traffic rate in all three sampling windows is still higher than 200Mbps, it is determined that the traffic after rate limiting still meets the surge condition, and further, the rate limiting escalation condition is met. At this point, it cannot be simply assumed that destination IP1 and destination IP2 are still the primary sources of abnormal traffic. Instead, the original sampled packets corresponding to the rate limiting escalation condition in the three sampling windows are re-acquired, and parallel statistics are performed on multiple traffic characteristic dimensions such as protocol, application, port, source IP, and destination IP.

[0135] For example, after recalculation, it was found that the current traffic corresponding to destination IP1 has decreased from a relatively high level before rate limiting to a relatively low level, with its traffic contribution being only 20%; the traffic contribution corresponding to destination IP2 has decreased to 15%; while destination IP3, which was not previously included in the currently effective rate-limited object set, has seen its traffic contribution rise to 40%, destination IP4's traffic contribution is 8%, and the combined traffic contribution of other destination IPs is 17%. After accumulating the traffic contribution from high to low, the cumulative traffic contribution corresponding to destination IP3 and destination IP1 is 60%. Adding destination IP2 further increases the cumulative traffic contribution to 75%, exceeding the preset contribution threshold of 70%. Therefore, the redefined initial rate-limited object set includes destination IP3, destination IP1, and destination IP2. Compared to the currently effective rate-limited object set, the redefined initial rate-limited object set includes destination IP3.

[0136] In this situation, it indicates that the abnormal traffic after the current rate limiting has not been completely eliminated, but rather a new major traffic source has emerged, and the original rate-limiting object set can no longer fully cover the current major abnormal traffic. Therefore, destination IP3, which exists in the newly determined initial rate-limiting object set but is not included in the currently effective rate-limiting object set, is added to the currently effective rate-limiting object set. This expands the currently effective rate-limiting object set from destination IP1 and destination IP2 to destination IP1, destination IP2, and destination IP3, and a new rate-limiting instruction is generated according to the adjusted rate-limiting object set. The rate-limiting instruction may include information such as the target interface, rate-limiting direction, traffic characteristic dimension corresponding to the rate-limiting object, the adjusted rate-limiting object set, the current rate-limiting level, and the corresponding minimum bandwidth. The generated rate-limiting instruction is then sent to the forwarding plane of the target interface, so that the forwarding plane simultaneously performs rate limiting on destination IP1, destination IP2, and destination IP3.

[0137] Using the above method, even if rate limiting reduces the traffic corresponding to the original rate-limited objects while increasing the relative contribution of other traffic objects, the main sources of newly added abnormal traffic can be identified in a timely manner by re-acquiring the original sampled packets and re-performing multi-dimensional parallel statistics. For example, a large amount of IoT terminal reported traffic, originally carried by destination IP1 and destination IP2 respectively, is suppressed after rate limiting is implemented, while destination IP3, corresponding to another backend server, continues to receive a large amount of reported traffic from IoT terminals. In this case, the traffic contribution of destination IP3 will be relatively increased. By adding destination IP3 to the currently effective rate-limited object set, the problem of failing to effectively control the remaining abnormal traffic by only continuously limiting destination IP1 and destination IP2 can be avoided.

[0138] On the other hand, if the newly determined initial set of rate-limited objects is consistent with the currently effective set of rate-limited objects, it indicates that the main source of the current abnormal traffic has not changed substantially after the re-statistical analysis, and the current set of rate-limited objects can still cover the main traffic objects required to reach the preset contribution threshold. In this case, if the traffic rate after rate limiting still meets the surge condition for multiple consecutive sampling windows, it indicates that although the current rate-limited objects are correctly selected, the current rate-limiting intensity is insufficient to reduce the abnormal traffic to the target range. Therefore, it is not necessary to further expand the set of rate-limited objects; instead, the rate-limiting level should be increased.

[0139] For example, assuming the currently effective rate-limiting object set is still destination IP1 and destination IP2, after re-acquiring the original sampled packets corresponding to the rate-limiting upgrade conditions, and through parallel statistics across multiple traffic characteristic dimensions, it is still determined that destination IP1 and destination IP2 are the minimum traffic objects required to achieve a cumulative traffic contribution of 70%, and the re-determined initial rate-limiting object set is completely consistent with the currently effective rate-limiting object set. Furthermore, assuming the cumulative traffic contribution corresponding to destination IP1 and destination IP2 reaches 85%, but under the current rate-limiting level, the uplink traffic rate after rate limiting remains at 210Mbps, 218Mbps, and 225Mbps for three consecutive sampling windows, all exceeding the 200Mbps surge threshold. Therefore, it can be determined that the main source of the current abnormal traffic is still destination IP1 and destination IP2, and there is no situation requiring additional rate-limiting objects to cover the abnormal traffic. The current problem mainly lies in the insufficient rate-limiting strength of the existing rate-limiting level.

[0140] Therefore, if the newly determined initial rate-limiting object set is consistent with the currently effective rate-limiting object set, the current rate-limiting level is increased. For example, if the pre-set rate-limiting levels include observation, light rate-limiting, moderate rate-limiting, and severe rate-limiting, and the currently effective rate-limiting level is light rate-limiting, then if it is determined that the rate-limiting upgrade conditions are met and the newly determined initial rate-limiting object set remains unchanged, the rate-limiting level can be increased from light rate-limiting to moderate rate-limiting, and rate-limiting can continue to be applied to destination IP1 and destination IP2. Simultaneously, the corresponding rate-limiting rate and guaranteed bandwidth are re-determined based on the increased rate-limiting level, and a new rate-limiting instruction is generated according to the increased rate-limiting level and the guaranteed bandwidth, and the rate-limiting instruction is sent to the forwarding plane of the target interface.

[0141] For example, suppose destination IP1 and destination IP2 are currently being rate-limited at a light rate-limiting level. The rate-limited rate for each target still allows a relatively high proportion of original traffic to pass through, while a corresponding minimum bandwidth is set to ensure that the rate-limited traffic is not completely blocked. If a re-analysis reveals that destination IP1 and destination IP2 are still the main sources of abnormal traffic, and their cumulative traffic contribution reaches 85%, but the traffic after rate-limiting still continues to exceed the surge entry threshold, then the rate-limiting level can be increased to a medium rate-limiting level. After increasing the rate-limiting level, the rate-limited rates for destination IP1 and destination IP2 can be recalculated according to the rate-limiting parameters corresponding to the medium rate-limiting level, while retaining the preset minimum bandwidth. This ensures that the traffic corresponding to destination IP1 and destination IP2 can still pass through the target interface at a rate no less than the minimum bandwidth, thereby suppressing abnormal traffic while avoiding complete blocking of related IoT services.

[0142] It should be noted that expanding the set of rate-limited objects and increasing the rate-limit level correspond to two different abnormal traffic change scenarios. If, after re-counting, the newly determined initial set of rate-limited objects contains traffic objects not included in the currently effective set of rate-limited objects, it indicates that the main source of abnormal traffic has spread or shifted. In this case, adding rate-limited objects will allow the rate-limiting scope to cover the new main source of abnormal traffic. If, after re-counting, the newly determined initial set of rate-limited objects is the same as the currently effective set of rate-limited objects, it indicates that the main source of abnormal traffic remains stable. In this case, continuing to add rate-limited objects will not solve the main problem; instead, the rate-limit level should be increased to strengthen the traffic control intensity for the existing rate-limited objects.

[0143] For example, suppose the currently effective rate-limiting target set includes destination IP1 and destination IP2, while the initial rate-limiting target set obtained after the rate-limiting upgrade includes destination IP1, destination IP2, and destination IP3. Since destination IP3 is not included in the currently effective rate-limiting target set, the rate-limiting upgrade is prioritized by expanding the rate-limiting target set. Conversely, if the initial rate-limiting target set obtained after the recalculation still includes destination IP1 and IP2, and both are still all traffic objects required to reach the preset contribution threshold, it indicates that the current rate-limiting target selection is still valid. In this case, the rate-limiting intensity is increased by raising the rate-limiting level. Therefore, the rate-limiting upgrade process can select the appropriate adjustment method based on the actual changes in the abnormal traffic composition, rather than using a fixed rate-limiting upgrade method.

[0144] After expanding the rate-limiting target set or increasing the rate-limiting level, the regenerated rate-limiting command continues to be sent to the forwarding plane of the target interface for execution, and the traffic rate in the direction corresponding to the traffic surge event after rate limiting continues to be monitored. If the adjusted traffic rate no longer meets the surge condition for multiple consecutive sampling windows, the rate-limiting upgrade stops, and the subsequent exit condition judgment is entered; if the adjusted traffic rate still meets the surge condition for multiple consecutive sampling windows, the original sampled packets in the corresponding sampling time window can be obtained again, the main traffic object of the current abnormal traffic can be re-determined, and the rate-limiting target set can be further expanded or the rate-limiting level can be increased. This forms a dynamic rate-limiting process of re-identification when abnormal traffic continues—expanding the rate-limiting target set or increasing the rate-limiting level according to the identification result—continuing monitoring—stopping the upgrade after the anomaly is relieved, so that the rate-limiting strategy can be adjusted with the changes in the composition and intensity of abnormal traffic in the cellular IoT core network.

[0145] In some embodiments of this application, the historical traffic baselines corresponding to the uplink and downlink directions are determined based on historical traffic data for the corresponding directions. Specifically, this includes: acquiring historical traffic rates within the same weekday and clock minute window as the current sampling time within a preset historical time period, calculating the arithmetic mean of these historical traffic rates, and determining the calculated arithmetic mean as the historical traffic baseline for the corresponding direction; if the historical traffic data within the preset historical time period is insufficient, calculating the arithmetic mean of the historical traffic rates based on existing historical data, and determining the calculated arithmetic mean as the historical traffic baseline for the corresponding direction. For example, if the current time is Monday 10:30, priority is given to calculating the traffic within multiple past Monday 10:30 time windows in the historical data, rather than simply averaging all traffic over a past period. This allows the historical traffic baseline to better reflect the periodic and time-specific normal traffic characteristics. Furthermore, considering the initial stage of system operation or the absence of historical data, if there is insufficient complete historical data within the preset historical time period, complete historical time data is not mandatory; instead, the arithmetic mean of existing historical data is directly used as the historical traffic baseline.

[0146] In some embodiments of this application, the uplink surge condition further includes a preset ratio in which the smoothed flow rate corresponding to the uplink direction is greater than or equal to the rated maximum bandwidth of the target interface in the uplink direction, and the downlink surge condition further includes the preset ratio in which the smoothed flow rate corresponding to the downlink direction is greater than or equal to the rated maximum bandwidth of the target interface in the downlink direction. The uplink surge condition is that the smooth flow rate corresponding to the uplink direction simultaneously satisfies the product condition of the historical flow baseline corresponding to the uplink direction and the surge entry threshold corresponding to the uplink direction, as well as the preset ratio condition of the rated maximum bandwidth of the uplink direction. The downlink surge condition is that the smooth flow rate corresponding to the downlink direction simultaneously satisfies the product condition of the historical flow baseline corresponding to the downlink direction and the surge entry threshold corresponding to the downlink direction, as well as the preset ratio condition of the rated maximum bandwidth of the downlink direction.

[0147] Specifically, the multiple traffic feature dimensions described in this embodiment include protocol traffic feature dimensions, application traffic feature dimensions, port traffic feature dimensions, source IP traffic feature dimensions, and destination IP traffic feature dimensions. The port traffic feature dimensions statistically analyze both source and destination ports, and the IP traffic feature dimensions statistically analyze both source and destination IPs. Furthermore, the traffic objects corresponding to the protocol traffic feature dimensions, application traffic feature dimensions, and port traffic feature dimensions are each their respective category of traffic objects, and a corresponding historical traffic baseline is maintained independently for each category of traffic object. The traffic increment corresponding to the traffic object is determined based on the difference between the current traffic rate of the traffic object of the category and the historical traffic baseline corresponding to the traffic object of the category.

[0148] Optionally, in some embodiments of this application, for the traffic objects corresponding to the source IP traffic feature dimension and the destination IP traffic feature dimension, the corresponding historical traffic baseline is determined based on the occurrence of the traffic object in the historical high-contribution object record, specifically including: If the traffic object did not previously appear in the historical high-contribution object record, the historical traffic baseline corresponding to the traffic object is set to zero, and the current traffic of the traffic object is used as the corresponding traffic increment. If the traffic object previously appeared in the historical high-contribution object record, the historical traffic baseline corresponding to the traffic object is determined based on the average traffic of the traffic object within the historical time window, and the corresponding traffic increment is determined based on the difference between the current traffic of the traffic object and the historical traffic baseline. In other words, prior to the current traffic surge event, traffic objects and traffic contribution were analyzed for historical traffic surge events, and the high-contribution traffic objects identified in the historical traffic surge events and their related historical traffic information were recorded, forming the historical high-contribution object record. Therefore, this record is essentially a retention of the historical analysis results of traffic objects that previously contributed significantly to abnormal traffic in past traffic surge events, used to establish object-level historical baselines when subsequent traffic surges occur again. Based on this, for source IP or destination IP traffic objects identified in the current traffic surge event, it can be first queried whether the traffic object appears in the historical high-contribution object record. If the traffic object has never been identified as a high-contribution object before, it indicates a lack of valid historical traffic references for that object. Therefore, its historical traffic baseline is set to zero, and all of the object's current traffic is considered as traffic increment. If the traffic object has already appeared in the historical high-contribution object record, its average traffic within the historical time window can be used as its historical traffic baseline, and the difference between the current traffic and this historical traffic baseline is determined as the traffic increment. Through this process, for newly emerging abnormal traffic objects, the new contribution formed by all their current traffic can be quickly identified. For high-contribution objects that have repeatedly appeared, their current traffic is not simply considered abnormal; instead, it is compared with the object's own historical average traffic to extract the true traffic increment, thus making the subsequently calculated traffic contribution more accurate.

[0149] In some embodiments of this application, the rate limiting level includes an observation level, a mild rate limiting level, a moderate rate limiting level, and a severe rate limiting level, and the rate limiting level is determined based on the traffic surge multiple in the direction corresponding to the traffic surge event; wherein, if the traffic surge multiple is within a first preset range, it is determined to be an observation level; if the traffic surge multiple is within a second preset range, it is determined to be a mild rate limiting level; if the traffic surge multiple is within a third preset range, it is determined to be a moderate rate limiting level; and if the traffic surge multiple reaches a fourth preset range, it is determined to be a severe rate limiting level. When the rate limiting level is moderate, the traffic rate corresponding to the rate limiting object is limited to 50% of the traffic rate before rate limiting; when the rate limiting level is severe, the traffic rate corresponding to the rate limiting object is limited to 20% of the current traffic rate corresponding to the rate limiting object at the time the rate limiting determination is triggered, and a minimum bandwidth is set for the rate limiting object to ensure that the traffic rate corresponding to the rate limiting object is not lower than the minimum bandwidth.

[0150] The guaranteed bandwidth is determined based on the traffic rate of the traffic feature dimension corresponding to the speed-limited object before the speed limit is applied, and the guaranteed bandwidth is a preset proportion of the traffic rate of the traffic feature dimension before the speed limit is applied.

[0151] Optionally, in some embodiments of this application, after determining the set of rate-limiting objects, it is determined whether the traffic objects in the set of rate-limiting objects exist in a pre-maintained object historical feature database; if the traffic object does not exist in the object historical feature database, the deep sampling message corresponding to the traffic object is asynchronously obtained, and the source analysis of the traffic object is performed based on the deep sampling message to generate the corresponding source tracing result; wherein, the source tracing process is executed in parallel with the generation and issuance process of the rate-limiting instruction. The object historical feature database is used to record the first appearance time and recent activity of traffic objects corresponding to each traffic feature dimension; after determining the set of rate-limiting objects, the traffic objects in the set of rate-limiting objects are written into the object historical feature database, or the historical record of the traffic objects in the object historical feature database is updated.

[0152] In other embodiments of this application, the determination of the historical traffic baseline includes: acquiring the traffic rate corresponding to multiple historical sampling windows for both the uplink and downlink directions, and determining an initial historical traffic baseline for the corresponding direction based on the traffic rate corresponding to the multiple historical sampling windows; if the traffic rate corresponding to the historical sampling window satisfies the surge condition for the corresponding direction, identifying the historical sampling window that satisfies the surge condition as an abnormal sampling window, and excluding the traffic rate corresponding to the abnormal sampling window when determining the historical traffic baseline; and updating the historical traffic baseline for the corresponding direction based on the traffic rate corresponding to the historical sampling window after excluding the abnormal sampling window.

[0153] In other embodiments of this application, after determining the traffic surge events in the uplink and downlink directions respectively, it can be further determined whether the traffic surge events in the uplink and downlink directions belong to related traffic surge events. Specifically, the occurrence time of the traffic surge events in the uplink and downlink directions is recorded respectively, and a correlation judgment is made based on the time interval between the occurrence times of the two traffic surge events. The occurrence time of the traffic surge event can be determined as the time of the sampling window when the surge condition is first met in the corresponding direction, or it can be determined based on the sampling window when multiple consecutive sampling windows meet the surge condition. By adopting a unified method for determining the event occurrence time, the traffic surge events in the uplink and downlink directions can have a comparable time reference. For example, if the sampling window of the target interface is 1 second, when multiple consecutive sampling windows in the uplink direction meet the uplink surge condition, the sampling window when the uplink surge condition is first met is determined as the occurrence time of the uplink traffic surge event; similarly, when multiple consecutive sampling windows in the downlink direction meet the downlink surge condition, the sampling window when the downlink surge condition is first met is determined as the occurrence time of the downlink traffic surge event. Assuming that the upward traffic surge condition is first met at 10:00:05 and the downward traffic surge condition is first met at 10:00:07, then the traffic surge events in the two directions are 2 seconds apart in time.

[0154] A pre-set association time interval is used, for example, 5 seconds. The time interval between traffic surge events in the uplink and downlink directions is compared with this association time interval. When the time interval between two traffic surge events does not exceed 5 seconds, the traffic surge events in both directions are identified as associated traffic surge events; when the time interval between two traffic surge events exceeds 5 seconds, the two traffic surge events are processed as independent traffic surge events. The association time interval can be pre-set according to the business traffic interaction characteristics of the target interface, the sampling window length, and the occurrence pattern of historical abnormal traffic, so that uplink and downlink surge events that are close in time can be identified as associated anomalies that may belong to the same business interaction process.

[0155] For example, in a cellular IoT core network, after a batch of IoT terminals sends a large amount of uplink data to the core network, the corresponding service processing in the core network may generate downlink response data within a short period of time. Therefore, when a surge in uplink traffic is followed by a surge in downlink traffic within a short period of time, the surges in both directions may not be two independent abnormal traffic events, but rather the traffic manifestations of the same service interaction process in both directions. By performing time correlation analysis on the traffic surge events in both directions, such time-correlated abnormal traffic events can be identified.

[0156] It's important to note that after determining that the traffic surge events in both the uplink and downlink directions are related traffic surge events, the uplink and downlink directions are not merged into a single traffic direction for unified rate limiting. Instead, separate rate limiting strategies are determined for each direction. In other words, related traffic surge events are used to establish the correlation between abnormal events in the two directions, while the independence of the uplink and downlink directions is maintained during actual rate limiting. This prevents abnormal traffic in one direction from causing normal traffic in the other direction to be restricted using the same rate limiting parameters.

[0157] Specifically, for the uplink direction, the uplink traffic objects and their respective traffic contributions can be determined based on the original sampled packets. Then, the set of uplink rate-limiting objects can be determined based on these traffic contributions. For example, in a related traffic surge event, analysis of the original sampled packets in the uplink direction reveals that devices A, B, and C generated the main abnormal traffic. Devices A and B have higher traffic contributions, and their cumulative traffic contributions have reached a preset contribution threshold. Therefore, devices A and B can be identified as uplink rate-limiting objects, and their rates can be limited according to a pre-determined uplink rate-limiting level and minimum bandwidth. Simultaneously, for the downlink direction, the original sampled packets can be analyzed independently. For example, if analysis determines that devices A, B, and D generated the main downlink abnormal traffic, and that the cumulative traffic contribution of devices A, B, and D reached a preset contribution threshold, then devices A, B, and D can be identified as downlink rate-limiting targets. Rate limits can then be applied to devices A, B, and D based on pre-determined downlink rate-limiting levels and guaranteed bandwidth. Therefore, although uplink and downlink traffic surges are identified as related traffic surges, the sets of rate-limiting targets, rate-limiting levels, and guaranteed bandwidths for the two directions can be different.

[0158] For example, in a certain target interface, the historical uplink traffic is relatively low, while the normal downlink traffic is relatively high. When an uplink traffic surge occurs due to a concentrated data transmission from abnormal terminals, and a downlink traffic surge occurs simultaneously due to a corresponding service response, the two directions can be identified as related traffic surge events. In this case, for the uplink direction, devices A and B, which generate the main abnormal traffic, can be identified as rate-limiting targets and rate-limited using the first rate-limiting level. For the downlink direction, devices A, B, and D can be identified as rate-limiting targets and rate-limited using a second rate-limiting level different from the first rate-limiting level, while reserving corresponding minimum bandwidth for normal services in both directions. This approach can both suppress related abnormal traffic and implement differentiated rate limiting based on the different traffic characteristics of the two directions.

[0159] Furthermore, after the rate limit takes effect, the flow rates in both the uplink and downlink directions are still monitored separately, and the effectiveness of the rate limit in each direction is assessed. For example, if the uplink flow rate has returned to normal after the rate limit, but the downlink flow rate still meets the surge condition for multiple consecutive sampling windows, the rate limit upgrade can be applied only to the downlink direction. This could involve expanding the set of downlink rate limit targets or increasing the downlink rate limit level, without increasing the uplink rate limit level. Conversely, if the downlink flow rate meets the exit condition, the rate limit can be gradually lifted only to the downlink direction according to a preset release step size, while the uplink direction maintains its current rate limit level based on its own flow status.

[0160] By employing the above methods, abnormal traffic detection and rate limiting can be implemented separately in the uplink and downlink directions. Furthermore, a temporal correlation between traffic surge events can be introduced, allowing sequential uplink and downlink traffic surges within a short period to be identified as correlated abnormal traffic events. Simultaneously, the independence of the two directions in terms of rate limiting targets, rate limiting levels, minimum bandwidth, and rate limiting escalation and release processes is preserved. This approach enables the identification of correlated abnormal traffic while avoiding excessive rate limiting of normal traffic, and allows for differentiated and dynamic rate limiting control based on the actual abnormal traffic characteristics in the uplink and downlink directions.

[0161] Next, taking a target interface in the cellular IoT core network as an example, the specific processing procedure of the abnormal traffic detection and rate limiting method described in this application will be explained. The target interface can be a network interface used to carry data interaction between multiple IoT terminals and the core network. The uplink and downlink traffic rate data of the target interface are continuously acquired, and the uplink and downlink traffic rate data are smoothed respectively to reduce the impact of instantaneous traffic fluctuations on the anomaly judgment result. In this embodiment, it is assumed that the historical traffic baseline corresponding to the uplink direction of the target interface is 100Mbps, and the historical traffic baseline corresponding to the downlink direction is 200Mbps. The threshold for traffic surges in the uplink and downlink directions is set to 1.5, that is, when the smoothed traffic rate in a certain direction reaches more than 1.5 times the corresponding historical traffic baseline, and this condition is met for multiple consecutive sampling windows, a traffic surge in that direction is determined to have occurred.

[0162] For example, if the smoothed uplink traffic rate of the target interface is 165Mbps, 172Mbps, and 180Mbps in three consecutive sampling windows within a certain time period, and the traffic rate in each of the three sampling windows is greater than or equal to 100Mbps × 1.5 = 150Mbps, then an uplink bandwidth surge is determined to have occurred at the target interface, and a corresponding traffic surge event is established for this uplink bandwidth surge, for example, assigning event number E20260909001 to this event. Simultaneously, assuming the smoothed downlink traffic rate of the target interface is 320Mbps, 335Mbps, and 340Mbps in three consecutive sampling windows, and the traffic rate in each of the three sampling windows is greater than or equal to 200Mbps × 1.5 = 300Mbps, then a downlink bandwidth surge is also determined to have occurred at the target interface, and another traffic surge event is established for this downlink bandwidth surge, for example, assigning event number E20260909002 to this event. In this scenario, although uplink and downlink bandwidth surge events correspond to the same target interface, they are managed as two independent traffic surge events, each maintaining its own event status, start time, duration, and processing progress. For example, while uplink bandwidth surge event E20260909001 has entered the abnormal traffic source analysis stage, downlink bandwidth surge event E20260909002 can still independently undergo traffic object analysis and rate limiting. This prevents the abnormal handling process in one direction from blocking the abnormal handling process in another direction, allowing multiple abnormal traffic surges on the same interface to be processed simultaneously.

[0163] The following explanation uses the upstream bandwidth surge event E20260909001 as an example. After identifying the upstream bandwidth surge event, the original sampled data packets within the sampling time window corresponding to the traffic surge event are obtained, and the original sampled data packets are analyzed simultaneously across four traffic feature dimensions: protocol, application, port, and IP. At the protocol dimension, traffic corresponding to different protocols is statistically analyzed based on the protocol field in the original sampled data packets; at the application dimension, traffic corresponding to different applications is statistically analyzed based on the application identification results corresponding to the original sampled data packets; at the port dimension, traffic corresponding to different ports is statistically analyzed based on the source and destination ports in the original sampled data packets; at the IP dimension, traffic corresponding to different IPs is statistically analyzed based on the source and destination IP addresses in the original sampled data packets. These four traffic feature dimensions can be analyzed simultaneously, and each dimension yields corresponding traffic object analysis results.

[0164] After obtaining the traffic statistics results for each traffic feature dimension, the traffic contribution of each traffic object is further determined. For example, for a traffic object in a certain traffic feature dimension, the current traffic of that traffic object within the sampling time window corresponding to the current traffic surge event is obtained. Based on the historical high-contribution object records formed by historical traffic surge events that have occurred and been analyzed before the current traffic surge event, the historical traffic baseline corresponding to that traffic object is determined. When the traffic object has not previously appeared in the historical high-contribution object records, the historical traffic baseline of that traffic object can be set to zero, and the current traffic can be used as the traffic increment of that traffic object. When the traffic object has previously appeared in the historical high-contribution object records, the historical traffic baseline of that traffic object can be determined based on the historical traffic information in the historical high-contribution object records, and the traffic increment of that traffic object can be determined by the difference between the current traffic and the historical traffic baseline. Subsequently, the traffic contribution of each traffic object is determined based on the proportion of the traffic increment corresponding to each traffic object to the total traffic increment of the current traffic surge event.

[0165] For example, the abnormal traffic increase corresponding to this surge in uplink traffic is 80 Mbps. In the protocol-level analysis, the current traffic for the MQTT protocol increased by 45 Mbps compared to its historical traffic baseline, HTTP by 20 Mbps, TCP by 8 Mbps, UDP by 5 Mbps, and other protocols by 2 Mbps. Therefore, the traffic contribution of MQTT, HTTP, TCP, UDP, and other protocols can be determined based on these traffic increases. The traffic contribution of the MQTT protocol is 45 / 80, or 56.25%. Similarly, in the IP-level analysis, the traffic increase corresponding to source IP address IP-A is 55 Mbps, source IP address IP-B is 20 Mbps, source IP address IP-C is 3 Mbps, and other IPs are 2 Mbps. Therefore, the traffic contribution of IP-A, IP-B, IP-C, and other IPs can be determined.

[0166] For each traffic characteristic dimension, the traffic objects within that dimension are further sorted from highest to lowest according to their traffic contribution, and the top N high-contribution traffic objects are determined based on a pre-set number N of objects. For example, in the protocol dimension, if N is pre-set to 3, the three protocols with the highest traffic contribution among MQTT, HTTP, TCP, UDP, and other protocols are selected as the high-contribution traffic objects for the protocol dimension; in the IP dimension, IP-A, IP-B, and IP-C can be selected as the high-contribution traffic objects for the IP dimension. The application and port dimensions are determined in the same way, with the top N high-contribution application objects and high-contribution port objects respectively. Thus, for the same traffic surge event, the high-contribution traffic objects and their traffic contribution values ​​corresponding to the four traffic characteristic dimensions of protocol, application, port, and IP can be obtained separately, instead of determining the source of abnormal traffic from only a single dimension.

[0167] After analyzing the four traffic characteristic dimensions—protocol, application, port, and IP—the traffic surge event E20260909001 was used as the correlation basis to aggregate and correlate the high-contribution traffic objects and their traffic contribution rates obtained from each of the four traffic characteristic dimensions. For example, the analysis revealed a correspondence between the MQTT protocol, which had a high contribution rate in the protocol dimension, and the 1883 port, which had a high contribution rate in the port dimension. Furthermore, the main traffic on port 1883 was concentrated from IP-A and IP-B, and the traffic corresponding to these IPs primarily belonged to device upgrade applications. Through this multi-dimensional correlation, it can be determined that the MQTT protocol, port 1883, device upgrade applications, and IP-A and IP-B are not independent abnormal objects, but may collectively correspond to the same abnormal traffic source in this traffic surge. Therefore, the correlation between multiple traffic characteristic dimensions can be used to further pinpoint the source of abnormal traffic.

[0168] After completing the above correlation analysis, the set of traffic objects that can cover the preset proportion of abnormal traffic is further determined. For example, assuming the preset traffic contribution threshold is 70%, it means that the cumulative traffic contribution corresponding to the determined set of rate-limiting objects must reach at least 70% of the current abnormal traffic increment. In the IP dimension, the traffic increment corresponding to IP-A is 55Mbps, accounting for 68.75% of the 80Mbps abnormal traffic increment. Selecting IP-A alone cannot reach the 70% traffic contribution threshold. When IP-B is added, the cumulative traffic increment corresponding to IP-A and IP-B reaches 75Mbps, accounting for 93.75% of the abnormal traffic increment. Therefore, IP-A and IP-B constitute the set of objects that meet the traffic contribution threshold. Similarly, in the protocol dimension, two protocol objects, MQTT and HTTP, may be needed to reach the preset traffic contribution threshold; in the port dimension, two port objects, port 1883 and port 443, may be needed; and in the application dimension, three application objects may be needed to reach the preset traffic contribution threshold.

[0169] Furthermore, the number of traffic objects required for each traffic feature dimension to reach the traffic contribution threshold is compared, and the traffic feature dimension requiring fewer traffic objects is preferentially selected as the target feature dimension. For example, the IP dimension requires 2 traffic objects to reach 93.75% of the cumulative traffic contribution, the protocol dimension requires 2 protocol objects to reach 88% of the cumulative traffic contribution, the port dimension requires 2 port objects to reach 85% of the cumulative traffic contribution, and the application dimension requires 3 application objects to reach the traffic contribution threshold. When the number of traffic objects required for the IP dimension and the protocol dimension is the same, the cumulative traffic contribution of the corresponding object sets of the two dimensions can be further compared, and the IP dimension with the higher cumulative traffic contribution is selected as the target feature dimension, thereby determining IP-A and IP-B as the initial rate-limiting object set corresponding to this traffic surge event.

[0170] After determining the initial rate-limiting object set, it can be compared with the object set determined in the previous sampling period to determine whether the current abnormal traffic source has stabilized. For example, if the initial rate-limiting object set determined in this analysis is {IP-A, IP-B}, while the object set determined in the previous sampling period is {IP-A, IP-C}, the difference between the two object sets indicates that the abnormal traffic source is still changing. In this case, the original sampled data packets of the next sampling period can be obtained, and the analysis of the four traffic feature dimensions of protocol, application, port, and IP can be performed again to redetermine the high-contribution traffic objects and the initial rate-limiting object set for each dimension. If, after the analysis of the next sampling period, the target feature dimension determined for two consecutive sampling periods is the IP dimension, and the corresponding initial rate-limiting object set is {IP-A, IP-B}, then the current abnormal traffic source can be considered relatively stable, and IP-A and IP-B can be finally determined as the rate-limiting object set.

[0171] After determining the final set of rate-limiting targets, the corresponding rate-limiting strategy is determined based on the pre-set rate-limiting levels and guaranteed bandwidth. For example, the rate-limiting level for IP-A and IP-B can be set to Level 1, and a preset guaranteed bandwidth can be set for the relevant services. Subsequently, a rate-limiting instruction is generated based on the rate-limiting target set, rate-limiting level, and guaranteed bandwidth, and the rate-limiting instruction is sent to the forwarding plane corresponding to the target interface, causing the forwarding plane to perform Level 1 rate limiting for IP-A and IP-B. In this embodiment, the generation and issuance of the rate-limiting instruction takes precedence over subsequent source tracing processing, thereby ensuring that abnormal traffic can be controlled as quickly as possible after the rate-limiting targets are identified.

[0172] For example, during multi-dimensional correlation analysis, if IP-A is found to be a suspicious object requiring further investigation, a source tracing task can be generated for IP-A to further obtain terminal information, historical communication relationships, or related business information corresponding to IP-A. However, this source tracing task is not a prerequisite for issuing rate-limiting commands. That is, rate-limiting commands can be generated and issued immediately after IP-A and IP-B are identified as rate-limiting objects, while source tracing analysis for IP-A continues to be executed in another processing flow. If the source tracing analysis requires a long processing time, the rate-limiting command will not wait for the source tracing analysis to be completed before being issued. By treating source tracing as an asynchronous process that does not block the rate-limiting execution flow, the real-time control of abnormal traffic can be avoided due to the time-consuming further investigation of abnormal objects.

[0173] To fully document the handling process of this traffic surge event, event number E20260909001 was used as a unified association identifier. The protocol dimension analysis results, application dimension analysis results, port dimension analysis results, IP dimension analysis results, the final determined set of rate-limiting objects, the corresponding rate-limiting policies, and the actual rate-limiting execution records corresponding to this traffic surge event were all associated with event number E20260909001. For example, the protocol dimension analysis result is recorded as E20260909001-protocol dimension, the application dimension analysis result as E20260909001-application dimension, the port dimension analysis result as E20260909001-port dimension, and the IP dimension analysis result as E20260909001-IP dimension. The rate-limiting object set and rate-limiting policy formed based on this are also associated with E20260909001. The first rate-limiting instruction is issued to the forwarding plane, forming the first rate-limiting execution record, which records the corresponding event number, execution time, rate-limiting object, and rate-limiting level. If a rate-limiting adjustment is subsequently performed again for the same abnormal event, the new execution record will still be associated with E20260909001. Therefore, based on an event number, the entire process of a traffic surge event—from the occurrence of the anomaly, analysis of the abnormal traffic source, determination of the rate-limiting object, formation of the rate-limiting policy, to one or more actual rate-limiting executions—can be queried.

[0174] After the initial rate limiting is completed, the traffic rate of the target interface continues to be monitored. For example, after the rate limiting is implemented, the uplink traffic drops from 180Mbps to 155Mbps. However, since the historical uplink traffic baseline is 100Mbps and the traffic surge threshold is 1.5, 150Mbps remains the threshold for determining a traffic surge. If the traffic after rate limiting remains above 150Mbps for multiple consecutive sampling windows, it indicates that the initial rate limiting failed to sufficiently suppress abnormal traffic. In this case, the rate limiting escalation conditions are met, and the abnormal traffic source analysis is re-performed for event number E20260909001.

[0175] Specifically, the original sampled data packets within the sampling window corresponding to the rate-limiting upgrade are reacquired, and traffic object analysis is performed again simultaneously across the four traffic characteristic dimensions: protocol, application, port, and IP. The high-contribution traffic objects and their traffic contribution are re-determined for each traffic characteristic dimension, and the target characteristic dimension and initial rate-limiting object set are re-determined based on the re-determined analysis results. For example, if IP-A and IP-B were identified as the main sources of abnormal traffic during the first rate-limiting, but re-analysis after rate-limiting reveals that IP-A still contributes significantly, while the original IP-B traffic has decreased significantly, and the newly emerging IP-C generates a high traffic contribution, then the rate-limiting object set can be adjusted from {IP-A, IP-B} to {IP-A, IP-C}, or IP-C can be added to the current effective rate-limiting object set if preset conditions are met. At this point, a new rate-limiting instruction is generated based on the re-determined object set, forming the second rate-limiting execution record corresponding to event number E20260909001.

[0176] If, after reanalysis, IP-A and IP-B are found to remain the primary sources of abnormal traffic, and the current rate-limiting object set does not need to be changed, but the current Level 1 rate limiting still cannot suppress the abnormal traffic, then the rate-limiting object set can be kept unchanged, and the rate limiting level can be raised from Level 1 to Level 2. The rate-limiting instruction can then be regenerated based on the rate-limiting parameters and guaranteed bandwidth corresponding to Level 2. For example, the first execution record corresponds to "IP-A, IP-B + Level 1 rate limiting," and the second execution record corresponds to "IP-A, IP-B + Level 2 rate limiting." In this way, the rate-limiting object set can be adjusted when the source of abnormal traffic changes, and the rate limiting level can be raised when the source of abnormal traffic remains stable but the original measures are insufficient, thereby achieving dynamic escalation of measures to address persistent abnormal traffic.

[0177] After the rate limiting is upgraded, the post-limiting traffic rate continues to be monitored. For example, after a level 2 rate limiting is implemented, the uplink traffic drops to 115Mbps, and for multiple consecutive sampling windows, the traffic rate is less than or equal to the preset rate limiting removal threshold. Assuming the historical uplink traffic baseline is 100Mbps and the preset removal threshold is 1.2, when the traffic rate for multiple consecutive sampling windows is less than or equal to 120Mbps, it can be determined that the rate limiting removal condition is met. At this point, the rate limiting is not immediately and completely lifted, but the rate limiting level is gradually reduced according to the preset release step size. For example, the level 2 rate limiting is first adjusted to level 1 rate limiting. After continuing to monitor multiple sampling windows, if the traffic still meets the removal condition, the rate limiting level is further reduced until the rate limiting is completely lifted. Each time a rate limiting release is executed, a corresponding rate limiting execution record can be generated, and the event number E20260909001 can be associated with it.

[0178] If, during the gradual lifting of the rate limit, the traffic on the target interface increases again, and the traffic surge condition is met again for multiple consecutive sampling windows, then the abnormal traffic is reassessed, and the rate limit escalation process is triggered again. For example, if the traffic had already dropped to 115Mbps during the initial rate limit release, but then rose above 160Mbps for multiple consecutive sampling windows after further rate limit release, then new raw sampled data packets will be obtained again for event E20260909001, and traffic object analysis will be performed again based on the four traffic characteristic dimensions of protocol, application, port, and IP to relocate the source of the abnormal traffic and redetermine the rate limit object set or increase the rate limit level. Therefore, rate limit lifting is not the end of the entire process, but a dynamic state in the continuous monitoring process; once abnormal traffic reappears, the rate limit process can be re-entered.

[0179] Furthermore, to ensure that the above-mentioned multiple processing processes can be coordinated according to predetermined relationships, corresponding processing priorities can be set for different types of processing tasks. For example, uplink bandwidth surge events and downlink bandwidth surge events can be set as higher priorities to enable timely identification of anomalies; traffic object analysis of the four traffic feature dimensions of protocol, application, port, and IP can be set as processing tasks for anomaly root cause localization, and the four dimensions can be executed in parallel; rate limiting decision processing can be set to be executed only after the analysis results of the four traffic feature dimensions are completed, so that rate limiting decisions can comprehensively utilize the analysis results of multiple dimensions; rate limiting command generation and issuance can be set as higher priorities to ensure that identified abnormal traffic can be controlled in a timely manner; source tracing analysis can be set as a processing priority lower than rate limiting execution, so that source tracing analysis can continue after rate limiting execution without blocking the generation and issuance of rate limiting commands; rate limiting escalation and rate limiting deactivation can be set as subsequent processing tasks in the state of continued anomalies, triggering rate limiting enhancement or rate limiting release respectively according to the traffic state after rate limiting.

[0180] As can be seen from the above embodiments, this application does not simply perform a fixed rate limit once for a detected traffic surge, but rather establishes a complete processing procedure for a specific traffic surge event. On the same target interface, uplink and downlink traffic surges are managed as independent events, allowing anomalies in different directions to be processed in parallel. For each traffic surge event, traffic objects are analyzed from four traffic characteristic dimensions: protocol, application, port, and IP, and the top-ranked high-contribution traffic objects are determined according to their traffic contribution. After all the analysis results from multiple dimensions are completed, the analysis results from different dimensions are correlated to determine the set of rate-limiting objects that can cover the main abnormal traffic. After a rate-limiting decision is made, rate limiting is executed first, and the source tracing of suspicious objects that require further investigation is executed asynchronously. At the same time, a unified event number is used to correlate and record the occurrence of anomalies, traffic object analysis, rate-limiting decisions, and one or more rate-limiting execution processes. When the rate-limiting effect is insufficient, multi-dimensional traffic object analysis is performed again and the set of rate-limiting objects is adjusted or the rate-limiting level is increased. After the anomaly is eliminated, the rate limit is gradually released, and when the anomaly rebounds, the rate-limiting upgrade process is restarted. Therefore, the entire process forms a complete closed loop from traffic surge detection, multi-dimensional anomaly source analysis, multi-dimensional analysis result correlation, rate limiting object identification, rate limiting execution, asynchronous source tracing, continuous anomaly escalation, to gradual rate limiting removal, enabling the cellular IoT core network to perform timely, accurate, and traceable dynamic handling of continuously changing abnormal traffic.

[0181] On the other hand, embodiments of this application also provide a cellular IoT core network abnormal traffic detection and rate limiting system, including: at least one processor; and at least one memory communicatively connected to the processor, wherein the memory stores program instructions executable by the processor, and the processor can execute the cellular IoT core network abnormal traffic detection and rate limiting method as described in the above embodiments by calling the program instructions.

[0182] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make modifications, alterations, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for abnormal traffic detection and rate limiting in a cellular Internet of Things (IoT) core network, characterized in that, include: The uplink and downlink traffic rate data of the target interface are obtained respectively, and the traffic rate data is smoothed to obtain the smoothed traffic rate in the corresponding direction. Based on the historical flow baselines and surge entry thresholds corresponding to the uplink and downlink directions, independent surge detection is performed on the smooth flow rate in the corresponding directions, and a flow surge event is determined when the surge condition is met in multiple consecutive sampling windows in the corresponding direction. Obtain the original sampled packets corresponding to the traffic surge event, and analyze multiple traffic feature dimensions in parallel based on the original sampled packets to determine the traffic object and traffic contribution corresponding to each traffic feature dimension; For each of the traffic characteristic dimensions, the cumulative traffic contribution is determined according to the corresponding traffic contribution, and based on the comparison result of the cumulative traffic contribution and the preset contribution threshold, the rate limiting strategy corresponding to the traffic surge event is determined, and the rate limiting command corresponding to the rate limiting strategy is sent to the forwarding plane of the target interface for rate limiting. The flow rate in the direction corresponding to the flow surge event after the rate limit is continuously monitored, and the rate limit is gradually lifted according to the preset release step size after the flow rate meets the preset exit condition and is confirmed by multiple consecutive sampling windows.

2. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 1, characterized in that, The uplink and downlink traffic rate data of the target interface are acquired separately, and the traffic rate data is smoothed to obtain the smoothed traffic rate for the corresponding direction. Specifically, this includes: The original flow rates of the target interface in the uplink and downlink directions in the current sampling window are obtained respectively. Based on the original flow rate of the current sampling window and the smoothed flow rate of the corresponding direction in the previous sampling window, the original flow rate of the current sampling window is processed by exponential weighted moving average according to a preset smoothing coefficient to obtain the smoothed flow rate of the corresponding direction in the current sampling window. The smooth flow rate is determined according to the following formula: ； Where Rs(t) is the smoothed flow rate in the direction corresponding to the t-th sampling window, and R(t) is the original flow rate in the direction corresponding to the t-th sampling window. Let α be the smoothed flow rate in the direction corresponding to the (t-1)th sampling window, where α is a preset smoothing coefficient and 0 < α < 1.

3. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 2, characterized in that, Based on the historical traffic baselines and surge entry thresholds corresponding to the uplink and downlink directions, independent surge detection is performed on the smoothed traffic rate in the corresponding directions. When the surge condition is met in multiple consecutive sampling windows in the corresponding direction, a traffic surge event is determined, specifically including: The smooth flow rate corresponding to the uplink direction is compared with the historical flow baseline and the sudden entry threshold corresponding to the uplink direction, and the smooth flow rate corresponding to the downlink direction is compared with the historical flow baseline and the sudden entry threshold corresponding to the downlink direction, respectively. If the smooth flow rate corresponding to the upward direction satisfies the upward surge condition in multiple consecutive sampling windows, the flow surge event in the upward direction is determined. If the smooth flow rate corresponding to the downlink direction satisfies the downlink surge condition for multiple consecutive sampling windows, the downlink flow surge event is determined. The surge conditions include uplink surge conditions and downlink surge conditions; the uplink surge condition is that the smooth flow rate corresponding to the uplink direction is greater than or equal to the product of the historical flow baseline corresponding to the uplink direction and the surge entry threshold corresponding to the uplink direction; the downlink surge condition is that the smooth flow rate corresponding to the downlink direction is greater than or equal to the product of the historical flow baseline corresponding to the downlink direction and the surge entry threshold corresponding to the downlink direction.

4. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 3, characterized in that, Obtain the original sampled packets corresponding to the traffic surge event, and perform parallel analysis of multiple traffic feature dimensions based on the original sampled packets to determine the traffic objects and traffic contribution corresponding to each traffic feature dimension, specifically including: Obtain the original sampled packets within the sampling time window corresponding to the traffic surge event, and perform parallel statistics on multiple traffic feature dimensions based on the same batch of original sampled packets to determine the traffic object corresponding to each traffic feature dimension; Obtain the current traffic and historical traffic baseline corresponding to each traffic object, and determine the traffic increment corresponding to each traffic object based on the difference between the current traffic and the historical traffic baseline. Based on the traffic increment corresponding to each of the traffic objects, the traffic contribution of each of the traffic objects is determined.

5. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 4, characterized in that, For each of the aforementioned traffic characteristic dimensions, a cumulative traffic contribution is determined based on the corresponding traffic contribution level. Then, based on the comparison between the cumulative traffic contribution level and a preset contribution threshold, a rate-limiting strategy corresponding to the traffic surge event is determined. The rate-limiting command corresponding to the rate-limiting strategy is then sent to the forwarding plane of the target interface for rate limiting. Specifically, this includes: For each of the aforementioned traffic feature dimensions, the traffic objects corresponding to the traffic feature dimensions are sorted according to their corresponding traffic contribution. Then, traffic objects are selected sequentially from the sorted traffic objects, and the sum of the traffic contribution corresponding to the selected traffic objects is calculated to obtain the cumulative traffic contribution. Determine whether there is a situation where the cumulative traffic contribution corresponding to the traffic feature dimension reaches a preset contribution threshold; In the absence of a traffic feature dimension in which the cumulative traffic contribution reaches the preset contribution threshold, the rate limiting strategy is determined to be an overall interface rate limiting strategy. The overall interface rate limiting strategy is to limit the overall traffic in the direction corresponding to the target interface to within a preset multiple of the historical traffic baseline in the direction corresponding to the traffic surge event. If there is a traffic feature dimension where the cumulative traffic contribution reaches the preset contribution threshold, the rate limiting strategy is determined to be an interface object rate limiting strategy. The interface object rate limiting strategy is to limit the rate limiting object set according to the corresponding rate limiting level and the minimum bandwidth. The rate limiting object set is determined based on the traffic objects that have reached the preset contribution threshold, and the rate limiting level and the minimum bandwidth are predetermined based on the traffic surge event. A corresponding rate limiting instruction is generated based on the overall rate limiting policy of the interface or the rate limiting policy of the interface object, and the rate limiting instruction is sent to the forwarding plane of the target interface so that the forwarding plane of the target interface performs rate limiting according to the rate limiting instruction.

6. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 5, characterized in that, The set of rate-limited objects is determined based on the method used to identify traffic objects that have reached the preset contribution threshold, specifically including: When the cumulative traffic contribution corresponding to at least one of the traffic feature dimensions reaches the preset contribution threshold, the minimum number of traffic objects required to make the cumulative traffic contribution reach the preset contribution threshold for each of the traffic feature dimensions is determined, and the traffic feature dimension with the smallest required number of traffic objects is determined as the target traffic feature dimension. The traffic objects that make the cumulative traffic contribution reach the preset contribution threshold in the target traffic feature dimension are determined as the initial rate-limiting object set; when there are multiple traffic feature dimensions with the same minimum number of traffic objects, the traffic feature dimension with the higher cumulative traffic contribution is determined as the target traffic feature dimension. The initial speed limit object set and the target traffic feature dimension determined this time are compared with the initial speed limit object set and the target traffic feature dimension determined in the previous time, respectively. If the initial speed limit object set determined this time is inconsistent with the initial speed limit object set determined in the previous time, or if the target flow feature dimension determined this time is inconsistent with the target flow feature dimension determined in the previous time, the initial speed limit object set and the target flow feature dimension shall be re-determined in the next sampling period. If the initial rate-limiting object set determined this time is consistent with the initial rate-limiting object set determined previously, and the target traffic feature dimension determined this time is consistent with the target traffic feature dimension determined previously, then the initial rate-limiting object set determined this time is determined as the rate-limiting object set, and the rate-limiting instruction is generated according to the rate-limiting object set and sent to the forwarding plane of the target interface.

7. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 6, characterized in that, Continuously monitor the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and after the flow rate meets the preset exit condition and is confirmed by multiple consecutive sampling windows, gradually lift the rate limit according to the preset release step size, specifically including: Continuously acquire the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and compare the flow rate with the historical flow baseline and preset exit threshold in the direction corresponding to the flow surge event; If the flow rate in the direction corresponding to the flow surge event is less than or equal to the product of the historical flow baseline in the direction corresponding to the flow surge event and the preset exit threshold, it is determined that the direction corresponding to the flow surge event meets the exit condition. If the exit condition is met in multiple consecutive sampling windows in the direction corresponding to the traffic surge event, it is determined that the rate limit exit condition is met, and the current rate limit is reduced according to the preset release step size to gradually remove the rate limit on the set of rate limit objects. Each time the current rate limit is reduced according to the preset release step size, the flow rate in the direction corresponding to the flow surge event continues to be monitored, and if the flow rate meets the exit condition, the current rate limit is reduced according to the preset release step size until the rate limit on the set of rate-limited objects is lifted.

8. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 7, characterized in that, The method further includes continuously monitoring the flow rate in the direction corresponding to the flow surge event after the rate limit is applied, and also includes: The flow rate in the direction corresponding to the flow surge event after the speed limit is compared with the historical flow baseline in the direction corresponding to the flow surge event and the surge entry threshold; If the flow rate in the direction corresponding to the flow surge event after the rate limit is set still meets the surge condition for multiple consecutive sampling windows, it is determined that the rate limit upgrade condition is met, and the rate limit strategy of the interface object is adjusted to expand the set of rate limit objects or increase the rate limit level. A rate-limiting instruction is generated based on the adjusted rate-limiting policy of the interface object, and the rate-limiting instruction is sent to the forwarding plane of the target interface for rate limiting.

9. The method for abnormal traffic detection and rate limiting in a cellular IoT core network according to claim 8, characterized in that, Under the condition that the rate limiting upgrade is met, the rate limiting strategy of the interface object is adjusted, specifically including: Reacquire the original sampled packets within the sampling time window corresponding to the rate limit upgrade condition, and perform parallel statistics on multiple traffic feature dimensions based on the reacquired original sampled packets to redetermine the traffic object and traffic contribution corresponding to each traffic feature dimension. Based on the traffic objects and traffic contribution corresponding to each of the redefined traffic feature dimensions, the initial set of rate-limiting objects and the target traffic feature dimensions are redefined. If there is a traffic object in the newly determined initial set of speed limit objects that is not included in the currently effective set of speed limit objects, the traffic object is added to the currently effective set of speed limit objects to expand the set of speed limit objects. If the newly determined initial set of speed-limited objects is consistent with the currently effective set of speed-limited objects, the speed limit level is increased, and the speed limit of the set of speed-limited objects is applied according to the increased speed limit level and the minimum bandwidth.

10. A cellular Internet of Things (IoT) core network abnormal traffic detection and rate limiting system, characterized in that, include: At least one processor; The processor includes at least one memory communicatively connected to the processor, wherein the memory stores program instructions executable by the processor, and the processor invokes the program instructions to execute the abnormal traffic detection and rate limiting method for the cellular IoT core network as described in any one of claims 1-9.

Images