Iot card data backhaul method and system based on multi-network fusion, and storage medium

Abstract

This application relates to the field of IoT communication technology, and discloses a method, system, and storage medium for IoT card data backhaul based on multi-network convergence. The method includes: collecting data and detecting network signals, intelligently switching networks when signals are insufficient; controlling latency after switching, enabling transmission protection, verifying cross-carrier compatibility, and evaluating stability; detecting data packet loss and reassembling fragments to obtain a complete data stream; retrying data streams after timeouts and repairing abnormal data; verifying alarm data and dynamically adjusting bandwidth allocation; simulating screen stuttering to evaluate transmission quality; and prioritizing data flow and ensuring real-time transmission. This application solves the problems of unstable network switching, easy data loss, alarm delays, and screen stuttering by using technologies such as intelligent multi-network switching, priority transmission, fragment reassembly, and dynamic bandwidth allocation, thereby improving the reliability, real-time performance, and transmission quality of IoT card data backhaul.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) communication technology, and in particular to a method, system, and storage medium for data backhaul of IoT cards based on multi-network convergence. Background Technology

[0002] With the widespread application of IoT technology in industrial control, urban management, and smart security, IoT devices require high-frequency transmission of emergency alarms and real-time monitoring data, placing stringent demands on the stability, real-time performance, and reliability of network links. Multi-network convergence has become the mainstream solution for dealing with complex network environments. IoT cards, relying on the network resources of multiple operators, have become the core carrier of device data transmission, and the quality of their data transmission directly affects operational efficiency.

[0003] Current IoT SIM card data backhaul methods generally employ a combination of single-network transmission and passive handover, lacking multi-network collaboration and service adaptation mechanisms, resulting in systemic deficiencies. In the network handover phase, handover decisions are based solely on current signal strength, lacking delay control and cross-carrier compatibility verification processes. This leads to link interruptions and buffer failures during handover, causing intermittent transmission drops. Furthermore, the absence of priority rules for emergency alarm data streams causes critical data to compete for resources with ordinary video streams, resulting in slow handover responses and inconsistent link connections. In the data transmission and repair phase, the lack of refined packet loss detection and verification mechanisms means that lost data packets are simply retransmitted without fragmentation and reassembly or backup channel retransmission capabilities, leading to missing or corrupted monitoring footage and alarm data. Finally, in terms of resource scheduling, bandwidth is allocated at a fixed ratio, unable to be dynamically adjusted based on transmission logs, traffic peaks, and service characteristics. Emergency alarms are prone to delays due to insufficient bandwidth, and real-time monitoring footage frequently experiences stuttering and screen flickering due to network fluctuations and resource congestion. In terms of transmission quality control, the lack of closed-loop assessment and path diversion optimization makes it impossible to predict the risk of lag and locate the delay node. The decision-making and response are lagging, making it difficult to meet the dual business requirements of high reliability for emergency alarms and high smoothness for monitoring. In scenarios such as industry, security, and smart cities, it is easy to cause security and efficiency problems such as untimely response and monitoring failure.

[0004] To address the above deficiencies, this application combines multi-network intelligent switching, priority transmission, fragmentation and reassembly, timeout retry, dynamic bandwidth allocation and traffic optimization to solve problems such as unstable network switching, easy data loss, alarm delay, and screen lag, thereby improving the reliability, real-time performance and transmission quality of IoT card data backhaul. Summary of the Invention

[0005] This application provides a method, system, and storage medium for IoT card data backhaul based on multi-network convergence, which solves problems such as unstable network switching, easy data loss, alarm delay, and screen lag, and improves the reliability, real-time performance, and transmission quality of IoT card data backhaul.

[0006] Firstly, this application provides a method for data backhaul of an IoT card based on multi-network convergence, the method comprising: S1. Collect emergency alarm data and real-time monitoring screen data from IoT devices, perform network signal strength detection on the data stream, and perform intelligent network switching when the network signal strength is lower than the preset strength threshold, and determine the network connection status after switching. S2. Based on the network connection status after the switch, control the switching delay and enable transmission interruption protection. Apply network switching priority rules to emergency alarm data, perform cross-carrier compatibility verification, and determine the stability assessment results. S3. Based on the stability assessment results, packet loss detection and verification are performed on the real-time monitoring screen data and emergency alarm data, and fragmentation and reconstruction processing is used to obtain a complete data stream. S4. Apply a transmission timeout retry strategy to the complete data stream and use a feedback mechanism to identify transmission anomalies. When an anomaly is detected, start abnormal data repair and determine the data integrity status after repair. S5. Based on the integrity status of the repaired data, perform integrity verification on the emergency alarm data and analyze the transmission log. When the alarm delay exceeds the preset delay threshold, dynamically adjust the bandwidth allocation ratio to obtain an optimized resource configuration scheme. S6. Based on the optimized resource configuration scheme, simulate transmission lag for real-time monitoring screen data, analyze the lag probability in combination with the stability assessment results, determine whether the transmission stability meets the business requirements, and determine the transmission quality assessment results. S7. Based on the transmission quality assessment results, the emergency alarm data and real-time monitoring screen data are processed separately. Combined with the transmission logs, it is determined whether the decision response speed meets the business requirements, and the overall transmission real-time guarantee status is determined.

[0007] Secondly, this application provides an IoT card data backhaul system based on multi-network convergence, used to implement the aforementioned IoT card data backhaul method based on multi-network convergence, the system comprising: The data acquisition and detection module is used to collect emergency alarm data and real-time monitoring screen data from IoT devices, perform network signal strength detection on the data stream, and perform intelligent network switching when the network signal strength is lower than a preset strength threshold, and determine the network connection status after switching. The handover control module is used to control handover delay and enable transmission interruption protection based on the network connection status after handover, apply network handover priority rules to emergency alarm data, perform cross-carrier compatibility verification, and determine the stability assessment results. The data reconstruction module is used to perform packet loss detection and verification on real-time monitoring screen data and emergency alarm data based on the stability assessment results, and to obtain a complete data stream by using fragment reconstruction processing. The anomaly repair module is used to apply a transmission timeout retry strategy to the complete data stream and use a feedback mechanism to identify transmission anomalies. When an anomaly is detected, the module initiates anomaly data repair and determines the data integrity status after repair. The bandwidth optimization module is used to perform integrity verification on emergency alarm data and analyze transmission logs based on the integrity status of the repaired data. When the alarm delay exceeds the preset delay threshold, the bandwidth allocation ratio is dynamically adjusted to obtain an optimized resource configuration scheme. The quality assessment module is used to simulate transmission lag in real-time monitoring screen data based on the optimized resource configuration scheme, analyze the lag probability in combination with the stability assessment results, determine whether the transmission stability meets the business requirements, and determine the transmission quality assessment result. The traffic splitting and protection module is used to split emergency alarm data and real-time monitoring screen data according to the transmission quality assessment results, and to determine whether the decision response speed meets the business requirements by combining the transmission logs, thereby determining the overall transmission real-time protection status.

[0008] Thirdly, this application provides a computer-readable storage medium storing instructions, characterized in that the instructions, when executed by a processor, implement the IoT card data backhaul method based on multi-network convergence.

[0009] This application proposes a method, system, and storage medium for IoT card data backhaul based on multi-network convergence, solving problems such as unstable network switching, easy data loss, alarm delay, and screen stuttering, and improving the reliability, real-time performance, and transmission quality of IoT card data backhaul. Compared with the prior art, the beneficial effects of the technical solution of this application are at least as follows: First, by real-time detection of network signal strength and intelligent switching between multiple operators, combined with switching delay control and cross-operator compatibility verification, the network switching process is ensured to be uninterrupted, and the connection stability after switching is improved.

[0010] Second, set priority transmission rules for emergency alarm data streams to achieve differentiated scheduling of critical data and monitoring screen data streams, ensuring priority transmission of emergency alarm data and reducing alarm delays.

[0011] Third, by using data packet loss detection, transmission check code generation, and data fragmentation and reassembly logic, we can achieve accurate recovery of segmented data and ensure the integrity of real-time monitoring footage and emergency alarm data transmission.

[0012] Fourth, a transmission timeout retry and server reception confirmation feedback mechanism is adopted to automatically repair abnormal data transmission, thereby improving the success rate and integrity of data transmission.

[0013] Fifth, based on transmission logs and latency status, the bandwidth allocation ratio is dynamically adjusted to optimize resource configuration, reduce the probability of real-time monitoring screen stuttering, and improve transmission smoothness.

