Iot device communication system

Abstract

The application discloses an Internet of Things device communication system, which splits the communication system into three independent components, i.e., an edge agent module, a transmission relay module and a center platform module, and key modules can be independently expanded according to respective bottlenecks; the transmission relay module is expanded according to connection number and encryption and decryption throughput, and the center platform module is expanded according to service message volume, thus solving the problem of overall expansion of the center platform module in the existing two-layer architecture, and a single transmission relay module instance can bear about 10,000 device connections and the whole system can support online concurrent connection of million-level devices. In the transmission relay module, in-place decryption and data frame rewriting are performed on device uplink messages in a forwarding process, and decryption calculation is dispersed from the center platform module to each transmission relay module node, so that the CPU load of the center platform module is reduced by about 60%, and meanwhile, only encryption needs to be performed at the device end, thereby reducing the calculation pressure of the embedded device.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to an IoT device communication system that enables bidirectional, secure, and reliable message transmission between large-scale embedded terminal devices (CPE devices such as home gateways and routers) and cloud center platform modules, and can be directly applied to scenarios such as remote management of smart gateways, data acquisition and remote control of IoT devices. Background Technology

[0002] Currently, IoT device communication mainly adopts MQTT protocol (publish / subscribe mode for direct device connection to Broker), CoAP protocol / LwM2M protocol (RESTful device management based on UDP), HTTP protocol / WebSocket polling, or custom TCP private protocol.

[0003] The typical architecture of the above solutions is a two-layer mode of "device directly connected to the central platform module" - the device directly connects to the cloud central platform module, and the central platform module undertakes all responsibilities such as connection management, protocol parsing, service routing, authentication and authorization.

[0004] (a) The central platform module is highly coupled and cannot scale independently according to its responsibilities: In the two-layer direct connection architecture, connection management (massive long connections), encryption and decryption calculation, and business processing are all coupled to the central platform module side. When the number of devices increases, it can only be expanded as a whole and cannot scale independently according to the bottleneck granularity (such as expanding only the encryption and decryption nodes).

[0005] (b) Rigid key management and message loss during key rotation: Fixed key schemes have poor security; Session key schemes have a "message failure window" during key rotation - when a message encrypted by the device with the old key arrives, the central platform module has already switched to the new key and the decryption fails.

[0006] (c) High overhead of reconnection after disconnection: After a network fluctuation causes a disconnection, the device needs to re-execute the complete authentication process (TLS handshake + token authentication + terminal device information reporting), which takes several seconds each time to recover, during which messages may be backlogged or lost.

[0007] (d) Lack of a unified management framework for multiple plugins: If multiple business plugins on the same device independently connect to the central platform module (N plugins = N connections), the overhead is too large; if they coordinate and reuse themselves, it increases the development complexity. In addition, the heartbeats of multiple plugins need to be reported one by one, and the number of network messages increases linearly with the number of plugins.

[0008] (e) Coupling of synchronous / asynchronous message channels: There are two modes for business systems to send messages to devices: "request-response" (waiting for a reply) and "notification" (delivery only). Existing solutions often process them in the same channel, which may cause synchronous requests to be blocked indefinitely, or asynchronous throughput to be slowed down by synchronous logic. Summary of the Invention

[0009] The purpose of this invention is to solve the above-mentioned problems existing in the prior art and to provide an Internet of Things (IoT) device communication system.

[0010] The objective of this invention is achieved through the following technical solution: The Internet of Things (IoT) device communication system includes an edge agent module, a transmission relay module, and a central platform module for sequential communication; The edge proxy module is deployed on the terminal device. When sending uplink service data, the edge proxy module performs the following encryption process: When it is determined that the number of bytes of the message body to be sent exceeds a preset threshold, DEFLATE compression is performed and the original length before compression is marked with a compression field. The derived key is calculated using the SHA256 hash algorithm based on the timestamp, device identifier, access_token, and client identifier. The derived key is used to encrypt the compressed message body using AES-256-GCM to generate a data packet containing a random nonce and ciphertext; The data packet is encapsulated into a TLV data frame and then sent to the transmission relay module via a TLS encrypted connection. The transmission relay module is deployed at the edge network node. When it receives the TLV data frame sent to it by the edge proxy module, it decrypts it. If the decryption fails, it discards the TLV data frame. If the decryption is successful, it rewrites the data frame and forwards the rewritten data frame to the central platform module through the uplink connection pool. The central platform module is deployed in the cloud. During the bidirectional information transmission with the edge agent module, it achieves the separation of synchronous and asynchronous message scheduling through a pending reply table and Kafka.

[0011] Preferably, after obtaining terminal device information through FFI, the edge proxy module sends a token request to the transmission relay module through a TLS encrypted connection; After receiving the Token request, the transmission relay module forwards the Token request to the central platform module through the uplink connection pool; After verifying the device identity, the central platform module generates an access_token and transmits it along the original path to the transmission relay module and the edge proxy module. The transmission relay module and the edge proxy module store the access_token respectively. The edge proxy module sends a device registration request to the transmission relay module, the device registration request containing an authentication string determined based on the access_token stored therein; The transmission relay module performs local verification on the authentication string in the registration request based on its stored access_token. If the verification passes, the registration request is forwarded to the central platform module. If the verification fails, an authentication failure response is returned directly to the edge proxy module. After completing device registration, the central platform module returns a registration response to the edge agent module. Upon receiving the registration response, the edge agent module enters a ready state and can perform bidirectional information transmission with the central platform module.

[0012] Preferably, the authentication string is determined using the SHA256 hash algorithm based on the access_token, timestamp, and device identifier.

