An operator throttling under the internet of things card flow estimation and self-calibration system

Abstract

The present application relates to the technical field of Internet of Things, in particular to a kind of operator flow limiting under Internet of Things card flow estimation and self-calibration system, including data acquisition module, Bluetooth communication and data transmission module, flow estimation module, data calibration and algorithm module, early warning and management module.The present application is through anti-interference connection to guarantee stable communication, hierarchical transmission strategy adapts to the flow sensitive demand in flow limiting scene, near-field offline synchronous replenishment high-speed batch data interaction, effectively solve the data transmission low consumption and high efficiency problem in the distributed deployment of Internet of Things equipment, realize equipment self-precision calibration, significantly improve the real-time, accuracy and autonomy of Internet of Things card flow management.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, specifically to a system for estimating and self-calibrating IoT card traffic under operator-limited traffic conditions. Background Technology

[0002] IoT SIM cards are embedded communication access carriers designed specifically for IoT devices. Essentially, they are SIM cards with data transmission capabilities. Their core function is to provide stable cellular network (2G / 3G / 4G / 5G / NB-IoT, etc.) access capabilities for various IoT terminals, enabling remote data interaction between devices and the cloud, and between devices themselves. They are the core communication carrier supporting the normal operation of IoT applications such as smart industry, smart security, and smart water management.

[0003] With the large-scale distributed deployment of IoT devices, the accurate measurement and efficient management of IoT SIM card traffic consumption are directly related to the control of operating costs and the stability of equipment operation in IoT projects. Current technologies suffer from several problems: IoT SIM card traffic statistics rely on operator delay bills or local coarse-grained data, leading to large statistical deviations in traffic-limiting scenarios; calibration relies on centralized servers, resulting in high maintenance costs and network coverage limitations; and data transmission struggles to balance low power consumption and high efficiency in traffic-limiting scenarios.

[0004] Based on this, the present invention provides an IoT card traffic estimation and self-calibration system under operator traffic throttling to solve the above-mentioned technical problems. Summary of the Invention

[0005] The purpose of this invention is to provide an IoT card traffic estimation and self-calibration system under operator-controlled traffic restrictions. This invention features anti-interference connectivity to ensure stable communication, a tiered transmission strategy to adapt to traffic-sensitive needs in traffic-limited scenarios, and near-field offline synchronous supplementation for high-speed batch data interaction. It effectively solves the problems of low-power and high-efficiency data transmission in distributed deployments of IoT devices. Furthermore, it relies on multi-source data fusion to provide accurate input, traffic-limiting behavior modeling to quantify potential "untransmitted" data, and high-fidelity estimation combining actual and potential data to predict trends. This overcomes the pain point of large traffic statistics deviations under operator-controlled traffic restrictions, achieving accurate measurement of real traffic consumption. Moreover, by aggregating group data through a Bluetooth mesh network, constructing a regional normal traffic benchmark using a weighted consensus algorithm, and dynamically correcting individual models through distributed calibration, it eliminates dependence on operator bills and centralized servers, enabling devices to autonomously and accurately calibrate, significantly improving the real-time performance, accuracy, and autonomy of IoT card traffic management.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] This invention provides a system for estimating and self-calibrating IoT card traffic under operator-controlled traffic throttling, comprising a data acquisition module, a Bluetooth communication and data transmission module, a traffic estimation module, a data calibration and algorithm module, and an early warning and management module, wherein:

[0008] The data acquisition module is used to collect raw data generated by IoT card data consumption and device operating status parameters.

[0009] The Bluetooth communication and data transmission module is used to establish an anti-interference and secure connection through dynamic frequency hopping and adaptive signal adjustment. It adopts a traffic-sensitive hierarchical transmission strategy and supports near-field offline high-speed mode to efficiently and low-power transmit raw traffic logs, calibration instructions and system updates.

[0010] The traffic estimation module is used to integrate device application behavior characteristics and Bluetooth collaborative sensing network status information to build a dynamic traffic estimation model under traffic limiting environment. By inferring the potential traffic that should have been transmitted but was not during the traffic limiting period, it can perform high-fidelity estimation and trend prediction of real data consumption.

[0011] The data calibration and algorithm module is used to aggregate traffic behavior data of neighboring devices through Bluetooth networking, build a group consistency benchmark, and use differential analysis and anomaly detection algorithms to autonomously identify traffic limiting interference and dynamically correct individual traffic estimation models, performing distributed self-calibration that does not rely on operator bills.

[0012] The early warning and management module monitors traffic usage in real time based on accurate calibrated estimates and issues early warnings to users when traffic approaches the throttling threshold.

[0013] The data acquisition module includes a raw traffic sniffing unit, a device status monitoring unit, and a data preprocessing unit, wherein:

[0014] The raw traffic sniffing unit is used to capture IP packet-level traffic records of IoT cards from the network protocol stack or driver layer, and obtain raw traffic data such as uplink and downlink data volume, timestamp, and communication protocol type.

[0015] The device status monitoring unit is used to collect operating parameters such as device CPU utilization, sensor working mode, and network access duration.

[0016] The data preprocessing unit is used to clean, denoise, and format and package the collected raw data.

[0017] The Bluetooth communication and data transmission module includes an anti-interference connection unit, a hierarchical transmission control unit, and an offline synchronization unit, wherein:

[0018] The anti-interference connection unit is used to maintain a stable Bluetooth connection between the device and the terminal through dynamic frequency hopping and signal strength adjustment.

[0019] The hierarchical transmission control unit is used to schedule the transmission of traffic logs and calibration instructions according to data priority.

[0020] The offline synchronization unit is used to activate the high-speed transmission channel in a near-field environment to synchronize historical data and system update packages in batches.

[0021] The hierarchical transmission control unit schedules the transmission of traffic logs and calibration commands according to data priority, as follows:

[0022] A1: Preset three-level data priority: calibration instructions are the highest priority, raw traffic logs are the medium priority, and system update packages are the low priority;

[0023] A2: Use a sliding window compression algorithm to lightweight process medium-priority data, and use a breakpoint resume mechanism for low-priority data.

[0024] A3: Real-time monitoring of the remaining data traffic of the IoT card. When the remaining data traffic is lower than the preset threshold, the three-level data transmission is automatically paused, and only the transmission channels for the highest priority and medium priority data are retained.

[0025] The traffic estimation module includes a multi-source data fusion unit, a traffic limiting behavior modeling unit, and a high-fidelity estimation unit, wherein:

[0026] The multi-source data fusion unit is used to perform spatiotemporal alignment and correlation analysis of application behavior characteristics, network status information and raw traffic data.

[0027] The traffic limiting behavior modeling unit is used to simulate the operator's traffic limiting strategy, infer and quantify the potential amount of "data that should have been transmitted but was not" caused by traffic limiting.

[0028] The high-fidelity estimation unit is used to calculate the estimated value of real data consumption by combining the actual transmitted data and the potential data volume, and to run a prediction algorithm to judge future trends.

[0029] The traffic limiting behavior modeling unit simulates the operator's traffic limiting strategy, infers and quantifies the potential amount of "untransmitted data" caused by traffic limiting, and the specific operations are as follows:

[0030] B1: Collect publicly available data throttling rule parameters from operators, including data throttling trigger thresholds. Bandwidth limit after rate limiting Average transmission bandwidth of devices before rate limiting ;

[0031] B2: Identifying Periods of Traffic Limiting: By comparing "actual transmission bandwidth suddenly drops to..." "±10% of the time" and "cumulative flow value reached" "The moment" determines the start time of traffic restriction. With end time Calculate the duration of rate limiting ;

[0032] B3: Quantifying the potential amount of "data that should have been transmitted but wasn't" The specific expression for calculation is:

[0033] ,

[0034] In the formula, This is the redundancy for data retransmission failures during the flow-limiting period.

[0035] The high-fidelity estimation unit combines the actual transmitted data and the potential data volume to calculate an estimated value of the actual data consumption, and runs a prediction algorithm to determine future trends. The specific operation is as follows:

[0036] C1: Calculate the estimated value of actual data consumption The actual amount of data transmitted based on the traffic estimation module. The potential data volume output by the flow-limiting behavior modeling unit The specific expression is:

[0037] ,

[0038] In the formula, This is a data validity coefficient, dynamically adjusted based on the device's current network signal strength; the stronger the signal, the higher the validity coefficient. The closer it is to 1.0;

[0039] C2: Determining future traffic consumption trends: Employing a sliding window algorithm with a 1-hour window period, accumulating nearly 24 windows. Data is used to construct a time series of traffic consumption; this series is then fitted using an autoregressive integral moving average model to output predicted traffic consumption values ​​for the next 12 hours. If three consecutive prediction windows If the consumption rate exceeds 15% of the average consumption rate for the current period, it is determined to be an "accelerated trend in traffic consumption"; otherwise, it is determined to be a "stable trend," and the trend results are synchronized to the early warning and management module.

[0040] The data calibration and algorithm module includes a group data aggregation unit, a consistency benchmark calculation unit, and a distributed calibration unit, wherein:

[0041] The group data aggregation unit is used to collect and aggregate traffic behavior data of devices in the vicinity via a Bluetooth mesh network.

[0042] The consensus benchmark calculation unit: based on the node consensus mechanism of the Bluetooth mesh network, it calculates the normal traffic behavior pattern of the area under the current network conditions as a benchmark through a consensus algorithm;

