Method, device and computer readable storage medium for reporting internet of things device data

Abstract

The application provides a method, device and computer readable storage medium for reporting data of an Internet of Things device. The method comprises: sending data of the Internet of Things device to be uploaded to a kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in a system kernel of the Internet of Things device; performing priority sorting and cache processing on the data of the Internet of Things device; the kernel-level MQTT client adopts an MQTT protocol, and sends at least part of the data of the Internet of Things device to an MQTT broker according to the priority order, so that the MQTT broker sends the received data of the Internet of Things device to a corresponding subscriber. The method solves the problem that current MQTT protocol implementation is dependent on a user layer library and is difficult to be directly processed efficiently at a kernel level.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and more specifically, to a method, apparatus, and computer-readable storage medium for reporting data from IoT devices. Background Technology

[0002] With the rapid development of IoT technology, data reporting from IoT devices has become a critical link. Traditional data reporting mechanisms typically rely on user-level programs, which not only increases system complexity and resource consumption but may also lead to untimely or lost data reporting due to anomalies or delays in user-level programs.

[0003] MQTT (Message Queuing Telemetry Transport) is a lightweight message transmission protocol that has been widely used in the Internet of Things (IoT) field due to its simplicity, efficiency, and reliability. However, existing MQTT implementations largely rely on user-level libraries, making it difficult to perform efficient processing directly at the kernel level. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, and computer-readable storage medium for reporting data from Internet of Things (IoT) devices, so as to at least solve the problem that current MQTT protocol implementations rely heavily on user-level libraries and are difficult to process efficiently at the kernel level.

[0005] To achieve the above objectives, according to one aspect of this application, a method for reporting IoT device data is provided, comprising: sending IoT device data to be uploaded to a kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device; prioritizing and caching the IoT device data; the kernel-level MQTT client using the MQTT protocol to send at least a portion of the IoT device data to an MQTT broker according to priority order, so that the MQTT broker sends the received IoT device data to the corresponding subscribers.

[0006] Optionally, before prioritizing and caching the IoT device data, the method further includes: encapsulating the IoT device data to obtain encapsulated data; wherein, encapsulating the IoT device data to obtain encapsulated data includes: performing a selection of encapsulation protocol sub-step, a data mapping sub-step, a header filling sub-step, and a verification and encryption sub-step to form the encapsulated data, wherein the data mapping sub-step indicates mapping the IoT device data to the payload portion of the encapsulation protocol, the header filling sub-step indicates filling the corresponding header information according to the selected encapsulation protocol, and the verification and encryption sub-step indicates verifying the integrity of the data and encrypting the data.

[0007] Optionally, the IoT device data is prioritized and cached, including: if the priority queue is full or network congestion prevents the IoT device data from being sent immediately, then this part of the IoT device data is stored in a deep buffer.

[0008] Optionally, the method further includes: if the IoT device data stored in the depth buffer meets the transmission conditions, transmitting the IoT device data using a first-in-first-out strategy.

[0009] Optionally, the method further includes: adjusting the depth of the depth buffer to optimize the utilization of storage space.

[0010] Optionally, the method further includes: cleaning up the IoT device data in the deep buffer according to a preset expiration policy, wherein the preset expiration policy includes a fixed expiration time policy and a relative expiration time policy, wherein the fixed expiration time policy is that the IoT device data is valid for a preset time period after its generation, and automatically expires after the preset time period, and the relative expiration time policy determines whether the data has expired based on the relative relationship between the generation time and the current time of the IoT device data.

[0011] Optionally, the method further includes: if the connection between the kernel-level MQTT client and the MQTT broker is lost, the kernel-level MQTT client automatically attempts to reconnect and re-reports the IoT device data cached in the deep buffer.

[0012] Optionally, the kernel-level MQTT client typically provides an API that integrates with the system kernel of the IoT device.

[0013] According to another aspect of this application, an apparatus for reporting IoT device data is provided, comprising: a first sending unit, configured to send IoT device data to be uploaded to a kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device; a processing unit, configured to perform priority sorting and caching processing on the IoT device data; and a second sending unit, configured for the kernel-level MQTT client to send at least a portion of the IoT device data to an MQTT broker according to priority order using the MQTT protocol, so that the MQTT broker sends the received IoT device data to the corresponding subscribers.

[0014] Optionally, the apparatus further includes: an encapsulation unit, configured to encapsulate the IoT device data before prioritizing and caching the IoT device data to obtain encapsulated data; wherein encapsulating the IoT device data to obtain encapsulated data includes: performing a selection encapsulation protocol sub-step, a data mapping sub-step, a header filling sub-step, and a verification and encryption sub-step to form the encapsulated data, wherein the data mapping sub-step indicates mapping the IoT device data to the payload portion of the encapsulation protocol, the header filling sub-step indicates filling the corresponding header information according to the selected encapsulation protocol, and the verification and encryption sub-step indicates verifying the integrity of the data and encrypting the data.

[0015] Optionally, the processing unit includes a storage module, used to store the IoT device data in a deep buffer if the priority queue is full or network congestion prevents the IoT device data from being sent immediately.

[0016] Optionally, the apparatus further includes a sending module, configured to send the IoT device data using a first-in-first-out strategy when the IoT device data stored in the depth buffer meets the sending conditions.

[0017] Optionally, the device further includes an adjustment module for adjusting the depth of the depth buffer to optimize the utilization of storage space.