[0013] Preferably, the edge proxy module and the transmission relay module store the current access_token and the previous access_token, respectively; When the edge proxy module and the transmission relay module receive a new access_token issued by the central platform module, they downgrade the current access_token to the previous access_token and store the new access_token as the current access_token.

[0014] Preferably, after receiving the TLV data frame sent to it by the edge proxy module, the transmission relay module performs the following processing: Retrieve the current access_token and the previous access_token stored in the database; First, calculate the cipher_key using the current access_token and decrypt it. If decryption fails, calculate the cipher_key using the previous access_token and decrypt it. If decryption fails, discard the TLV data frame. If decryption is successful, the decrypted data is decompressed to obtain plaintext to replace the ciphertext payload of the original TLV data frame, and the real IP address of the terminal device where the edge proxy module is located is injected into the IP field. The frame is then re-encoded and forwarded to the central platform module.

[0015] Preferably, the edge proxy module includes a sleep manager, which controls the edge proxy module to actively disconnect from the TLS connection with the transmission relay module and enter a sleep state when there is no plugin activity within a preset time period, and wakes up and reconnects through dual-channel events, namely plugin activity events and heartbeat timing events.

[0016] Preferably, before sending a heartbeat request to the transmission relay module in each heartbeat cycle, the edge proxy module first broadcasts a heartbeat probe request to all connected local service plugins and collects the heartbeat responses returned by each local service plugin. Then, it aggregates the collected heartbeat responses and the status information of the terminal device into a heartbeat request and sends it to the transmission relay module.

[0017] Preferably, after the edge proxy module abnormally loses connection with the transmission relay module, it determines whether the current access_token has expired; If it is determined that the current access_token has not expired, the edge proxy module remains in a ready state, and after the edge proxy module and the transmission relay module re-establish the TLS encrypted connection, the buffered messages to be sent during the disconnection period are directly replayed. If the current access_token is determined to be expired, the edge proxy module will obtain a new access_token after re-establishing a TLS encrypted connection with the transmission relay module.

[0018] Preferably, the transmission relay module selects a TCP plaintext connection from the uplink connection pool using a random starting point polling method to distribute uplink data.

[0019] Preferably, the separation of synchronous and asynchronous message scheduling through the pending reply table and Kafka specifically involves: When a synchronization request is received from an HTTP interface, the central platform module inserts the synchronization request into the pending response table based on a key composed of a device identifier, a client identifier, and a message identifier, creates a oneshot channel corresponding to the key, and sends the synchronization request to the corresponding local business plugin through the transmission relay module and the edge proxy module. When the central platform module receives the corresponding reply, it searches for a matching key in the reply table. If a match is found, the reply is returned to the synchronization request waiting party through the oneshot channel corresponding to the matching key. If the match fails, the response will be asynchronously written back to the business system via Kafka; When a downlink message is received from Kafka, the central platform module does not insert the downlink message into the pending reply table, but directly sends the downlink message to the local business plugin corresponding to the downlink message via the transmission relay module and the edge proxy module.

[0020] Preferably, the pending response table maintains an independent in-transit concurrent counter for each client identifier. When the number of in-transit requests for a certain client identifier exceeds a preset quota, new synchronization requests related to that client identifier are rejected. The entries in the pending response table are configured with a timeout expiration policy. When a synchronization request corresponding to an entry times out without receiving a response, the pending response table triggers the cache expiration callback corresponding to the entry to automatically send a timeout notification to the synchronization request waiting party corresponding to the entry, and decrements the in-transit concurrency counter corresponding to the client identifier of the entry by 1.

[0021] The advantages of the technical solution of this invention are mainly reflected in: This invention divides the system into three independent components: an edge proxy module, a transmission relay module, and a central platform module. Key modules can be scaled up independently according to their respective bottlenecks: the transmission relay module can be scaled up according to the number of connections and encryption / decryption throughput, and the central platform module can be scaled up according to the volume of business messages. This solves the problem of overall scaling of the central platform module in the existing two-layer architecture. A single transmission relay module instance can support approximately 10,000 device connections, and the whole system supports millions of devices online concurrently.

[0022] The transmission relay module of this invention performs on-site decryption and data frame rewriting of the uplink message on the device during the forwarding process. The decryption calculation is distributed from the central platform module to each transmission relay module node, reducing the CPU load of the central platform module by about 60%. At the same time, the device only needs to perform encryption, which reduces the computing pressure on the embedded device.

[0023] The uplink service data frame of this invention adopts the TLV data frame format. The transmission relay module can make decisions based on the 8-byte frame header of the TLV data frame, reducing the processing overhead of a single frame by about 80%.

[0024] This invention employs a double-buffering mechanism that stores both the current access token and the previous access token. During key rotation, the old token is automatically downgraded to the previous value and retained. During decryption, the current value is used first, and the previous value is rolled back if the decryption fails, thus eliminating the message failure window during key rotation.

[0025] When a device disconnects and reconnects, this invention reuses the access token if it has not expired, skipping the token authentication and device registration process. The recovery time is only one TCP+TLS handshake RTT (usually less than 500ms), which is significantly shorter than the 2 to 4 seconds of the traditional solution.

[0026] In each heartbeat cycle, this invention aggregates the heartbeat probe responses of N plugins into a single heartbeat request report. For typical scenarios with multiple plugins running, the number of uplink heartbeat messages is significantly reduced. When N=10, the message volume is reduced by 91%, and network bandwidth utilization is significantly improved.

[0027] The central platform module of this invention achieves natural separation of synchronous and asynchronous messages through a pending response table. Synchronous requests that hit the pending response table return via the one-shot channel, while those that miss return via Kafka asynchronous write-back. At the same time, the pending response table provides per-client concurrency quotas and automatic timeout notifications to ensure that the waiting party will receive a response. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the communication system architecture of the present invention; Figure 2 This is a flowchart of the device registration process performed by the edge proxy module in the communication system of the present invention; Figure 3 This is a flowchart illustrating the cooperation between the edge proxy module and the transmission relay module in the communication system of this invention for uplink data transmission. Detailed Implementation