[0014] Sixth, by optimizing data stream splitting and transmission paths, we can improve decision-making response speed and ensure that the overall transmission process meets the requirements of high real-time services. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating the IoT card data backhaul method based on multi-network convergence in this application; Figure 2 This is a diagram showing the network intelligent handover triggering and marking results in this application; Figure 3 This is a time-series comparison of transmission stability in this application; Figure 4 This is a comparison chart of the cumulative distribution of transmission delay in this application; Figure 5 This is a schematic diagram of the IoT card data backhaul system based on multi-network convergence in this application. Detailed Implementation

[0017] This application provides a method, system, and storage medium for data backhaul of IoT cards based on multi-network convergence. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0018] For ease of understanding, the specific process of the embodiments of this application is described below. Please refer to [link / reference]. Figure 1 One embodiment of the IoT card data backhaul method based on multi-network convergence in this application includes: S1. Collect emergency alarm data and real-time monitoring screen data from IoT devices, perform network signal strength detection on the data stream, and perform intelligent network switching when the network signal strength is lower than the preset strength threshold to determine the network connection status after switching.

[0019] In one specific embodiment, performing step S1 includes the following steps: Emergency alarm data and real-time monitoring data are obtained from IoT devices. Key information about network transmission is extracted by analyzing the data flow to determine the stability of the data flow transmission. Based on the transmission stability of the data stream, network signal strength is detected in the data stream to determine whether the network signal strength is lower than a preset strength threshold. If so, then combine the operator's network coverage data to obtain a list of currently available networks; Based on the list of available networks and the handover criteria, the priority of each operator's network is sorted to determine the optimal target network for handover. Based on the optimal target network for handover, an intelligent handover process is initiated and the network connection status is updated. The signal strength and data flow stability after handover are continuously monitored to obtain the network connection status after handover.

[0020] Specifically, the built-in sensors of the IoT device collect device operating status parameters at a set cycle. When the parameters exceed a preset safety range, emergency alarm data is generated. The emergency alarm data is encapsulated in a fixed message format, including device identifier, alarm type, and timestamp fields. The camera collects real-time monitoring video data at a fixed resolution and frame rate. The real-time monitoring video data is encapsulated in a video stream format. The emergency alarm data and real-time monitoring video data are output simultaneously. The two data streams are parsed to extract the data stream transmission direction, transmission rate, packet interval, and packet length as key network transmission information. Based on the extracted key network transmission information, the data stream transmission stability index is calculated, where the continuous transmission duration of the data stream is obtained statistically based on the transmission direction and transmission rate. The packet interval fluctuation value is calculated from the average deviation between the packet interval and the reference interval, and the transmission rate deviation value is calculated from the relative deviation between the actual transmission rate and the target rate. The transmission stability index corresponding to the emergency alarm data and the transmission stability index corresponding to the real-time monitoring screen data are stored separately to complete the determination of data stream transmission stability. The signal strength value of the current access operator network is collected at a fixed sampling frequency. The signal strength value is represented by dBm. The collected signal strength value is compared with the preset strength threshold set according to the network coverage conditions of the device application scenario. When the signal strength value is greater than or equal to the preset strength threshold, the current network connection status is maintained. When the signal strength value is less than the preset strength threshold, the network switching trigger condition is triggered.

[0021] The system retrieves multi-carrier network coverage data from local storage. This data includes the base station locations, signal coverage radius, network drop rate, and network latency data for each carrier in the current geographical area. Based on the location information of the current IoT device, it matches the network parameters of each carrier in the corresponding geographical area, filtering out carrier networks with signal strength higher than a preset strength threshold of -85dBm, network latency lower than a preset latency threshold of 50ms to 200ms, and drop rate lower than a preset drop rate threshold of 0.1% to 1%. This forms a list of currently available networks, which includes carrier identification, network type, estimated signal strength, network latency, and drop rate fields. Preset network switching conditions are loaded, including signal strength weight, network latency weight, drop rate weight, and cost weight. The weight parameters are set according to the service requirements of the IoT device. The parameters of each carrier network in the available network list are then substituted into a weighted scoring algorithm. The algorithm formula is as follows: ,in For comprehensive scoring, For signal strength weights, This is the normalized value of the signal strength. For network latency weighting, This is a standardized value for network latency. As a weight for disconnection rate, This is a standardized value for the disconnection rate. As a weighted factor for cost of service, Using standardized tariff costs as the benchmark, the comprehensive scores of each operator's network are ranked in descending order, and the operator's network with the highest score is the optimal target network for handover.

[0022] A connection request is initiated to the optimal target network for switching. The connection request includes fields such as IoT SIM card identity information, device model, and data transmission type. Authentication, link establishment, and IP allocation are completed according to the operator's network access protocol. The network connection status of the IoT device is updated, including fields such as access operator identifier, network type, signal strength, network latency, packet loss rate, and connection establishment time. The signal strength value of the network after switching is continuously collected, and the flow stability index of emergency alarm data and real-time monitoring screen data is simultaneously acquired. The signal strength value and flow stability index are uploaded to the network status monitoring platform in real time. When the signal strength value falls below the preset strength threshold or the flow stability index falls below the preset stability threshold again, the network detection process is triggered. The signal strength detection, available network screening, and target network switching steps are repeated to maintain the continuity of the IoT device's network connection and complete the determination of the network connection status after switching.

[0023] The above steps rely on data stream parsing and real-time signal detection to identify network degradation status. Through weighted scoring, the optimal switching between multiple operator networks is completed. Combined with continuous status monitoring, network connectivity continuity is maintained, transmission interruptions caused by insufficient coverage of a single network are avoided, the problems of passive network switching and poor link connection are alleviated, and the connection stability and data backhaul continuity of IoT devices in complex network environments are improved.

[0024] S2. Based on the network connection status after the switch, control the handover delay and enable transmission interruption protection. Apply network handover priority rules to emergency alarm data, perform cross-carrier compatibility verification, and determine the stability assessment results.

[0025] In one specific embodiment, performing step S2 includes the following steps: Based on the switched network connection status, obtain the current network latency parameter and determine whether the current network latency parameter is greater than the preset time limit. If so, it is determined that there is a risk of network transmission delay and the delay control is switched. At the same time, the transmission interruption protection mechanism is activated, the buffering strategy is adjusted, and the protection activation status is determined. Based on the protection activation status, apply network switching priority rules to emergency alarm data to determine alarm flow priority; Based on alarm flow priority, cross-carrier compatibility verification is performed to analyze the degree of support for alarm flow priority in each network and determine the degree of compatibility. Based on compatibility compliance, monitor network status and collect connectivity metrics, and determine stability assessment results based on connectivity metrics.

[0026] Specifically, the switched network connection status carries data such as operator identifier, network type, signal strength, network latency, packet loss rate, and connection establishment time. Network latency data is extracted from the network connection status as the current network latency parameter. This parameter characterizes the data transmission time between the IoT card and the data receiver. The current network latency parameter is compared with a preset time limit, which is set based on the real-time requirements of IoT device data backhaul services. If the current network latency parameter is less than or equal to the preset time limit, the existing network transmission configuration remains unchanged. If the current network latency parameter is greater than the preset time limit, a latency risk is flagged in the network transmission. This latency risk flag is associated with the current network latency parameter and is used to trigger [the event / event]. Subsequent handover delay control and transmission interruption protection mechanisms are implemented. Handover delay control reduces transmission time during the handover process by adjusting the timing parameters of network link establishment. These timing parameters include link request interval, authentication response waiting time, and data channel activation delay. The timing parameters are matched and adjusted according to the delay risk level. After the transmission interruption protection mechanism is activated, the data transmission buffering strategy is adjusted. The buffering strategy includes data cache capacity, cache write rate, cache read priority, and cache overflow handling rules. After the buffering strategy is adjusted, a protection activation state is generated. The protection activation state represents the operating status of the transmission interruption protection mechanism. The protection activation state is bound to the transmission channels of emergency alarm data and real-time monitoring screen data to ensure that the data transmission process is not interrupted due to network handover.

[0027] After the protection activation state takes effect, the network switching priority rules are loaded. These rules assign transmission weights based on data service type, with emergency alarm data having a higher transmission weight than real-time monitoring data. Emergency alarm data is then imported into the network switching priority rules for matching. The matching operation determines the weight allocation based on the emergency alarm data's message identifier, data transmission cycle, and data triggering conditions. The matching operation outputs an alarm flow priority, which is used to allocate network transmission channel resources and data processing sequence. A one-to-one correspondence is established between the alarm flow priority and the emergency alarm data packets. The alarm flow priority is synchronously written into the emergency alarm data's message header field, which is used by network nodes to identify data transmission priority. After the alarm flow priority is determined, real-time monitoring data is transmitted according to the default priority, which is lower than the alarm flow priority. The two priority rules operate in parallel without interference, and the transmission sequence of emergency alarm data always takes precedence over that of real-time monitoring data, ensuring that emergency alarm data is transmitted first in scenarios with network resource contention.

