An offline cache data differential backhaul method, system, terminal and medium

Abstract

This invention belongs to the field of IoT communication technology and discloses a method, system, terminal, and medium for differential backhaul of offline cached data. The method includes: when the current network status is detected as offline, acquiring service data; wherein the service data is any one or more of location data, heartbeat data, and alarm data; writing the service data into local storage based on data type to obtain an independent cache queue corresponding to the data type; when the current network status is detected as online, acquiring the communication link status with the target server; retrieving the independent cache queue from the local storage and reassembling the service data in the independent cache queue; and uploading the reassembled service data to the target server according to a preset priority rule based on the communication link status. This invention achieves high efficiency and integrity of offline data transmission after network recovery of IoT terminal devices by implementing a data type-based differential pruning strategy.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and in particular to a differential backhaul method, system, terminal, and medium for offline cached data. Background Technology

[0002] IoT terminal devices (such as wearable devices, smart sensors, and vehicle positioning terminals) often go offline for extended periods while on the move due to entering signal dead zones (such as basements, tunnels, and remote mountainous areas). Once the network connection is restored, the terminal needs to send the accumulated but unuploaded data back to the server.

[0003] In existing technologies, terminals typically employ one of the following two strategies after reconnecting: (1) Full data upload strategy, uploading all location data, heartbeat data, and alarm data accumulated during offline periods to the server. While this strategy ensures data integrity, it can trigger a severe data storm when the data volume is large: a large number of concurrent uploads in a short period of time can cause instantaneous server overload, bandwidth resources to be heavily occupied, and may even cause server response delays or reconnection due to traffic surges. (2) Simple discard strategy, retaining only the latest few data entries and discarding the rest of the historical data. While this strategy can reduce the amount of data, it has a serious problem of information loss, especially for security alarm data, any loss of which may lead to untraceable security incidents. In addition, existing technologies usually use a uniform compression or cropping method for data of different business types, without considering the differences in business value and timeliness of different data types, which wastes transmission resources and cannot guarantee the integrity of critical data.

[0004] Existing technologies still have the problem that after IoT terminal devices regain connection, data transmission is difficult to balance transmission efficiency and data integrity. Therefore, existing technologies need to be improved. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a differential backhaul method for offline cached data in order to address the shortcomings of the existing technology, thereby solving the problem that existing IoT terminal devices cannot balance transmission efficiency and data integrity in data transmission after reconnection.

[0006] The technical solution adopted by this invention to solve the technical problem is as follows: In a first aspect, the present invention provides a method for differential backhaul of offline cached data, comprising: When the current network status is detected as offline, business data is acquired; wherein, the business data is any one or more of location data, heartbeat data, and alarm data; The business data is written to the local storage based on the data type to obtain an independent cache queue corresponding to the data type; When the current network status is switched to online, obtain the communication link status with the target server; The independent cache queue is retrieved from the local storage, and the business data in the independent cache queue is reorganized. Based on the communication link status, the reassembled service data is uploaded to the target server according to a preset priority rule.

[0007] In one implementation, the independent cache queue is any one or more of an initial location data queue, an initial heartbeat data queue, and an initial alarm data queue, and the reorganization process of the business data in the independent cache queue includes: An adaptive sparse pruning strategy is applied to the initial positioning data queue to obtain the target positioning data queue; A tail-pruning strategy is performed on the initial heartbeat data queue to obtain the target heartbeat data; A characteristic compression strategy is applied to the initial alarm data queue to obtain the target alarm data queue.

[0008] In one implementation, the step of performing an adaptive sparse pruning strategy on the initial positioning data queue to obtain the target positioning data queue includes: Obtain the motion state parameters of each historical positioning point in the initial positioning data queue; Based on the acquired motion state parameters, calculate the change in motion state parameters of each historical positioning point relative to the previous historical positioning point. Determine whether the change in the motion state parameters is greater than a preset threshold for the change in motion state parameters; The latest positioning point and the positioning points in the positioning data queue whose motion state parameter changes are greater than a preset motion state parameter change threshold are retained. Obtain the target location data queue.

[0009] In one implementation, the step of performing a tail-pruning strategy on the initial heartbeat data queue to obtain the target heartbeat data includes: Retain the single heartbeat data with the latest timestamp in the initial heartbeat data queue, and discard other heartbeat data in the initial heartbeat data queue; The single heartbeat data point that is retained is used as the target heartbeat data.

[0010] In one implementation, the step of performing a feature-based compression strategy on the initial alarm data queue to obtain the target alarm data queue includes: Remove the service load segment of all alarm data in the initial alarm data queue to obtain the effective alarm data queue; Obtain the alarm feature code of the alarm event corresponding to the alarm data in the valid alarm data queue, and construct the alarm message based on the obtained alarm feature code; Obtain the target alarm data queue containing all alarm messages.

[0011] In one implementation, the communication link state includes congestion status and signal quality parameters. The step of uploading the reassembled service data to the target server according to a preset priority rule based on the communication link state includes: When the congestion state is a congestion state or the signal quality parameter does not meet the preset signal quality parameter threshold, the alarm data queue and the target heartbeat data are uploaded sequentially. When the congestion state is non-congestion state and the signal quality parameters meet the preset signal quality parameter threshold, the alarm data queue, the target heartbeat data and the target location data queue are uploaded sequentially.