[0029] The objectives, advantages, and features of this invention will be illustrated and explained through the following non-limiting description of preferred embodiments. These embodiments are merely typical examples of applying the technical solutions of this invention, and all technical solutions formed by equivalent substitutions or equivalent transformations fall within the scope of protection claimed by this invention.

[0030] In the description of the solution, it should be noted that the terms "center," "upper," "lower," "left," "right," "front," "rear," "vertical," "horizontal," "inner," and "outer," etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the accompanying drawings and are only for the convenience and simplification of description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0031] Example 1 The communication system for IoT devices disclosed in this invention will now be described in conjunction with the accompanying drawings, as shown below. Figure 1 As shown, the communication system includes an edge proxy module, a transmission relay module, and a central platform module that communicate sequentially. The edge proxy module is deployed on the terminal device, and it communicates with the local service plug-in and with the transmission relay module via a TLS encrypted connection. The transmission relay module is deployed at the edge network node and performs differentiated processing on the data received from the edge proxy module and the central platform module; The central platform module is deployed in the cloud. During the bidirectional information transmission with the edge agent module, it achieves the separation of synchronous and asynchronous message scheduling through a pending reply table and Kafka.

[0032] The terminal device may be, for example, a home gateway, a router, or other CPE device, and is not limited here. The terminal device runs multiple local service plugins, such as network diagnostic plugins, WiFi optimization plugins, and device identification plugins.

[0033] The edge proxy module includes a southbound terminal device information interface submodule, a local plug-in service submodule, an uplink connection management submodule, and a local token cache submodule.

[0034] The southbound terminal device information interface submodule uses FFI (Foreign Function Interface) to call the manufacturer's C language dynamic library to read device identity information. The device identity information read includes, but is not limited to, MAC address (as the device's unique identifier UID), serial number, firmware version, and hardware version.

[0035] The local plugin service submodule communicates with the multiple business plugins via Unix Domain Socket. The local plugin service submodule maintains an independent TokenBucket rate limiter and MPSC control channel for each connected local business plugin (a local business plugin that has established a communication link with the local plugin service submodule and is in an active state). The TokenBucket rate limiter is used to limit the amount of data or the number of requests that each plugin can send to the edge agent per unit time. The MPSC control channel is an asynchronous communication channel with multiple producers and a single consumer. The specific working principle of the TokenBucket rate limiter and the MPSC control channel is a known technology and is not an innovation of this invention, so it will not be described in detail here.

[0036] The uplink connection management submodule communicates with the transmission relay module through a TLS encrypted connection. It has the ability to perform various processing on uplink service data and send uplink data to the transmission relay module through a TLS encrypted connection. The uplink connection management submodule includes a protocol state machine, a pending buffer queue, a heartbeat collector, a sleep manager, and an exponential backoff reconnection device.

[0037] The protocol state machine includes three phases: Token request, device registration, and heartbeat keep-alive.

[0038] The Token request phase is triggered when the edge proxy module process starts, reconnects after a network interruption, or when a locally cached Token is deemed invalid. During the Token request phase, the edge proxy module sends an authentication request to the transmission relay module, carrying the device certificate or a pre-set key, requesting an access_token issued by the central platform module. If obtaining the access_token fails, the process stops at this phase and triggers an exponential backoff retry.

[0039] The device registration phase is triggered after successfully obtaining the access_token. During the device registration phase, the core action of the edge proxy module is to generate an Init registration request (device registration request) and send it to the central platform module through the transmission relay module. After successful registration, it enters the ready state.

[0040] The heartbeat keep-alive phase automatically begins after successful device registration and continues until it is powered off or abnormally interrupted. During the heartbeat keep-alive phase, the edge proxy module periodically sends heartbeat Ping messages and forwards business data according to a preset process.

[0041] The pending transmission buffer queue is a first-in-first-out (FIFO) queue in memory, used to temporarily store uplink service data that has not yet been successfully sent to the transmission relay module.

[0042] The heartbeat probe collector is an independent timed task module responsible for constructing and sending lightweight heartbeat requests according to a preset period (e.g., every 60 seconds).

[0043] Before sending a heartbeat request to the transmission relay module in each heartbeat cycle, for example, 5 seconds before sending the heartbeat request, the heartbeat probe collector collects the terminal device status information of each local service plugin. It then aggregates the collected terminal device status information with the plugin snapshots of connected local service plugins and the terminal device status snapshots into a single heartbeat request and sends it to the transmission relay module all at once. The transmission relay module performs local authentication verification and IP injection on the heartbeat request before forwarding it to the central platform module. The central platform module can obtain the health status of all local service plugins in a single processing step.

[0044] The hibernation manager is used to control the edge proxy module to actively disconnect the TLS connection and enter a hibernation state when there is no plugin activity within a preset time period, and to wake up and reconnect through dual-channel events. The dual-channel events are plugin activity events and heartbeat timer events. The heartbeat timer event is, for example, when the hibernation reaches a predetermined time. The predetermined time can be set as needed, such as 1 minute, 2 minutes, etc., and is not limited here.

[0045] The local token cache submodule is used to store the access_token.

[0046] The transmission relay module includes a client access submodule, a frame rewriting submodule, an uplink connection pool submodule, and a token caching submodule.