[0018] Optionally, the device further includes: a cleaning unit, configured to clean the IoT device data in the deep buffer according to a preset expiration policy, wherein the preset expiration policy includes a fixed expiration time policy and a relative expiration time policy, wherein the fixed expiration time policy stipulates that the IoT device data is valid for a preset time period after its generation and automatically expires after the preset time period, and the relative expiration time policy determines whether the data has expired based on the relative relationship between the generation time and the current time of the IoT device data.

[0019] Optionally, the apparatus further includes a connection unit, configured to automatically attempt to reconnect and re-report the IoT device data cached in the deep buffer if the connection between the kernel-level MQTT client and the MQTT broker is lost.

[0020] Optionally, the kernel-level MQTT client typically provides an API that integrates with the system kernel of the IoT device.

[0021] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform any of the above-described methods for reporting Internet of Things (IoT) device data.

[0022] The technical solution of this application sends IoT device data to be uploaded to a kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device; it prioritizes and caches the IoT device data; the kernel-level MQTT client uses the MQTT protocol to send at least a portion of the IoT device data to the MQTT broker according to priority, so that the MQTT broker can send the received IoT device data to the corresponding subscribers. This solution uses a kernel-level MQTT client, priority sorting, and deep caching technology, making the data reporting process more stable and reliable, reducing the risk of system crashes caused by user-level program anomalies, and thus solving the problem that current MQTT protocol implementations mostly rely on user-level libraries and are difficult to process efficiently at the kernel level. Attached Figure Description

[0023] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0024] Figure 1 A flowchart illustrating a method for reporting data from an Internet of Things (IoT) device according to an embodiment of this application is shown;

[0025] Figure 2 A schematic diagram of the overall server architecture provided according to an embodiment of this application is shown;

[0026] Figure 3 A structural block diagram of an apparatus for reporting data from Internet of Things (IoT) devices, according to an embodiment of this application, is shown. Detailed Implementation

[0027] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first," "second," etc., 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 for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises 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 apparatus.

[0030] As described in the background section, traditional data reporting mechanisms in the prior art typically rely on user-level programs. This not only increases the complexity and resource consumption of the system, but may also lead to untimely or lost data reporting due to anomalies or delays in user-level programs. The MQTT protocol, as a lightweight message transmission protocol, has been widely used in the Internet of Things (IoT) field due to its simplicity, efficiency, and reliability. However, existing MQTT protocol implementations mostly rely on user-level libraries, making it difficult to perform efficient processing directly at the kernel level. To address the problem that current MQTT protocol implementations mostly rely on user-level libraries and are difficult to perform efficient processing directly at the kernel level, embodiments of this application provide a method, apparatus, and computer-readable storage medium for reporting IoT device data.

[0031] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0032] This embodiment provides a method for reporting IoT device data running on the kernel of an IoT device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] Figure 1 This is a flowchart of a method for reporting IoT device data according to an embodiment of this application. Figure 1 As shown, the method includes the following steps:

[0034] Step S101: Send the IoT device data to be uploaded to the kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device.

[0035] The system kernel of the IoT device can be selected as the Linux kernel;

[0036] Specifically, implementing the MQTT client in the device's system kernel enables real-time transmission and processing of device data, improving the stability and security of data transmission. Integrating a kernel-level MQTT client allows the device to function normally even without an external network connection, reducing latency between the device and the external network, and improving the real-time performance and reliability of data. Furthermore, the kernel-level MQTT client can be better integrated with other functional modules of the device, improving the overall system performance and stability, and enabling better management and control of IoT devices.

[0037] Step S102: Prioritize and cache the IoT device data.

[0038] Specifically, applying eBPF technology can prioritize data, ensuring that important data is transmitted first, improving data real-time performance and accuracy. By integrating eBPF technology into the kernel-level MQTT client, it is possible to manage heartbeat packets and device status data to be sent. Heartbeat packets and device status data are encapsulated into MQTT messages in the kernel and sorted and cached according to the rules of eBPF technology. Through caching, data transmission latency and network bandwidth consumption can be reduced, improving data transmission efficiency and stability. This effectively optimizes the data transmission process and enhances the effectiveness and performance of data reporting by IoT devices.

[0039] In step S103, the kernel-level MQTT client uses the MQTT protocol to send at least a portion of the IoT device data to the MQTT broker according to priority, so that the MQTT broker can send the received IoT device data to the corresponding subscribers.

[0040] Specifically, a kernel-level MQTT client can send IoT device data to an MQTT broker, which can then forward the data to the relevant subscribers, thereby achieving reliable data transmission and real-time updates. This ensures that subscribers can obtain the latest device data in a timely manner. By setting priority order, important data can be sent first, improving the efficiency and reliability of data transmission. This enhances the efficiency and reliability of IoT device data reporting and provides a guarantee for real-time data updates and transmission.

[0041] This embodiment sends IoT device data to be uploaded to a kernel-level MQTT client, which is implemented within the IoT device's system kernel. The client prioritizes and caches the IoT device data. Using the MQTT protocol, the kernel-level MQTT client sends at least a portion of the IoT device data to the MQTT broker according to priority, enabling the MQTT broker to forward the received data to the corresponding subscribers. This solution utilizes a kernel-level MQTT client, priority sorting, and deep caching technology, making the data reporting process more stable and reliable, reducing the risk of system crashes due to user-level program anomalies, and thus solving the problem that current MQTT protocol implementations often rely on user-level libraries and are difficult to process efficiently at the kernel level.