[0043] The distributed calibration unit is used to perform differential comparison between individual device data and group benchmarks, identify abnormal deviations, and generate calibration parameters to correct individual models.

[0044] The distributed calibration unit performs differential comparison between individual device data and the group benchmark to identify abnormal deviations and generates calibration parameters to correct individual models. The specific operations are as follows:

[0045] D1: Differential comparison between individual and group baselines: Calculates the estimated flow rate of individual devices per unit time. Consistency benchmark with the group relative deviation rate ;when If the deviation exceeds the preset threshold for three consecutive time periods, it is determined to be an abnormal deviation, and the deviation type is marked.

[0046] D2: Calibration Parameter Generation and Model Correction: Dynamic calibration coefficient k is generated based on deviation type and deviation rate. The calculation formula is as follows:

[0047] ,

[0048] In the formula, To calibrate the sensitivity coefficient, The sign for the direction of deviation. The maximum correction threshold;

[0049] The calibration coefficient k is injected into the potential data volume calculation stage of the flow estimation model to complete the real-time correction of the individual model, and the correction log is recorded and synchronized to the Bluetooth communication and data transmission module.

[0050] The early warning and management module includes a traffic monitoring unit, a policy early warning unit, and a configuration management unit, wherein:

[0051] The traffic monitoring unit is used to display the current traffic usage, remaining quota, and predicted exhaustion time in real time.

[0052] The strategy warning unit is used to trigger tiered warnings in various ways based on user-set thresholds.

[0053] The configuration management unit provides a human-machine interface, allowing users to view historical data, configure early warning rules, and manually trigger calibration processes.

[0054] Compared with the prior art, the beneficial effects of the present invention are:

[0055] This invention effectively solves the problems of low power consumption and high efficiency in data transmission during the distributed deployment of IoT devices by ensuring stable communication through anti-interference connection, adapting to traffic-sensitive needs in traffic-limiting scenarios through hierarchical transmission strategies, and supplementing high-speed batch data interaction through near-field offline synchronization. It also relies on multi-source data fusion to provide accurate input, modeling and quantifying potential "untransmitted" data in traffic-limiting behavior, and combining actual and potential data with high-fidelity estimation to predict trends. This overcomes the pain point of large traffic statistics deviations under operator traffic limiting, and achieves accurate measurement of real traffic consumption. Furthermore, by aggregating group data through Bluetooth mesh networks, constructing regional normal traffic benchmarks through weighted consensus algorithms, and dynamically correcting individual models through distributed calibration, it eliminates dependence on operator bills and centralized servers, enabling devices to autonomously and accurately calibrate, and significantly improving the real-time performance, accuracy, and autonomy of IoT card traffic management. Attached Figure Description

[0056] Figure 1 This is a system diagram of an IoT card traffic estimation and self-calibration system under operator traffic limiting according to the present invention.

[0057] Figure 2 This is a flowchart of a hierarchical transmission control unit in an IoT card traffic estimation and self-calibration system under operator traffic limiting, as described in this invention.

[0058] Figure 3 This is a flowchart of a distributed calibration unit in an IoT card traffic estimation and self-calibration system under operator traffic limiting, as described in this invention.

[0059] Explanation of icon numbers:

[0060] 100. Data Acquisition Module; 101. Raw Traffic Sniffing Unit; 102. Device Status Monitoring Unit; 103. Data Preprocessing Unit; 200. Bluetooth Communication and Data Transmission Module; 201. Anti-interference Connection Unit; 202. Hierarchical Transmission Control Unit; 203. Offline Synchronization Unit; 300. Traffic Estimation Module; 301. Multi-Source Data Fusion Unit; 302. Traffic Limiting Behavior Modeling Unit; 303. High-Fidelity Estimation Unit; 400. Data Calibration and Algorithm Module; 401. Group Data Aggregation Unit; 402. Consistency Benchmark Calculation Unit; 403. Distributed Calibration Unit; 500. Early Warning and Management Module; 501. Traffic Monitoring Unit; 502. Policy Early Warning Unit; 503. Configuration Management Unit. Detailed Implementation

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

[0062] Example:

[0063] like Figures 1-3 As shown, this embodiment provides an IoT card traffic estimation and self-calibration system under operator-limited traffic conditions, including a data acquisition module 100, a Bluetooth communication and data transmission module 200, a traffic estimation module 300, a data calibration and algorithm module 400, and an early warning and management module 500. Specifically: the data acquisition module 100 is used to collect raw data generated by IoT card traffic consumption and device operating status parameters; the Bluetooth communication and data transmission module 200 is used to establish an anti-interference secure connection through dynamic frequency hopping and signal adaptive adjustment, adopting a traffic-sensitive hierarchical transmission strategy and supporting near-field offline high-speed mode, to efficiently and with low power transmit raw traffic logs, calibration commands, and system updates; the traffic estimation module 300... 0: Used to integrate device application behavior characteristics with Bluetooth-coordinated network status information to build a dynamic traffic estimation model under traffic limiting conditions. By inferring potential traffic that should have been transmitted but wasn't during traffic limiting, it performs high-fidelity estimation and trend prediction of actual data consumption. Data calibration and algorithm module 400: Used to aggregate traffic behavior data of neighboring devices through Bluetooth networking, build a group consistency benchmark, and use differential analysis and anomaly detection algorithms to autonomously identify traffic limiting interference and dynamically correct individual traffic estimation models. It performs distributed self-calibration without relying on operator bills. Early warning and management module 500: Based on the accurate estimated value after calibration, it monitors traffic usage in real time and issues early warnings to users when the traffic limiting threshold is approached.

[0064] It should be noted that after the data acquisition module 100 collects basic data, the Bluetooth communication and data transmission module 200 realizes efficient and low-power transmission of data and commands. The traffic estimation module 300 completes high-fidelity estimation and trend prediction of real traffic based on the transmitted data. The data calibration and algorithm module 400 builds a group benchmark through Bluetooth networking and dynamically corrects the estimation model. Finally, the early warning and management module 500 realizes traffic monitoring and early warning based on the calibrated data.

[0065] In this embodiment, it should also be noted that the data acquisition module 100 includes a raw traffic sniffing unit 101, a device status monitoring unit 102, and a data preprocessing unit 103, wherein: the raw traffic sniffing unit 101 is used to capture IP packet-level traffic records of the IoT card from the network protocol stack or driver layer, and obtain raw traffic data of uplink and downlink data volume, timestamp, and communication protocol type; the device status monitoring unit 102 is used to collect operating parameters such as device CPU utilization, sensor working mode, and network access duration; the data preprocessing unit 103 is used to clean, denoise, and format and package the collected raw data.

[0066] It should be noted that the raw traffic sniffing unit 101 and the device status monitoring unit 102 collect raw traffic data and operating parameters from the network layer and the device layer, respectively. Both types of data are uniformly sent to the data preprocessing unit 103 for cleaning, noise reduction and formatting packaging to form standardized data output.

[0067] Furthermore, it should be noted that the cleaning and denoising operations in the data preprocessing unit 103 are as follows: "empty packets with a length of 0" and "invalid packets with checksum errors" are removed from the original flow data, as well as "values ​​outside the reasonable range" in the device status parameters (such as CPU utilization > 100% or absence of sensor operating mode codes); "denoising" uses "3..." "Criterion" refers to calculating the average of a certain parameter (such as the amount of uplink and downlink data within 1 minute). with standard deviation Remove excess Outliers within the range are excluded to avoid interference from extreme data in subsequent estimations. The formatted package uses JSON format, with fields including "Device ID (unique identifier)," "Collection Timestamp (yyyy-MM-dd HH:mm:ss.SSS)," "Traffic Data (including uplink bytes, downlink bytes, and protocol type list)," and "Device Status (CPU utilization, sensor operating mode code, and network access duration)." This ensures that subsequent modules can directly parse the data, reducing data format conversion overhead.

[0068] In this embodiment, it should also be noted that the Bluetooth communication and data transmission module 200 includes an anti-interference connection unit 201, a hierarchical transmission control unit 202, and an offline synchronization unit 203. Specifically: the anti-interference connection unit 201 maintains a stable Bluetooth connection between the device and the terminal through dynamic frequency hopping and signal strength adjustment; the hierarchical transmission control unit 202 schedules the transmission of traffic logs and calibration commands according to data priority; the specific operations are as follows: A1: Preset three levels of data priority: calibration commands are the highest priority, raw traffic logs are the medium priority, and system update packages are the low priority; A2: Use a sliding window compression algorithm to lightweight process medium priority data, and a breakpoint resume mechanism for low priority data; A3: Monitor the remaining traffic of the IoT card in real time. When the remaining traffic is lower than a preset threshold, automatically pause the three-level data transmission, retaining only the transmission channels for the highest and medium priority data. The offline synchronization unit 203 activates the high-speed transmission channel in a near-field environment to batch synchronize historical data and system update packages.

[0069] It should be noted that the anti-interference connection unit 201 provides basic support for establishing a stable Bluetooth connection between the device and the terminal, the hierarchical transmission control unit 202 realizes efficient data scheduling and transmission based on preset priorities and traffic status, and the offline synchronization unit 203 supplements the high-speed batch data synchronization function in near-field scenarios.