[0028] Priority test data packets are generated based on alarm flow priorities. These packets include alarm flow priority fields, data length fields, and transmission timing fields. The priority test data packets are sent to the current access network and backup operator networks, respectively. Test response data is received from each operator network. This response data includes the network's recognition result for the priority fields, data transmission latency, and packet loss rate. Compatibility analysis is performed on the test response data. The compatibility analysis determines the degree of support based on the network's accuracy in recognizing alarm flow priorities, priority transmission latency deviation, and priority packet loss rate. A weighted fitting algorithm is used for the compatibility analysis, and the algorithm formula is as follows: ,in For compatibility, Identify weights for priorities. Prioritize the accuracy of identification. For transmission delay weight, This is the transmission delay deviation value. As a weight for packet loss rate, The algorithm outputs a compatibility score for the packet loss rate. The compatibility score characterizes the degree to which the operator's network supports the priority of alarm flows. The compatibility score is associated with the corresponding operator identifier and stored in a storage relationship.

[0029] The network status monitoring cycle is set based on compatibility compliance, and the monitoring cycle is negatively correlated with compatibility compliance. Network connectivity indicators are collected according to the monitoring cycle, including signal strength fluctuation, network latency jitter, packet retransmission rate, and connection hold duration. These indicators are then imported into a stability assessment model, which is a quantitative assessment model of network transmission status based on multi-indicator threshold judgment and linear trend fitting. The model input layer receives four types of network connectivity indicators: signal strength fluctuation, network latency jitter, packet retransmission rate, and connection hold duration. The model preprocessing layer performs maximum-minimum normalization on these four types of indicators. The model processing layer uses a processing logic combining threshold comparison and trend fitting, setting independent judgment thresholds for each type of network connectivity indicator. The threshold settings are determined based on the data backhaul service transmission requirements of the IoT card. The threshold comparison process compares the normalized indicator values ​​with the corresponding thresholds one by one, generating a single-indicator qualified status identifier. The trend fitting process uses the indicator values ​​collected over multiple consecutive cycles as samples and performs linear fitting using the least squares method. The fitting formula is... , To fit the trend value, The slope is the fitted slope. This is the collection cycle number. The fitting intercept and the fitting slope are used to characterize the trend of the index change. The pass / fail indicator is weighted and calculated with the trend result to obtain the intermediate evaluation value in the interval of 0 to 1. The calculation formula is: ,in As the indicator weight, For single-indicator qualification, For trend weighting, This is the inverse correction term for the fitted slope. The model fusion layer performs a weighted fusion operation on the intermediate evaluation values ​​and the compatibility compliance, using the following fusion formula: , For the stability assessment results, As the weight of the intermediate evaluation value, This is an intermediate evaluation value. For compatibility compliance weighting, To ensure compatibility, the fusion calculation outputs a stability assessment result. The stability assessment result characterizes the continuous transmission capability of the network connection after the switchover. The stability assessment result, along with the network connection status after the switchover, alarm flow priority, and compatibility, forms a complete data correlation chain to support subsequent data transmission and quality optimization processes.

[0030] The above steps mitigate network handover link interruption issues through delay control and transmission interruption protection, ensure priority transmission of emergency alarm data based on priority rules, adapt to multi-carrier network environments through compatibility verification, and determine network stability status through indicator collection and model calculation. This improves the shortcomings of slow network handover response, poor link connection, and obstruction of critical data transmission, thereby enhancing the stability and real-time performance of IoT card data backhaul.

[0031] S3. Based on the stability assessment results, packet loss detection and verification are performed on the real-time monitoring screen data and emergency alarm data, and fragmentation and reconstruction processing is used to obtain a complete data stream.

[0032] In one specific embodiment, performing step S3 includes the following steps: Based on the stability assessment results, the sequence numbers of the emergency alarm data and the real-time monitoring screen data are compared one by one to identify and locate the location of the lost data packets during transmission. Based on the location of lost data packets, a fixed-size fragmentation mechanism is used to segment the data stream, and a unique index identifier is added to each data fragment to generate a set of segmented transmission units. Based on the location of the lost data packet and the unique index identifier, the segmented transmission units are sequentially reassembled and the missing positions are filled with data; A second verification is performed on the data stream after reorganization and padding to obtain a complete data stream after confirming that there is no missing data.

[0033] Specifically, the stability assessment results include quantitative values ​​related to network continuous transmission capacity, signal strength fluctuation, network latency jitter, packet retransmission rate, and connection hold duration. The stability assessment results directly determine the execution frequency and comparison accuracy of packet loss detection. The execution frequency and stability assessment results are positively correlated. The comparison accuracy is set based on the transmission requirements of emergency alarm data and real-time monitoring screen data. Emergency alarm data and real-time monitoring screen data generate continuously increasing sequence numbers at the sending end according to the transmission sequence. These sequence numbers are written into a fixed field in the packet header, which is used by the receiving end to identify the transmission order of the packets. The receiving end stores the complete sequence number sequence sent by the sending end. The receiving end configures the execution based on the stability assessment results. The process involves comparing the sequence numbers of received emergency alarm data and real-time monitoring video data packets one by one. This process matches the sequence number in the header of the received data packet with the values ​​in the complete sequence number sequence. Unmatched sequence number values ​​correspond to the location of lost data packets during transmission. The location of lost data packets has a fixed correspondence with the data stream type, transmission timestamp, and data packet length. The location of lost data packets in emergency alarm data is directly related to the integrity of the alarm information, while the location of lost data packets in real-time monitoring video data is directly related to the continuity of video frames. The locations of lost data packets for the two types of data are stored separately and maintain an independent correspondence to avoid cross-interference between the lost location information of different types of data.

[0034] Once the location of the lost data packet is determined, a fixed-size fragmentation mechanism is initiated to segment the emergency alarm data and real-time monitoring screen data separately. The fixed-size fragmentation mechanism determines the fragment length based on the maximum transmission unit of the data transmission link. Emergency alarm data and real-time monitoring screen data use different fragment lengths. During the fragmentation process, the data stream is divided into independent data fragments according to the set fragment length. Each data fragment is given a unique index identifier according to its transmission time sequence, data stream type, and data packet sequence number. The unique index identifier contains the fragment sequence number, data stream type, data packet sequence number, and fragment verification information. The unique index identifier forms an inseparable binding relationship with the corresponding data fragment. All data fragments carrying unique index identifiers together constitute a segmented transmission unit set. The segmented transmission unit set is divided into an emergency alarm data segmented transmission unit subset and a real-time monitoring screen data segmented transmission unit subset according to the data stream type. The two subsets are associated with the location of the lost data packet of the corresponding data type, providing a data foundation for subsequent sequential reassembly.

[0035] Based on the location of lost data packets and unique index identifiers, the set of segmented transmission units is reassembled in order. The reassembly uses the fragment sequence number within the unique index identifier as the core sorting criterion, and simultaneously combines it with the sequence number of the corresponding data packets to complete the ascending order of all segmented transmission units. During the sorting process, the sequence number interval corresponding to the location of the lost data packet is traversed synchronously, and each sequence number within the interval is matched with the unique index identifier of the segmented transmission unit. Sequence number points that cannot be matched with the corresponding segmented transmission unit are marked as missing data stream points. All missing points form a missing position sequence according to the sorting order. Data padding is performed based on the missing position sequence. First, according to the data stream type corresponding to the missing position, the original data copy of the corresponding time period is retrieved from the local cache. The original data copy retains the complete data structure before the sender transmits the data. Then, according to a fixed-size fragmentation mechanism, the original data copy is padded with the missing data. The missing data segment is re-fragmented, and the length of the re-fragmented segment is completely consistent with that of the normally transmitted data segment of the same type. At the same time, according to the encoding rules of the unique index identifier, the data segment generated for padding is assigned a fragment sequence number, the sequence number of the data packet to which it belongs, and the verification information to match the missing position. This makes the index rules of the padding data segment fully compatible with the original segmented transmission unit. After the padding data segment is generated, it is accurately inserted into the arrangement gap corresponding to the missing position. During the insertion process, the index continuity of the adjacent segmented transmission units before and after is checked to ensure that the fragment sequence number and the sequence number of the data packet to which it belongs have no jumps or repetitions. After the padding is completed, the segmented transmission units of emergency alarm data and real-time monitoring screen data are checked respectively to ensure that both types of data streams form a continuous arrangement state without interruption or misalignment, and to keep the transmission timing and business logic of the original data unchanged.