[0042] It should be noted that the aforementioned kernel-level MQTT client is an MQTT client program that runs at the operating system kernel level. It is used to report data from IoT devices to the MQTT broker server. Kernel-level MQTT clients have higher performance and lower system resource consumption. They typically communicate directly with the MQTT broker server through the operating system's network protocol stack, without going through the intermediate layer in user space. This method of handling MQTT communication directly in the kernel reduces the number of times data packets are transmitted between user space and kernel space, thereby improving data transmission efficiency. Furthermore, it can utilize some optimization features of the operating system, such as zero-copy technology and efficient network buffer management, to further improve the speed and performance of data transmission.

[0043] In addition, the client communicates directly with the MQTT broker without going through user-level programs and supports all the basic functions of the MQTT protocol.

[0044] Optionally, the above functions may include, but are not limited to: Connect, Publish, Subscribe, Disconnect, etc.

[0045] It should be noted that the aforementioned eBPF (Extended Berkeley Packet Filter) technology is a powerful programming framework primarily used for network packet processing and operating system-level monitoring. While originating from BPF (Berkeley Packet Filter) technology, eBPF has been extended and improved, making it more powerful and flexible. It is particularly suitable for data reporting mechanisms of IoT devices, combining the advantages of priority queues and deep buffers to achieve efficient, real-time, and reliable data processing. Through priority queues and deep buffers, eBPF ensures that high-priority data is sent first, while avoiding data loss. With eBPF, IoT devices can directly publish collected data to a database, and other devices can subscribe to the database to obtain the latest information. This simplifies data transmission and processing, reduces the communication burden between devices, and improves data real-time performance and reliability. Furthermore, eBPF helps in better monitoring and managing IoT devices, improving their operational efficiency and reliability.

[0046] Furthermore, it should be noted that in eBPF technology, data encapsulation is the process of mapping business data into the payload of a certain encapsulation protocol and filling in the corresponding protocol header to form a data packet of the encapsulation protocol. This step is crucial to ensuring that data is transmitted reliably and accurately in the network.

[0047] The specific working principle of the priority queue is as follows:

[0048] 1. Definition: A priority queue is a special type of queue in which each element is associated with a priority value, and elements are served according to their priority, that is, elements with higher priority are served first.

[0049] 2. Priority Definition: In eBPF technology, priority can be flexibly set according to actual needs. For example, different priorities can be assigned according to the type of data packet (such as heartbeat packets, emergency alarm information, etc.) and the degree of urgency. Among them, heartbeat packets usually have the highest priority to ensure real-time updates of device connection status, while ordinary device status data may have a lower priority.

[0050] 3. Operations: In a priority queue, the insertion operation adds a new element to the queue and sorts it according to its priority. The removal operation removes the highest priority element from the queue for processing. If there are multiple elements with the same priority in the queue, they are processed according to their order in the queue.

[0051] It should be noted that the MQTT (Message Queuing Telemetry Transport) protocol mentioned above is a lightweight, publish / subscribe-based communication protocol, particularly suitable for communication between IoT devices. Through the MQTT protocol, IoT devices can quickly and reliably report real-time data to cloud servers or other devices. IoT devices connect to an MQTT server (also known as a Broker) via the MQTT protocol and publish data to a specified topic, allowing other devices or applications that have subscribed to the same topic to receive the data. The publish / subscribe approach makes communication between devices more flexible and efficient, reducing network transmission overhead.

[0052] In the specific implementation process, before prioritizing and caching the IoT device data, the above method also includes: encapsulating the IoT device data to obtain encapsulated data; wherein, encapsulating the IoT device data to obtain encapsulated data includes: performing a selection of encapsulation protocol sub-step, a data mapping sub-step, a header filling sub-step, and a verification and encryption sub-step to form encapsulated data, wherein the data mapping sub-step indicates that the IoT device data is mapped to the payload part of the encapsulation protocol, the header filling sub-step indicates that the corresponding header information is filled according to the selected encapsulation protocol, and the verification and encryption sub-step indicates that the integrity of the verification data is verified and the data is encrypted.

[0053] Specifically, by selecting a suitable encapsulation protocol, the reliability and stability of data during transmission can be ensured. Mapping IoT device data to the payload of the encapsulation protocol can effectively integrate data into encapsulated data, facilitating transmission and processing. Filling in the corresponding header information according to the selected encapsulation protocol can provide relevant information about the transmitted data, making it easier for the receiving end to correctly parse and process the data. Verifying the integrity of the data and encrypting the data can ensure the security and confidentiality of the data during transmission, preventing data from being tampered with or stolen. By encapsulating IoT device data to obtain encapsulated data, the security and reliability of data transmission can be effectively guaranteed, data transmission efficiency and stability can be improved, and the reporting and transmission of IoT device data can be effectively realized.

[0054] The specific data encapsulation process is as follows:

[0055] 1. Data preparation: Raw data generated by IoT devices, such as heartbeat packets and device status changes, are first collected and prepared for encapsulation. This data may include, but is not limited to, key information such as device ID, sensor readings, and timestamps.

[0056] 2. Protocol Selection: Based on the data transmission requirements and network characteristics, select an appropriate encapsulation protocol. Common encapsulation protocols include TCP / IP (Transmission Control Protocol / Internet Protocol), MQTT, etc., which provide different levels of reliability and security.

[0057] 3. Data Mapping: Mapping business data to the payload of the encapsulation protocol may involve steps such as data formatting, encoding, and compression to ensure efficient data transmission.

[0058] 4. Packet header padding: Based on the selected encapsulation protocol, fill in the corresponding packet header information. The packet header usually includes key fields such as destination address, source address, protocol type, and data length, which are used to guide data routing and transmission.

