Multi-network server parallel communication method for LoRa gateway and LoRa gateway

Abstract

The embodiment of the invention provides a multi-network server parallel communication method for a LoRa gateway and the LoRa gateway. The method comprises the following steps: the LoRa gateway configures and manages a hardware receiving thread, a plurality of reporting threads, a plurality of downlink receiving threads, a downlink sending thread and a beacon thread by using a main thread; the hardware receiving thread receives an uplink data packet from a sensor communicating with the LoRa gateway, and stores the uplink data packet in a cache region of the LoRa gateway; a plurality of reporting threads respectively correspond to different network servers, and each reporting thread responds to the storage of the uplink data packet, acquires the uplink data packet from the cache region in parallel, and forwards the uplink data packet to the respective corresponding network server through an independent network connection; a plurality of downlink receiving threads submit the received downlink data packets to a unified delay sending queue; and the downlink sending thread sequentially takes out the expired downlink data packets needing to be sent from the delay sending queue and sends the downlink data packets to the sensors specified by the downlink data packets.

Description

Technical Field

[0001] This application relates to the field of network communication technology, specifically to a method for parallel communication between multiple network servers for a LoRa gateway and a LoRa gateway. Background Technology

[0002] In related technologies, the LoRa gateway in the entire LoRaWAN network only plays a transparent transmission role. Data from sensors is acquired and demodulated by the LoRa chip, and then uploaded via the local network. The transmission methods include, but are not limited to, the two mainstream protocols: User Datagram Protocol (UDP) and WebSocket, a network protocol for full-duplex communication over a single Transmission Control Protocol (TCP) connection. This extends to bridging, where data is packetized and transmitted to the Network Server (NS) via Message Queuing Telemetry Transport (MQTT) at a single layer. This implicitly limits the ability of an NS to connect to multiple gateways, but a gateway can only connect to one NS. This severely restricts deployment and use in certain scenarios. Users wishing to transmit data to multiple NSs in an environment need to deploy multiple gateways, significantly increasing deployment costs. Therefore, how to enable data interaction between a single gateway and multiple NSs has become a pressing technical problem to be solved. Summary of the Invention

[0003] The purpose of this application is to provide a method for parallel communication between multiple network servers for a LoRa gateway and a LoRa gateway, the specific technical solution of which is as follows: In a first aspect, a method for parallel communication between multiple network servers for a LoRa gateway is provided, the method comprising: The LoRa gateway uses a main thread to configure and manage one hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, one downlink transmitting thread, and one beacon thread; The hardware receiving thread receives uplink data packets from sensors communicating with the LoRa gateway and stores them in the buffer area of ​​the LoRa gateway. The multiple reporting threads correspond to different network servers. In response to the storage of the uplink data packet, each reporting thread retrieves the uplink data packet from the cache area in parallel and forwards it to its corresponding network server through an independent network connection. The hardware receiving thread waits for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet. Multiple downlink receiving threads maintain connections with different network servers, listen for and receive downlink data packets from their respective network servers, and submit the received downlink data packets to a unified delayed transmission queue. The downlink transmission thread retrieves the downlink data packets that are due for transmission from the delayed transmission queue in sequence and sends them to the sensor specified by the downlink data packet; When the LoRa gateway is operating in Class B mode, the beacon thread periodically generates time synchronization beacons and broadcasts them to the sensors.

[0004] Secondly, a LoRa gateway is provided, the gateway comprising: The main thread of the LoRa gateway is used to configure and manage a hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, a downlink transmitting thread, and a beacon thread; The hardware receiving thread receives uplink data packets from sensors communicating with the LoRa gateway and stores them in the buffer area of ​​the LoRa gateway. The multiple reporting threads correspond to different network servers. Each reporting thread is used to retrieve the uplink data packet from the cache area in parallel in response to the storage of the uplink data packet, and forward it to its corresponding network server through an independent network connection. The hardware receiving thread is used to wait for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet. Multiple downlink receiving threads are used to maintain connections with different network servers, listen for and receive downlink data packets from their respective network servers, and submit the received downlink data packets to a unified delayed transmission queue. The downlink transmission thread is used to retrieve the downlink data packets that are due for transmission from the delayed transmission queue in sequence, and send them to the sensor specified by the downlink data packet; When the LoRa gateway is operating in Class B mode, the beacon thread is used to periodically generate time synchronization beacons and broadcast them to the sensors.

[0005] This application has the following beneficial effects: This is for situations where different nodes need to be deployed in the same location to access different NSs (e.g., the service provider offers solutions and sensors, such as deploying multiple sensors for multiple stores, and then using the same gateway for pass-through, with each store choosing a different NS based on its desired solution).

[0006] This is useful in scenarios where the same node needs to be simultaneously added to multiple network nodes (NSs) using Activation By Personalization (ABP). Examples include service providers offering sensor and platform services to customers but needing to retain their own data records, or the same sensor being available to different customers to simultaneously acquire information about public resources such as parking spaces and outdoor temperature and humidity. ABP is one of the two main methods for node addition in the LoRaWAN protocol. It's a statically configured method that allows devices to have their network parameters pre-configured before leaving the factory or deployment, eliminating the need for over-the-air activation.