[0047] The client access submodule acts as a TLS server, listening for and accepting TLS handshake requests initiated by the edge proxy module to establish a secure communication channel between the transmission relay module and the edge proxy module. After establishing the TLS secure communication channel, both the edge proxy module and the client access submodule enable the TCP_NODELAY option (disabling the Nagle algorithm) at the TCP layer to avoid additional latency caused by small data packets waiting to be merged. Simultaneously, the client access submodule executes a frame-by-frame forwarding strategy at the application layer—that is, it immediately forwards each complete protocol frame received to the upper layer without buffering or merging, thereby further reducing end-to-end transmission latency and meeting the real-time requirements of IoT scenarios.

[0048] The frame rewriting submodule performs preset processing on the data frames that have passed through. The specific processing strategy is driven by a decision state machine, which includes four types of processing: Unchanged, Forward, Respond, and Drop.

[0049] When the data frame is a Token request, the decision is Unchanged, i.e., transparent forwarding; When the data frame is a registration request or heartbeat request, the authentication string is locally validated. If the validation passes, the decision is Unchanged; if the validation fails, the decision is Respond. That is, an authentication failure response is generated locally and returned to the edge proxy module. When the data frame is an uplink service data frame, after performing data decryption and IP address injection, it is re-encoded and the decision is to Forward, i.e., rewrite and forward. If decryption fails or there is no usable token, the decision is to Drop, i.e., discard. When the data frame is of other types, the decision is Unchanged.

[0050] The uplink connection pool submodule maintains an uplink connection pool, which includes multiple TCP plaintext connections from the transmission relay module to the central platform module. The uplink connection pool submodule uses a random-start polling, lock-free write method for load distribution. Specifically, after receiving a data frame to be sent, the uplink connection pool submodule polls a live TCP plaintext connection from a random start point and sends the data frame to the central platform module. A snapshot of the live TCP plaintext connection is read using atomic references. The uplink connection pool submodule maintains an independent asynchronous sending queue for each live TCP plaintext connection. When business data needs to be sent through a live TCP plaintext connection, the submodule uses a non-blocking try_send method to submit the data frame to the corresponding asynchronous sending queue. If the asynchronous sending queue is full, try_send immediately returns an error instead of suspending and waiting. The uplink connection pool submodule then switches to another live TCP plaintext connection in the connection pool to retry. When all live TCP plaintext connections are full, a waiting response is returned to the edge proxy module.

[0051] The Token caching submodule is used to cache the access_token corresponding to each terminal device.

[0052] The central platform module includes a TCP service sub-module, an HTTP service sub-module (Axum), a message dispatch service sub-module (Dispatch Service), a pending response table sub-module (PendingTable), a Kafka access sub-module, and a data warehouse sub-module.

[0053] The TCP server terminal module is used to accept TCP plaintext connections initiated by the transmission relay module and maintain a mapping table (Registry) of the terminal device's UID (device identifier) ​​and its corresponding TCP plaintext connection. The corresponding TCP plaintext connection is the TCP plaintext connection used by the transmission relay module to forward a token request containing the UID to the central platform module.

[0054] The HTTP service terminal module (Axum) provides a synchronous message delivery API, i.e., a RESTful API for business systems (such as App backends) to actively send commands to a terminal device. Axum is a high-performance asynchronous web framework, which is a well-known technology and not an innovation of this invention, so it will not be described in detail here.

[0055] The message dispatch service submodule (Dispatch Service) is used to implement synchronous / asynchronous dual-channel dispatching.

[0056] The PendingTable module is used to maintain the pending response table with a combination of device identifier (UID), client identifier (client_id), and message identifier (msg_id) as the key and oneshot channel (one-time channel) as the value.

[0057] The pending response table supports per-client concurrent quotas and automatic timeout notifications based on Moka expiration callbacks.

[0058] The pending response table supports per-client concurrency quotas, meaning that the pending response table maintains an independent in-transit concurrency counter for each client identifier. When the number of in-transit requests for a certain client identifier exceeds the preset quota, new synchronization requests related to that client identifier are rejected.

[0059] The automatic timeout notification based on Moka expiration callback means that the entries in the pending response table are configured with a timeout expiration policy. When the synchronization request corresponding to an entry (a key-value record) in the pending response table times out without receiving a reply, the pending response table triggers the cache expiration callback corresponding to the entry to automatically send a timeout notification to the synchronization request waiting party corresponding to the entry, and decrements the in-transit concurrency counter corresponding to the client identifier of the entry by 1.

[0060] The Kafka access submodule is used to consume / publish messages to multiple topics, including, for example, normal channels, high-priority channels, and configuration channels. The Kafka access submodule acts as an "asynchronous message bus" between the central platform module and the business system, used for: 1) Asynchronously push the business data reported by the local business plugin to the business system; 2) Receive asynchronous instructions from the business system; 3) Used as a supplementary write-back channel after HTTP synchronization timeout.

[0061] The data warehouse submodule is responsible for storing and providing all non-transient business data, such as device metadata, authentication and security credentials, device configuration and policies, etc. The data warehouse submodule includes a three-layer cache: MySQL (main storage) + Redis (distributed cache) + Moka (local in-process cache). High-performance reading and reliable persistence are achieved through the three-layer cache (Moka→Redis→MySQL). When reading, the query is performed in the order of Moka→Redis→MySQL. When writing, the MySQL is written synchronously and the cache is updated.

[0062] As attached Figure 2As shown, after the edge proxy module is launched, it obtains terminal device information through FFI, including but not limited to MAC address (as UID), firmware version, etc., and constructs a token request based at least on the MAC address, firmware version, timestamp, random number, etc. The specific method for constructing the token request is a known technology and is not an innovation of this invention, so it will not be described in detail here.

[0063] The edge proxy module establishes a TLS encrypted connection with the transmission relay module based on the configured transmission relay module address through a TCP three-way handshake and a TLS handshake. Then, the edge proxy module sends the Token request to the transmission relay module through the TLS encrypted connection.