[0059] 5. Verification and Encryption: During the encapsulation process, data verification and encryption may also be required. Verification can ensure data integrity, while encryption can protect data confidentiality.

[0060] 6. Packet Formation: After the above steps, the business data is encapsulated into a complete data packet, which can now be transmitted in the network and can be routed and forwarded through different network layers.

[0061] In the specific implementation process, eBPF technology is used to cache IoT device data, including: if the priority queue is full or network congestion prevents IoT device data from being sent immediately, then this part of the IoT device data is stored in a deep buffer.

[0062] Specifically, to ensure that IoT device data is not lost in the event of network congestion or a full priority queue, it is stored in a deep buffer to guarantee data integrity and accuracy, and to avoid affecting the normal operation of the system due to the inability to send data in a timely manner. By applying eBPF technology to cache IoT device data, the reliability and stability of data can be improved, and timely transmission and processing of data can be ensured.

[0063] It should be noted that the aforementioned deep buffer is a storage space used to store data packets that cannot be processed temporarily. When the priority queue is full or network congestion prevents data packets from being sent immediately, the data packets will be stored in the deep buffer to wait for processing.

[0064] The depth of the buffer refers to the maximum number of data packets that the buffer can store. This depth can be flexibly set according to actual needs. For example, the depth of the buffer can be determined based on factors such as the number of IoT devices, the frequency of data packet generation, and the network bandwidth.

[0065] In the specific implementation process, the above method also includes: when the IoT device data stored in the deep buffer meets the sending conditions, the IoT device data is sent using a first-in-first-out strategy.

[0066] Specifically, adopting a first-in, first-out (FIFO) strategy ensures that data is sent in the order it is stored, avoiding data transmission chaos and errors, guaranteeing data integrity and accuracy, ensuring that data is not lost or duplicated during network transmission, improving the reliability and stability of data transmission, effectively managing and sending IoT device data, ensuring that data is sent in the correct order, thereby improving data transmission efficiency and reliability.

[0067] Optionally, the management of the aforementioned depth buffer may include, but is not limited to, operations such as data storage, reading, and deletion.

[0068] Specifically, when a new data packet arrives, if the priority queue is full, it is stored in the deep buffer. When there is free space in the priority queue or the network conditions improve, the data packet is retrieved from the deep buffer for processing. In order to optimize the use of storage space, the deep buffer can also use a first-in-first-out (FIFO) strategy to manage data packets.

[0069] In the specific implementation process, the above method also includes: applying eBPF technology to adjust the depth of the depth buffer to optimize the utilization of storage space.

[0070] Specifically, using eBPF technology to adjust the depth of the depth buffer can optimize the utilization of storage space. By adjusting the depth of the depth buffer, the space required to store data can be effectively reduced, thereby reducing storage costs and improving storage efficiency. This allows for more effective management and storage of data generated by IoT devices, improving the efficiency of data collection, transmission, and storage, and also enhancing system performance and stability.

[0071] Specifically, in eBPF technology, the depth of the deep buffer can be dynamically adjusted according to the actual situation. For example, when network congestion is severe, the depth of the buffer can be temporarily increased to store more data packets, while when the network condition improves, the depth of the buffer can be reduced to free up storage space.

[0072] In the specific implementation process, the above method also includes: applying eBPF technology to clean up IoT device data in the deep buffer according to a preset expiration policy. The preset expiration policy includes a fixed expiration time policy and a relative expiration time policy. The fixed expiration time policy means that IoT device data is valid for a preset time period after it is generated, and automatically expires after the preset time period. The relative expiration time policy determines whether the data has expired based on the relative relationship between the generation time and the current time of the IoT device data.

[0073] Specifically, by pre-setting expiration policies to clean up IoT device data in the deep buffer, resources can be released in a timely manner, improving system response speed and efficiency. Different expiration policies can be selected according to different needs, flexibly responding to data management requirements in different scenarios. Fixed expiration time policies are suitable for scenarios that require strict control of data validity, while relative expiration time policies are more suitable for scenarios that require dynamic determination of data validity based on actual conditions. By reasonably setting expiration policies, data can be effectively managed, improving system performance and reliability, thereby ensuring that IoT device data stored in the deep buffer is always up-to-date and valid, avoiding the waste of system performance and resources caused by expired data.

[0074] The above-mentioned timestamp-based preset expiration strategy is as follows:

[0075] 1. Fixed expiration time policy: Set a fixed expiration time for each data packet. When the data packet reaches the specified time, it will be considered expired and deleted regardless of whether it has been processed. For example, the data packet can be set to be valid for 24 hours after its generation, and will automatically expire after that time.

[0076] 2. Relative expiration time strategy: Determine whether a data packet has expired based on the relative relationship between the data packet's generation time and the current time. For example, a strategy can be set so that a data packet is valid for a certain period of time after its generation (such as the most recent 1 hour), and is considered to have expired after that period of time.

[0077] In the specific implementation process, the above method also includes: if the connection between the kernel-level MQTT client and the MQTT broker is lost, the kernel-level MQTT client will automatically attempt to reconnect and re-report the IoT device data cached in the deep buffer.

[0078] Specifically, it can ensure the reliability and continuity of data from IoT devices. In the event of a disconnection, the kernel-level MQTT client will automatically attempt to reconnect, ensuring that data is not lost. This can improve system stability, reduce the risk of data loss, ensure timely data reporting, and guarantee the accuracy and timeliness of the data.

[0079] In practice, the aforementioned kernel-level MQTT clients typically provide APIs that integrate with the system kernel of IoT devices.