[0007] This can reduce the number of gateways deployed, greatly reducing the hardware deployment costs in the two scenarios mentioned above. Attached Figure Description

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

[0009] Figure 1 A schematic diagram of network communication provided for an embodiment of this application; Figure 2 A system architecture diagram provided for an embodiment of this application; Figure 3 A schematic diagram of the architecture of a multi-packet forwarding module provided in an embodiment of this application; Figure 4 An uplink flowchart of a message in a multi-NS implementation scenario provided in this application embodiment; Figure 5 A downlink flowchart of a message in a multi-NS implementation scenario is provided for embodiments of this application; Figure 6 This is a flowchart illustrating a method for a LoRa gateway to simultaneously connect to multiple network servers, as provided in an embodiment of this application. Detailed Implementation

[0010] To further illustrate the technical means and effects adopted by this application to achieve the intended purpose of the invention, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a method for a LoRa gateway to simultaneously connect to multiple network servers according to this application. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined from any suitable form.

[0011] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0012] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0014] Figure 1 This is a schematic diagram of network communication provided in an embodiment of this application, such as... Figure 1 As shown in the diagram, the schematic diagram includes end nodes 11, a gateway 12, and a network server 13, wherein, End Nodes 11 include at least one of the following sensors: pet tracking sensor, smoke alarm sensor, water meter, trash container sensor, vending machine, and gas monitoring sensor.

[0015] Gateway 12 communicates with End Nodes 11.

[0016] Network Server 13 can communicate with multiple Gateways 12, but each Gateway 12 can only communicate with one Network Server 13. If users want to transfer data from End Nodes 11 to multiple NSs 13 in their environment, they need to deploy multiple Gateways 12, significantly increasing deployment costs. How to enable data interaction between a single gateway and multiple NSs has become a pressing technical problem to be solved.

[0017] Figure 2 A system architecture diagram is provided for an embodiment of this application, such as Figure 2 As shown, the system architecture diagram includes: terminal nodes 11 (node ​​1, node 2, node 3), gateway 12, and network servers 13 (other NS, remote chirpstack NS, remote NS), where, Gateway 12 internally includes a multi-packet forwarding module, a chirpstack bridge, and a lora bridge, allowing simultaneous UDP connections to multiple different destinations. "ChirpStack bridge" refers to ChirpStack Gateway Bridge, which is used for protocol conversion between the gateway and the network server. As a bridge between the gateway and the ChirpStack Network Server, it receives raw LoRa packets from the gateway, standardizes them, and forwards them to the network server for processing.

[0018] A LoRa bridge, or LoRa gateway bridge, is used for protocol conversion and data relay between a LoRa gateway and a network server. It receives raw data packets (typically transmitted via UDP) from the LoRa gateway, unpacks these packets, converts them into a format (such as MQTT messages) that the network server (e.g., Chirpstack) can understand, and then forwards them to the network server. Conversely, a LoRa bridge can forward commands from the network server to the gateway.

[0019] For example, the multi-packet forwarding module can directly connect to other third-party NS such as TTN and Tencent NS; it can also convert packets into MQTT and connect to the third-party open-source Chirpstack NS through the built-in Chirpstack bridge; or it can connect to the local built-in NS and other gateways of the same brand (remote NS) through Lora bridge to form a network.

[0020] Figure 3 This application provides an embodiment of a multi-packet forwarding module architecture diagram, as shown below. Figure 3 As shown, aside from the open-source parts, we have self-developed and implemented multiple signal processing flows (pink background) with four threads configured in the main thread (main) 30 (purple background). The four threads with different functions are: hardware receiving thread (thread_lgw_receive) 31, reporting thread (thread_report) 32, downlink receiving thread (thread_receive) 33, beacon thread (thread_beacon) 34, and downlink transmitting thread (thread_jit) 35. Hardware receiving thread 31 is responsible for retrieving messages from the hardware (RF front end) and adding them to the internal buffer 36 for sending to multiple servers.

[0021] Reporting thread 32 is responsible for retrieving messages from the internal buffer and passing them to a single NS. Multiple threads 32 are created to achieve the effect of passing messages to different NSs at the same time.

[0022] Downlink receiving thread 33: Each thread 33 is responsible for retrieving downlink messages from one NS. Multiple threads 33 are created to connect to multiple NSs and are queued in a unified queue. Subsequent downlink messages to the sensor are retrieved from this queue and sent by downlink sending thread 35.

[0023] Beacon thread 34 is responsible for creating beacon messages (required in class B scenario).

[0024] The main thread (main) version 30 was revised, primarily adding the following three functionalities: 1. Parsing of multiple NS destination parameters.

[0025] 2. Statistical breakdowns for multiple NS destinations are performed separately.