[0012] In one implementation, the differential data backhaul method for offline cached data further includes: During the process of uploading the reconstructed business data to the target server according to the preset priority upload rules, if the current network status is detected to switch to offline, the reconstructed business data is marked as a breakpoint. When the current network status switches back to online, the reconstructed business data is uploaded to the target server according to the preset priority upload rules based on the breakpoint.

[0013] Secondly, the present invention provides a differential data return system for offline cached data, comprising: The offline data acquisition module is used to acquire business data when the current network status is offline; wherein, the business data is any one or more of location data, heartbeat data, and alarm data; An offline data storage module is used to write the business data into local storage based on the data type, thereby obtaining an independent cache queue corresponding to the data type. The communication link status acquisition module is used to acquire the communication link status with the target server when the current network status switches to online. The queue data reorganization processing module is used to retrieve the independent cache queue from the local storage and reorganize the business data in the independent cache queue. The queue data upload module is used to upload the reassembled business data to the target server according to a preset priority rule based on the communication link status.

[0014] Thirdly, the present invention provides a terminal, comprising: a processor and a memory, wherein the memory stores an offline cached data differential return program, and the offline cached data differential return program, when executed by the processor, is used to implement the operation of the offline cached data differential return method as described in the first aspect.

[0015] Fourthly, the present invention also provides a computer-readable storage medium storing an offline cached data differential return program, which, when executed by a processor, is used to implement the operation of the offline cached data differential return method as described in the first aspect.

[0016] The present invention, by employing the above technical solution, has the following effects: This invention discloses a differential backhaul method, system, terminal, and medium for offline cached data, comprising: when the current network status is detected as offline, acquiring service data; wherein the service data is any one or more of location data, heartbeat data, and alarm data; writing the service data into local storage based on the data type to obtain an independent cache queue corresponding to the data type; when the current network status is detected as online, acquiring the communication link status with the target server; retrieving the independent cache queue from the local storage and reassembling the service data in the independent cache queue; and uploading the reassembled service data to the target server according to a preset priority rule based on the communication link status. This invention achieves high efficiency and integrity of offline data transmission after network recovery for IoT terminal devices by implementing a data type-based differential pruning strategy. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the differential data return method for offline cached data in this invention.

[0019] Figure 2 This is a flowchart of a method for implementing an adaptive thinning and pruning strategy in one implementation of the present invention.

[0020] Figure 3 This is a schematic diagram illustrating the effect of using a feature-based compression strategy in one implementation of the present invention.

[0021] Figure 4This is a flowchart illustrating a method for scheduling and uploading business data to the target server using a breakpoint resume strategy in one implementation of the present invention.

[0022] Figure 5 This is a schematic diagram of the differential data return system structure for offline cached data in one implementation of the present invention.

[0023] Figure 6 This is a functional schematic diagram of the terminal in one implementation of the present invention.

[0024] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0026] Exemplary methods In existing technologies, terminals typically employ one of the following two strategies after reconnecting: (1) Full data upload strategy – uploading all location data, heartbeat data, and alarm data accumulated during offline periods to the server. While this strategy ensures data integrity, it can trigger a severe data storm when the data volume is large: a large number of concurrent uploads in a short period of time can cause instantaneous server overload, bandwidth resources to be heavily occupied, and may even cause server response delays or reconnection due to traffic surges. (2) Simple discard strategy – retaining only the latest few data entries and discarding the rest of the historical data. While this strategy can reduce the amount of data, it has a serious problem of information loss, especially for security alarm data, any loss of which may lead to untraceable security incidents.

[0027] Furthermore, existing technologies typically employ uniform compression or cropping methods for data across different business types, failing to consider the varying business value and timeliness differences among data types. For instance, much of historical location data consists of redundant location points generated by uniform linear motion; the truly valuable data for positioning lies in trajectory inflection points. Alarm data, on the other hand, possesses an indispensable business attribute; and heartbeat data only needs to reflect the latest terminal status. Applying the same processing strategy to different data types wastes transmission resources and fails to guarantee the integrity of critical data.

[0028] Existing technologies still have the problem that after IoT terminal devices regain connection, data transmission is difficult to balance transmission efficiency and data integrity. Therefore, existing technologies need to be improved.

[0029] To address the above technical problems, this invention provides a differential backhaul method for offline cached data, comprising: when the current network status is offline, acquiring service data; wherein the service data is any one or more of location data, heartbeat data, and alarm data; writing the service data into local storage based on the data type to obtain an independent cache queue corresponding to the data type; when the current network status switches to online, acquiring the communication link status with the target server; acquiring the independent cache queue from the local storage and reassembling the service data in the independent cache queue; and based on the communication link status, uploading the reassembly processed service data to the target server according to a preset priority rule. This invention achieves high efficiency and integrity of offline data transmission after network recovery for IoT terminal devices by implementing a data type-based differential pruning strategy.

[0030] like Figure 1 As shown, this embodiment of the invention provides a differential data return method for offline cached data, including the following steps: Step S100: When the current network status is detected as offline, acquire service data; wherein, the service data is any one or more of location data, heartbeat data, and alarm data.

[0031] It should be noted that the differential data backhaul method for offline cached data in this embodiment is applied to IoT positioning terminals with cellular network communication capabilities, such as elderly / child positioning watches, vehicle positioning terminals, etc.