[0036] A secondary verification is performed on the data stream after reassembly and padding. The secondary verification uses the Cyclic Redundancy Check (CRC) algorithm, and the algorithm formula is as follows: ,in To verify the results, For the numerical values ​​of the data fragment content, To verify the weights, the verification process traverses all segmented transmission units, calculates the weighted sum of all data fragments to obtain the overall verification value, and compares the calculated verification value with the baseline verification value pre-stored at the sending end. If the verification values ​​match, it confirms that there are no missing or disordered data. If the verification values ​​do not match, the sequence number packet comparison, fragmentation processing, order reassembly, and data padding operations are restarted. After confirming that there are no missing data, a complete data stream is generated. The complete data stream is divided into an emergency alarm complete data stream and a real-time monitoring screen complete data stream. The two types of complete data streams maintain the same content and structure as the original collected emergency alarm data and real-time monitoring screen data, respectively. The complete data stream is used to support subsequent transmission timeout detection, abnormal data repair, and bandwidth allocation adjustment related operations.

[0037] The above steps locate the packet loss position by comparing the sequence number packet by packet, segment the data by relying on fixed fragmentation and unique index, restore the data continuity by combining index matching sorting and in-situ padding, and ensure data accuracy by cooperating with cyclic redundancy check. This solves the problem of data loss and disorder in IoT data transmission and improves the integrity and accuracy of the returned data.

[0038] S4. Apply a transmission timeout retry strategy to the complete data stream and use a feedback mechanism to identify transmission anomalies. When an anomaly is detected, start abnormal data repair and determine the integrity status of the repaired data.

[0039] In one specific embodiment, performing step S4 includes the following steps: Monitor the transmission timeout of the complete data stream, record the data stream sending time and server receiving time in real time, and calculate the time interval between sending and receiving; If the time interval exceeds the preset time threshold, it is determined to be a transmission timeout, and the transmission retry mechanism is activated to retransmit the data packet segment corresponding to the location of the lost data packet to the server. If a data packet fragment is not successfully received after transmission, the data packet fragment is marked as an abnormal data fragment, and the abnormality identifier is recorded. Based on the anomaly identifier and the location of the lost data packet, the corresponding complete data segment is extracted from the local backup storage unit, and the anomaly data repair is performed through the backup transmission channel. The sequence number and content of the repaired data fragments are compared with those of the original data to determine the integrity status of the repaired data.

[0040] Specifically, the complete data stream includes an emergency alarm complete data stream and a real-time monitoring screen complete data stream. Both types of data streams initiate transmission requests at the sending end according to a fixed time sequence. The transmission request carries a data packet sequence number, data fragment length, and a timestamp field. The timestamp field accurately records the moment when the data stream initiates transmission. The receiving end records the server reception time for each received data fragment in real time. The server reception time is written to the reception log with millisecond precision. The receiving end correlates and matches the data stream sending time with the server reception time, and calculates the time interval between sending and receiving by performing a numerical subtraction operation. The calculation result of the time interval is bound to the sequence number and data fragment identifier of the corresponding data stream. The time interval is used to determine whether a delay or timeout occurs during the transmission process. For example, the time interval calculation result of the emergency alarm data stream is directly related to the real-time transmission requirements of the alarm information, and the time interval calculation result of the real-time monitoring screen data stream is related to the smooth transmission requirements of the video stream. The time interval data of the two types of data streams are stored independently and do not cause cross-interference.

[0041] The time interval is compared with a preset time threshold, which is set based on the real-time requirements of IoT device data transmission. The preset time threshold for emergency alarm data streams is less than the preset time threshold for real-time monitoring data streams. When the time interval is less than or equal to the corresponding preset time threshold, the current transmission configuration is maintained and the transmission status of subsequent data streams continues to be monitored. When the time interval exceeds the corresponding preset time threshold, it is determined as a transmission timeout. The timeout determination result is associated with the corresponding data packet sequence number and data fragment position, triggering a transmission retry mechanism. The transmission retry mechanism retrieves the corresponding retransmission strategy according to the type of timeout data stream. The retransmission strategy includes the maximum number of retransmissions, the retransmission interval duration, and the retransmission data range. The maximum number of retransmissions refers to the maximum number of times a single data packet is allowed to be transmitted repeatedly, which is used to avoid infinite retransmissions that lead to resource consumption and transmission blockage. The retransmission interval duration refers to the waiting time between each retransmission, which is set according to the exponential backoff rule to avoid dense retransmissions in a short period of time that exacerbate network congestion. Both parameters are preset based on the real-time requirements of IoT card transmission and the network fluctuation level. Once the transmission retry mechanism is activated, the data packet segment corresponding to the timed-out data packet position is retransmitted to the server. During the retransmission process, a complete and unique index identifier and sequence number information are carried to ensure that the server can accurately identify the ownership and location of the retransmitted data segment.

[0042] The retransmission mechanism is executed a count, and the number of retransmissions is compared with the upper limit. If the number of retransmissions has not reached the upper limit, retransmission operations continue to be performed according to the retransmission interval. If the number of retransmissions reaches the upper limit and the server still fails to successfully receive the corresponding data packet segment, it is determined as a retransmission failure. The failed data packet segment is marked as an abnormal data segment. The abnormal data segment includes the data packet sequence number, data fragment content, data stream type, and transmission failure timestamp information. At the same time, an abnormal identifier is generated, which includes the abnormal level, abnormal cause, and retransmission count statistics. The abnormal identifier and the abnormal data segment are bound together and stored in the local storage area. The abnormal data segment is used for accurate positioning in the subsequent abnormal data repair process. For example, the abnormal data segment of the emergency alarm data stream is marked with the emergency repair needs associated with the alarm information, and the abnormal data segment of the real-time monitoring screen data stream is marked with the missing video frame repair needs.

[0043] Based on the anomaly identifier and the location of the lost data packet, abnormal data repair is initiated. First, the anomaly identifier is parsed to extract the data stream type, corresponding data packet sequence number, data fragment length, and transmission time interval information of the abnormal data fragment. Then, using the parsed information as search criteria, the original data index directory in the local backup storage area is traversed. The original data index directory uses a hierarchical index structure based on data stream type and data packet sequence number to accurately locate the original complete data fragment that perfectly matches the abnormal data fragment. The extraction process strictly adheres to the fragment length of the abnormal data fragment, ensuring that the length, encoding format, and message structure of the extracted data fragment are completely consistent with the abnormal data fragment. After extraction, the backup data fragment is processed. Format verification ensures compatibility with the protocol specifications of the current transmission link. Subsequently, a backup transmission channel, physically independent of the main transmission channel, is activated. The backup transmission channel uses an independent network access link and transmission protocol to avoid the impact of network fluctuations, link congestion, and carrier compatibility issues present in the main channel on the repair transmission. The backup data fragment is sent to the receiving end through the backup transmission channel. During the transmission process, it carries a unique index identifier, sequence number, and verification information that is completely identical to the abnormal data fragment, enabling the receiving end to accurately match the repair data fragment to the missing position in the original data stream. After the transmission is completed, the receiving end returns repair transmission confirmation information, which includes the reception status of the repair data fragment, the index matching result, and the verification result.

[0044] The repaired data fragments are compared with the original complete data fragments using both sequence numbers and content. The sequence number comparison process matches the sequence numbers of the repaired data fragments with those of the original complete data fragments one by one to ensure that the data fragments are not offset or duplicated in the complete data stream. The content comparison process uses a custom hash verification algorithm, the formula of which is: ,in, This indicates a preset standard hash function (such as SHA-256, CRC32 derived hash, etc.) used to map the preprocessed result into a fixed-length, irreversible hash value; This means compressing the result of the weighted sum to the range of a 32-bit unsigned integer; This is the hash check value. The content values ​​of the repaired data fragment. The verification coefficient ranges from 0.2 to 0.8. The hash verification value is compared with the pre-stored hash verification value of the original complete data segment. If the comparison results are consistent, the content of the repaired data segment is confirmed to be complete and error-free. If the comparison results are inconsistent, the backup data extraction and backup channel transmission repair operations are re-executed. After the sequence number and content are compared, the repaired data integrity status is generated. The data integrity status includes the integrity level, comparison result, repaired data range, and repair timestamp information. The data integrity status, complete data stream, anomaly identifier, and location of lost data packets form a complete data association chain, which is used to support the subsequent data transmission quality assessment and link optimization and adjustment process.

[0045] The above steps identify transmission anomalies through timeout monitoring, improve the retransmission success rate through multi-level retries, achieve accurate data repair by relying on backup storage and independent channels, and ensure repair accuracy with dual verification. This solves the problems of unrecoverable data transmission and low repair reliability after anomalies in IoT data transmission, and improves the stability and integrity of data backhaul.