[0064] After receiving the Token request, the transmission relay module determines that the data frame is a Token request and decides to forward it transparently without local processing. It directly forwards the Token request to the central platform module through the uplink connection pool submodule, that is, it selects a live TCP plaintext connection from the uplink connection pool in a random round-robin manner to forward the Token request to the central platform module.

[0065] After verifying the device identity, the central platform module generates an access_token and transmits it along the original path to the transmission relay module and the edge proxy module. The specific method for generating the access_token is a known technology and not an innovation of this invention, so it will not be described in detail here. The transmission relay module and the edge proxy module respectively store the access_token in their respective local token cache submodules.

[0066] The edge proxy module determines the authentication string based on the access_token and collects snapshots of currently connected local service plugins. The authentication string is determined using the SHA256 hash algorithm based on the access_token, timestamp, and device identifier, specifically according to the formula auth_str = SHA256(timestamp + device identifier + access_token). The edge proxy module constructs a device registration request (InitReq) based on the determined authentication string and the collected snapshots of currently connected local service plugins. The device registration request also includes terminal device information. The specific construction method of the device registration request is known technology and not an innovation of this invention, so it will not be elaborated here. The edge proxy module sends the device registration request to the transmission relay module.

[0067] When the transmission relay module receives the device registration request, it decides to perform local verification. That is, the transmission relay module obtains the access_token corresponding to the terminal device from its local Token cache submodule, calculates the authentication string using the SHA256 hash algorithm and based on the timestamp, device identifier, and access_token, and compares the calculated authentication string with the authentication string in the device registration request to determine whether the two are consistent. If they match, the verification passes. At this point, the transmission relay module forwards the device registration request to the central platform module. If the two are inconsistent, the verification fails. In this case, the transmission relay module directly returns an authentication failure response to the edge proxy module, and the device registration request is intercepted and not forwarded to the central platform module.

[0068] The central platform module receives the device registration request and performs terminal device registration. The specific terminal device registration process is a known technology and is not an innovation of this invention, so it will not be described in detail here.

[0069] After the terminal device registration is completed, the central platform module returns a registration response to the edge proxy module through the transmission relay module. After receiving the registration response, the edge proxy module enters the ready state and can perform bidirectional information transmission with the central platform module.

[0070] Subsequently, the edge proxy module sends a token refresh request according to a predetermined refresh rule. For example, the validity period of the access_token is a set duration. When the edge proxy module obtains the access_token issued by the central platform module, it records the current time and starts counting down from the current time. When the countdown reaches a predetermined duration close to the validity period, for example, if the validity period of the access_token is 3600 seconds, the edge proxy module sends a token refresh request when the countdown reaches 3300 seconds.

[0071] Meanwhile, the edge proxy module and the transmission relay module store the current access_token and the previous access_token, respectively; When the edge proxy module and the transmission relay module receive a new access_token issued by the central platform module, they downgrade the current access_token to the previous access_token and store the new access_token as the current access_token.

[0072] The exponential backoff reconnection device is used to determine whether the current access_token has expired after the edge proxy module and the transmission relay module have been abnormally disconnected, that is, to determine whether the timeout period has reached the time for sending the next token refresh request. If it is determined that the current access_token has not expired, that is, the timeout period has not reached the time for sending the next token refresh request, the edge proxy module remains in a ready state, and after the edge proxy module and the transmission relay module re-establish the TLS encrypted connection, the buffered messages to be sent during the disconnection period are directly replayed. If the current access_token is determined to have expired, i.e., the timeout period reaches the time when the next token refresh request will be sent, the edge proxy module will re-establish a TLS encrypted connection with the transmission relay module and obtain a new access_token. If there are messages in transit encrypted with the old token during the token refresh period, the transmission relay module will first try to decrypt them using the current access_token. If decryption fails, it will fall back to the previous access_token for decryption, achieving a seamless transition.

[0073] After each failed reconnection with the transmission relay module, the waiting time for the next reconnection increases exponentially (e.g., 2 times, 4 times, 8 times) until the reconnection is successful.

[0074] As attached Figure 3 As shown, the edge proxy module performs the following encryption process when sending uplink service data: After receiving the raw business data sent to it by the local business plugin, the local plug-in service submodule of the edge proxy module sends it to the uplink connection management submodule. The uplink connection management submodule triggers a compression judgment, that is, determines whether the number of bytes of the message body to be sent exceeds a preset threshold. The preset threshold can be set as needed, for example, 1024 bytes.

[0075] When the number of bytes in the message body (payload portion) to be sent exceeds a preset threshold, DEFLATE compression is performed, and the original length before compression is marked with a compression field. The specific technology of DEFLATE compression is a known technology and not an innovation of this invention, so it will not be elaborated here. The reason for DEFLATE compression is that it is determined by balancing multiple factors such as compression ratio, speed, and memory usage. This method is fast, has controllable memory overhead, and is standard and universal, which can effectively adapt to the needs of IoT edge computing. When the number of bytes in the message body does not exceed the preset threshold, the data compression of the message body is not performed.

[0076] Then, the edge proxy module performs derived key calculation, AES encryption, and TLV encapsulation, and finally calls the TLS encrypted connection to send it to the transport relay module.

[0077] Specifically, the derived key is calculated using the SHA256 hash algorithm based on the timestamp (time), device identifier (uid), access_token, and client identifier (client_id). That is, the derived key is calculated according to the formula cipher_key=SHA256(time+uid+access_token+client_id). This formula concatenates the above strings and performs an irreversible hash calculation, outputting a fixed-length (256 bits, or 32 bytes) binary value. Finally, cipher_key is a 32-byte binary number.

[0078] Then, the derived key is used to encrypt the compressed or uncompressed message body using AES-256-GCM to generate a data packet containing a random nonce and ciphertext.