[0032] In this embodiment, the cellular network connection status is monitored in real time. When a TCP connection is detected to be disconnected and remains disconnected for more than a preset timeout period (e.g., 30 seconds), the terminal is determined to be in a network offline state. During the offline period, the terminal will acquire various types of service data. This service data includes any one or more of location data, heartbeat data, and alarm data.

[0033] Specifically, the location data is acquired by periodically collecting location data points during offline periods. Each record includes: timestamp (Unix time, 4 bytes), longitude (4 bytes), latitude (4 bytes), speed (2 bytes), heading angle (2 bytes), location type (1 byte, GPS / BeiDou / LBS / WiFi), and accuracy factor (1 byte). The heartbeat data is obtained by directly acquiring the heartbeat records that should be reported during offline periods. Each record includes: timestamp (4 bytes), device battery percentage (1 byte), signal strength RSSI (1 byte), and device operating status word (2 bytes). The alarm data is obtained by acquiring the security alarm event records triggered during offline periods. Each record includes: a complete alarm data message (including protocol header, payload data segment and checksum). The payload segment contains raw sensor data, environmental context information, etc., and the data size is usually 110KB.

[0034] In one implementation of this embodiment, the differential backhaul method for offline cached data is not only applicable to IoT positioning terminals with cellular network communication capabilities, but also to narrowband IoT terminal devices, LoRa spread spectrum communication terminal devices, or WiFi intermittent connection terminal devices.

[0035] In one implementation of this embodiment, the positioning data is not limited to GPS positioning data, but may also include BeiDou positioning data, Landscaping Location Services (LBS) data, WiFi positioning data, Bluetooth beacon positioning data, or their fused positioning data. The data types of the alarm data may include various safety event data such as fall detection alarms, electronic fence boundary crossing alarms, low battery alarms, and equipment disassembly alarms.

[0036] like Figure 1 As shown, this embodiment of the invention provides a differential data return method for offline cached data, including the following steps: Step S200: Write the business data into the local storage based on the data type to obtain an independent cache queue corresponding to the data type.

[0037] In this embodiment, the generated business data are written into the local storage according to their data attributes to obtain independent cache queues corresponding to the data types; the independent cache queues are any one or more of the initial location data queue (LocationQueue), the initial heartbeat data queue (Heartbeat Queue), and the initial alarm data queue (Alarm Queue).

[0038] Specifically, the generated business data is written into three independent cache queues in the local non-volatile memory according to the data attributes: the initial positioning data queue, the initial heartbeat data queue, and the initial alarm data queue.

[0039] like Figure 1 As shown, this embodiment of the invention provides a differential data return method for offline cached data, including the following steps: Step S300: When the current network status is switched to online, obtain the communication link status with the target server.

[0040] In this embodiment, the communication link status includes congestion status and signal quality parameters. When the current network status is switched to online, the communication link status is obtained through handshake communication with the server.

[0041] Specifically, the system periodically attempts to re-establish a TCP connection with the target server. Once the connection is successfully established, a handshake communication is performed with the server: a version query request is sent (containing the current firmware version number, device IMEI, and SIM card ICCID), and the server responds with the communication link status (including at least the current server time, link quality score / signal quality parameters, and congestion status indicator). After a successful handshake confirms the communication link is stable, the system enters the data return phase.

[0042] like Figure 1 As shown, this embodiment of the invention provides a differential data return method for offline cached data, including the following steps: Step S400: Obtain the independent cache queue from the local storage and reorganize the business data in the independent cache queue.

[0043] In this embodiment, before uploading the business data in the independent cache queue to the target server, the method further includes: obtaining the independent cache queue from the local storage and reorganizing the business data in the independent cache queue.

[0044] In this embodiment, the business data in the independent cache queues is reorganized using a storm-prevention pruning strategy, and differentiated data reorganization is performed on the three independent cache queues respectively.

[0045] Specifically, in one implementation of this embodiment, step S400 includes the following steps: Step S401: Perform an adaptive sparse pruning strategy on the initial positioning data queue to obtain the target positioning data queue.

[0046] In this embodiment, the flowchart of the method for implementing the adaptive thinning and pruning strategy is as follows: Figure 2 As shown, firstly, all historical positioning points in the positioning data queue are read to obtain motion state parameters (heading angle, velocity, etc. with timestamps). Then, the positioning point sequence is traversed in timestamp order to calculate the change in heading angle between adjacent positioning points. and velocity change Obtain the set threshold for the change in heading angle. (e.g., 30 degrees) and velocity change threshold (e.g., 5km / h), when or When a location point is identified as a critical trajectory inflection point, it is retained. For a continuous sequence of location points where neither the change in heading angle nor the change in velocity exceeds the corresponding threshold, the segment is determined to be in a normal motion state (such as uniform linear motion), and only the single location data with the latest timestamp in the segment is retained, while the remaining redundant data points are discarded. In addition, motion state recognition is performed: for motion segments where the standard deviation of the velocity sequence exceeds a preset threshold or the frequency of heading angle change exceeds a preset threshold, it is determined to be a non-uniform or non-linear motion state, and all location point data corresponding to the motion segment are retained to ensure that the integrity of complex motion trajectories (such as hovering, sharp turns, and frequent lane changes) is not destroyed; then it is determined whether the traversal is complete. If not, the location point sequence is traversed in timestamp order; if it is complete, the reconstructed location data queue is output.