[0026] 3. Multi-NS destination connection judgment and reconnection execution.

[0027] The main thread (main) 30 adds threads for parsing and creating multiple packets. During implementation, a for loop can be used to trigger the connection status of multiple packets, message delivery status, and reconnection threads.

[0028] like Figure 3 As shown, a cache area (server_cache) 36 is also set in the gateway to store the acquired packets.

[0029] like Figure 3As shown, 37 other threads are also configured in the gateway: thread-gps, thread-valid, thread-sync, and thread_spectral_scan. thread-gps is responsible for acquiring and processing Global Positioning System (GPS) data. In many wireless communication and IoT gateway systems, GPS data is crucial for determining a device's geographic location. For example, in location-based services (LBS), a gateway needs to know its own location information to provide accurate location-related services to connected end devices.

[0030] Thread-valid focuses on validating received data. In wireless communication, data may be affected by interference, noise, and other factors during transmission, leading to errors or corruption. Thread-valid verifies received data packets using methods such as checksums and cyclic redundancy check (CRC) to determine whether the data is complete and correct.

[0031] Thread-sync is responsible for coordinating the synchronized work of various threads and components within a system. In a complex system, different threads may be responsible for different tasks, such as data reception, processing, and transmission. Thread-sync ensures that these threads can work together in a certain order and rhythm, avoiding problems such as data races and deadlocks.

[0032] The primary function of `thread_spectral_scan` is to scan and analyze the wireless spectrum. In wireless communication environments, spectrum resources are limited and various interference sources may exist. `thread_spectral_scan` can monitor spectrum usage in real time and detect the presence of interference signals, illegal signals, or other anomalies.

[0033] The LoRa gateway universal bus (lora_gateway_u bus) 39 acts as a communication bus for data transmission between different components or modules within the LoRa gateway. Similar to the system bus in a computer system, it is responsible for the efficient and reliable transmission of data between various functional units. For example, data received from the LoRa wireless interface is transmitted through this bus to subsequent processing modules, or processed data is sent to the corresponding output interface via the bus.