[0046] S5. Based on the integrity status of the repaired data, perform integrity verification on the emergency alarm data and analyze the transmission log. When the alarm delay exceeds the preset delay threshold, dynamically adjust the bandwidth allocation ratio to obtain an optimized resource configuration scheme.

[0047] In one specific embodiment, performing step S5 includes the following steps: Based on the restored data integrity status, perform data integrity verification on the emergency alarm data, and verify whether the retransmitted data is complete and error-free by combining the location of the lost data packets; If so, extract the generation timestamp and reception timestamp of the emergency alarm data from the transmission log and calculate the alarm delay. When the alarm delay exceeds the preset delay threshold, it is marked as exceeding the delay limit. Based on the calibration results of excessive latency, analyze the current bandwidth allocation ratio and historical traffic peak data, and dynamically increase the bandwidth ratio of alarm data according to the transmission requirements of emergency alarm data; The adjusted bandwidth configuration is applied to the current transmission channel, alarm data transmission delay is monitored in real time, and the optimized resource configuration scheme is obtained after confirming that the alarm delay does not exceed the preset delay threshold.

[0048] Specifically, the restored data integrity status carries information such as data integrity level, comparison results, repaired data range, and repair timestamp. Based on this status, emergency alarm data integrity verification is initiated. The integrity verification is performed in conjunction with the previously located lost data packet positions. The verification process traverses all retransmitted data segments in the emergency alarm data, matching the unique index identifier and data packet sequence number of each retransmitted data segment with the original data sequence item by item. Simultaneously, the matching process verifies the encoding format, message length, and business field integrity of the data segments. The verification uses a Cyclic Redundancy Check (CRC) algorithm, with the following formula: Where D is the initial value of the 16-bit check register, set to 0xFFFF. D<<1 means shifting all binary bits of check register D to the left by 1 bit, filling the low bits with 0; D>>15 means shifting all binary bits of check register D to the right by 15 bits, keeping only the highest bit; (D>>15)&1 means extracting the highest bit value of check register D and checking if it is 1; ?0x1021:0 means a ternary operation, taking the value 0x1021 when the highest bit is 1, and taking the value 0 when it is 0; 0x1021 is the CRC-CCITT standard generator polynomial; ^ means binary bitwise XOR operation; = means reassigning the result after shifting and XORing to check register D. The verification bit is 16 bits. The verification process traverses the contents of the supplementary data segment bit by bit and performs iterative shift and XOR operations. After the operation is completed, the result is inverted to obtain the final verification value. When the final verification value is completely consistent with the original data pre-stored verification value, the supplementary data is considered to be complete and error-free. If they are inconsistent, the abnormal data repair process is restarted. The integrity verification result forms a fixed correspondence with the emergency alarm data, the location of the lost data packet, and the supplementary data segment, which is used to support subsequent alarm delay calculation and bandwidth adjustment operations.

[0049] After the emergency alarm data integrity verification passes, the generation timestamp and reception timestamp corresponding to the emergency alarm data are extracted from the transmission log. The generation timestamp represents the moment the emergency alarm data is generated at the IoT device, and the reception timestamp represents the moment the data is received at the server. The alarm delay is calculated by performing a time difference operation on the two types of timestamps, with the alarm delay measured in milliseconds. The alarm delay is bound to the device identifier, alarm type, and transmission link information of the emergency alarm data and stored in a specific order. The alarm delay is then compared with a preset delay threshold, also measured in milliseconds, which is set according to the emergency alarm response requirements of the IoT service. It can be dynamically configured according to business scenarios. For example, it can be set to 1000ms in industrial equipment fault alarm scenarios and 500ms in security intrusion alarm scenarios. When the alarm delay is less than or equal to the preset delay threshold, the existing transmission parameters remain unchanged. When the alarm delay is greater than the preset delay threshold, it is marked as exceeding the delay limit. The delay exceeding the limit mark is associated with the corresponding emergency alarm data, alarm delay value, and transmission link identifier to trigger subsequent bandwidth allocation ratio adjustment operations. For example, in industrial scenarios, the delay exceeding the limit mark of emergency alarm data is directly associated with the equipment fault response efficiency, and in security scenarios, the delay exceeding the limit mark is associated with the timeliness of abnormal event handling.

[0050] Based on the calibration results of excessive latency, the bandwidth allocation ratio of the current transmission channel is retrieved. This ratio includes the bandwidth share occupied by emergency alarm data, real-time monitoring data, and other service data. Simultaneously, historical traffic peak data is extracted, containing traffic fluctuation values, bandwidth utilization, and transmission congestion frequency information for different time periods. The current bandwidth allocation ratio and historical traffic peak data are then input into the bandwidth optimization algorithm. The algorithm formula is as follows: ,in To adjust the bandwidth ratio of alarm data, B represents the current bandwidth weight, and B represents the current bandwidth ratio of alarm data, which is obtained in real time by the transmission scheduling node. B is the ratio of the current bandwidth occupied by emergency alarm data to the total transmission bandwidth. A represents the peak traffic weight, and A is the peak traffic correction coefficient, which is calculated by normalizing historical peak traffic data. It is used to characterize the correction strength of bandwidth allocation based on the degree of traffic congestion. The higher the degree of congestion, the larger the correction coefficient. The algorithm increases the corresponding bandwidth ratio based on the transmission priority and real-time requirements of emergency alarm data, while simultaneously reducing the bandwidth allocation share of non-critical business data to maintain a balanced total bandwidth resource. The adjusted bandwidth allocation ratio is correlated with the latency exceedance flag and historical peak traffic data, and is used for the resource reallocation of the transmission channel.

[0051] The adjusted bandwidth allocation ratio will be sent to the scheduling nodes of the transmission links. The scheduling nodes will then allocate time slots and map resource blocks to physical channel resources according to the new ratio. Dedicated transmission time slots and resource blocks will be allocated to emergency alarm data, while real-time monitoring screen data and other service data will use the remaining time slots and resource blocks. During the resource allocation process, dedicated resources for emergency alarm data will be locked to prevent other non-critical data from preempting them. After the bandwidth configuration takes effect, the transmission delay of emergency alarm data will be collected at fixed intervals, consistent with the network status monitoring cycle. Each collection will synchronously record the generation timestamp, transmission timestamp, and reception timestamp, and calculate the real-time delay. Each set of real-time delay data will be compared in real-time with a preset delay threshold. When multiple sets of collected data meet the latency requirements, the bandwidth adjustment is considered stable. If latency still exceeds the limit, the bandwidth optimization algorithm is iterated again based on the current latency value. The bandwidth ratio of emergency alarm data is slightly increased, and the resource configuration and latency monitoring process is repeated until the latency value is consistently within the preset latency threshold range. Finally, the stable and effective bandwidth allocation ratio, resource scheduling rules, time slot configuration parameters, latency monitoring records, and adjustment iteration records are integrated to form an optimized resource configuration scheme. This scheme is strongly correlated with the emergency alarm data transmission requirements, transmission link status, and traffic change characteristics. It can be directly reused in similar network environments and serves as the basis for subsequent transmission quality assessment and path optimization.

[0052] The above steps ensure the accuracy of alarm data through integrity verification, calculate the delay status based on timestamp calculation, and dynamically adjust the bandwidth and continuously iterate and optimize in combination with traffic data to solve the problem of delay caused by insufficient bandwidth in emergency alarms, thereby improving the real-time performance of critical data transmission and the rationality of resource allocation.

[0053] S6. Based on the optimized resource configuration scheme, simulate transmission lag for real-time monitoring screen data, analyze the lag probability in combination with the stability assessment results, determine whether the transmission stability meets the business requirements, and determine the transmission quality assessment results.

[0054] In one specific embodiment, performing step S6 includes the following steps: Based on the optimized resource allocation scheme, network fluctuation simulation is applied to the real-time monitoring screen data to reproduce the screen stuttering phenomenon during the transmission process; The number of interruptions and the duration of interruptions in the simulated transmission of video data are statistically analyzed, and the probability of video stuttering is calculated by combining the stability assessment results and the location of lost data packets. The probability of stuttering is compared with the preset standards of the service to determine whether the current transmission stability meets the requirements of the service. Based on the comparison results, the network operation indicators are comprehensively scored to form a transmission quality assessment result that includes lag rate, stability, and latency.