[0047] Specifically, the initial positioning data queue is subjected to an adaptive thinning and pruning strategy to obtain the target positioning data queue, including the following steps: Step S4011: Obtain the motion state parameters of each historical positioning point in the initial positioning data queue.

[0048] In this embodiment, the motion state parameters of each historical positioning point in the initial positioning data queue are obtained. The initial positioning data queue is stored in local non-volatile memory, and its scope is all positioning data stored within the time period from the last execution of business data upload to the current detection of the network status switching to online. It includes positioning points and the motion state parameters of positioning points, such as: timestamp, longitude, latitude, speed, heading angle, positioning type, accuracy factor, etc.

[0049] Step S4012: Based on the acquired motion state parameters, calculate the change in motion state parameters of each historical positioning point relative to the previous historical positioning point.

[0050] In this embodiment, the sequence of positioning points is traversed according to timestamp order, and the change in motion state parameters of each historical positioning point relative to the previous historical positioning point is calculated. Specifically, the change in motion state parameters includes the change in heading angle ΔHeading and the change in velocity ΔSpeed.

[0051] Step S4013: Determine whether the change in the motion state parameter is greater than a preset threshold for the change in motion state parameter.

[0052] In this embodiment, preset threshold values ​​for changes in motion state parameters are obtained, including a heading angle change threshold TH_heading (e.g., 30 degrees) and a speed change threshold TH_speed (e.g., 5 km / h).

[0053] In one implementation of this embodiment, the heading angle change threshold TH_heading and the speed change threshold are exemplary values. In actual applications, they can be adaptively adjusted according to the service scenario, motion characteristics, and network environment of the terminal device.

[0054] Step S4014: Retain the latest positioning point in the positioning data queue and the positioning points whose motion state parameter changes are greater than a preset motion state parameter change threshold.

[0055] In this embodiment, for any positioning point in the positioning data queue, if the change in heading angle ΔHeading of the positioning point is greater than the heading angle change threshold TH_heading or the change in speed ΔSpeed ​​is greater than the speed change threshold TH_speed, the positioning point is determined to be a critical trajectory inflection point and is retained.

[0056] In this embodiment, in addition to key trajectory inflection points, the latest positioning point in the positioning data queue, i.e. the latest single positioning data, is also retained to obtain the location and motion state parameters of the terminal device when the positioning data is uploaded.

[0057] In one implementation of this embodiment, for a continuous sequence of positioning points where neither the change in heading angle nor the change in velocity exceeds the corresponding threshold, the segment is determined to be in a normal motion state (such as uniform linear motion), and only the single positioning data with the latest timestamp in the segment is retained, while the remaining data points are discarded.

[0058] In one implementation of this embodiment, a motion state recognition strategy is also executed. For motion segments where the standard deviation of the velocity sequence exceeds a preset threshold or the frequency of heading angle change exceeds a preset threshold, the motion segment is determined to be a non-uniform or non-linear motion state. All positioning point data corresponding to the motion segment are retained to ensure that the integrity of complex motion trajectories (such as hovering, sharp turns, and frequent lane changes) is not destroyed.

[0059] Step S4015: Obtain the target location data queue.

[0060] In this embodiment, the positioning points in the initial positioning data queue are filtered by the heading angle change threshold TH_heading and the velocity change threshold TH_speed to obtain the retained positioning points, and a target positioning data queue based on timestamp order and containing the motion state parameters of the retained points is obtained.

[0061] Step S402: Perform a tail pruning strategy on the initial heartbeat data queue to obtain the target heartbeat data.

[0062] In this embodiment, the initial heartbeat data queue is subjected to a tail pruning strategy to obtain the target heartbeat data, including the following steps: Step S4021: Retain the single heartbeat data with the latest timestamp in the initial heartbeat data queue, and discard other heartbeat data in the initial heartbeat data queue; In this embodiment, a tail-pruning strategy is applied to the initial heartbeat data queue, reading and retaining only the single heartbeat data with the latest timestamp from the initial heartbeat data queue, while discarding the remaining historical heartbeat data records. This reduces traffic consumption, channel occupancy, and transmission latency caused by acquiring heartbeat data that has no incremental value for business decision-making; the server only needs to obtain the liveness status of the terminal device.

[0063] Step S4022: The retained single heartbeat data is used as the target heartbeat data.

[0064] In this embodiment, the retained single heartbeat data is used as the target heartbeat data and is awaited to be transmitted to the target server.

[0065] Step S403: Perform a feature-based compression strategy on the initial alarm data queue to obtain the target alarm data queue.

[0066] In this embodiment, a feature-based compression strategy is applied to the initial alarm data queue to obtain the target alarm data queue, including the following steps: Step S4031: Remove the service load segment of all alarm data in the initial alarm data queue to obtain the effective alarm data queue; In this embodiment, as Figure 3 The diagram illustrates the effect of the feature-based compression strategy used in this embodiment. The feature-based compression strategy is applied to the original alarm messages in the initial alarm data queue, extracting the AlarmKey portion from the Payload data segment. The alarm messages are then reconstructed based on the extracted Alarm Key portion, resulting in simplified alarm messages. The initial alarm data queue is stored in local non-volatile memory, encompassing all alarm data corresponding to alarm events stored within the timeframe from the last time service data was uploaded to the current detection of the network status switching to online. Each alarm data entry includes a complete alarm data message, containing a protocol header, a Payload data segment, and a checksum.