[0079] The data packet is encapsulated into a TLV data frame and then sent to the transmission relay module via a TLS encrypted connection.

[0080] The TLV data frame format consists of an 8-byte fixed header (magic number prefix + opcode + payload length) + a variable-length Protobuf payload body. The encoding process has transaction rollback capability: if encoding fails, the buffer is truncated to the beginning position, ensuring that no half-frames remain in the TCP stream.

[0081] The specific TLV data frame format is as follows: Bytes 0-1: Magic number prefix 0xF1E2 (fixed); Bytes 2-3: Opcode (big-endian, e.g., 0x0001=TokenReq, 0x0009=DataUp); Bytes 4-7: Payload length (big-endian); 8 bytes+: Payload (Protobuf-encoded message body).

[0082] Encoding transaction rollback: Before encoding, record dst.len() as the starting position. If Protobuf encoding or length verification fails, execute dst.truncate(start) to roll back, ensuring no half-frame residue remains in the TCP stream. During decoding, if there is insufficient data, return None (not an error). tokioFramedRead automatically waits for more data, naturally supporting TCP packet merging / half-packet handling.

[0083] After receiving the TLV data frame sent to it by the edge proxy module, the transmission relay module performs the following processing: After receiving the TLV data frame, the client access submodule directly hands it over to the frame rewriting submodule.

[0084] The frame rewriting submodule executes a decision state machine. When it determines that the frame is an uplink service data frame, it performs data decryption, injects the device IP address, and re-encodes the data. Specifically: The frame rewriting submodule obtains the current access_token and the previous access_token stored in the local token cache submodule of the transmission relay module; First, calculate the cipher key (derived key) using the current access key and decrypt it. If decryption fails, calculate the cipher key using the previous access key and decrypt it. If decryption fails again, discard the TLV data frame. The specific method for calculating the derived key based on the current and previous access keys is the same as the method for calculating the derived key during encryption, and will not be elaborated here. Decryption involves performing AES-256-GCM decryption using the calculated cipher key.

[0085] If decryption is successful, the plaintext data obtained directly from decryption or the plaintext data obtained from decompressing the decrypted compressed data will replace the ciphertext payload of the original TLV data frame. The real IP address of the terminal device where the edge proxy module is located will be injected into the IP field. After re-encoding the frame, it will be forwarded to the central platform module, that is, after being re-encapsulated according to the TLV data frame format, it will be forwarded to the uplink connection pool sub-module. The uplink connection pool module will then forward the re-encapsulated data frame to the central platform module.

[0086] The TCP service submodule of the central platform module receives the data frame forwarded by the uplink connection pool submodule and hands the data frame over to the message scheduling service submodule. The message scheduling service submodule determines that the data frame is uplink data and routes it to the Kafka access submodule. The Kafka access submodule publishes the data frame to a predetermined topic for consumption by the business system.

[0087] The central platform module achieves the separation of synchronous and asynchronous message scheduling through a pending reply table and Kafka, specifically as follows: When the HTTP service terminal module of the central platform module receives a synchronization request from the HTTP interface, it parses the request parameters, constructs a downlink command frame, and calls the message scheduling service submodule. The message scheduling service submodule calls the pending reply table submodule, which inserts the key composed of the device identifier, client identifier, and message identifier of the synchronization request into the pending reply table, creates a one-shot channel corresponding to the key, and delivers the downlink command frame to the TCP service terminal module. The TCP service terminal module sends the downlink command frame to the transmission relay module, which then sends it to the edge proxy module. The edge proxy module then forwards the synchronization request to the corresponding local business plugin.

[0088] When the TCP server terminal module of the central platform module receives the corresponding reply, it calls the reply-pending table submodule to search for a matching key. If a match is found, that is, if the UID, client_id, and msg_id in the reply are found to be the same in the reply-pending table, then the TCP server terminal module returns the reply to the synchronization request waiting party through the oneshot channel corresponding to the matching key.

[0089] If the request is not received, the TCP server submodule sends the reply to the Kafka access submodule. The Kafka access submodule then asynchronously writes the reply back to the business system. In other words, the reply is encapsulated as a "delayed receipt" message and published to a custom-named Topic by the Kafka access submodule. The business system subscribes to this Topic and receives these messages asynchronously in the background.

[0090] When the central platform module receives a downlink message from Kafka, it does not insert the downlink message into the pending reply table, but directly sends the downlink message to the local business plugin corresponding to the downlink message via the transmission relay module and the edge proxy module.

[0091] The following description uses the communication system of the present invention for remote management of a home gateway device as an example. The deployment topology is as follows: Terminal device: Huawei OptiXstarV173 gateway (ARMv7Linux), deploying an edge proxy module (Rust static link, approximately 1.1MB). The edge proxy module is a monolithic executable file written in Rust, which is compiled with all dependencies packaged into itself, and the final output is approximately 1.1MB.

[0092] The terminal device has three local service plugins, as follows: Network diagnostic plugin, client_id=1001; WiFi optimization plugin, client_id=1002; Device identification plugin; client_id=1003); They communicate with the edge agent module via / var / run / xlink.sock (a socket file).

[0093] Transmission relay module: Deployed on 3 x86 edge servers, each bound to TLS port 19000, maintaining an uplink connection pool containing 4 TCP plaintext connections to the central platform module.

[0094] Central platform module: The Kubernetes 3Pod instance, with MySQL 8.0, Redis 7.0, and Kafka 3.9 as external components, means that the central platform module runs as three Pod instances on the Kubernetes cluster and relies on external MySQL 8.0, Redis 7.0, and Kafka 3.9 as data storage and message middleware.