[0055] Specifically, the optimized resource allocation scheme carries information such as bandwidth allocation ratio, resource scheduling rules, time slot configuration parameters, and latency monitoring records. Based on this scheme, network fluctuation simulation is applied to the real-time monitoring screen data. The network fluctuation simulation sets fluctuation parameters according to the network change characteristics in the actual operating environment of IoT devices. The fluctuation parameters include signal strength fluctuation amplitude, transmission delay jitter range, packet loss rate range, and instantaneous bandwidth compression ratio. The network fluctuation simulation reproduces the screen stuttering phenomenon during transmission by dynamically changing the transmission rate, packet sending interval, and data fragmentation transmission sequence of the real-time monitoring screen data. The screen stuttering phenomenon corresponds to the increased frame interval, missing video frames, and screen freeze state during the transmission of real-time monitoring screen data. The network fluctuation simulation is adapted to the encoding format, resolution, and frame rate of the real-time monitoring screen data. The simulation process does not change the original content of the real-time monitoring screen data, but only adjusts the data transmission state to match the transmission performance in the real network environment. The execution cycle of the network fluctuation simulation is synchronized with the collection cycle of the stability assessment results. The simulation process continuously records the changes in the transmission state of the real-time monitoring screen data, providing a basis for subsequent stuttering-related data statistics.

[0056] During simulated transmission, the number of interruptions and the duration of interruptions in the video data are continuously recorded. The number of interruptions corresponds to the number of frame transmission interruptions that occur during the real-time monitoring video data transmission, and the interruption duration corresponds to the duration of a single frame transmission interruption. The number of interruptions and the interruption duration are stored in time sequence and correlated with the frame sequence number of the real-time monitoring video data. Combined with the stability assessment results obtained earlier and the location of lost data packets, the probability of video stuttering is calculated. The stability assessment results include the network's continuous transmission capability, signal strength fluctuation value, network latency jitter value, data packet retransmission rate, and connection hold time quantified values. The location of lost data packets corresponds to the location of missing frame data during the real-time monitoring video data transmission. The stuttering probability calculation adopts an exponential weighted calculation method based on transmission anomaly factors. The algorithm formula is as follows: ,in Let e ​​be the probability of a lag, and e be the natural constant. As an interruption frequency weight, As an interruption duration weight, For network stability weights, all three are normalized preset weights and satisfy the following conditions: Preferably, the default value for general scenarios is... ; This is a standardized value for the number of interruptions per unit time. This is the standardized value of the average duration of a single interruption. As the inverse mapping value of the stability assessment result, the algorithm exponentially weights and fuses three factors: interruption frequency, interruption duration, and network stability. The exponential function amplifies the impact of transmission anomalies on lag. At the same time, the algorithm corrects the calculation result by combining the impact level of the screen frame corresponding to the location of lost data packets. This yields the lag probability of real-time monitoring screen data under the current resource configuration. The lag probability forms a complete data correlation chain with real-time monitoring screen data, interruption count, interruption duration, stability assessment result, and location of lost data packets.

[0057] The calculated stuttering probability is compared with the value of the business preset standard. The business preset standard is set according to the application scenario transmission requirements of the real-time monitoring screen data. The business preset standard represents the upper limit of the stuttering probability allowed to meet the normal display of the screen. When the stuttering probability is lower than the business preset standard, it is determined that the current transmission stability meets the business usage requirements. When the stuttering probability is higher than the business preset standard, it is determined that the current transmission stability does not meet the business usage requirements. The compliance judgment result is bound to the real-time monitoring screen data, stuttering probability, and business preset standard. The compliance judgment result is used to guide the subsequent comprehensive scoring of transmission quality and the optimization and adjustment of transmission parameters. For example, the compliance judgment result in the security monitoring scenario is directly related to the continuity of screen monitoring, and the compliance judgment result in the industrial visualization scenario is related to the effectiveness of equipment operation status monitoring.

[0058] Based on the comparison between the stuttering probability and the preset service standards, a comprehensive score is applied to network operation indicators. These indicators include three core categories: stuttering rate, stability, and latency. The stuttering rate is derived from the stuttering probability, stability from the stability assessment results, and latency from previous transmission delay monitoring data. The comprehensive score uses a geometric weighted scoring algorithm, the formula of which is: E represents the overall score. Rate the stuttering rate. Weighted by stuttering rate, For stability rating, For stability weights, For latency scoring, As a latency weight, the three weights are normalized and set according to the real-time and smoothness requirements of the business to meet the requirements. Prioritize scene selection from surveillance footage Real-time alarm priority scenarios Default value for general scenarios The algorithm uses a geometric weighting method to highlight the contribution of low stuttering rate and high stability to transmission quality, avoiding the abnormal bias of a single indicator on the overall score. The score results maintain a continuous range distribution. The comprehensive score, along with stuttering rate, stability, and latency values, forms the transmission quality assessment result. The transmission quality assessment result fully records the transmission performance of real-time monitoring screen data under the current resource configuration scheme. The transmission quality assessment result is linked and stored with the optimized resource configuration scheme, real-time monitoring screen data, stuttering probability, and compliance judgment results to support subsequent data stream splitting and transmission path optimization operations.

[0059] The above steps simulate and reproduce the stuttering state through network fluctuations, calculate the stuttering probability based on the exponential weighting algorithm, and complete the quality evaluation using geometric weighting scoring. This solves the problems of stuttering in video transmission and the inability to objectively quantify transmission quality, thereby improving the rationality of the evaluation results and the smoothness of video transmission.

[0060] S7. Based on the transmission quality assessment results, the emergency alarm data and real-time monitoring screen data are processed separately. Combined with the transmission logs, it is determined whether the decision response speed meets the business requirements, and the overall transmission real-time guarantee status is determined.

[0061] In one specific embodiment, performing step S7 includes the following steps: Based on the transmission quality assessment results, data stream splitting is performed according to the principle of prioritizing emergency alarm data and then real-time monitoring screen data; Based on the split transmission channel, extract the time information of the emergency alarm trigger time and the corresponding real-time monitoring screen transmission interruption point, calculate the time interval between the two and compare it with the preset response threshold to determine whether there is a response delay. If so, then parse the jump information of the transmission path nodes of the split data stream and locate the delay node; Optimize the transmission path based on the delayed nodes to reduce the number of hops and shorten the transmission latency. Combine the transmission log statistics to calculate the total decision response time after optimization. The total decision response time is compared with the real-time requirements of the business to determine the overall real-time transmission guarantee status.

[0062] Specifically, the transmission quality assessment results include a comprehensive score, stuttering rate, stability, and latency-related quantitative values. These results serve as the configuration basis for data stream offloading. Transmission channels are allocated according to the principle of prioritizing emergency alarm data and then real-time monitoring screen data. Offloading allocates independent transmission links based on data service attributes. Emergency alarm data is assigned to low-latency, high-reliability transmission channels, while real-time monitoring screen data is assigned to high-bandwidth, high-throughput transmission channels. The two types of transmission channels are physically isolated to avoid mutual interference. The offloading process assigns the highest transmission priority flag to emergency alarm data and a secondary transmission priority flag to real-time monitoring screen data. The transmission priority flags are written into the packet header field. Network transmission nodes perform data forwarding scheduling based on the priority flags. The forwarding sequence of emergency alarm data is always earlier than that of real-time monitoring screen data. The status of the offloaded transmission channels forms a fixed correspondence with the transmission quality assessment results, data types, and transmission priority flags, providing a transmission environment basis for subsequent response speed determination.

[0063] Based on the split transmission channel, the time information of the emergency alarm trigger time and the corresponding real-time monitoring screen transmission interruption point is extracted from the transmission log. The emergency alarm trigger time represents the time when the emergency alarm data is generated at the IoT device, and the real-time monitoring screen transmission interruption point represents the time when the corresponding screen data transmission is interrupted. The time difference between the two types of time information is calculated to obtain the time interval. The time interval represents the response time from the triggering of the emergency alarm to the interruption of the corresponding screen transmission. The time interval is bound to the emergency alarm data, real-time monitoring screen data, and transmission channel identifier. The time interval is compared with a preset response threshold. The preset response threshold is set according to the real-time response requirements of IoT services. If the time interval is less than or equal to the preset response threshold, it is determined that there is no response delay. If the time interval is greater than the preset response threshold, it is determined that there is a response delay. The delay determination result is associated with the time interval, the emergency alarm trigger time, and the real-time monitoring screen transmission interruption point, which is used to trigger subsequent transmission path parsing and optimization operations.