[0067] In this embodiment, for each alarm data, its business data payload segment is stripped, and only the alarm key is extracted. The alarm key contains the following fields: alarm type code (1 byte, such as 0x01=SOS, 0x02=fall, 0x03=low battery, 0x04=out of bounds), alarm level identifier (1 byte, 14 levels), trigger timestamp (4 bytes), and event sequence number (2 bytes). This results in a valid alarm data queue that retains only the protocol header, alarm key, and checksum.

[0068] Step S4032: Obtain the alarm feature code of the alarm event corresponding to the alarm data in the valid alarm data queue, and construct an alarm message based on the obtained alarm feature code; In this embodiment, the alarm feature code corresponding to the alarm event in the valid alarm data queue is obtained, and the alarm message is reconstructed.

[0069] Specifically, the protocol frame header structure of the original alarm event (including synchronization word, protocol version, device identifier, data length field, etc.) is retained, the Payload data segment is replaced with a compressed data segment containing only the Alarm Key, the checksum is recalculated and filled into the end of the message.

[0070] In one implementation of this embodiment, the Alarm Key can also employ hash encoding. The original key fields of the alarm event (alarm type, level, trigger time, device identifier) ​​are concatenated into a string, and this string is hashed (e.g., truncated using CRC16 or MD5). The resulting hash value is then used as the Alarm Key. In this scheme, the Alarm Key has a fixed and shorter length (e.g., a 4-byte hash value). The server can match the corresponding alarm processing logic in a preset alarm event registry based on the hash value, further reducing transmission overhead.

[0071] In one implementation of this embodiment, the Alarm Keys of multiple alarm events can be aggregated into a batch alarm signature set, encapsulated in a single concise alarm message, and transmitted in a merged manner. This is suitable for scenarios where a large number of alarms of the same type (such as continuous out-of-bounds alarms) are generated during offline periods. After receiving the aggregated signature set, the server parses it and triggers the business processing flow of each alarm event.

[0072] Step S4033: Obtain the target alarm data queue containing all alarm messages.

[0073] In this embodiment, the final target alarm data queue is used to transmit to the target server. Each data item in the queue is a reconstructed alarm message. The data volume of the reconstructed alarm message is usually only 5% to 10% of the original alarm message. The server can fully restore the key information of the alarm event and trigger the corresponding business processing flow (such as notifying family members, dispatching rescue, recording safety logs, etc.) based on the device identifier and timestamp information in the protocol frame header combined with the alarm type code and level identifier in the Alarm Key.

[0074] like Figure 1 As shown, this embodiment of the invention provides a differential data return method for offline cached data, including the following steps: Step S500: Based on the communication link status, the reassembled service data is uploaded to the target server according to a preset priority rule.

[0075] In this embodiment, based on the communication link status, the reassembled service data is uploaded to the target server according to a preset priority rule; wherein, the preset priority rule is: alarm data has the highest priority, heartbeat data has the second highest priority, and location data has the lowest priority.

[0076] In this embodiment, the queue priority rules corresponding to the preset priority rules are as follows: the initial alarm data queue has the highest priority, the initial heartbeat data queue has the second highest priority, and the initial location data queue has the lowest priority.

[0077] In this embodiment, step S300 acquires the communication link status with the target server, evaluates the current network link quality score / signal quality parameters, such as RSSI (Received Signal Strength Indicator) and SNR (Signal-to-Noise Ratio), acquires the server's congestion status identifier, and judges based on server response delay, packet loss rate, etc. If the signal quality parameters are lower than a preset signal threshold (e.g., RSSI < 100 dBm), or the server response delay exceeds a preset threshold (e.g., > 2 seconds), the current network is determined to be in a poor state, and an extreme flow control mode is activated: only the reassembled alarm data queue and heartbeat data queue are uploaded according to priority, and the upload of the location data queue is suspended or delayed; if the signal quality parameters are higher than the preset signal threshold and the server response is normal, the queues are uploaded according to a fixed priority order.

[0078] Specifically, in one implementation of this embodiment, step S500 includes the following steps: Step S501: When the congestion state is congested or the signal quality parameter does not meet the preset signal quality parameter threshold, the alarm data queue and the target heartbeat data are uploaded sequentially.

[0079] In this embodiment, when the congestion state is a congestion state or the signal quality parameter does not meet the preset signal quality parameter threshold, the extreme flow control mode is activated, and the alarm data queue and the target heartbeat data are uploaded sequentially.

[0080] Step S501: When the congestion state is non-congestion state and the signal quality parameter meets the preset signal quality parameter threshold, the alarm data queue, the target heartbeat data and the target positioning data queue are uploaded sequentially.

[0081] In this embodiment, when the congestion state is a non-congestion state and the signal quality parameters meet the preset signal quality parameter threshold, the alarm data queue, the target heartbeat data, and the target location data queue are uploaded in a fixed priority order.

[0082] In this embodiment, under the normal online state of the device, the alarm data uploaded to the target server is shown in Table 1 below, and the location data uploaded to the target server is shown in Table 2 below. It should be noted that the data in Tables 1 and 2 are not the original data, but rather the content displayed online after the target server has processed the original data.

[0083] Table 1. Example of alarm data uploaded during normal online status.

[0084]

[0085] Table 2. Example table of location data uploaded in normal online status.