[0095] Business System: The operator's operation and maintenance system accesses the central platform module through PlatformSDK (Java8). PlatformSDK is compiled in Java and is used to enable business systems to integrate both asynchronous Kafka and synchronous HTTP access methods.

[0096] The entire system works as follows: (1) Token Acquisition: After the edge proxy module starts, it obtains the MAC address of the terminal device (as UID) through FFI, constructs a TokenReq, and sends the TokenReq to the central platform module via the transmission relay module.

[0097] After verification by the central platform module, a TokenResp (containing an access token, valid for 3600 seconds) is returned.

[0098] Both the transmission relay module and the edge proxy module store the access_token in their local token cache submodules. The edge proxy module sets next_refresh_at=now (the time the access_token was received) + 3300s, meaning it sends a token refresh request 300 seconds before the current access_token expires.

[0099] (2) Equipment registration: The edge proxy module calculates the derived key according to the formula auth_str=SHA256(time+uid+access_token), combines the derived key with the terminal device information and the plugin snapshot of the connected local service plugin to construct InitReq and send it to the transmission relay module.

[0100] The relay module performs local authentication verification. That is, the relay module reads the access_token it stores, calculates the SHA256 and compares it with the auth_str in the frame. If the comparison matches, the verification is successful and the data is forwarded to the central platform module to register the terminal device. If the comparison does not match, the verification fails and the relay module directly returns AuthFail to the edge proxy module to prevent illegal requests from entering the central platform module.

[0101] (3) Heartbeat keep-alive: The edge proxy module sends a heartbeat request every 60 seconds. Five seconds before each heartbeat request is sent, it broadcasts probes to three local service plugins, collects the heartbeat responses of each local service plugin and the status information of the terminal devices, and then aggregates them into a single HeartbeatReq for reporting.

[0102] The relay module also performs local authentication and IP injection on heartbeat requests. The central platform module processes and obtains the health status of all four components (1 terminal device + 3 plugins) at once.

[0103] (4) Service message transmission: Synchronization scenario: The business system queries the WiFi channel via HTTP API (timeout=5s).

[0104] The central platform module inserts the synchronization request into the PendingTable (key=uid+client_id+msg_id), and the synchronization request is forwarded to the WiFi optimization plugin of the terminal device via the transmission relay module and the edge proxy module; After processing by the WiFi optimization plugin, a DataDownReply is returned. This DataDownReply is then sent to the central platform module via the edge proxy module and the transmission relay module. Upon receiving the DataDownReply, the central platform module matches the key in the PendingTable, determines the corresponding oneshot channel, and returns an HTTP response through the corresponding oneshot channel.

[0105] If the central platform module does not receive a DataDownReply within the timeout period, the Moka expiration callback will automatically return DeviceTimeout and return the per-client quota.

[0106] Asynchronous scenario: The operator operation and maintenance system issues device configuration instructions (downlink messages) via Kafka. The central platform module consumes the corresponding topic, pulls the device configuration instruction, converts it into an internal identification frame DeviceConfigDown recognizable by the device, and issues it to the edge agent module via the transmission relay module.

[0107] The edge agent module performs hot update of the configuration (protocol.update_config() — without changing the current timer state) and then replies with a configuration processing result, which is forwarded to the central platform module via the transmission relay module, and the central platform module writes back an acknowledgement via Kafka.

[0108] (5) Disconnection reconnection and Token reuse: Assume that a network flicker occurs at 15:30:00, at which time next_refresh_at=15:55:00: The protocol state machine determines that the current access_token is valid; (now=15:30:05<next_refresh_at), and the edge agent module remains in the ready state; After the edge agent module and the transmission relay module are reconnected, the Token request and Init reporting process are skipped, and buffered messages are replayed immediately; TCP+TLS handshake reconnection takes about 200ms, and the total recovery time is <300ms (the conventional solution requires 2-4 seconds).

[0109] If the current access_token has expired, the access_token is reacquired after reconnection, and the expired current access_token (old access_token) is automatically downgraded to prev (previous access_token).

[0110] If there is an in-transit message encrypted with the old access_token during the token refresh period, the transmission relay module falls back to the old access_token for decryption when decryption fails, so as to achieve seamless transition.

[0111] (6) Key derivation and encryption / decryption: Encryption by the edge agent module: If the message body does not reach the 1024-byte threshold, no compression is performed (ziplen=0); Calculate cipher_key=SHA256(time+uid+access_token+client_id); AES-256-GCM encryption: a random 12-byte Nonce, output [Nonce||ciphertext+Tag] and store the same in pack_data; Assemble ClientDataMsg → Encapsulate TLV data frames → Send via TLS Decrypting the transmission relay module: Retrieve the current access_token and the previous access_token from the local token cache submodule (if the current access_token fails, use the previous access_token as a fallback). Calculate cipher_key=SHA256(time+uid+access_token+client_id); AES-256-GCM decryption: Take the Nonce (first 12 bytes) and the ciphertext, and call the decryption function; With ziplen=0, no decompression is required. The plaintext is written back to pack_data, the device's real IP is injected, and the frame is re-encoded before being forwarded to the central platform module.

[0112] The pack_data in the frame received by the central platform module is already in plaintext and does not need to be decrypted.

[0113] This invention has many other embodiments, and all technical solutions formed by equivalent transformation or equivalent transformation fall within the protection scope of this invention.

Claims