[0034] lora / spaghet and lora / local_conf (file #38) contain configuration files.

[0035] Figure 4 The uplink flowchart of a message in a multi-NS implementation scenario provided in this application embodiment is as follows: Figure 4 As shown, the hardware receiving thread 31 and the reporting thread 32 can be used to upload the messages obtained from the sensor to multiple NSs. This can be achieved through the following steps: Step 1: Initialization is performed, with the main thread responsible for initializing the hardware and various threads.

[0036] Step 2: The message retrieving thread, thread_lgw_receive, is responsible for retrieving messages from the hardware queue.

[0037] Step 3: The hardware receiving thread is responsible for serializing the message into JSON.

[0038] Step 4: Submit the message to the buffer and trigger the sending announcement.

[0039] Step 5: This notification will be asynchronously triggered to all reporting threads via a signal.

[0040] Step Six: All reporting threads will execute the following respectively: 1. Obtain new messages.

[0041] 2. Determine whether to add statistical messages.

[0042] 3. Whether you append a statistical message or not, you need to send it to the corresponding NS.

[0043] 4. Obtain the result of the transmission (ACK response).

[0044] 5. If the result is obtained within the timeout period or if it is not obtained after the timeout period, set the corresponding result to the buffer corresponding to NS in the buffer and trigger a signal.

[0045] Step 7: The hardware receiving thread blocks and waits for all NS operations to finish executing. The waiting method is to synchronously wait for the results of all NS operations in the buffer and for signal triggers.

[0046] Step 8: Print a prompt based on the waiting result and proceed to the next round of uplink message transmission.

[0047] Figure 5 A downlink flowchart of a message in a multi-NS implementation scenario is provided for embodiments of this application, as follows: Figure 5 As shown, multiple downlink receiving threads 33 and downlink sending threads 35 are used to send messages from multiple NSs to the sensor, which is achieved through the following steps: Step 1: Initialization is performed, with the main thread responsible for initializing the hardware and various threads.

[0048] Step 2: Each individual downlink receiving thread can first perform keep-alive processing and send a keep-alive message.

[0049] Step 3: Then the downlink receiving thread can begin receiving server responses and downlink messages from the sensors.

[0050] Step 4: If a downlink occurs within the next message interval, proceed; otherwise, return to Step 2 and resend the keep-alive message.

[0051] Step 5: Mark the link as normal and begin processing packets.

[0052] Step 6: If the message is a keep-alive response, return to step 3 to continue receiving server responses and downlink messages from the sensor.

[0053] Step 7: Deserialize the normal downlink message, parse it from JSON into a structure, and submit it to the downlink sending thread. Then return to Step 3 to continue receiving responses.

[0054] Step 8: Another downlink sending thread is responsible for submitting the messages that are due to be sent in the queue to the hardware queue for transmission.

[0055] In this embodiment, the logic of the radio frequency processing hardware is stripped away and processed separately. Each NS destination is abstracted as a server. The software supports connecting to multiple servers at the same time, processing radio frequency messages and sending them to multiple NSs simultaneously to obtain responses and simultaneously obtain downlink data from multiple NSs, and performing message statistics and connection maintenance.

[0056] The beneficial effects are as follows: This is for situations where different nodes need to be deployed in the same location to access different NSs (e.g., the service provider offers solutions and sensors, such as deploying multiple sensors for multiple stores, and then using the same gateway for pass-through, with each store choosing a different NS based on its desired solution).

[0057] This is useful in scenarios where the same node needs to be simultaneously added to multiple network nodes (NSs) using Activation By Personalization (ABP). Examples include service providers offering sensor and platform services to customers but needing to retain their own data records, or the same sensor being available to different customers to simultaneously acquire information about public resources such as parking spaces and outdoor temperature and humidity. ABP is one of the two main methods for node addition in the LoRaWAN protocol. It's a statically configured method that allows devices to have their network parameters pre-configured before leaving the factory or deployment, eliminating the need for over-the-air activation.

[0058] This can reduce the number of gateways deployed, greatly reducing the hardware deployment costs in the two scenarios mentioned above.

[0059] This application provides a method for parallel communication between multiple network servers for a LoRa gateway, wherein the LoRa gateway utilizes, as shown in the example... Figure 3 The main thread 30 shown is configured with a hardware receive thread 31, multiple reporting threads 32, multiple downlink receive threads 33, a downlink transmit thread 35, and a beacon thread 34, as follows. Figure 6 As shown, this parallel communication method can be implemented through the following steps: Step S600: The LoRa gateway uses the main thread to configure and manage one hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, one downlink transmitting thread, and one beacon thread; Here, as Figure 3 As shown, the main thread 30 configures and manages a hardware receiving thread 31, multiple reporting threads 32, multiple downlink receiving threads 33, a downlink sending thread 35, and a beacon thread 34.

[0060] Step S610: The hardware receiving thread receives uplink data packets from the sensor communicating with the LoRa gateway and stores them in the buffer area of ​​the LoRa gateway. Here, the sensor communicating with the LoRa gateway can be, for example, Figure 1 The End Nodes 11 shown include at least one of the following sensors: pet tracking sensor, smoke alarm sensor, water meter, trash container sensor, vending machine, and gas monitoring sensor.

[0061] like Figure 3 The hardware receiving thread 31 shown acts as the main receiving thread of the gateway, responsible for capturing uplink data packets (such as environmental data and status information reported by the sensors) from the sensor cluster and adding them to the LoRa gateway's buffer area, i.e. Figure 3 The cache area shown is (server_cache) 36.

[0062] The LoRa RF module receives wireless signals, performs signal demodulation, frame parsing, verification, and other operations, and extracts valid data packets.

[0063] During implementation, the hardware receiving thread 31 writes the parsed data packets into the buffer area in order (usually using a thread-safe queue structure, such as a circular buffer or a blocking queue) to avoid data loss or overwriting.

[0064] Step S620: The multiple downlink receiving threads maintain connections with different network servers, listen for and receive downlink data packets from their respective network servers, and submit the received downlink data packets to a unified delayed transmission queue. Here, each downlink receiving thread maintains a connection with a different target network server (such as NS1, NS2, NS3) and listens for and receives downlink data packets from its respective network server in real time.

[0065] Here, each thread_receive thread corresponds to a network server, which is responsible for receiving downlink data packets (such as control commands and firmware updates) from the server and scheduling the LoRa radio module to send them to the target sensor.

[0066] Step S630: The hardware receiving thread waits for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet; During implementation, the hardware receiving thread can receive the response message obtained by the uplink thread to confirm that all the uplink threads have completed the forwarding of the uplink data packets and are processing the next uplink data packet.

[0067] Step S640: The multiple downlink receiving threads maintain connections with different network servers, listen to and receive downlink data packets from their respective network servers, and submit the received downlink data packets to a unified delayed transmission queue. During implementation, the downlink receiving thread continuously listens for downlink messages pushed by the server (such as through long polling, WebSocket, or MQTT subscription) and submits the received downlink data packets to a unified delayed sending queue.

[0068] In some embodiments, LoRa's time slot scheduling algorithm (such as Class A receive window or Class C continuous listening) can be used to transmit downlink data through the radio frequency module within a specified time window.

[0069] Step S650: The downlink transmission thread retrieves the downlink data packets that are due for transmission from the delayed transmission queue in sequence and sends them to the sensor specified by the downlink data packet; During implementation, multiple downlink transmission threads can sequentially retrieve the downlink data packets due for transmission from the delayed transmission queue and send them to the sensor specified by the downlink data packet, enabling a single gateway to receive instructions from multiple servers. Independent threads handle downlink logic, decoupling it from uplink reception, ensuring real-time bidirectional communication.

[0070] Step S660: When the LoRa gateway is operating in Class B mode, the beacon thread periodically generates time synchronization beacons and broadcasts them to the sensors.

[0071] When the LoRa gateway is operating in Class B mode, a beacon thread periodically broadcasts Beacon messages containing time synchronization information for clock synchronization between the sensor and the gateway. The Beacon messages contain precise timestamps (such as GPS time or the gateway's local clock) and are sent via LoRa broadcast.

[0072] After receiving the Beacon, the sensor adjusts its own clock according to the time information in the message (such as through phase locking or time compensation algorithms) to ensure that it is aligned with the time slot of the gateway.

[0073] Class B mode relies on strict time synchronization to achieve time slot scheduling (such as Ping Slot communication), and Beacon messages are the basis for synchronization.

[0074] Regular transmissions can compensate for clock drift and ensure long-term communication reliability.

[0075] In this embodiment, the LoRa gateway utilizes a main thread configured with one hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, one downlink transmitting thread, and one beacon thread. The uplink is implemented as follows: sensor → gateway → buffer storage area → multiple servers. The downlink is: multiple servers → gateway → sensor. The synchronization link is: gateway → sensor, supporting high-precision time slot scheduling in Class B mode. Through thread division of labor, the entire process of "receiving-buffering-reporting-downlinking-synchronization" is decoupled, allowing a single gateway to interact with multiple servers simultaneously. Furthermore, it enables dynamic scaling of servers or sensor clusters. Through multi-threaded parallel processing and buffering mechanisms, the data transmission efficiency, synchronization accuracy, and system stability issues of LoRa gateways in multi-server scenarios are effectively solved, meeting the requirements of the LoRaWAN protocol for large-scale IoT deployments.

[0076] In some embodiments, step S610 above, "the hardware receiving thread receives uplink data packets from the sensor communicating with the LoRa gateway and stores them in the buffer area of ​​the LoRa gateway," can be implemented through the following steps: Step 611: The hardware receiving thread obtains the uplink data packet from the radio frequency front-end of the LoRa gateway; During implementation, the hardware receiving thread receives raw LoRa data packets (containing metadata such as binary payload, signal strength RSSI, signal-to-noise ratio SNR, etc.) from the radio frequency front end, and extracts the payload through a protocol parser (such as LoRaWAN frame parser).

[0077] Step 612: Serialize the messages in the uplink data packet into JSON format messages; During implementation, the parsed uplink data packets can be converted into JSON format. JSON format has cross-platform compatibility and is easy for different network servers (such as Alibaba Cloud IoT and AWS IoT) to parse directly.

[0078] In some embodiments, the serialization process may insert a data checksum (such as CRC32) to ensure reliable transmission.

[0079] Step 613: The main thread marks the JSON format message based on the message content to obtain a marked message. The mark includes at least a data information identifier and an additional information identifier. Here, the main thread can set the message to be marked based on its content. If it is determined to be a body message, it can be marked as a data information identifier; if it is determined to be an appendix message, it can be marked as an attachment information identifier.

[0080] After marking the message, the lgw receive thread can determine whether there are normal messages or statistical messages being reported based on the flag, and trigger the acquisition of uplink messages based on the reports.

[0081] Step 614: The hardware receiving thread adds the completed message to the buffer area of ​​the LoRa gateway; During implementation, the hardware receiving thread adds the completed message to the... Figure 3 The cache area shown is 35.

[0082] Step 615: Send a notification signal, wherein the notification signal is used to asynchronously trigger all the thread_report threads.

[0083] Here, notification signals can be implemented through event notification mechanisms (such as Linux's eventfd or condition variables) to avoid the overhead of frequent polling between threads.

[0084] Each reporting thread listens for the notification signal via epoll or select. Once triggered, it retrieves the corresponding tagged data packet from the cache queue and reports it. The notification signal supports multicast mode, which can wake up multiple reporting threads simultaneously (such as threads corresponding to different servers) to achieve parallel reporting.

[0085] Asynchronous triggering allows the reporting thread to process data when idle, reducing CPU idling.

[0086] In this embodiment, serialization and tokenization are completed in the receiving thread, avoiding redundant processing in the reporting thread and reducing CPU overhead. A buffer queue acts as a data buffer, enabling parallel execution of RF receiving and reporting operations. The uplink sequence is: sensor → RF front-end → hardware receiving thread → buffer queue → reporting thread → network server. The notification signal acts as a "soft interrupt," enabling lightweight collaboration between the receiving and reporting threads. Through a pipeline of data preprocessing, tokenization, buffering, and asynchronous triggering, the uplink data processing efficiency of the LoRa gateway is effectively improved, while ensuring system reliability and scalability.

[0087] In some embodiments, step S620 above, "the plurality of reporting threads correspond to different network servers, and each reporting thread, in response to the storage of the uplink data packet, retrieves the uplink data packet from the cache area in parallel and forwards it to its corresponding network server through an independent network connection," can be implemented through the following steps: Step 621: In response to receiving the notification signal, each of the reporting threads retrieves the completion marker message from the cache area; During implementation, the reporting thread listens for notification signals (such as the eventfd event) via epoll / select. The notification signal is triggered when the hardware receiving thread completes data serialization and writes it to the buffer queue.

[0088] The asynchronous triggering mechanism activates the reporting thread only when the data is ready, reducing CPU utilization.

[0089] Step 622: If the message identifier of the completion mark is determined to be a data information identifier, the message with the data information identifier is taken as the target data packet; During implementation, the thread_report thread parses the identifier field of the message. If a data information identifier exists, it is directly used as the body of the target data packet, i.e., the main message.

[0090] Step 623: If the message identifier of the completion mark is determined to be an additional information identifier, add the message with the additional information identifier to the target data packet; During implementation, the reporting thread checks whether there are any normal or statistical packets being reported; if so, it triggers an uplink. The reporting thread determines whether it can handle this uplink. While processing, it identifies and appends any statistical information to the attached message. The appended statistical message can be added to the end of the normal message, forming a single message.

[0091] Step 624: Each reporting thread will forward the information to its corresponding network server via an independent network connection.

[0092] During implementation, each reporting thread is bound to a specific network server (such as NS1, NS2), and a long connection is established through TCP / IP or MQTT protocols.

[0093] In some embodiments, the message is encapsulated using a protocol (such as JSON format for LoRaWAN or Protobuf binary format) before transmission, and a checksum (such as CRC32) is added to ensure integrity.

[0094] After transmission, wait for the server's ACK response; if a timeout occurs, trigger a retransmission mechanism.

[0095] In this embodiment, the uplink data reporting efficiency of the LoRa gateway is effectively improved by using an asynchronous trigger-marking and filtering-dynamic reassembly-directed transmission pipeline, while ensuring the system's reliability, scalability, and data security.

[0096] In some embodiments, the above step S630, "the hardware receiving thread waits for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet," can be implemented through the following steps: Step 631: Each of the reporting threads sends the response information obtained from the corresponding network server to the hardware receiving thread; During implementation, each reporting thread can continuously monitor the server's response channel after completing data transmission to the corresponding network server. Once a response is received from the server, whether it is a successful acknowledgment signal (such as an ACK packet) or a timeout message indicating no response received, the `thread_report` thread will encapsulate this response information into a message of a specific format and then send it to the `thread_lgw_receive` thread. For example, a message queue can be used to place the response information into a dedicated queue for communication between the two threads.

[0097] Step 632: The hardware receiving thread determines that it has received response information sent by all the reporting threads; The response information includes successful response information obtained by the network server within a preset time, or timeout no response information if no response information is received within the preset time.

[0098] During implementation, the hardware receiving thread records and compiles statistics after receiving response information from the reporting thread. A counter or status table is maintained to track the server response status for each reporting thread. When all response information from all reporting threads has been collected (whether successful or timed out), the hardware receiving thread can confirm that it has completed the feedback collection for this round of data reporting.

[0099] This ensures that the system has a comprehensive understanding of each batch of reported data. Only when the responses from all servers are clear can the overall result of this round of data reporting be accurately determined, avoiding the problem of unclear data status due to missing responses from some servers.

[0100] In some embodiments, if a server frequently times out without responding, the server can be flagged and corresponding fault-tolerant measures can be taken, such as switching to a backup server, thereby improving fault tolerance and maintainability.

[0101] Step 633: The hardware receiving thread proceeds to the next round of uplink data packet transmission.

[0102] After confirming receipt of all response messages, the hardware receiving thread can process them accordingly. If most or all servers return successful responses, the thread can proceed to the next round of acquiring uplink data packets from the RF front-end and initiating a new reporting process. If there are many servers that have timed out and failed to respond, the thread can adjust retransmission parameters or mark abnormal servers according to preset strategies before proceeding to the next round of data transmission.

[0103] This ensures the periodic and orderly execution of the data reporting process. Through response-based process control, the system can continuously and stably process upstream data, while dynamically adjusting its workflow based on actual network conditions and server response, thus improving the system's adaptability and stability.

[0104] In this embodiment, by collecting and confirming response information, the system can promptly detect problems during data transmission, such as network interruptions and server failures. For data that fails to respond within a timeout period, retransmission and other measures can be taken to ensure that the data is eventually successfully delivered to the server, greatly improving the reliability of data reporting. This mechanism ensures the synchronization of work between the hardware receiving thread and multiple reporting threads. Only after all responses to data reports in the current round have been processed will the next round of operation be initiated, avoiding confusion and conflicts between data from different rounds and making the entire system's workflow more orderly and efficient. The response information contains rich network and server status information. By analyzing this information, potential fault points can be identified in a timely manner and addressed accordingly.

[0105] In some embodiments, step S640 above, "the plurality of downlink receiving threads submit the received downlink data packets to a unified delayed transmission queue," can be achieved through the following steps: Step 641: Each downlink receiving thread deserializes the JSON-formatted downlink data packets into structured data; During implementation, multiple downlink receiving threads receive JSON-formatted downlink commands (such as control commands and firmware updates) from multiple network servers, and parse them into predefined structures using a JSON parsing library (such as cJSON or jsoncpp).

[0106] In some embodiments, data integrity can be verified during the parsing process (such as checking whether JSON fields are complete and whether the numerical range is valid). If the process fails, error handling is triggered (such as discarding the data and logging it).

[0107] Step 642: Submit the structure data to a unified delayed transmission queue; Here, the delayed sending queue (jit_queue) adopts a thread-safe priority queue, which is sorted by "priority + timestamp" to ensure that high-priority data is dequeued first.

[0108] During implementation, the structure data can be submitted to the jit_queue for sorting.

[0109] In this embodiment, the downlink data transmission efficiency of the LoRa gateway is effectively improved through deserialization and queue buffering processes, while ensuring the system's reliability, scalability, and protocol compatibility.

[0110] In some embodiments, step S640, "the plurality of downlink receiving threads maintain connections with different network servers respectively, and listen for and receive downlink data packets from their respective corresponding network servers," can be achieved through the following steps: Step 643: Each downlink receiving thread will send a keep-alive message to the corresponding network server and sensor; Here, the downlink receive thread periodically generates bidirectional keep-alive messages (e.g., every 30 seconds) and sends them to both the target network server and the target sensor. The keep-alive message contains a lightweight identifier and a current timestamp for subsequent response matching.

[0111] In some embodiments, the sending strategy employs adaptive interval adjustment: if an acknowledgment is received N times consecutively, the sending interval is extended (e.g., from 30 seconds to 60 seconds) to reduce redundant traffic; if no acknowledgment is received, the interval is shortened (e.g., reduced to 10 seconds) and a retry is triggered.

[0112] In this way, bidirectional probes can simultaneously verify the bidirectional reachability of the gateway-server link and the gateway-sensor link, avoiding misjudgments from unidirectional probes (such as the server being reachable but the sensor being unreachable).

[0113] The adaptive interval optimizes network resource utilization while ensuring real-time link health monitoring.

[0114] Step 644: Upon receiving a successful response message from the network server and the sensor, mark the link as normal to trigger the processing of the downlink data packet.

[0115] During implementation, when the downlink receiving thread receives responses from the network server and the sensor, it marks the corresponding link as "normal" and updates the link quality indicators (such as RSSI and SNR).

[0116] Link state flags are stored in a global link state table, which can be monitored in real time by the thread_jit thread. Only when the target sensor link state is "normal" will thread_jit retrieve the corresponding downlink data packet from the jit_queue for radio frequency scheduling.

[0117] In this way, precise triggering can avoid invalid transmissions when the link is abnormal, reducing the waste of radio frequency resources (such as avoiding sending commands to offline sensors).

[0118] Link quality awareness provides decision-making basis for downlink scheduling (such as prioritizing the use of high RSSI links to transmit high-priority instructions), thereby improving the transmission success rate.

[0119] In this embodiment, the downlink reliability of the LoRa gateway is effectively improved by using a pipeline of keep-alive detection-link verification-triggered transmission, while optimizing network resource utilization and system scalability.

[0120] This application provides a LoRa gateway, such as... Figure 3 As shown, the LoRa gateway includes: The main thread of the LoRa gateway is used to configure and manage a hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, a downlink transmitting thread, and a beacon thread; The hardware receiving thread receives uplink data packets from sensors communicating with the LoRa gateway and stores them in the buffer area of ​​the LoRa gateway. The multiple reporting threads correspond to different network servers. Each reporting thread is used to retrieve the uplink data packet from the cache area in parallel in response to the storage of the uplink data packet, and forward it to its corresponding network server through an independent network connection. The hardware receiving thread is used to wait for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet. Multiple downlink receiving threads are used to maintain connections with different network servers, listen for and receive downlink data packets from their respective network servers, and submit the received downlink data packets to a unified delayed transmission queue. The downlink transmission thread is used to retrieve the downlink data packets that are due for transmission from the delayed transmission queue in sequence, and send them to the sensor specified by the downlink data packet; When the LoRa gateway is operating in Class B mode, the beacon thread is used to periodically generate time synchronization beacons and broadcast them to the sensors.

[0121] In this embodiment, the LoRa gateway utilizes a main thread configured with one hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, one downlink transmitting thread, and one beacon thread. The uplink is implemented as follows: sensor → gateway → buffer storage area → multiple servers. The downlink is: multiple servers → gateway → sensor. The synchronization link is: gateway → sensor, supporting high-precision time slot scheduling in Class B mode. Through thread division of labor, the entire process of "receiving-buffering-reporting-downlinking-synchronization" is decoupled, allowing a single gateway to interact with multiple servers simultaneously. Furthermore, it enables dynamic scaling of servers or sensor clusters. Through multi-threaded parallel processing and buffering mechanisms, the data transmission efficiency, synchronization accuracy, and system stability issues of LoRa gateways in multi-server scenarios are effectively solved, meeting the requirements of the LoRaWAN protocol for large-scale IoT deployments.

[0122] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multiple task processing and parallel processing are possible or may be advantageous. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. The above content is only a specific implementation of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application.

Claims

1. A method for parallel communication between multiple network servers for a LoRa gateway, characterized in that, The method includes: The LoRa gateway uses a main thread to configure and manage one hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, one downlink transmitting thread, and one beacon thread; The hardware receiving thread receives uplink data packets from sensors communicating with the LoRa gateway and stores them in the buffer area of ​​the LoRa gateway. The multiple reporting threads correspond to different network servers. In response to the storage of the uplink data packet, each reporting thread retrieves the uplink data packet from the cache area in parallel and forwards it to its corresponding network server through an independent network connection. The hardware receiving thread waits for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet. Multiple downlink receiving threads maintain connections with different network servers, listen for and receive downlink data packets from their respective network servers, and submit the received downlink data packets to a unified delayed transmission queue. The downlink transmission thread retrieves the downlink data packets that are due for transmission from the delayed transmission queue in sequence and sends them to the sensor specified by the downlink data packet; When the LoRa gateway is operating in Class B mode, the beacon thread periodically generates time synchronization beacons and broadcasts them to the sensors.

2. The method as described in claim 1, characterized in that, The hardware receiving thread receives uplink data packets from sensors communicating with the LoRa gateway and stores them in the LoRa gateway's buffer area, including: The hardware receiving thread obtains the uplink data packet from the radio frequency front end of the LoRa gateway; The messages in the uplink data packets are serialized into JSON format messages; The main thread marks the JSON-formatted message based on the message content to obtain a marked message. The mark includes at least a data information identifier and an additional information identifier. The hardware receiving thread adds the completed and marked message to the buffer area of ​​the LoRa gateway; Send a notification signal, wherein the notification signal is used to asynchronously trigger all the reporting threads.

3. The method as described in claim 2, characterized in that, The plurality of reporting threads correspond to different network servers. Each reporting thread, in response to the storage of the uplink data packet, retrieves the uplink data packet from the cache area in parallel and forwards it to its corresponding network server through an independent network connection, including: In response to receiving the notification signal, each of the reporting threads retrieves the completion marker message from the cache area; If the message identifier of the completion mark is determined to be a data information identifier, the message with the data information identifier is taken as the target data packet; If the message identifier of the completion mark is determined to be an additional information identifier, the message with the additional information identifier is added to the target data packet; Each of the reporting threads forwards the information to its corresponding network server via an independent network connection.

4. The method as described in claim 3, characterized in that, The hardware receiving thread waits for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet, including: Each of the reporting threads sends the response information obtained from the corresponding network server to the hardware receiving thread; The hardware receiving thread determines that it has received response information sent by all the reporting threads; The hardware receive thread processes the next uplink data packet.

5. The method as described in claim 4, characterized in that, The response information includes successful response information obtained by the network server within a preset time, or timeout no response information if no response information is received within the preset time.

6. The method as described in claim 1, characterized in that, The plurality of downlink receiving threads submit the received downlink data packets to a unified delayed transmission queue, including: Each downlink receiving thread deserializes the JSON-formatted downlink data packets into structured data; The structure data is submitted to a unified delayed transmission queue.

7. The method as described in claim 1, characterized in that, The plurality of downlink receiving threads maintain connections with different network servers, listen for and receive downlink data packets from their respective network servers, including: Each downlink receiving thread will send a keep-alive message to the corresponding network server and sensor; Upon receiving a successful response message from the network server and the sensor, the link is marked as normal to trigger the processing of the downlink data packet.

8. A LoRa gateway, characterized in that, The LoRa gateway includes: The main thread of the LoRa gateway is used to configure and manage a hardware receiving thread, multiple reporting threads, multiple downlink receiving threads, a downlink transmitting thread, and a beacon thread; The hardware receiving thread receives uplink data packets from sensors communicating with the LoRa gateway and stores them in the buffer area of ​​the LoRa gateway. The multiple reporting threads correspond to different network servers. Each reporting thread is used to retrieve the uplink data packet from the cache area in parallel in response to the storage of the uplink data packet, and forward it to its corresponding network server through an independent network connection. The hardware receiving thread is used to wait for all reporting threads to complete the forwarding operation of the current uplink data packet before processing the next uplink data packet. Multiple downlink receiving threads are used to maintain connections with different network servers, listen for and receive downlink data packets from their respective network servers, and submit the received downlink data packets to a unified delayed transmission queue. The downlink transmission thread is used to retrieve the downlink data packets that are due for transmission from the delayed transmission queue in sequence, and send them to the sensor specified by the downlink data packet; When the LoRa gateway is operating in Class B mode, the beacon thread is used to periodically generate time synchronization beacons and broadcast them to the sensors.

Images