[0086]

[0087] When the device reconnects to the network after being offline for a period of time, the alarm data to be re-uploaded to the target server based on the differential data transmission method of the offline cache data in this application is shown in Table 3 below; the location data to be re-uploaded to the target server is shown in Table 4 below. It should be noted that the data in Tables 3 and 4 are not the original data, but rather the content displayed online after the target server has processed the original data.

[0088] Table 3. Example of alarm data uploaded after being offline and then back online.

[0089]

[0090] Table 4. Example table of location data uploaded after being offline and then back online.

[0091]

[0092] As shown in Table 3, the alarm data uploaded after the device goes offline for a period of time and then comes back online is mainly used to obtain alarm events in order to return the key information of the alarm events. As shown in Table 4, the location data uploaded after the device goes offline for a period of time and then comes back online is mainly used to obtain the location of the terminal device. The location data is uploaded together with the alarm data, and the alarm data has a higher priority.

[0093] like Figure 1 As shown, this embodiment of the invention provides a differential data return method for offline cached data, including the following steps: In step S600, when uploading the reorganized business data to the target server according to the preset priority rules, the breakpoint resume strategy is executed.

[0094] In this embodiment, the flowchart of the method for scheduling and uploading business data to the target server using a breakpoint resume strategy is as follows: Figure 4 As shown. First, the network signal quality (e.g., RSSI value, signal-to-noise ratio SNR) is assessed, and the server congestion status is evaluated (e.g., through response latency and packet loss rate). Then, it is determined whether the signal quality parameters are lower than the preset signal threshold (e.g., RSSI < 100dBm) or whether the server response latency exceeds the preset threshold (e.g., > 2 seconds). If either condition is met, the extreme flow control mode is activated, uploading only alarm data and heartbeat data, pausing / delaying the upload of location data; otherwise, the normal priority upload strategy is activated, and the breakpoint resumption strategy is executed. Specifically, during the upload process, for each successfully uploaded data batch, the queue identifier, data offset, and acknowledgment number of that batch are written to the local non-volatile memory as a breakpoint marker; if the network is interrupted again during the upload process, the terminal records the current breakpoint position; after the network is restored, the breakpoint marker is read and the upload continues from the breakpoint position to avoid data duplication.

[0095] Specifically, in one implementation of this embodiment, step S600 includes the following steps: Step S601: During the process of uploading the reconstructed business data to the target server according to the preset priority upload rules, if the current network status is detected to switch to offline, the reconstructed business data is marked with a breakpoint. Step S602: When the current network status switches back to online, based on the breakpoint, continue to upload the reconstructed business data to the target server according to the preset priority upload rules.

[0096] Furthermore, in this embodiment, the differential data return method for offline cached data is described based on some specific application scenarios.

[0097] In some application scenarios, when the terminal is worn by elderly people or children who move at low speeds, the overall movement speed is low (usually walking speed does not exceed 5km / h), and the heading angle changes more frequently (frequent turning during walking). The heading angle change threshold TH_heading can be appropriately increased (e.g., 45 degrees), and the speed change threshold TH_speed can be appropriately decreased (e.g., 2km / h) to avoid misidentifying normal turning during walking as a critical inflection point, while being more sensitive to capturing abnormal speed changes (e.g., sudden running).

[0098] In some application scenarios, when the terminal is installed on a high-speed moving vehicle such as a vehicle, due to the high speed and relatively smooth changes in heading angle (large turning radius of the vehicle), the heading angle change threshold TH_heading can be appropriately reduced (e.g., 15 degrees), and the speed change threshold TH_speed can be appropriately increased (e.g., 15 km / h) to more sensitively capture vehicle turning events while filtering out normal acceleration and deceleration fluctuations of the vehicle.

[0099] In some application scenarios, the terminal can automatically calculate thresholds based on the statistical characteristics of historical motion data (such as mean speed and speed variance). For example, the threshold for change in heading angle can be set to 1.5 times the standard deviation of the heading angle sequence, and the threshold for change in speed can be set to 2 times the standard deviation of the speed sequence, so that the thresholds can be automatically adapted to the motion mode without manual configuration.

[0100] In this embodiment of the application, the differential backhaul method for offline cached data described above can also be applied to IoT terminal devices that use other communication methods.

[0101] In some application scenarios, the differential backhaul method for offline cached data can be applied to narrowband IoT terminal devices. In this scenario, the advantages of the three-level differentiated pruning strategy are more prominent: adaptive thinning of positioning data filters out a large number of redundant location points, heartbeat data retains only one record, and the simplified alarm data alarm message occupies only the protocol header + Alarm Key (about 2030 bytes), which fully meets the strict data volume limit of NBIoT.

[0102] In some application scenarios, the differential backhaul method for offline cached data can be applied to LoRa spread spectrum communication terminal equipment. In LoRa networks, channel duty cycles are limited by regulations (e.g., in China, the single-channel duty cycle of the 470MHz band is usually no more than 1%), and long-term, large-volume uploads will trigger duty cycle limits. After differential cropping, the data volume is significantly reduced, and all critical data can be backhauled within a limited channel occupancy time.

[0103] In some application scenarios, the differential backhaul method for offline cached data can be applied to terminal devices with intermittent WiFi connections. In non-real-time WiFi scenarios (such as devices connecting to home WiFi at night to upload data for the day), despite sufficient bandwidth, a large amount of redundant data still wastes storage resources and upload time. Differentiated cropping can also improve efficiency and reduce operating costs.