[0080] Specifically, kernel-level MQTT clients provide APIs integrated with the system kernel, which can help devices quickly and efficiently send data to cloud servers or other devices, enabling real-time monitoring, remote control, and data analysis of device data. This improves the overall performance and efficiency of the IoT system. Through kernel-level integrated APIs, data security and stability can be better guaranteed, ensuring the accuracy and reliability of device data and improving the stability and reliability of the IoT system.

[0081] The kernel-level MQTT client and the user-level MQTT client mentioned above have the following differences:

[0082] 1. Interface level

[0083] APIs tightly integrated with the kernel: Kernel-level MQTT clients typically provide APIs (Application Programming Interfaces) that are tightly integrated with the kernel. These APIs allow developers to directly call MQTT-related functions, such as connection, publishing, and subscription, within the kernel space. This integration reduces the data exchange overhead between user space and kernel space and improves communication efficiency.

[0084] Kernel-level resource management: Kernel-level MQTT clients can directly utilize the resource management functions provided by the kernel, such as memory allocation and process scheduling, which helps optimize client performance and reduce latency caused by resource contention.

[0085] 2. Functional level

[0086] Higher real-time performance and reliability: Kernel-level MQTT clients typically run in kernel space, enabling them to respond to network events and interrupts more quickly. This gives them an advantage in handling applications with high real-time requirements. At the same time, due to the kernel space's direct access to hardware resources, kernel-level clients also perform better in terms of data transmission reliability.

[0087] Enhanced security and isolation: Kernel-level MQTT clients can leverage kernel-provided security mechanisms, such as firewalls and access control lists (ACLs), to enhance communication security. Furthermore, kernel-level isolation mechanisms ensure that the MQTT client operates independently from other user-space processes, reducing potential security risks.

[0088] Optimized network performance: Kernel-level MQTT clients can leverage the network stack optimization features provided by the kernel, such as TCP / IP protocol stack optimization and network buffer management, which helps improve client network performance and reduce communication latency and packet loss rate.

[0089] Better power management: In embedded devices or low-power scenarios, kernel-level MQTT clients can better integrate with power management systems. By optimizing power management strategies, such as sleep and wake-up mechanisms, device power consumption can be significantly reduced.

[0090] Rich debugging and monitoring features: The development and debugging of kernel-level MQTT clients are relatively complex, but they usually provide rich debugging and monitoring features, which help developers quickly locate problems, optimize performance, and ensure the stable operation of the client during the development process.

[0091] 3. Special Function Implementation

[0092] Kernel-level persistent storage: Kernel-level MQTT clients can utilize the persistent storage mechanism provided by the kernel to save unfinished message delivery tasks, enabling the client to resume unfinished message delivery tasks after device restart or network interruption, ensuring message reliability.

[0093] Kernel-level topic filtering: Kernel-level MQTT clients can implement a more efficient topic filtering mechanism. By utilizing the string matching algorithms and data structures provided by the kernel, the topic filtering process can be accelerated, improving message processing efficiency.

[0094] Kernel-level concurrent processing: Kernel-level MQTT clients can utilize the concurrent processing mechanisms provided by the kernel to manage multiple connections and sessions, which helps optimize the client's concurrent performance and improve message processing throughput.

[0095] The technical solutions provided by the above embodiments of this application have the following beneficial effects: 1) Improved real-time data transmission: By implementing the MQTT client and integrating eBPF technology at the kernel level, data transmission latency is reduced, improving the real-time performance of data transmission; 2) Enhanced data transmission reliability: eBPF technology, through priority queues and deep buffer mechanisms, ensures that high-priority data is sent first and avoids data loss; 3) Reduced system resource consumption: The data reporting process does not require processing by user-level programs, reducing system resource consumption and complexity; 4) Improved system stability: The integration of the kernel-level MQTT client, priority sorting, and deep caching technology makes the data reporting process more stable and reliable, reducing the risk of system crashes caused by user-level program anomalies. Simultaneously, by integrating eBPF technology at the kernel level, efficient and direct reporting of heartbeat packets and device status data from IoT devices is achieved without user-level program processing, thereby improving the real-time performance and reliability of data transmission.

[0096] As can be seen from the above, this application provides an IoT device data reporting mechanism based on eBPF technology and MQTT protocol. By integrating eBPF technology at the kernel level, it enables efficient and direct reporting of heartbeat packets and device status data without the need for user-level program processing, thereby improving the real-time performance and reliability of data transmission.

[0097] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the method for reporting IoT device data in this application will be described in detail below with reference to specific embodiments.

[0098] This embodiment relates to a specific method for reporting data from Internet of Things (IoT) devices, including the following steps:

[0099] Step S1: When an IoT device needs to report heartbeat packets or device status data, the data is first sent to the eBPF buffer of the kernel-level MQTT client.

[0100] Step S2: The eBPF buffer sorts and caches the data according to its priority and buffer depth.

[0101] Step S3: Based on the state of the eBPF buffer, the MQTT client automatically sends high-priority data to the MQTT broker via the MQTT protocol. The MQTT broker then forwards the received data to the corresponding subscribers, completing the data reporting process.

[0102] Step S4: When the connection between the IoT device and the MQTT broker is lost, the kernel-level MQTT client will automatically attempt to reconnect and resend the data cached in the eBPF buffer.

[0103] Step S5: If the device is unable to restore the connection for an extended period of time, the eBPF buffer will automatically clean up expired data according to the preset expiration policy to avoid resource exhaustion.