[0070] Furthermore, it should be noted that the dynamic frequency hopping in the anti-interference connection unit 201 is based on the adaptive frequency hopping algorithm of Bluetooth 5.0. It scans 23 available channels in the 2.4GHz band in real time (excluding the area restriction of channels 12-14), and selects channels with interference intensity below -85dBm to form an "available channel set" through "channel quality evaluation indicators" (such as bit error rate and signal strength stability). The channel quality is updated once every 100ms. When the current channel interference intensity exceeds the threshold, it automatically switches to the channel with the best quality in the available channel set. The "signal strength adjustment" dynamically adjusts the transmission power according to the Bluetooth RSSI value. For example, when RSSI ≥ -70dBm, the transmission power is set to 0dBm (low power), when RSSI is between -80dBm and -70dBm, it is set to 5dBm, and when RSSI < -80dBm, it is set to 10dBm, which ensures connection stability and reduces device power consumption. In A3, the remaining traffic of the IoT card is monitored in real time by reading the "cumulative used traffic" preprocessed by the data acquisition module 100 and combining it with the IoT card's "total quota" (configured by the user through the early warning and management module 500) to calculate the remaining traffic. The "preset threshold" is set to 10% of the total quota by default and can be customized by the user through the configuration management unit 503 (range 5%-20%) to meet the traffic management needs in different scenarios. The near-field environment judgment standard of the offline synchronization unit 203 is "the Bluetooth RSSI of the device and the calibration terminal is ≥-60dBm and remains stable for 3 seconds" to avoid misjudgment due to instantaneous signal fluctuations. The "high-speed transmission channel" is based on Bluetooth 5.0 LE Coded PHY mode, with a transmission rate of up to 2Mbps. During synchronization, a "multi-packet concurrent transmission" mechanism is used (5 data packets are transmitted concurrently each time, and each packet is 255 bytes in size), which greatly improves the efficiency of historical data synchronization.

[0071] In this embodiment, it should also be noted that the traffic estimation module 300 includes a multi-source data fusion unit 301, a traffic limiting behavior modeling unit 302, and a high-fidelity estimation unit 303, wherein: the multi-source data fusion unit 301 is used to perform spatiotemporal alignment and correlation analysis of application behavior characteristics, network status information, and raw traffic data; the traffic limiting behavior modeling unit 302 is used to simulate the operator's traffic limiting strategy, infer and quantify the potential amount of "should have been transmitted but not transmitted" due to traffic limiting; the specific operation is as follows: B1: Collect the traffic limiting rule parameters published by the operator, including the traffic limiting trigger threshold. Bandwidth limit after rate limiting Average transmission bandwidth of devices before rate limiting B2: Identifying periods of bandwidth throttling: By comparing "actual transmission bandwidth suddenly drops" "±10% of the time" and "cumulative flow value reached" "The moment" determines the start time of traffic restriction. With end time Calculate the duration of rate limiting B3: Quantifying the potential amount of "data that should have been transmitted but wasn't" The specific expression for calculation is:

[0072] ,

[0073] In the formula, This represents the redundancy for data retransmission failures during the rate-limiting period. High-fidelity estimation unit 303: This unit integrates actual transmitted data and potential data volume to calculate an estimate of the actual data consumption and runs a prediction algorithm to determine future trends. Specific operations are as follows: C1: Calculate the estimated actual data consumption. The actual amount of data transmitted based on the traffic estimation module 300. The potential data volume output by the flow-limiting behavior modeling unit 302 The specific expression is:

[0074] ,

[0075] In the formula, This is a data validity coefficient, dynamically adjusted based on the device's current network signal strength; the stronger the signal, the higher the validity coefficient. The closer to 1.0; C2: Determine future traffic consumption trends: Use a sliding time window algorithm with a 1-hour window period, accumulating nearly 24 windows. Data is used to construct a time series of traffic consumption; this series is then fitted using an autoregressive integral moving average model to output predicted traffic consumption values ​​for the next 12 hours. If three consecutive prediction windows If the consumption exceeds 15% of the average consumption for the current period, it is judged as an "accelerated trend of traffic consumption"; otherwise, it is judged as a "stable trend," and the trend results are synchronized to the early warning and management module 500.

[0076] It should be noted that the multi-source data fusion unit 301 performs spatiotemporal alignment and correlation analysis on application behavior characteristics, network status information and raw traffic data, providing fused data support for the traffic limiting behavior modeling unit 302 to simulate operator traffic limiting strategies and quantify the potential amount of "should be transmitted but not transmitted" data. The high-fidelity estimation unit 303 calculates the estimated value of real data consumption and predicts traffic trends based on the fused data and potential data volume.