[0104] This embodiment achieves the following technical effects through the above technical solution: This embodiment fundamentally prevents data storms through a differentiated three-level pruning strategy. Location data, after adaptive thinning, retains only key trajectory inflection points and the latest data points, reducing data volume by over 80%. Heartbeat data retains only the latest record. Alarm data undergoes feature-based compression, converting the complete payload into a concise alarm message containing only the protocol header and Alarm Key, minimizing bandwidth usage. This differentiated processing significantly reduces the overall data volume, effectively preventing instantaneous server overload.

[0105] The adaptive thinning and pruning algorithm differs from a simple discarding strategy: it identifies trajectory inflection points by analyzing changes in motion state parameters (heading angle and velocity), reducing the amount of data while retaining key feature information of the motion trajectory, rather than drastically deleting all historical data. Data points from normal motion states (such as uniform straight-line segments) contribute very little to trajectory reconstruction, and discarding them does not affect positioning accuracy; however, trajectory inflection point data is fully preserved, ensuring the reconstructability of historical trajectories.

[0106] The characteristic compression strategy for alarm data achieves the dual goals of "zero data loss" and "low bandwidth." By stripping away the payload and retaining only the alarm key, the server can retrieve key information such as alarm type, level, and time based on the alarm key, triggering corresponding business processing flows. The streamlined alarm message protocol design ensures that all alarm events are completely lossless with minimal transmission overhead.

[0107] The dynamic flow control mechanism enables the storm protection strategy to not only rely on data pruning, but also adaptively adjust upload behavior based on real-time network conditions. It automatically downgrades uploads when network quality is poor or servers are congested, prioritizing alarm and heartbeat data, further enhancing the system's robustness in harsh network environments.

[0108] The breakpoint resume mechanism ensures that in extreme scenarios of repeated network interruptions, uploaded data is not retransmitted and unuploaded data is not lost, maximizing the use of the limited network window to complete data return.

[0109] Exemplary device Based on the above embodiments, the present invention also provides a differential data return system for offline cached data, such as... Figure 5 As shown, the differential data return system for offline cached data includes: The offline data acquisition module 51 is used to acquire business data when the current network status is offline; wherein, the business data is any one or more of location data, heartbeat data and alarm data; Offline data storage module 52 is used to write the business data into local storage based on the data type to obtain an independent cache queue corresponding to the data type; The communication link status acquisition module 53 is used to acquire the communication link status with the target server when the current network status is switched to online. The queue data reorganization processing module 54 is used to obtain the independent cache queue from the local storage and reorganize the business data in the independent cache queue. The queue data upload module 55 is used to upload the reassembled business data to the target server according to a preset priority rule based on the communication link status.

[0110] In this embodiment, the queue data reassembly processing module includes a location data queue processing unit, a heartbeat data queue processing unit, and an alarm data queue processing unit.

[0111] The positioning data queue processing unit is used to perform an adaptive thinning and pruning strategy on the initial positioning data queue to obtain the target positioning data queue. A heartbeat data queue processing unit is used to perform a tail pruning strategy on the initial heartbeat data queue to obtain target heartbeat data. The alarm data queue processing unit is used to perform a feature-based compression strategy on the initial alarm data queue to obtain the target alarm data queue.

[0112] In this embodiment, the queue data upload module includes a dynamic flow control unit, a scheduling upload unit, and a breakpoint resume upload unit.

[0113] The dynamic flow control unit is used to activate the extreme flow control mode and sequentially upload the alarm data queue and the target heartbeat data when the congestion state is a congestion state or the signal quality parameter does not meet the preset signal quality parameter threshold. The scheduling upload unit is used to sequentially upload the alarm data queue, the target heartbeat data, and the target location data queue when the congestion state is a non-congestion state and the signal quality parameters meet the preset signal quality parameter threshold. The breakpoint resume unit is used to mark the reassembled service data as a breakpoint when the current network status switches to offline during the process of uploading the reassembled service data to the target server according to the preset priority upload rules; and to continue uploading the reassembled service data to the target server according to the preset priority upload rules when the current network status switches back to online.

[0114] Based on the above embodiments, the present invention also provides a terminal, the principle block diagram of which can be as follows: Figure 6 As shown.

[0115] The terminal includes: a processor, a memory, an interface, a display screen, and a communication module connected via a system bus; wherein, the processor of the terminal provides computing and control capabilities; the memory of the terminal includes a computer-readable storage medium and internal memory; the computer-readable storage medium stores an operating system and computer programs; the internal memory provides an environment for the operation of the operating system and computer programs in the computer-readable storage medium; the interface is used to connect to external devices; the display screen is used to display relevant information; and the communication module is used to communicate with a cloud server or other devices.

[0116] This computer program is used by the processor to implement the differential backhaul method for offline cached data.

[0117] It will be understood by those skilled in the art that Figure 6 The schematic diagram shown is merely a partial structural diagram related to the present invention and does not constitute a limitation on the terminal to which the present invention is applied. A specific terminal may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0118] In one embodiment, a terminal is provided, comprising: a processor and a memory, the memory storing an offline cached data differential return program, which, when executed by the processor, is used to implement the operation of the offline cached data differential return method as described above.