1. An Internet of Things (IoT) device communication system, characterized in that: This includes an edge proxy module, a transmission relay module, and a central platform module for sequential communication; The edge proxy module is deployed on the terminal device. When sending uplink service data, the edge proxy module performs the following encryption process: When it is determined that the number of bytes of the message body to be sent exceeds a preset threshold, DEFLATE compression is performed and the original length before compression is marked with a compression field. The derived key is calculated using the SHA256 hash algorithm based on the timestamp, device identifier, access_token, and client identifier. The derived key is used to encrypt the compressed message body using AES-256-GCM to generate a data packet containing a random nonce and ciphertext; The data packet is encapsulated into a TLV data frame and then sent to the transmission relay module via a TLS encrypted connection. The transmission relay module is deployed at the edge network node. When it receives the TLV data frame sent to it by the edge proxy module, it decrypts it. If the decryption fails, it discards the TLV data frame. If the decryption is successful, it rewrites the data frame and forwards the rewritten data frame to the central platform module through the uplink connection pool. The central platform module is deployed in the cloud. During the bidirectional information transmission with the edge agent module, it achieves the separation of synchronous and asynchronous message scheduling through a pending reply table and Kafka.

2. The IoT device communication system according to claim 1, characterized in that: After obtaining terminal device information through FFI, the edge proxy module sends a token request to the transmission relay module through a TLS encrypted connection. After receiving the Token request, the transmission relay module forwards the Token request to the central platform module through the uplink connection pool; After verifying the device identity, the central platform module generates an access_token and transmits it along the original path to the transmission relay module and the edge proxy module. The transmission relay module and the edge proxy module store the access_token respectively. The edge proxy module sends a device registration request to the transmission relay module, the device registration request containing an authentication string determined based on the access_token stored therein; The transmission relay module performs local verification on the authentication string in the registration request based on its stored access_token. If the verification passes, the registration request is forwarded to the central platform module. If the verification fails, an authentication failure response is returned directly to the edge proxy module. After completing device registration, the central platform module returns a registration response to the edge agent module. Upon receiving the registration response, the edge agent module enters a ready state and can perform bidirectional information transmission with the central platform module.

3. The IoT device communication system according to claim 2, characterized in that: The authentication string is determined using the SHA256 hash algorithm based on the access_token, timestamp, and device identifier.

4. The IoT device communication system according to claim 1, characterized in that: The edge proxy module and the transmission relay module store the current access_token and the previous access_token, respectively; When the edge proxy module and the transmission relay module receive a new access_token issued by the central platform module, they downgrade the current access_token to the previous access_token and store the new access_token as the current access_token.

5. The IoT device communication system according to claim 1, characterized in that: The edge proxy module includes a hibernation manager, which controls the edge proxy module to actively disconnect from the TLS connection with the transmission relay module and enter a hibernation state when there is no plugin activity within a preset time period, and wakes up and reconnects through dual-channel events, namely plugin activity events and heartbeat timing events.

6. The IoT device communication system according to claim 1, characterized in that: Before sending a heartbeat request to the transmission relay module in each heartbeat cycle, the edge proxy module first broadcasts a heartbeat probe request to all connected local service plugins and collects the heartbeat responses returned by each local service plugin. Then, it aggregates the collected heartbeat responses and the status information of the terminal devices into a heartbeat request and sends it to the transmission relay module.

7. The IoT device communication system according to claim 1, characterized in that: After the edge proxy module loses connection with the transmission relay module, it determines whether the current access_token has expired. If it is determined that the current access_token has not expired, the edge proxy module remains in a ready state, and after the edge proxy module and the transmission relay module re-establish the TLS encrypted connection, the buffered messages to be sent during the disconnection period are directly replayed. If the current access_token is determined to be expired, the edge proxy module will obtain a new access_token after re-establishing a TLS encrypted connection with the transmission relay module.

8. The IoT device communication system according to claim 1, characterized in that: After receiving the TLV data frame sent to it by the edge proxy module, the transmission relay module performs the following processing: Retrieve the current access_token and the previous access_token stored in the database; First, calculate the cipher_key using the current access_token and decrypt it. If decryption fails, calculate the cipher_key using the previous access_token and decrypt it. If decryption fails, discard the TLV data frame. If decryption is successful, the decrypted data is decompressed to obtain plaintext to replace the ciphertext payload of the original TLV data frame, and the real IP address of the terminal device where the edge proxy module is located is injected into the IP field. The frame is then re-encoded and forwarded to the central platform module.

9. The IoT device communication system according to claim 1, characterized in that: The transmission relay module selects a TCP plaintext connection from the uplink connection pool using a random starting point polling method to send uplink data.

10. The IoT device communication system according to claim 1, characterized in that: The specific steps for separating the scheduling of synchronous and asynchronous messages using a pending reply table and Kafka are as follows: When a synchronization request is received from an HTTP interface, the central platform module inserts the synchronization request into the pending response table based on a key composed of a device identifier, a client identifier, and a message identifier, creates a oneshot channel corresponding to the key, and sends the synchronization request to the corresponding local business plugin through the transmission relay module and the edge proxy module. When the central platform module receives the corresponding reply, it searches for a matching key in the reply table. If a match is found, the reply is returned to the synchronization request waiting party through the oneshot channel corresponding to the matching key. If the match fails, the response will be asynchronously written back to the business system via Kafka; When a downlink message is received from Kafka, the central platform module does not insert the downlink message into the pending reply table, but directly sends the downlink message to the local business plugin corresponding to the downlink message via the transmission relay module and the edge proxy module.

11. The IoT device communication system according to any one of claims 1-10, characterized in that: The pending response table maintains an independent in-transit concurrent counter for each client identifier. When the number of in-transit requests for a certain client identifier exceeds a preset quota, new synchronization requests related to that client identifier are rejected. The entries in the pending response table are configured with a timeout expiration policy. When a synchronization request corresponding to an entry times out without receiving a response, the pending response table triggers the cache expiration callback corresponding to the entry to automatically send a timeout notification to the synchronization request waiting party corresponding to the entry, and decrements the in-transit concurrency counter corresponding to the client identifier of the entry by 1.

Images