[0064] When a response delay exists, the node jump information of the transmission path of the split data stream is parsed. The node jump information includes the network node identifiers traversed by the data stream, the transmission delay between nodes, the number of node jumps, and the node processing time. The parsing process traverses all node information according to the data stream transmission order, records the input and output times of each node, and calculates the single node processing delay by the time difference. When the single node processing delay exceeds the node delay limit, it is marked as a delayed node. The node delay limit is set according to the hardware processing capability of the network node, and is usually set to 50ms~200ms. Specifically, it is set to 50ms~100ms in alarm real-time priority scenarios, 100ms~200ms in monitoring screen priority scenarios, and 120ms by default in general scenarios. The delay node location adopts the path delay contribution calculation method. The specific calculation logic is that the node delay contribution is equal to the single node processing delay multiplied by the corresponding weight, plus the node hop frequency multiplied by the corresponding weight. This calculation comprehensively considers the processing time of a single node and the frequency of the node being repeatedly passed on the entire transmission path. All network nodes are arranged from high to low according to the calculated delay contribution value. The node with the highest delay contribution value is the core delay node causing the overall transmission delay. The core delay node is associated with the transmission path, hop information, and single node processing delay to guide the transmission path optimization operation.

[0065] Based on the identified delay nodes, transmission path optimization is performed. This optimization process removes core delay nodes, re-plans data flow transmission routes, and selects alternative paths with fewer hops and lower node processing latency. Transmission path optimization follows the rules of shortening transmission latency and reducing node hops. The optimized transmission path maintains the channel attribute of prioritizing emergency alarm data transmission. After path optimization, the total decision response time is calculated. The total decision response time is obtained by accumulating multiple time-series data segments, specifically including the time spent generating emergency alarm data at the terminal, the encapsulation time before data enters the transmission channel, and the time spent between nodes in the optimized transmission path. The link transmission time, the processing time of all relay nodes for data packets, and the parsing time after the server receives the data are all calculated. Each segment of time is obtained by extracting the corresponding timestamp from the transmission log and subtracting adjacent time points. The generation time, encapsulation time, link transmission time, node processing time, and parsing time are sequentially accumulated. The total time obtained is the total decision response time. The total decision response time fully reflects the entire process from alarm triggering to platform identification. This time is associated with the optimized transmission path, delayed nodes, number of jumps, and the time of each segment and stored in a related manner for subsequent real-time assurance status determination.

[0066] The total decision response time is compared with the real-time requirements of the business. The real-time requirements represent the upper limit of the response time required for the normal operation of IoT services. When the total decision response time is less than or equal to the real-time requirements of the business, the overall transmission real-time guarantee status is deemed to be up to standard. When the total decision response time is greater than the real-time requirements of the business, the overall transmission real-time guarantee status is deemed to be down to standard, and transmission path optimization and traffic splitting strategy adjustment operations need to be performed again. The real-time guarantee status includes the compliance indicator, the total decision response time, transmission path parameters, and traffic splitting configuration information. The real-time guarantee status, transmission quality assessment results, traffic splitting strategies, and optimized transmission paths form a complete data association chain to support the transmission strategy iteration and performance improvement of the overall IoT card data backhaul system.

[0067] The above steps ensure the priority transmission of critical data through priority routing, determine response delay based on time difference, locate delay nodes and optimize paths based on delay contribution, shorten the overall response time, solve the problems of data transmission congestion and decision response lag in multi-network convergence scenarios, and improve the real-time performance and reliability of IoT data backhaul.

[0068] Please see Figure 2 , Figure 2 The graph shows the network intelligent switching triggering result. The graph uses time as the horizontal axis and switching triggering state as the vertical axis. A value of 1 indicates that network switching is performed and 0 indicates that the normal network connection is maintained. The curve changes over time to show the distribution of triggering states, which shows the timing and execution of multi-network switching when the network signal strength is below the threshold. This demonstrates that the network switching triggering mechanism has real-time performance and effectiveness, and can respond quickly according to the signal degradation state. It shows that this application ensures the continuity of IoT card transmission through intelligent network switching.

[0069] Please see Figure 3 , Figure 3 The graph shows the time-series comparison results of transmission stability. The graph uses time as the horizontal axis and transmission stability value as the vertical axis. It also plots the comparison curves of the traditional method and the proposed method, showing the transmission stability fluctuation trend and numerical difference of the two schemes under the same time dimension. This demonstrates that the proposed method has higher and more stable transmission stability than the traditional method, which can alleviate transmission anomalies caused by network fluctuations. It also verifies that the proposed method can improve transmission reliability through handover control, compatibility verification, and stability assessment.

[0070] Please see Figure 4 , Figure 4The graph shows the cumulative distribution of transmission delay. It plots transmission delay on the horizontal axis and cumulative percentage on the vertical axis, marking the baselines of 50ms and 100ms and comparing the distribution curves of the traditional method and the present method. The graph shows that the transmission delay of the present method is more concentrated in the low-latency range, and the cumulative percentage is better than that of the traditional method. This demonstrates that the present application can effectively reduce data return delay and meet the low latency requirements of emergency alarm services. It also verifies that the present application can improve transmission real-time performance through priority scheduling, bandwidth optimization, and path optimization.

[0071] Please see Figure 5 The following describes the IoT card data backhaul system based on multi-network convergence in the embodiments of this application. The IoT card data backhaul system based on multi-network convergence includes: The data acquisition and detection module is used to collect emergency alarm data and real-time monitoring screen data from IoT devices, perform network signal strength detection on the data stream, and perform intelligent network switching when the network signal strength is lower than a preset strength threshold, and determine the network connection status after switching. The handover control module is used to control handover delay and enable transmission interruption protection based on the network connection status after handover, apply network handover priority rules to emergency alarm data, perform cross-carrier compatibility verification, and determine the stability assessment results. The data reconstruction module is used to perform packet loss detection and verification on real-time monitoring screen data and emergency alarm data based on the stability assessment results, and to obtain a complete data stream through fragment reconstruction processing. The anomaly repair module is used to apply the transmission timeout retry strategy to the complete data stream and use the feedback mechanism to identify transmission anomalies. When an anomaly is detected, the abnormal data repair is initiated, and the integrity status of the repaired data is determined. The bandwidth optimization module is used to perform integrity verification on emergency alarm data and analyze transmission logs based on the integrity status of the repaired data. When the alarm delay exceeds the preset delay threshold, the bandwidth allocation ratio is dynamically adjusted to obtain an optimized resource configuration scheme. The quality assessment module is used to simulate transmission lag in real-time monitoring screen data based on the optimized resource configuration scheme, analyze the probability of lag in combination with the stability assessment results, determine whether the transmission stability meets the business requirements, and determine the transmission quality assessment result. The traffic splitting and protection module is used to split emergency alarm data and real-time monitoring screen data according to the transmission quality assessment results, and to determine whether the decision response speed meets the business requirements by combining the transmission logs, and to determine the overall transmission real-time protection status.

[0072] Through the collaborative efforts of the aforementioned components, this system constructs a closed-loop management system for the entire process of IoT card data backhaul under multi-network convergence. It achieves reliable, real-time, and efficient backhaul of emergency alarm data and real-time monitoring screen data, resolving technical issues such as multi-network switching link interruptions, critical data transmission delays, lag, packet loss, and unreasonable resource allocation. Specifically: the data acquisition stage accurately captures two types of core data, providing raw data support for subsequent processing. Combined with multi-network compatibility verification, it adapts to different operator network environments, avoiding transmission anomalies caused by insufficient network adaptability. In the packet loss detection and fragmentation reassembly stage, packet loss locations are located by comparing sequence numbers packet by packet. Relying on fixed fragmentation, unique indexes, and cache padding, data integrity is restored. Combined with a cyclic redundancy check algorithm, it ensures that retransmitted data is complete and unaltered. In the transmission timeout retry and anomaly repair stage, real-time timeout monitoring and multi-level retry mechanisms improve the retransmission success rate. Utilizing local backup storage and independent backup transmission channels, it achieves precise repair of abnormal data. The system addresses the challenge of unrecoverable data after transmission anomalies. In the dynamic bandwidth adjustment phase, based on alarm latency and traffic data, a weighted optimization logic adjusts the bandwidth allocation ratio, prioritizing emergency alarm data transmission and mitigating latency issues caused by insufficient bandwidth. In the stuttering simulation and quality assessment phase, network fluctuations are simulated to reproduce real-world transmission scenarios. An exponential weighted algorithm quantifies stuttering probabilities, and a geometric weighted scoring method generates an objective transmission quality assessment, providing a basis for traffic offloading. In the traffic offloading and path optimization phase, independent transmission channels are allocated according to priority. Delay nodes are located through path node resolution and latency contribution calculation, optimizing transmission routes to reduce hop counts and shorten overall process time. Finally, the total decision response time is compared to determine the real-time performance status, forming a complete collaborative link of "collection-verification-transmission-optimization-evaluation." This ensures the system maintains stable, real-time, and accurate data transmission even in complex network environments, meeting the core data transmission requirements of IoT services.