[0119] In one embodiment, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores an offline cached data differential return program, which, when executed by a processor, is used to implement the operation of the offline cached data differential return method described above.

[0120] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, database, or other media used in the embodiments provided by this invention can include both non-volatile and volatile memory.

[0121] In summary, this invention provides a method, system, terminal, and medium for differential backhaul of offline cached data, comprising: when the current network status is detected as offline, acquiring service data; wherein the service data is any one or more of location data, heartbeat data, and alarm data; writing the service data into local storage based on data type to obtain an independent cache queue corresponding to the data type; when the current network status is detected as online, acquiring the communication link status with the target server; acquiring the independent cache queue from the local storage and reassembling the service data in the independent cache queue; and uploading the reassembly processed service data to the target server according to a preset priority rule based on the communication link status. This invention achieves high efficiency and integrity of offline data transmission after network recovery of IoT terminal devices by executing a data type-based differential pruning strategy.

[0122] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A method for differential backhaul of offline cached data, characterized in that, include: When the current network status is detected as offline, business data is acquired; wherein, the business data includes location data, heartbeat data, and alarm data; The business data is written to the local storage based on the data type to obtain an independent cache queue corresponding to the data type; When the current network status is switched to online, obtain the communication link status with the target server; The independent cache queue is retrieved from the local storage, and the business data in the independent cache queue is reorganized; an adaptive sparse pruning strategy is performed on the initial location data queue to obtain the target location data queue; a tail pruning strategy is performed on the initial heartbeat data queue to obtain the target heartbeat data; and a feature-based compression strategy is performed on the initial alarm data queue to obtain the target alarm data queue. Based on the communication link status, the reassembled service data is uploaded to the target server according to a preset priority rule; The communication link status includes congestion status and signal quality parameters. Based on the communication link status, uploading the reassembled service data to the target server according to a preset priority rule includes: When the congestion state is a congestion state or the signal quality parameter does not meet the preset signal quality parameter threshold, the alarm data queue and the target heartbeat data are uploaded sequentially. When the congestion state is non-congestion state and the signal quality parameters meet the preset signal quality parameter threshold, the alarm data queue, the target heartbeat data and the target location data queue are uploaded sequentially.

2. The differential data return method for offline cached data according to claim 1, characterized in that, The step of performing an adaptive sparse pruning strategy on the initial positioning data queue to obtain the target positioning data queue includes: Obtain the motion state parameters of each historical positioning point in the initial positioning data queue; Based on the acquired motion state parameters, calculate the change in motion state parameters of each historical positioning point relative to the previous historical positioning point. Determine whether the change in the motion state parameters is greater than a preset threshold for the change in motion state parameters; The latest positioning point and the positioning points in the positioning data queue whose motion state parameter changes are greater than a preset motion state parameter change threshold are retained. Obtain the target location data queue.

3. The differential data return method for offline cached data according to claim 1, characterized in that, The step of performing a tail-pruning strategy on the initial heartbeat data queue to obtain the target heartbeat data includes: Retain the single heartbeat data with the latest timestamp in the initial heartbeat data queue, and discard other heartbeat data in the initial heartbeat data queue; The single heartbeat data point that is retained is used as the target heartbeat data.

4. The differential data return method for offline cached data according to claim 1, characterized in that, The step of performing a feature-based compression strategy on the initial alarm data queue to obtain the target alarm data queue includes: Remove the service load segment of all alarm data in the initial alarm data queue to obtain the effective alarm data queue; Obtain the alarm feature code of the alarm event corresponding to the alarm data in the valid alarm data queue, and construct the alarm message based on the obtained alarm feature code; Obtain the target alarm data queue containing all alarm messages.

5. The differential data return method for offline cached data according to claim 1, characterized in that, The differential data return method for offline cached data further includes: During the process of uploading the reconstructed business data to the target server according to the preset priority upload rules, if the current network status is detected to switch to offline, the reconstructed business data is marked as a breakpoint. When the current network status switches back to online, the reconstructed business data is uploaded to the target server according to the preset priority upload rules based on the breakpoint.

6. A differential data return system for offline cached data, used to implement the differential data return method for offline cached data as described in any one of claims 1-5, characterized in that, include: The offline data acquisition module is used to acquire business data when the current network status is offline; wherein, the business data includes location data, heartbeat data, and alarm data. An offline data storage module is used to write the business data into local storage based on the data type, thereby obtaining an independent cache queue corresponding to the data type. The communication link status acquisition module is used to acquire the communication link status with the target server when the current network status switches to online. The queue data reassembly processing module is used to retrieve the independent cache queue from the local storage and reassemble the business data in the independent cache queue; to perform an adaptive sparse pruning strategy on the initial location data queue to obtain the target location data queue; to perform a tail pruning strategy on the initial heartbeat data queue to obtain the target heartbeat data; and to perform a feature-based compression strategy on the initial alarm data queue to obtain the target alarm data queue. The queue data upload module is used to upload the reassembled business data to the target server according to a preset priority rule based on the communication link status.

7. A terminal, characterized in that, include: The processor and memory, wherein the memory stores a differential return program for offline cached data, and the differential return program for offline cached data, when executed by the processor, is used to implement the operation of the differential return method for offline cached data as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a differential return program for offline cached data, which, when executed by a processor, is used to implement the operation of the differential return method for offline cached data as described in any one of claims 1-5.

Images