[0104] It should be noted that in the data reporting mechanism of IoT devices, eBPF technology can significantly improve the real-time performance and reliability of data reporting. By combining priority queues and deep buffers, efficient data processing and storage can be achieved.

[0105] For example, when an IoT device generates a heartbeat or changes its state, the data is encapsulated into a data packet and sent to a priority queue. The priority queue sorts the data packets according to their priority and attempts to send them to the MQTT server. If the current network conditions are good and the MQTT server has available bandwidth, the data packet will be sent immediately; otherwise, the data packet will be stored in a deep buffer to await processing.

[0106] Figure 2 This is a schematic diagram of the overall server architecture provided according to the embodiments of this application. The specific data reporting process is as follows: First, the data packet is sent to the eBPF buffer of the kernel-level MQTT client. The integrated eBPF technology manages the heartbeat packets and device status data to be sent, encapsulates them into MQTT messages, and sorts and caches them. The user-level MQTT client automatically sends high-priority data to the MQTT server broker according to the status of the eBPF buffer, and forwards the received data to the corresponding subscribers.

[0107] After the data is encapsulated into data packets, eBPF technology will process it using a priority queue and a depth buffer. The specific data processing flow after encapsulation is as follows:

[0108] 1. Priority queue processing: Data packets are sent to a priority queue and sorted according to their priority. Data packets with higher priority will be processed first and sent to the MQTT server or other destination address.

[0109] 2. Deep Buffer Processing: If the priority queue is full or network congestion prevents packets from being sent immediately, the packets will be stored in a deep buffer to await processing. The deep buffer uses strategies such as First In First Out (FIFO) to manage packets to ensure that data is processed in the correct order.

[0110] 3. Dynamic adjustment: Based on network conditions and data processing needs, eBPF technology can dynamically adjust the depth of the depth buffer to optimize storage space utilization.

[0111] In addition, it includes an exception handling mechanism. When the connection between the IoT device and the MQTT broker is lost, the kernel-level MQTT client automatically reconnects and resends the cached data. When the device is unable to restore the connection for a long time, the buffer automatically cleans up expired data.

[0112] This application also provides an apparatus for reporting IoT device data. It should be noted that the apparatus for reporting IoT device data in this application can be used to execute the method for reporting IoT device data provided in this application. This apparatus is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0113] The following describes the apparatus for reporting IoT device data provided in the embodiments of this application.

[0114] Figure 3 This is a schematic diagram of an apparatus for reporting IoT device data according to an embodiment of this application. Figure 3 As shown, the device includes: a first transmitting unit 31, a processing unit 32, and a second transmitting unit 33.

[0115] The first sending unit 31 is used to send the IoT device data to be uploaded to the kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device.

[0116] Specifically, implementing the MQTT client in the device's system kernel enables real-time transmission and processing of device data, improving the stability and security of data transmission. Integrating a kernel-level MQTT client allows the device to function normally even without an external network connection, reducing latency between the device and the external network, and improving the real-time performance and reliability of data. Furthermore, the kernel-level MQTT client can be better integrated with other functional modules of the device, improving the overall system performance and stability, and enabling better management and control of IoT devices.

[0117] Processing unit 32 is used to prioritize and cache data from IoT devices.

[0118] Specifically, applying eBPF technology can prioritize data, ensuring that important data is transmitted first, improving data real-time performance and accuracy. By integrating eBPF technology into the kernel-level MQTT client, it is possible to manage heartbeat packets and device status data to be sent. Heartbeat packets and device status data are encapsulated into MQTT messages in the kernel and sorted and cached according to the rules of eBPF technology. Through caching, data transmission latency and network bandwidth consumption can be reduced, improving data transmission efficiency and stability. This effectively optimizes the data transmission process and enhances the effectiveness and performance of data reporting by IoT devices.

[0119] The second sending unit 33 is used by the kernel-level MQTT client to send at least a portion of the IoT device data to the MQTT broker according to priority order using the MQTT protocol, so that the MQTT broker can send the received IoT device data to the corresponding subscribers.

[0120] Specifically, a kernel-level MQTT client can send IoT device data to an MQTT broker, which can then forward the data to the relevant subscribers, thereby achieving reliable data transmission and real-time updates. This ensures that subscribers can obtain the latest device data in a timely manner. By setting priority order, important data can be sent first, improving the efficiency and reliability of data transmission. This enhances the efficiency and reliability of IoT device data reporting and provides a guarantee for real-time data updates and transmission.

[0121] This embodiment sends IoT device data to be uploaded to a kernel-level MQTT client, which is implemented within the IoT device's system kernel. The client prioritizes and caches the IoT device data. Using the MQTT protocol, the kernel-level MQTT client sends at least a portion of the IoT device data to the MQTT broker according to priority, enabling the MQTT broker to forward the received data to the corresponding subscribers. This solution utilizes a kernel-level MQTT client, priority sorting, and deep caching technology, making the data reporting process more stable and reliable, reducing the risk of system crashes due to user-level program anomalies, and thus solving the problem that current MQTT protocol implementations often rely on user-level libraries and are difficult to process efficiently at the kernel level.

[0122] The aforementioned device for reporting IoT device data further includes: an encapsulation unit, used to encapsulate the IoT device data before prioritizing and caching it to obtain encapsulated data; wherein, encapsulating the IoT device data to obtain encapsulated data includes: performing a selection of encapsulation protocol sub-step, a data mapping sub-step, a header filling sub-step, and a verification and encryption sub-step to form encapsulated data, wherein the data mapping sub-step indicates mapping the IoT device data to the payload portion of the encapsulation protocol, the header filling sub-step indicates filling the corresponding header information according to the selected encapsulation protocol, and the verification and encryption sub-step indicates verifying the integrity of the data and encrypting the data.