[0077] Furthermore, it should be noted that the correlation analysis in the multi-source data fusion unit 301 uses the "Pearson correlation coefficient" to calculate the correlation between application behavior characteristics, network status information, and traffic consumption. The calculation of the average consumption for the current time period in C2 is as follows: the average of the traffic consumption during the same time period as the prediction window over the past 7 days (e.g., if the prediction window is "14:00-15:00", then the traffic consumption during 14:00-15:00 over the past 7 days is calculated). Simultaneously, the parameter determination method for the ARIMA model is explained: the optimal parameter combination (usually p=2, d=1, q=1) is selected through the "AIC information criterion," and a "rolling prediction" mechanism is adopted, updating historical data hourly and refitting the model to ensure that prediction accuracy is continuously optimized with data updates.

[0078] In this embodiment, it should also be noted that the data calibration and algorithm module 400 includes a group data aggregation unit 401, a consensus benchmark calculation unit 402, and a distributed calibration unit 403, wherein: the group data aggregation unit 401 is used to collect and aggregate traffic behavior data of devices in the vicinity through a Bluetooth mesh network; the consensus benchmark calculation unit 402, based on the node consensus mechanism of the Bluetooth mesh network, calculates the normal traffic behavior pattern of the area under the current network conditions as a benchmark through a consensus algorithm; the distributed calibration unit 403 is used to perform differential comparison between individual device data and the group benchmark, identify abnormal deviations, and generate calibration parameters to correct the individual model. The specific operation is as follows: D1: Differential comparison between individual and group benchmarks: calculate the estimated traffic value of the individual device per unit time. Consistency benchmark with the group relative deviation rate ;when If the deviation exceeds the preset threshold for three consecutive time units, it is judged as an abnormal deviation, and the deviation type is marked; D2: Calibration parameter generation and model correction: Based on the deviation type and deviation rate, a dynamic calibration coefficient k is generated, and the calculation formula is:

[0079] ,

[0080] In the formula, To calibrate the sensitivity coefficient, The sign for the direction of deviation. The maximum correction threshold is set; the calibration coefficient k is injected into the potential data volume calculation stage of the flow estimation model to complete the real-time correction of the individual model, and the correction log is recorded and synchronized to the Bluetooth communication and data transmission module 200.

[0081] It should be noted that the group data aggregation unit 401 collects and aggregates traffic behavior data of neighboring devices through the Bluetooth mesh network, providing a data foundation for the consistency benchmark calculation unit 402 to generate a regional normal traffic behavior benchmark based on the node consensus mechanism. The distributed calibration unit 403 then relies on this group benchmark to complete the differential comparison, anomaly identification and calibration parameter generation of individual device data, thereby correcting the individual traffic estimation model and synchronizing the logs to the Bluetooth communication and data transmission module 200.

[0082] Furthermore, it should be noted that the consensus algorithm in the consensus benchmark calculation unit 402 adopts a "weighted voting consensus algorithm." Each node calculates a comprehensive weight based on "signal similarity" (RSSI difference with the current node ≤10dBm is high similarity, weight 1.0; difference 10-20dBm is medium similarity, weight 0.8; difference >20dBm is low similarity, weight 0.6) and "application behavior similarity" (sampling frequency difference ≤1 time / minute is high similarity, weight 1.0; difference 1-3 times / minute is medium similarity, weight 0.8; difference >3 times / minute is low similarity, weight 0.6). The comprehensive weight = signal similarity weight × 0.5 + application behavior similarity weight × 0.5; the final group consensus benchmark value is calculated as follows. The weighted average of the estimated traffic for all nodes is calculated using the following formula: In the formula, Let be the overall weight of the i-th node. Let m be the estimated traffic for the i-th node, and m be the number of nodes participating in the consensus.

[0083] In D2, the value of k ranges from 0.8 to 1.2; The value range is 0.6-0.9, and the specific adjustment rule is: when the node's overall weight is ≥0.9 ( When the weight is 0.7-0.9 When the weight is <0.7 .

[0084] positive deviation Take +1 for time, negative deviation Take -1 at time; Set to 20% to avoid coefficient anomalies due to extreme bias. The specific calculation of the potential data injection amount for the calibration coefficient k is as follows, and the correction formula is: In the formula, To calculate the corrected potential data volume, the corrected data is re-substituted into the high-fidelity estimation formula. Complete individual model calibration.

[0085] In this embodiment, it should also be noted that the early warning and management module 500 includes a traffic monitoring unit 501, a policy early warning unit 502, and a configuration management unit 503, wherein: the traffic monitoring unit 501 is used to display the current traffic usage, remaining quota, and predicted exhaustion time in real time; the policy early warning unit 502 is used to trigger tiered early warnings in various ways according to the threshold set by the user; and the configuration management unit 503 is used to provide a human-computer interaction interface, allowing users to view historical data, configure early warning rules, and manually trigger calibration processes.