[0073] This application also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the IoT card data backhaul method based on multi-network convergence.

[0074] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the methods and systems described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0075] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for data backhaul of IoT cards based on multi-network convergence, characterized in that, Includes the following steps: S1. Collect emergency alarm data and real-time monitoring screen data from IoT devices, perform network signal strength detection on the data stream, and perform intelligent network switching when the network signal strength is lower than the preset strength threshold, and determine the network connection status after switching. S2. Based on the network connection status after the switch, control the switching delay and enable transmission interruption protection. Apply network switching priority rules to emergency alarm data, perform cross-carrier compatibility verification, and determine the stability assessment results. S3. Based on the stability assessment results, packet loss detection and verification are performed on the real-time monitoring screen data and emergency alarm data, and fragmentation and reconstruction processing is used to obtain a complete data stream. S4. Apply a transmission timeout retry strategy to the complete data stream and use a feedback mechanism to identify transmission anomalies. When an anomaly is detected, start abnormal data repair and determine the data integrity status after repair. S5. Based on the integrity status of the repaired data, perform integrity verification on the emergency alarm data and analyze the transmission log. When the alarm delay exceeds the preset delay threshold, dynamically adjust the bandwidth allocation ratio to obtain an optimized resource configuration scheme. S6. Based on the optimized resource configuration scheme, simulate transmission lag for real-time monitoring screen data, analyze the lag probability in combination with the stability assessment results, determine whether the transmission stability meets the business requirements, and determine the transmission quality assessment results. S7. Based on the transmission quality assessment results, the emergency alarm data and real-time monitoring screen data are processed separately. Combined with the transmission logs, it is determined whether the decision response speed meets the business requirements, and the overall transmission real-time guarantee status is determined.

2. The method according to claim 1, characterized in that, Step S1 includes: Emergency alarm data and real-time monitoring data are obtained from IoT devices. Key information about network transmission is extracted by analyzing the data flow to determine the stability of the data flow transmission. Based on the transmission stability of the data stream, network signal strength detection is performed on the data stream to determine whether the network signal strength is lower than a preset strength threshold. If so, then combine the operator's network coverage data to obtain a list of currently available networks; Based on the list of available networks, the priority of each operator's network is sorted according to the handover conditions to determine the optimal target network for handover. Based on the optimal target network for handover, an intelligent handover process is initiated and the network connection status is updated. The signal strength and data flow stability after handover are continuously monitored to obtain the network connection status after handover.

3. The method according to claim 1, characterized in that, Step S2 includes: Based on the switched network connection status, obtain the current network latency parameter and determine whether the current network latency parameter is greater than the preset time limit. If so, it is determined that there is a risk of network transmission delay and the delay control is switched. At the same time, the transmission interruption protection mechanism is activated, the buffering strategy is adjusted, and the protection activation status is determined. Based on the protection activation status, apply network switching priority rules to the emergency alarm data to determine the alarm flow priority; Based on the alarm flow priority, cross-carrier compatibility verification is performed to analyze the degree of support of each network for the alarm flow priority and determine the compatibility compliance. Based on the compatibility compliance, monitor the network status and collect connection metrics, and determine the stability assessment result based on the connection metrics.

4. The method according to claim 1, characterized in that, Step S3 includes: Based on the stability assessment results, the sequence numbers of the emergency alarm data and the real-time monitoring screen data are compared packet by packet to identify and locate the location of lost data packets during transmission. Based on the location of the lost data packets, a fixed-size fragmentation mechanism is used to segment the data stream, and a unique index identifier is added to each data fragment to generate a set of segmented transmission units. Based on the location of the lost data packet and the unique index identifier, the segmented transmission units are sequentially reassembled and the missing positions are filled with data. A second verification is performed on the data stream after reorganization and padding to obtain a complete data stream after confirming that there is no missing data.

5. The method according to claim 4, characterized in that, Step S4 includes: The transmission timeout of the complete data stream is monitored, and the data stream sending time and server receiving time are recorded in real time, and the time interval between sending and receiving is calculated. If the time interval exceeds the preset time threshold, it is determined to be a transmission timeout, and the transmission retry mechanism is activated to retransmit the data packet segment corresponding to the location of the lost data packet to the server. If a data packet fragment is not successfully received after transmission, the data packet fragment is marked as an abnormal data fragment, and the abnormality identifier is recorded. Based on the anomaly identifier and the location of the lost data packet, the corresponding complete data segment is extracted from the local backup storage unit, and the anomaly data repair is performed through the backup transmission channel. The sequence number and content of the repaired data fragments are compared with those of the original data to determine the integrity status of the repaired data.

6. The method according to claim 1, characterized in that, Step S5 includes: Based on the restored data integrity status, perform data integrity verification on the emergency alarm data, and verify whether the retransmitted data is complete and error-free by combining the location of the lost data packets; If so, the generation timestamp and reception timestamp of the emergency alarm data are extracted from the transmission log and the alarm delay is calculated. When the alarm delay exceeds the preset delay threshold, it is marked as a delay exceeding the standard. Based on the calibration results of excessive latency, analyze the current bandwidth allocation ratio and historical traffic peak data, and dynamically increase the bandwidth ratio of alarm data according to the transmission requirements of emergency alarm data; The adjusted bandwidth configuration is applied to the current transmission channel, alarm data transmission delay is monitored in real time, and the optimized resource configuration scheme is obtained after confirming that the alarm delay does not exceed the preset delay threshold.

7. The method according to claim 1, characterized in that, Step S6 includes: Based on the optimized resource allocation scheme, network fluctuation simulation is applied to the real-time monitoring screen data to reproduce the screen stuttering phenomenon during transmission; The number of interruptions and the duration of interruptions in the simulated transmission of image data are statistically analyzed, and the probability of image stuttering is calculated by combining the stability assessment results with the location of lost data packets. The probability of stuttering is compared with the preset service standard to determine whether the current transmission stability meets the service requirements. Based on the comparison results, the network operation indicators are comprehensively scored to form a transmission quality assessment result that includes lag rate, stability, and latency.

8. The method according to claim 1, characterized in that, Step S7 includes: Based on the transmission quality assessment results, data stream splitting is performed according to the principle of prioritizing emergency alarm data and then real-time monitoring screen data; Based on the transmission channel after the traffic split, extract the time information of the emergency alarm trigger time and the corresponding real-time monitoring screen transmission interruption point, calculate the time interval between the two and compare it with the preset response threshold to determine whether there is a response delay. If so, then parse the jump information of the transmission path nodes of the split data stream and locate the delay node; Optimize the transmission path based on the delay nodes to reduce the number of hops and shorten the transmission latency, and combine the transmission log statistics to calculate the total decision response time after optimization. The total decision response time is compared with the real-time requirements of the business to determine the overall real-time transmission guarantee status.

9. A multi-network converged IoT card data backhaul system, used to implement the multi-network converged IoT card data backhaul method as described in any one of claims 1 to 8, characterized in that, The IoT card data backhaul system based on multi-network convergence includes: The data acquisition and detection module is used to collect emergency alarm data and real-time monitoring screen data from IoT devices, perform network signal strength detection on the data stream, and perform intelligent network switching when the network signal strength is lower than a preset strength threshold, and determine the network connection status after switching. The handover control module is used to control handover delay and enable transmission interruption protection based on the network connection status after handover, apply network handover priority rules to emergency alarm data, perform cross-carrier compatibility verification, and determine the stability assessment results. The data reconstruction module is used to perform packet loss detection and verification on real-time monitoring screen data and emergency alarm data based on the stability assessment results, and to obtain a complete data stream by using fragment reconstruction processing. The anomaly repair module is used to apply a transmission timeout retry strategy to the complete data stream and use a feedback mechanism to identify transmission anomalies. When an anomaly is detected, the module initiates anomaly data repair and determines the data integrity status after repair. The bandwidth optimization module is used to perform integrity verification on emergency alarm data and analyze transmission logs based on the integrity status of the repaired data. When the alarm delay exceeds the preset delay threshold, the bandwidth allocation ratio is dynamically adjusted to obtain an optimized resource configuration scheme. The quality assessment module is used to simulate transmission lag in real-time monitoring screen data based on the optimized resource configuration scheme, analyze the lag probability in combination with the stability assessment results, determine whether the transmission stability meets the business requirements, and determine the transmission quality assessment result. The traffic splitting and protection module is used to split emergency alarm data and real-time monitoring screen data according to the transmission quality assessment results, and to determine whether the decision response speed meets the business requirements by combining the transmission logs, thereby determining the overall transmission real-time protection status.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instruction is executed by the processor, it implements the IoT card data backhaul method based on multi-network convergence as described in any one of claims 1-8.

Images