[0123] Specifically, by selecting a suitable encapsulation protocol, the reliability and stability of data during transmission can be ensured. Mapping IoT device data to the payload of the encapsulation protocol can effectively integrate data into encapsulated data, facilitating transmission and processing. Filling in the corresponding header information according to the selected encapsulation protocol can provide relevant information about the transmitted data, making it easier for the receiving end to correctly parse and process the data. Verifying the integrity of the data and encrypting the data can ensure the security and confidentiality of the data during transmission, preventing data from being tampered with or stolen. By encapsulating IoT device data to obtain encapsulated data, the security and reliability of data transmission can be effectively guaranteed, data transmission efficiency and stability can be improved, and the reporting and transmission of IoT device data can be effectively realized.

[0124] The aforementioned processing unit includes a storage module, used to store the IoT device data in a deep buffer if the priority queue is full or network congestion prevents the IoT device data from being sent immediately.

[0125] Specifically, to ensure that IoT device data is not lost in the event of network congestion or a full priority queue, it is stored in a deep buffer to guarantee data integrity and accuracy, and to avoid affecting the normal operation of the system due to the inability to send data in a timely manner. By applying eBPF technology to cache IoT device data, the reliability and stability of data can be improved, and timely transmission and processing of data can be ensured.

[0126] The aforementioned device for reporting IoT device data also includes: a sending module, used to send IoT device data using a first-in-first-out strategy when the IoT device data stored in the deep buffer meets the sending conditions.

[0127] Specifically, adopting a first-in, first-out (FIFO) strategy ensures that data is sent in the order it is stored, avoiding data transmission chaos and errors, guaranteeing data integrity and accuracy, ensuring that data is not lost or duplicated during network transmission, improving the reliability and stability of data transmission, effectively managing and sending IoT device data, ensuring that data is sent in the correct order, thereby improving data transmission efficiency and reliability.

[0128] The aforementioned device for reporting IoT device data also includes an adjustment module, used to apply eBPF technology to adjust the depth of the depth buffer to optimize the utilization of storage space.

[0129] Specifically, using eBPF technology to adjust the depth of the depth buffer can optimize the utilization of storage space. By adjusting the depth of the depth buffer, the space required to store data can be effectively reduced, thereby reducing storage costs and improving storage efficiency. This allows for more effective management and storage of data generated by IoT devices, improving the efficiency of data collection, transmission, and storage, and also enhancing system performance and stability.

[0130] The aforementioned device for reporting IoT device data further includes: a cleaning unit, used to clean up IoT device data in the deep buffer using eBPF technology according to a preset expiration policy. The preset expiration policy includes a fixed expiration time policy and a relative expiration time policy. The fixed expiration time policy ensures that IoT device data is valid for a preset time period after its generation and automatically expires after the preset time period. The relative expiration time policy determines whether the data has expired based on the relative relationship between the generation time and the current time of the IoT device data.

[0131] Specifically, by pre-setting expiration policies to clean up IoT device data in the deep buffer, resources can be released in a timely manner, improving system response speed and efficiency. Different expiration policies can be selected according to different needs, flexibly responding to data management requirements in different scenarios. Fixed expiration time policies are suitable for scenarios that require strict control of data validity, while relative expiration time policies are more suitable for scenarios that require dynamic determination of data validity based on actual conditions. By reasonably setting expiration policies, data can be effectively managed, improving system performance and reliability, thereby ensuring that IoT device data stored in the deep buffer is always up-to-date and valid, avoiding the waste of system performance and resources caused by expired data.

[0132] The aforementioned device for reporting IoT device data further includes a connection unit, which is used to automatically attempt to reconnect if the connection between the kernel-level MQTT client and the MQTT broker is lost, and to re-report the IoT device data cached in the deep buffer.

[0133] Specifically, it can ensure the reliability and continuity of data from IoT devices. In the event of a disconnection, the kernel-level MQTT client will automatically attempt to reconnect, ensuring that data is not lost. This can improve system stability, reduce the risk of data loss, ensure timely data reporting, and guarantee the accuracy and timeliness of the data.

[0134] The aforementioned kernel-level MQTT clients typically provide APIs that integrate with the system kernel of IoT devices.

[0135] Specifically, kernel-level MQTT clients provide APIs integrated with the system kernel, which can help devices quickly and efficiently send data to cloud servers or other devices, enabling real-time monitoring, remote control, and data analysis of device data. This improves the overall performance and efficiency of the IoT system. Through kernel-level integrated APIs, data security and stability can be better guaranteed, ensuring the accuracy and reliability of device data and improving the stability and reliability of the IoT system.

[0136] The aforementioned device for reporting IoT device data includes a processor and a memory. The first transmitting unit, processing unit, and second transmitting unit, etc., are all stored as program units in the memory, and the processor executes the program units stored in the memory to achieve the corresponding functions. All of the above modules are located in the same processor; alternatively, the modules may be located in different processors in any combination.

[0137] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can address the issue that current MQTT protocol implementations largely rely on user-level libraries, making efficient processing at the kernel level difficult.

[0138] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0139] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the method for reporting IoT device data.

[0140] Specifically, methods for reporting IoT device data include:

[0141] Step S101: Send the IoT device data to be uploaded to the kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device.

[0142] Step S102: Prioritize and cache the IoT device data.