[0086] It should be noted that the traffic monitoring unit 501 displays traffic usage, remaining quota, and predicted exhaustion time in real time, providing real-time data support for the policy warning unit 502 to trigger tiered warnings based on user-set thresholds. The configuration management unit 503 allows users to view historical data, configure warning rules, and manually trigger calibration processes through a human-computer interaction interface.

[0087] Furthermore, it should be noted that the traffic monitoring unit 501 provides a three-dimensional visualization of traffic usage: ① Real-time data: displays current traffic usage, remaining quota, and real-time consumption rate; ② Historical data: displays traffic consumption curves by day / week / month, and marks the periods of traffic throttling and calibration events; ③ Predictive data: displays the traffic consumption prediction curve for the next 12 hours, and marks the periods of "acceleration trend"; the data refresh frequency is set to 10 seconds / time to ensure real-time performance.

[0088] The strategy warning unit 502 supports multi-level warning configuration and multi-channel push: ① Warning level: set to "Reminder" (remaining traffic ≥ 20% of total quota), "Alarm" (remaining traffic 10%-20%), "Emergency Alarm" (remaining traffic ≤ 10%).

[0089] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0090] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A system for estimating and self-calibrating IoT card traffic under operator-limited traffic conditions, characterized in that, It includes a data acquisition module (100), a Bluetooth communication and data transmission module (200), a traffic estimation module (300), a data calibration and algorithm module (400), and an early warning and management module (500), wherein: The data acquisition module (100) is used to collect raw data generated by IoT card traffic consumption and device operating status parameters; The Bluetooth communication and data transmission module (200) is used to establish an anti-interference secure connection through dynamic frequency hopping and signal adaptive adjustment, adopts a traffic-sensitive hierarchical transmission strategy and supports near-field offline high-speed mode, and performs efficient and low-power transmission of raw traffic logs, calibration instructions and system updates. The traffic estimation module (300) is used to integrate device application behavior characteristics and Bluetooth collaborative sensing network status information to construct a dynamic traffic estimation model under the traffic limiting environment. By inferring the potential traffic that "should have been transmitted but was not" during the traffic limiting period, it performs high-fidelity estimation and trend prediction of real data consumption. The data calibration and algorithm module (400) is used to aggregate traffic behavior data of neighboring devices through Bluetooth networking, build a group consistency benchmark, and use differential analysis and anomaly detection algorithms to autonomously identify traffic limiting interference and dynamically correct individual traffic estimation models, and perform distributed self-calibration that does not depend on operator bills. The early warning and management module (500) monitors traffic usage in real time based on the calibrated and accurate estimated value, and issues an early warning to the user when the traffic limit threshold is approached.

2. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions as described in claim 1, characterized in that, The data acquisition module (100) includes a raw traffic sniffing unit (101), a device status monitoring unit (102), and a data preprocessing unit (103), wherein: The raw traffic sniffing unit (101) is used to capture the IP packet-level traffic records of the IoT card from the network protocol stack or driver layer, and obtain the raw traffic data of uplink and downlink data volume, timestamp and communication protocol type; The device status monitoring unit (102) is used to collect operating parameters such as device CPU utilization, sensor working mode, and network access duration. The data preprocessing unit (103) is used to clean, denoise, and format and package the collected raw data.

3. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions as described in claim 1, characterized in that, The Bluetooth communication and data transmission module (200) includes an anti-interference connection unit (201), a hierarchical transmission control unit (202), and an offline synchronization unit (203), wherein: The anti-interference connection unit (201) is used to maintain a stable Bluetooth connection between the device and the terminal through dynamic frequency hopping and signal strength adjustment. The hierarchical transmission control unit (202) is used to schedule the transmission of traffic logs and calibration instructions according to data priority. The offline synchronization unit (203) is used to activate the high-speed transmission channel in a near-field environment and synchronize historical data and system update packages in batches.

4. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions as described in claim 3, characterized in that, The hierarchical transmission control unit (202) schedules the transmission of traffic logs and calibration instructions according to data priority. The specific operation is as follows: A1: Preset three-level data priority: calibration instructions are the highest priority, raw traffic logs are the medium priority, and system update packages are the low priority; A2: Use a sliding window compression algorithm to lightweight process medium-priority data, and use a breakpoint resume mechanism for low-priority data. A3: Real-time monitoring of the remaining data traffic of the IoT card. When the remaining data traffic is lower than the preset threshold, the three-level data transmission is automatically paused, and only the transmission channels for the highest priority and medium priority data are retained.

5. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions according to claim 1, characterized in that, The traffic estimation module (300) includes a multi-source data fusion unit (301), a traffic limiting behavior modeling unit (302), and a high-fidelity estimation unit (303), wherein: The multi-source data fusion unit (301) is used to perform spatiotemporal alignment and correlation analysis of application behavior characteristics, network status information and raw traffic data; The traffic limiting behavior modeling unit (302) is used to simulate the operator's traffic limiting strategy, infer and quantify the potential amount of "data that should have been transmitted but was not" caused by traffic limiting. The high-fidelity estimation unit (303) is used to comprehensively calculate the estimated value of real data consumption by combining the actual transmitted data and the potential data volume, and to run a prediction algorithm to judge future trends.

6. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions as described in claim 5, characterized in that, The traffic limiting behavior modeling unit (302) simulates the operator's traffic limiting strategy, infers and quantifies the potential amount of "untransmitted data" caused by traffic limiting, and the specific operation is as follows: B1: Collect publicly available data throttling rule parameters from operators, including data throttling trigger thresholds. Bandwidth limit after rate limiting Average transmission bandwidth of devices before rate limiting ; B2: Identifying Periods of Traffic Limiting: By comparing "actual transmission bandwidth suddenly drops" "±10% of the time" and "cumulative flow value reached" "The moment" determines the start time of traffic restriction. With end time Calculate the duration of rate limiting ; B3: Quantifying the potential amount of "data that should have been transmitted but wasn't" The specific expression for calculation is: ， In the formula, This is the redundancy for data retransmission failures during the flow-limiting period.

7. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions as described in claim 5, characterized in that, The high-fidelity estimation unit (303) integrates the actual transmitted data and the potential data volume to calculate the estimated value of the actual data consumption, and runs a prediction algorithm to judge the future trend. The specific operation is as follows: C1: Calculate the estimated value of actual data consumption The actual amount of data transmitted based on the traffic estimation module (300) The amount of potential data output by the flow-limiting behavior modeling unit (302) The specific expression is: ， In the formula, This is a data validity coefficient, dynamically adjusted based on the device's current network signal strength; the stronger the signal, the higher the validity coefficient. The closer it is to 1.0; C2: Determining future traffic consumption trends: Employing a sliding window algorithm with a 1-hour window period, accumulating nearly 24 windows. Data is used to construct a time series of traffic consumption; this series is then fitted using an autoregressive integral moving average model to output predicted traffic consumption values ​​for the next 12 hours. ; If three consecutive prediction windows If the consumption exceeds 15% of the average consumption for the current period, it is judged as an "accelerated trend of traffic consumption"; otherwise, it is judged as a "stable trend". The trend results are then synchronized to the early warning and management module (500).

8. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions according to claim 1, characterized in that, The data calibration and algorithm module (400) includes a group data aggregation unit (401), a consistency benchmark calculation unit (402), and a distributed calibration unit (403), wherein: The group data aggregation unit (401) is used to collect and aggregate traffic behavior data of devices in the vicinity through a Bluetooth mesh network; The consensus benchmark calculation unit (402) is based on the node consensus mechanism of the Bluetooth mesh network and uses a consensus algorithm to calculate the normal traffic behavior pattern of the area under the current network conditions as a benchmark. The distributed calibration unit (403) is used to perform differential comparison between individual device data and group benchmark, identify abnormal deviations, and generate calibration parameters to correct individual models.

9. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions as described in claim 8, characterized in that, The distributed calibration unit (403) performs differential comparison between individual device data and the group benchmark to identify abnormal deviations and generates calibration parameters to correct individual models. The specific operation is as follows: D1: Differential comparison between individual and group baselines: Calculates the estimated flow rate of individual devices per unit time. Consistency benchmark with the group relative deviation rate ;when If the deviation exceeds the preset threshold for three consecutive time periods, it is determined to be an abnormal deviation, and the deviation type is marked. D2: Calibration Parameter Generation and Model Correction: Dynamic calibration coefficient k is generated based on deviation type and deviation rate. The calculation formula is as follows: ， In the formula, To calibrate the sensitivity coefficient, The sign for the direction of deviation. The maximum correction threshold; The calibration coefficient k is injected into the potential data volume calculation stage of the flow estimation model to complete the real-time correction of the individual model, and the correction log is recorded and synchronized to the Bluetooth communication and data transmission module (200).

10. The IoT card traffic estimation and self-calibration system under operator-limited traffic conditions according to claim 1, characterized in that, The early warning and management module (500) includes a traffic monitoring unit (501), a policy early warning unit (502), and a configuration management unit (503), wherein: The traffic monitoring unit (501) is used to display the current traffic usage, remaining quota, and predicted exhaustion time in real time. The strategy warning unit (502) is used to trigger graded warnings in various ways according to the threshold set by the user. The configuration management unit (503) is used to provide a human-machine interface, allowing users to view historical data, configure early warning rules, and manually trigger the calibration process.

Images