[0143] In step S103, the kernel-level MQTT client uses the MQTT protocol to send at least a portion of the IoT device data to the MQTT broker according to priority, so that the MQTT broker can send the received IoT device data to the corresponding subscribers.

[0144] Optionally, before prioritizing and caching the IoT device data, the method further includes: encapsulating the IoT device data to obtain encapsulated data; wherein, encapsulating the IoT device data to obtain encapsulated data includes: performing a selection of encapsulation protocol sub-step, a data mapping sub-step, a header filling sub-step, and a verification and encryption sub-step to form encapsulated data, wherein the data mapping sub-step indicates mapping the IoT device data to the payload portion of the encapsulation protocol, the header filling sub-step indicates filling the corresponding header information according to the selected encapsulation protocol, and the verification and encryption sub-step indicates verifying the integrity of the data and encrypting the data.

[0145] Optionally, IoT device data can be prioritized and cached, including storing the IoT device data in a deep buffer if the priority queue is full or network congestion prevents the IoT device data from being sent immediately.

[0146] Optionally, the above method further includes: sending the IoT device data using a first-in-first-out strategy when the IoT device data stored in the deep buffer meets the sending conditions.

[0147] Optionally, the above method further includes: adjusting the depth of the depth buffer to optimize the utilization of storage space.

[0148] Optionally, the above method further includes: cleaning up IoT device data in the deep buffer according to a preset expiration policy, wherein the preset expiration policy includes a fixed expiration time policy and a relative expiration time policy, wherein the fixed expiration time policy is that IoT device data is valid for a preset time period after it is generated, and automatically expires after the preset time period, and the relative expiration time policy determines whether it expires based on the relative relationship between the generation time and the current time of the IoT device data.

[0149] Optionally, the above method further includes: if the connection between the kernel-level MQTT client and the MQTT broker is lost, the kernel-level MQTT client automatically attempts to reconnect and re-reports the IoT device data cached in the deep buffer.

[0150] Alternatively, kernel-level MQTT clients typically provide APIs that integrate with the system kernel of IoT devices.

[0151] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0152] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0153] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0154] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0155] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0156] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0157] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0158] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0159] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0160] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for reporting data from Internet of Things (IoT) devices, characterized in that, include: The data of the IoT device to be uploaded is sent to the kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device; The data from the IoT devices is prioritized and cached. The kernel-level MQTT client uses the MQTT protocol to send at least a portion of the IoT device data to the MQTT broker according to priority, so that the MQTT broker can send the received IoT device data to the corresponding subscribers. The method further includes: If the connection between the kernel-level MQTT client and the MQTT broker is lost, the kernel-level MQTT client will automatically attempt to reconnect and re-report the IoT device data cached in the deep buffer. The priority sorting and caching process for the IoT device data includes: If the priority queue is full or network congestion prevents the IoT device data from being sent immediately, then this part of the IoT device data will be stored in a deep buffer. The IoT device data in the deep buffer is cleaned up according to a preset expiration policy, wherein the preset expiration policy includes a fixed expiration time policy and a relative expiration time policy. The fixed expiration time strategy means that the IoT device data is valid for a preset time period after it is generated, and automatically expires after the preset time period. The relative expiration time strategy determines whether the data has expired based on the relative relationship between the generation time and the current time of the IoT device data.

2. The method according to claim 1, characterized in that, Before prioritizing and caching the data from the IoT devices, the method further includes: The data from the IoT device is encapsulated to obtain encapsulated data; The encapsulation process for the IoT device data includes: selecting an encapsulation protocol, data mapping, header filling, and verification and encryption. The data mapping step maps the IoT device data to the payload portion of the encapsulation protocol. The header filling step fills the corresponding header information according to the selected encapsulation protocol. The verification and encryption step verifies the integrity of the data and encrypts the data.

3. The method according to claim 1, characterized in that, The method further includes: If the IoT device data stored in the depth buffer meets the transmission conditions, the IoT device data is transmitted using a first-in-first-out (FIFO) strategy.

4. The method according to claim 1, characterized in that, The method further includes: The depth of the depth buffer is adjusted to optimize the utilization of storage space.

5. The method according to any one of claims 1 to 4, characterized in that, The kernel-level MQTT client typically provides an API that integrates with the system kernel of the IoT device.

6. A device for reporting data from Internet of Things (IoT) devices, characterized in that, include: The first sending unit is used to send the IoT device data to be uploaded to the kernel-level MQTT client, wherein the kernel-level MQTT client is implemented in the system kernel of the IoT device; The processing unit is used to prioritize and cache the data from the IoT devices. The second sending unit is used by the kernel-level MQTT client to send at least a portion of the IoT device data to the MQTT broker according to priority order using the MQTT protocol, so that the MQTT broker sends the received IoT device data to the corresponding subscribers; The device further includes: The connection unit is configured to automatically attempt to reconnect if the connection between the kernel-level MQTT client and the MQTT broker is lost, and to re-report the IoT device data cached in the deep buffer. The processing unit includes: The storage module is used to store the IoT device data in a deep buffer if the priority queue is full or network congestion prevents the IoT device data from being sent immediately. The cleaning unit is used to clean up the IoT device data in the deep buffer according to a preset expiration policy. The preset expiration policy includes a fixed expiration time policy and a relative expiration time policy. The fixed expiration time policy is that the IoT device data is valid for a preset time period after it is generated, and automatically expires after the preset time period. The relative expiration time policy is to determine whether the data has expired based on the relative relationship between the generation time and the current time of the IoT device data.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method for reporting Internet of Things device data as described in any one of claims 1 to 5.

Images