An emergency data network construction method based on LoRa and Beidou cooperation

CN122909545APending Publication Date: 2026-10-13LANZHOU JIAOTONG UNIV +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611051483.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-15
Publication Date
2026-10-13

AI Technical Summary

Technical Problem

在应急救援与灾害演进的动态过程中,现场网络往往需要根据灾情等级实时改变监测节奏,而缺乏可靠的反向控制链路与执行反馈机制,导致指挥中心面对突发状况只能被动接收数据,完全丧失了对前端感知网络的动态调度与主动干预能力

Benefits of technology

[0027]1.突破公网束缚,构建极具韧性的全天候跨域应急通信干线

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122909545A_ABST
    Figure CN122909545A_ABST
Patent Text Reader

Abstract

The application discloses an emergency data network construction method based on LoRa and Beidou cooperation, relates to the wireless sensor network and emergency communication technical field, and aims at the technical problems that public network coverage is insufficient in remote mountainous areas or disaster sites, and it is difficult to consider low-power dense deployment of the front end and reliable remote backhaul. The application proposes that local area self-organizing networks are constructed by ordinary monitoring nodes and gateway gathering nodes on the site. The ordinary nodes collect sensor data and gather the sensor data to the gateway through LoRa link single hop or multi hop; the gateway is provided with an operating system, data is packaged after being scheduled according to priority, and then the data is transmitted back to the remote monitoring center through the Beidou short message link. Meanwhile, the monitoring center can reversely issue control instructions through the Beidou and LoRa links, the nodes execute and feedback. The application realizes reliable gathering transmission of multi-source monitoring data and dynamic bidirectional scheduling of the on-site nodes in the environment without public network, and greatly improves the connectivity and survival ability of the emergency monitoring network.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of wireless sensor networks and emergency communication technology, specifically to a method for constructing an emergency data network based on LoRa and BeiDou collaboration. Background Technology

[0002] In complex physical environments such as mountain slopes, geological disaster-prone areas, remote forest areas, tunnel entrances, and emergency disaster relief sites, environmental monitoring and safety early warning are crucial. These areas typically face extreme communication challenges: First, there is a lack of terrestrial cellular network coverage, or the existing public network infrastructure is extremely fragile, making it highly susceptible to base station damage or fiber optic cable interruptions leading to large-scale communication paralysis in the event of earthquakes, mudslides, or extreme weather disasters; second, there is often a lack of stable mains power supply on-site, and monitoring equipment is highly dependent on limited battery power; third, the terrain is rugged, vegetation is dense, and electromagnetic signal attenuation and physical obstruction are extremely severe.

[0003] Against this backdrop, there is an urgent need to reliably transmit front-end monitoring sensor data, device status information, and emergency control commands even when completely disconnected from stable ground-based communication infrastructure. However, existing wireless communication networks and IoT transmission solutions all face insurmountable technical bottlenecks when dealing with these extreme scenarios:

[0004] First, traditional monitoring systems based on cellular mobile networks are highly dependent on ground base stations and operator core networks. In remote areas or at the initial stage of emergency rescue, communication blind spots prevent front-end sensing data from being transmitted at all, rendering the system ineffective at critical moments and failing to meet the core requirements of emergency monitoring for "absolute independence" and "high reliability" of communication channels.

[0005] Secondly, in recent years, low-power wide-area network (LPWAN) technologies such as LoRa have been widely introduced into the Internet of Things (IoT) field. While LoRa technology solves the problems of low-power access for front-end sensors and local wireless networking, it is essentially still a local or metropolitan area communication technology. It must rely on gateways with public network or broadband access capabilities to transmit data back to the cloud. When encountering large-scale geological disasters or being in areas with absolutely no public network, LoRa technology alone cannot establish remote backbone backhaul links across provinces, cities, or regions, and the on-site network becomes an "information island" unable to make outward calls.

[0006] Secondly, satellite communication offers global coverage without the limitations of terrestrial public networks. However, most existing BeiDou monitoring solutions adopt a direct connection mode of "one device, one SIM card," meaning that an expensive BeiDou communication module is mounted on each front-end sensor node. This crude architecture not only leads to a surge in node hardware costs and bulky size, but more critically, the satellite launch module consumes a huge amount of power instantly, significantly shortening the battery life of field monitoring nodes. Furthermore, the frequent concurrent access of a massive number of nodes to the limited satellite short message channel easily causes channel congestion and communication conflicts, resulting in extremely low utilization of communication resources.

[0007] Finally, most existing geological disaster monitoring networks are designed as open-loop architectures with "one-way data reporting." The systems severely lack support for downlink control requirements such as dynamic configuration of remote parameters, emergency adjustment of sampling frequency, and in-depth querying of node status. During the dynamic process of emergency rescue and disaster evolution, the field network often needs to change its monitoring pace in real time according to the disaster level. However, the lack of reliable reverse control links and execution feedback mechanisms means that the command center can only passively receive data in the face of emergencies, completely losing its ability to dynamically schedule and proactively intervene in the front-end sensing network. Summary of the Invention

[0008] The purpose of this invention is to provide a method for constructing an emergency data network based on LoRa and BeiDou collaboration to solve the above-mentioned problems.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a method for constructing an emergency data network based on LoRa and BeiDou collaboration, comprising the following steps:

[0010] S1. Deploy multiple ordinary monitoring nodes within the target monitoring area and deploy at least one gateway aggregation node, with the ordinary monitoring nodes and the gateway aggregation node forming a local sensor network on site;

[0011] S2. The ordinary monitoring node samples the connected sensors according to a preset sampling strategy, obtains on-site monitoring data, and generates node data messages. The node data messages include at least node identifier, sampling time, monitoring data value, and status information.

[0012] S3. Ordinary monitoring nodes transmit node data packets to the gateway aggregation node via the LoRa wireless communication link in a single-hop or multi-hop manner;

[0013] S4. The gateway aggregation node receives node data packets from multiple ordinary monitoring nodes, and performs caching, filtering, classification and packaging of the node data packets according to node source, data type and priority.

[0014] S5. The gateway aggregation node generates BeiDou backhaul messages according to the preset reporting strategy, and sends the processed monitoring data to the remote monitoring center through the BeiDou short message link to establish a cross-regional wireless communication network in an environment without a public network.

[0015] S6. The remote monitoring center generates a control command message based on the received monitoring data and sends the control command message to the gateway aggregation node through the Beidou short message link.

[0016] S7. The gateway aggregation node parses the control command message and sends the command to the target ordinary monitoring node through the LoRa link; after the target ordinary monitoring node performs the corresponding operation, it generates an execution feedback message and reports it to the remote monitoring center through the gateway aggregation node, forming a closed-loop control.

[0017] Furthermore, in steps S1 and S2, the sensor interface unit of the ordinary monitoring node is used to connect to sensors of displacement, tilt angle, temperature and humidity, pressure, water level or vibration type; after acquiring the raw monitoring data, the ordinary monitoring node performs data format sorting, time stamping, node identity binding and preliminary filtering of outliers, and generates node data packets suitable for transmission in the local sensor network.

[0018] Further, in step S3, the single-hop or multi-hop method refers to: after the ordinary monitoring node is powered on and initialized, it identifies nearby reachable nodes and builds a self-organizing network with dynamic routing based on the LoRa protocol; for ordinary monitoring nodes with direct connection conditions, the data is sent to the gateway aggregation node in a single-hop manner; for nodes without direct connection conditions, the node data packets are sent to the nearby relay nodes in the self-organizing network for tiered forwarding.

[0019] Furthermore, during the hop-by-hop forwarding process, if a hop in the self-organizing network fails to be transmitted, a retransmission is performed. If the retransmission fails after a preset number of attempts, the node data packet is written into the local cache of the ordinary monitoring node and sent again after the LoRa wireless communication link is restored.

[0020] Furthermore, in steps S4 and S5, the core processing unit of the gateway aggregation node has a built-in sensor network operating system; the sensor network operating system schedules the received node data packets, and data that exceeds the threshold, undergoes a sudden change, or has an alarm mark is included in the high-priority sending queue as alarm data, while periodic and routine monitoring data is included in the periodic cache queue as ordinary data.

[0021] Furthermore, in step S5, when the gateway aggregation node sends data via BeiDou short messages: for alarm data in the high-priority sending queue, BeiDou backhaul messages are generated first and immediate reporting is triggered; for ordinary data in the periodic cache queue, data is periodically summarized, packaged and reported according to a preset time window, message length limit or data number threshold.

[0022] Furthermore, in step S6, the control command message includes the target node identifier, control type, execution parameters, and issuance time; the control type includes adjusting the sampling frequency of the sensor, configuring parameters, querying status, supplementing data, switching working modes, or waking up from sleep.

[0023] Furthermore, in step S7, after receiving the control command message, the gateway aggregation node parses the target node identifier in it and determines whether the control command is a broadcast control or a directional control. For target ordinary monitoring nodes that are currently unreachable, the gateway aggregation node writes the corresponding control command into the queue to be sent and resends it after the target node restores connectivity.

[0024] Furthermore, in step S7, the execution feedback message includes the target node identifier, execution result, execution time, and abnormal status information; when the control task is executed successfully, it is used to confirm that the remote instruction has been implemented; when the task fails, it is used to record the reason for the failure or the current node status, thereby ensuring the reliability of the bidirectional scheduling of the entire wireless communication network.

[0025] Furthermore, when the gateway aggregation node detects that the BeiDou short message communication link is temporarily unavailable, it saves the return message to be reported and the execution feedback information in the storage and log unit on the gateway side; after the BeiDou link of the wireless communication network is restored, it continues to send according to the priority order, realizing fault-tolerant processing of multi-node interruption resume transmission in emergency scenarios.

[0026] Compared with existing technologies, the emergency data network construction method based on LoRa and BeiDou collaboration provided by this invention has the following beneficial effects:

[0027] 1. Break free from the constraints of the public network and build a highly resilient, all-weather, cross-domain emergency communication backbone.

[0028] By deeply integrating BeiDou short message technology with local sensor networks, a satellite backhaul link completely independent of terrestrial public communication infrastructure has been established between the gateway aggregation node and the remote monitoring center. Even in extreme network outage environments such as the complete destruction of on-site 4G / 5G base stations and power outages caused by major geological disasters, the system can still rely on satellite channels to deliver the most critical disaster precursor warning data to the command center, fundamentally eliminating the "communication blind spots" in remote and dangerous areas and opening up an absolutely reliable life information channel for emergency disaster relief.

[0029] 2. Balancing large-scale, high-density, low-cost deployment with full network coverage in complex terrain.

[0030] This invention employs a layered deployment strategy based on node roles. The massive number of ordinary monitoring nodes at the front end are stripped of their high-power, high-cost satellite communication modules, using only low-power LoRa radio frequency technology for data access. This significantly reduces node cost and size, greatly extending battery life in the field and meeting the needs of "massive deployment and close-range sensing" in emergency scenarios. Simultaneously, through a multi-hop self-organizing network built on the LoRa underlying protocol, ordinary nodes can act as relay routers, relaying data from neighboring nodes. This perfectly overcomes line-of-sight obstacles such as mountain valleys and tunnels, exponentially increasing the coverage depth and access rate of the wireless communication network in complex three-dimensional spaces.

[0031] 3. Overcome satellite bandwidth bottlenecks and achieve efficient channel resource scheduling based on QoS.

[0032] Existing technologies often transmit data indiscriminately, overwhelming satellite channels. This invention introduces a sensor network operating system-level priority scheduling mechanism into the gateway aggregation node. The gateway is no longer a simple physical layer repeater, but an intelligent hub with edge computing capabilities. By automatically identifying aggregated data, the system ensures that "high-priority alarm data," such as sudden emergencies, receives immediate transmission privileges; simultaneously, low-frequency routine data is compressed and merged into high-density binary data according to time windows or protocol payload limits before being sent on a timed basis. This mechanism ensures zero delay in alarm responses while increasing the effective data carrying capacity of the BeiDou satellite short message channel several times, significantly saving expensive satellite communication frequencies.

[0033] 4. Forming a two-way closed-loop dispatch network, giving the system excellent emergency dynamic response capabilities.

[0034] This invention breaks away from the rigid, one-way, blind reporting model of traditional IoT, innovatively establishing a complete control channel: "cloud-based distribution—gateway temporary storage and distribution—terminal execution—result feedback." The command center can issue intervention commands such as sampling frequency increase and sleep / wake-up to front-end physical devices at any time based on the evolving disaster situation; and through a strict execution result confirmation mechanism, it completely eliminates the "state blind spot" in remote control. This enables the field sensor network to function like a nervous system, achieving a combination of peacetime and wartime operations and flexibly changing monitoring rhythms, greatly enhancing the system's intelligence and schedulability.

[0035] 5. Provides multi-level non-volatile fault-tolerant protection to ensure zero data loss under extreme operating conditions.

[0036] To address the common signal fading and temporary interference in the wireless radio frequency space, this invention constructs a breakpoint resumption mechanism on both the LoRa link side of ordinary nodes and the BeiDou link side of gateway nodes, employing "failure retransmission + local Flash suspension and dumping + link reconstruction followed by retransmission". When the external backbone network is disrupted due to severe weather, the field sensing network can rely on a large-capacity buffer to internally store and retain data, automatically releasing and retransmitting it once the channel is restored. This deep disaster recovery mechanism endows the entire system with extremely strong self-healing and resilience, ensuring the temporal continuity and spatial integrity of critical historical monitoring data. Attached Figure Description

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

[0038] Figure 1 This is a diagram of the overall system architecture of the present invention;

[0039] Figure 2 This is a schematic diagram of the method flow of the present invention;

[0040] Figure 3 This is a schematic diagram of the emergency data network of the present invention;

[0041] Figure 4 This is a block diagram of a typical monitoring node structure of the present invention;

[0042] Figure 5 This is a block diagram of the gateway aggregation node structure of the present invention;

[0043] Figure 6 This is a schematic diagram of LoRa multi-hop aggregation and BeiDou backhaul of the present invention;

[0044] Figure 7 This is a schematic diagram of the remote command issuance and feedback closed loop of the present invention. Detailed Implementation

[0045] To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings.

[0046] Please see Figure 1-7 A method for constructing an emergency data network based on LoRa and BeiDou collaboration includes the following steps:

[0047] S1. Deploy multiple ordinary monitoring nodes within the target monitoring area and deploy at least one gateway aggregation node, with the ordinary monitoring nodes and the gateway aggregation node forming a local sensor network on site;

[0048] S2. Ordinary monitoring nodes sample the connected sensors according to a preset sampling strategy, acquire on-site monitoring data, and generate node data messages. The node data messages include at least the node identifier, sampling time, monitoring data value, and status information.

[0049] S3. Ordinary monitoring nodes transmit node data packets to the gateway aggregation node via the LoRa wireless communication link in a single-hop or multi-hop manner;

[0050] S4. The gateway aggregation node receives node data packets from multiple ordinary monitoring nodes and performs caching, filtering, classification and packaging of node data packets according to node source, data type and priority.

[0051] S5. The gateway aggregation node generates BeiDou backhaul messages according to the preset reporting strategy, and sends the processed monitoring data to the remote monitoring center through the BeiDou short message link to establish a cross-regional wireless communication network in an environment without a public network.

[0052] S6. The remote monitoring center generates control command messages based on the received monitoring data and sends the control command messages to the gateway aggregation node through the Beidou short message link.

[0053] S7. The gateway aggregation node parses the control command message and sends the command to the target ordinary monitoring node through the LoRa link. After the target ordinary monitoring node performs the corresponding operation, it generates an execution feedback message and reports it to the remote monitoring center through the gateway aggregation node, forming a closed-loop control.

[0054] In practical implementation, 10 to 200 ordinary monitoring nodes and 1 to 5 gateway aggregation nodes are deployed, depending on the monitoring area, terrain conditions, and risk level. Ordinary monitoring nodes acquire physical quantity data according to a preset sampling period and encapsulate it into message format. The gateway aggregation node acts as a field hub, establishing a bridge between the on-site LoRa local area network and the remote BeiDou communication link. After receiving and analyzing the data, the remote monitoring center generates command packets and sends them along the reverse path from BeiDou to the gateway and from the gateway to the ordinary nodes. The ordinary nodes execute the commands and then send back result messages.

[0055] The overall architecture of this method is logically divided into a front-end perception layer, a field aggregation layer, a remote transmission layer, and an application control layer. Its working mechanism aims to achieve seamless integration and bidirectional data flow between heterogeneous communication networks. The front-end utilizes LoRa modulation spread spectrum technology and low-power characteristics to solve the problem of low-level data inflow from a large number of dispersed nodes in complex terrain. The core gateway acts as a protocol converter, transforming high-frequency, fragmented LAN data streams into low-frequency, high-density data streams suitable for satellite channels. Simultaneously, the system introduces a handshake mechanism for reverse command issuance and terminal response confirmation, transforming a simple data acquisition network into a bidirectional "acquisition-control" system with feedback adjustment capabilities.

[0056] This enables the system to establish independent communication links across regions even in harsh environments where it does not rely on terrestrial cellular networks, fiber optic lines, or external power supplies, ensuring the reliability of two-way communication between emergency disaster site data uploads and command center instructions.

[0057] In steps S1 and S2, the sensor interface unit of the ordinary monitoring node is used to connect to sensors of displacement, tilt angle, temperature and humidity, pressure, water level or vibration type; after acquiring the raw monitoring data, the ordinary monitoring node performs data formatting, time stamping, node identity binding and preliminary filtering of outliers, and generates node data packets suitable for transmission in the local sensor network.

[0058] In practical implementation, the sensor interface unit of a typical monitoring node connects to various physical state sensing devices using an analog-to-digital converter or a standard digital bus. After the main control processing unit reads the raw signal, it adds a precise sampling timestamp using its internal RTC clock, binds the node's unique physical MAC address as an identifier, removes invalid mutation values ​​that exceed physical limits, and encapsulates it into a standardized message containing a header, payload, and CRC checksum.

[0059] This section serves as the core entry point for digitizing the entire physical world and connecting it to the network. Its working principle involves normalizing multi-source, heterogeneous analog / digital sensor signals. Time stamps assign absolute time coordinates to the data, while identification tags provide clear spatial and object coordinates. Anomaly filtering algorithms perform primary calculations at the edge, directly intercepting invalid transition data caused by electromagnetic interference or poor contact by calculating the first derivative of the original waveform or setting static upper and lower limits, preventing it from entering the communication queue.

[0060] It unifies the underlying data format of different monitoring devices, reducing the parsing pressure on gateways and remote servers; through preliminary filtering at the edge, it significantly reduces the invalid and junk data from occupying limited wireless radio frequency bandwidth.

[0061] In step S3, single-hop or multi-hop mode refers to: after power-on initialization, ordinary monitoring nodes identify nearby reachable nodes and build a self-organizing network with dynamic routing based on the LoRa protocol; for ordinary monitoring nodes with direct connection conditions, single-hop mode is used to send data to the gateway aggregation node; for nodes without direct connection conditions, node data packets are sent to nearby relay nodes in the self-organizing network for tiered forwarding.

[0062] In practice, each ordinary monitoring node sends a broadcast handshake packet after powering on and establishes a neighbor node topology table based on received signal strength indicators. Nodes determine whether they have the conditions for direct connection based on a free-space path loss model.

[0063]

[0064] In the formula, Distance Loss at the point; For reference distance Loss at the point; This refers to the environmental path loss index. The distance between the sending and receiving nodes; For reference distance. When the calculated link margin is sufficient, a direct connection is established and data is sent in a single-hop manner; when a direct connection cannot be established due to mountains or buildings blocking the connection, the microprocessor selects the nearest node with the fewest hops to the gateway and the best link quality from the topology table, and sets it as the next-hop MAC address for data relay.

[0065] Its working mechanism relies on a distributed dynamic routing algorithm. Each ordinary monitoring node in the network has a dual identity: it is both a terminal that generates its own data and a relay router that forwards data from others. When a physical barrier cuts off direct line-of-sight communication between a node and the gateway, the node automatically queries its local routing table, encapsulates the data packet, and directs it to an intermediate node within line of sight. The intermediate node parses the packet header, finds that the destination address is the gateway, and then continues to forward the packet transparently to the next level up, and so on, forming a tree-like or mesh-like topology.

[0066] It effectively overcomes the problem of radio frequency signal blockage dead zones in complex terrains such as mountainous areas, forest areas, or slopes, and significantly expands the coverage area and node access depth of the underlying sensing network without increasing the cost of additional base station hardware.

[0067] During hop-by-hop forwarding, if a hop in the self-organizing network fails to transmit, a retransmission is performed. If the retransmission fails after a preset number of attempts, the node data packet is written into the local buffer of the ordinary monitoring node and sent again after the LoRa wireless communication link is restored.

[0068] In practice, after sending a message, the sending node starts an internal watchdog timer to wait for an acknowledgment frame from the receiver. If no acknowledgment frame is received within the timeout period, the current hop is considered a failure, triggering a backoff algorithm and retrying within a preset range of 1 to 5 times. If the maximum number of retransmissions is reached, the main control microprocessor writes the data packet and time sequence into the built-in non-volatile flash memory via the SPI bus. The buffer period can be set from 5 minutes to 24 hours. After the link communication is detected to be restored in the next cycle, the buffer is read according to the FIFO principle and transmission resumes.

[0069] An automatic retransmission request state machine with acknowledgment is established in the underlying communication protocol stack, combined with a hardware-level power-off non-volatile storage mechanism. When the radio frequency space encounters sudden broadband noise interference or a temporary power outage of a nearby relay node, a hard interruption occurs in the communication link. The system stops meaningless continuous transmission to avoid power depletion and instead redirects the data pointer to local solid-state memory for timing suspension. Once the underlying heartbeat packet detects successful link reconstruction, the storage controller is awakened and the suspended data is re-injected into the transmission buffer.

[0070] It avoids the permanent loss of critical monitoring data caused by short-term communication interruptions due to environmental interference, wildlife obstruction, or extreme weather, and endows the underlying sensor network with strong fault tolerance and self-healing resilience.

[0071] In steps S4 and S5, the core processing unit of the gateway aggregation node has a built-in sensor network operating system. The sensor network operating system schedules the received node data packets, and data that exceeds the threshold, undergoes a sudden change, or has an alarm mark is included in the high-priority sending queue as alarm data, while periodic and routine monitoring data is included in the periodic cache queue as ordinary data.

[0072] In practical implementation, the gateway aggregation node runs an embedded sensor network operating system with preemptive scheduling, and allocates an independent doubly linked list in RAM as a buffer queue. After receiving a front-end message, the communication interrupt service routine triggers a traffic splitting task. By comparing the local threshold matrix, it identifies messages containing indicators such as sudden shifts in displacement and pushes their memory pointers into the "high-priority transmission queue"; data pointers within the normal fluctuation range are pushed into the "periodic buffer queue".

[0073] Its core lies in the deployment of a multi-task concurrent scheduling mechanism based on quality of service classification within the gateway. Traditional gateways typically employ a single-threaded serial processing method, while this mechanism utilizes the operating system's task scheduler to logically isolate service flows. When high-risk alarm data arrives, the operating system immediately suspends or interrupts low-priority background tasks processing ordinary data, forcibly transferring control of CPU computation cycles and communication peripheral buses to the alarm processing task. This ensures that data flows related to emergency events can obtain "queue-free" physical layer access privileges within the gateway.

[0074] It breaks through the channel congestion bottleneck inside the gateway when massive concurrent data access occurs, ensuring that the most critical life and property alarm signals can break through the encirclement of conventional data and achieve millisecond-level ultra-fast burst upload in critical moments such as the precursor to landslides.

[0075] In step S5, when the gateway aggregation node sends data via BeiDou short message: for alarm data in the high-priority sending queue, BeiDou backhaul messages are generated first and immediate reporting is triggered; for ordinary data in the periodic cache queue, data is periodically summarized, packaged and reported according to a preset time window, message length limit or data number threshold.

[0076] In practical implementation, the gateway's BeiDou communication module driver layer sets two concurrency strategies. As soon as the "high-priority transmission queue" is detected to be non-empty, a single transmission interface is immediately invoked to request a channel from the satellite terminal. For the "periodic buffer queue," the system sets an aggregation time window of 5 to 30 minutes, or monitors whether the total length of the current backlog of data is approaching the limit of bytes for a single BeiDou communication. When either condition is triggered, the processor strips redundant LoRa communication headers from multiple regular data packets belonging to the same time period, extracts only the payload, performs binary concatenation and reassembly, and encapsulates it into a high-payload BeiDou short message for transmission.

[0077] The BeiDou satellite short message system addresses bandwidth mismatch issues between different network architectures by reconfiguring the protocol payload. It has strict limitations on the number of bytes per transmission and a lock-in period for transmission intervals. Forwarding data every time a node's data is received would not only rapidly deplete the satellite channel but also waste significant protocol overhead. This mechanism constructs an intelligent packet pool within the gateway. Urgent data is directly transmitted to trigger hardware transmission; while regular data is continuously added as fragments to a preset-sized data frame template until it is full or a timeout occurs, triggering a physical layer transmission only then. This allows multiple small packets to be aggregated into a single large packet.

[0078] Under the premise of absolutely ensuring zero-delay reporting of alarm data, the effective payload utilization rate of BeiDou satellite channels has been increased several times, significantly reducing the consumption of expensive satellite communication frequency resources and the overall transmission power consumption of gateways.

[0079] In step S6, the control command message includes the target node identifier, control type, execution parameters, and issuance time; the control type includes adjusting the sensor sampling frequency, configuring parameters, querying status, supplementing data, switching working modes, or waking up from sleep.

[0080] In practice, the software platform of the remote monitoring center translates management intentions into specific hexadecimal command streams. The message header contains the specific node's MAC address or a network-wide broadcast address; the control type byte maps to predetermined actions, for example: command code 0x01 represents adjusting the sampling frequency, 0x02 represents querying battery level, and 0x05 represents a sleep / wake-up command. These commands are transparently transmitted from the BeiDou central station to the on-site gateway devices via satellite downlink.

[0081] The command message is equivalent to a remote procedure call protocol. It establishes a standard syntax between the cloud platform and the physical hardware in the field. The message carries the target address, action command code, and specific constraint variables. When the command is transmitted to the terminal device, the terminal microcontroller's command parser decodes it and modifies specific hardware configuration registers or operates specific general-purpose input / output ports to cut off or connect the power supply to the sensor based on the decoding result.

[0082] This completely changes the rigid situation where traditional monitoring networks can only passively report data according to a fixed pattern after deployment, enabling the system to have the remote control capability to dynamically adjust the work rhythm according to changes in the disaster situation and deeply intervene in the operation status of on-site equipment.

[0083] In step S7, after receiving the control command message, the gateway aggregation node parses the target node identifier and determines whether the control command is a broadcast control or a directional control. For target ordinary monitoring nodes that are currently unreachable, the gateway aggregation node writes the corresponding control command into the queue to be sent and resends it after the target node restores connectivity.

[0084] In practice, the gateway extracts the target address segment from the BeiDou-transmitted message. If it is a flooding broadcast address, the gateway controls the LoRa module to broadcast it to the entire network at maximum power. If it is a unicast target ID, the gateway queries the internally maintained node online activity table. If the target ordinary monitoring node is in a dormant period or temporarily disconnected due to interference, the gateway does not discard the instruction but instead stores it in the instruction buffer in memory. Once it receives a data packet or a timed heartbeat packet actively reported by the node and confirms that its radio frequency reception window is open, the gateway immediately delivers the buffered instruction to the node within a very short wake-up period.

[0085] In this process, the gateway aggregation node acts as an asynchronous communication proxy server. Downlink commands from the BeiDou satellites can arrive at any time, but to operate with extremely low power consumption, the front-end LoRa nodes are in deep sleep mode 99% of the time, with their radio frequency receivers disabled. The gateway identifies and intercepts these downlink commands, suspending their status. Utilizing the physical characteristic that edge nodes briefly open their receiving windows after each data transmission, the gateway precisely captures the timing of data transmissions, achieving timeline synchronization between the long-connection communication network and the intermittent duty cycle communication network.

[0086] It perfectly solves the timing conflict between the long-term sleep of low-power front-end nodes and the random issuance of control commands by the center, ensuring a 100% delivery rate of remote control commands and avoiding the problems of command loss or nodes being forced to increase power consumption while waiting for commands.

[0087] In step S7, the execution feedback message includes the target node identifier, execution result, execution time, and abnormal status information; when the control task is executed successfully, it is used to confirm that the remote command has been implemented; when the task fails, it is used to record the reason for the failure or the current node status, thereby ensuring the reliability of the bidirectional scheduling of the entire wireless communication network.

[0088] In practice, after receiving and attempting to execute the control commands distributed by the gateway, the main control microprocessor of the target ordinary monitoring node checks the internal hardware execution flag. Based on the check result, it generates a return message with a status code. This message is then returned to the gateway using the existing LoRa uplink, and the gateway pushes it back to the scheduling interface of the remote monitoring center via the BeiDou link.

[0089] A status response and anomaly capture and verification mechanism has been introduced into the network control logic. Traditional remote control is often open-loop, meaning that after the central server issues a command, it cannot know whether the physical entity of the field device has actually changed. By requiring nodes to send back the actual execution result code after performing hardware-level register operations, the system logically closes the control loop. After receiving this feedback stream, the central server verifies and compares it with the expected status in the system database to confirm whether the control command has been effectively terminated.

[0090] It eliminates blind spots in the remote scheduling process, enabling the command center to accurately grasp the specific implementation status of each front-end operation; in the face of execution obstruction, it can directly locate the cause of the on-site fault based on the feedback error code, which greatly improves the controllability and operation and maintenance efficiency of the system.

[0091] When the gateway aggregation node detects that the BeiDou short message communication link is temporarily unavailable, it saves the return message to be reported and the execution feedback information in the storage and log unit on the gateway side; after the BeiDou link of the wireless communication network is restored, it continues to send according to the priority order, realizing fault-tolerant processing of multi-node interruption resume transmission in emergency scenarios.

[0092] In practice, the gateway's core processing unit monitors the health of the satellite-to-ground link in real time by reading the satellite signal lock pin level of the BeiDou communication module or detecting heartbeat response frames. If the link becomes unavailable due to heavy clouds, heavy rain, or temporary antenna obstruction, the processor stops calling the transmission interface and redirects all data packets that were originally going to enter the BeiDou transmission buffer to a large-capacity non-volatile storage and log unit. Once the satellite signal is relocked and restored, the system initiates a background recovery task, pushing the historical data in batches into the BeiDou transmission queue to complete the supplementary reporting, following the most efficient sequence of "abnormal alarm - execution feedback - regular data".

[0093] A state machine-driven local disaster recovery data buffer pool was established at the system's backbone transmission nodes. This isolated the internal data acquisition system from the negative impact of unreliable external satellite physical links. When the external long-distance trunk line was interrupted, the data acquisition and command suspension mechanisms of the internal LAN continued to operate normally, creating a "reservoir effect" at the gateway. When the physical layer of the link reconnected, this mechanism used a preset weighted priority algorithm to release data from the "reservoir," ensuring that the most critical control feedback and alarm information preferentially occupied the newly restored valuable channels.

[0094] It completely eliminates the potential for trunk system paralysis caused by extreme weather or occasional satellite communication blind spots, ensures the integrity and continuity of historical monitoring data, and greatly enhances the survivability and reliable operation of the entire network system in harsh field environments.

[0095] Example 1: Overall System Implementation Process

[0096] In this embodiment, as Figure 1 As shown in the system architecture diagram, multiple ordinary monitoring nodes are deployed within the target monitoring area, and at least one gateway aggregation node is deployed in a location with favorable on-site communication conditions and convenient BeiDou communication. The ordinary monitoring nodes, gateway aggregation node, BeiDou satellite communication link, and remote monitoring center together constitute a hierarchical emergency data network. The implementation process can be carried out according to the following steps.

[0097] S101. Based on the monitoring area, terrain conditions, and risk level, deploy 10 to 200 ordinary monitoring nodes and 1 to 5 gateway aggregation nodes. Ordinary monitoring nodes are used to connect to monitoring equipment and form the front-end sensing layer, while gateway aggregation nodes are used to form the interface between the field aggregation layer and the remote communication layer.

[0098] S102. Ordinary monitoring nodes perform data collection according to the preset sampling strategy. Under normal circumstances, the sampling period can be from 1 minute to 60 minutes; when the monitored value exceeds the preset threshold or a remote scheduling instruction is received, the sampling frequency can be temporarily adjusted to a higher frequency.

[0099] S103. Ordinary monitoring nodes format the collected data and generate node data messages. Node data messages may include at least the node number, sensor type, sampling time, monitored value, power status, and a verification field.

[0100] S104. Ordinary monitoring nodes send node data packets to the gateway aggregation node via LoRa wireless link in a single-hop or multi-hop manner; when a stable link cannot be established directly with the gateway aggregation node, the data packets can be relayed through neighboring ordinary monitoring nodes.

[0101] The S105 gateway aggregation node receives, caches, filters, summarizes, and packages data packets from multiple ordinary monitoring nodes, and sends the processed monitoring data to the remote monitoring center via the BeiDou short message link. Abnormal alarm data can be reported first, while periodic ordinary data can be transmitted in batches according to preset time windows.

[0102] S106. After receiving monitoring data, the remote monitoring center can generate control commands based on analysis results, alarm status, or scheduling needs. Control commands may include sampling frequency adjustment commands, node status query commands, data supplementation commands, parameter update commands, or sleep / wake-up commands.

[0103] S107. After receiving control commands from the remote monitoring center via the BeiDou link, the gateway aggregation node parses the control commands and broadcasts or distributes them to the target ordinary monitoring nodes via the LoRa link. After the target ordinary monitoring nodes perform the corresponding operations, they can further return execution result messages, thus forming an implementation process that combines uplink monitoring and downlink control.

[0104] Example 2: Detailed Implementation of Ordinary Monitoring Nodes

[0105] In this embodiment, the internal structure of a typical monitoring node is as follows: Figure 4 The typical monitoring node structure diagram shows that it mainly includes a sensor interface unit, a main control processing unit, a storage unit, a LoRa communication unit, and a power management unit. The sensor interface unit is used to connect to at least one monitoring device, the main control processing unit is used to control sampling and complete basic data processing, the storage unit is used to cache collected data and save node parameters, the LoRa communication unit is used to complete data transmission and command reception, and the power management unit is used to supply power to each functional module and perform low-power management.

[0106] Depending on the specific application scenario, the monitoring equipment can be displacement sensors, tilt sensors, temperature sensors, humidity sensors, pressure sensors, water level sensors, vibration sensors, photoelectric switches, Hall elements, or other types of status sensing devices. Ordinary monitoring nodes can perform periodic sampling at preset sampling intervals of 1 minute to 60 minutes, or immediately trigger supplementary sampling and priority reporting when the monitored value exceeds a preset threshold.

[0107] After acquiring raw monitoring data, ordinary monitoring nodes undergo time stamping, node identifier binding, data format organization, verification, and encapsulation by the main control processing unit, generating node data packets to be sent. These node data packets may include at least the node number, sensor type, sampling time, monitored value, power status, and a verification field, thus providing a foundation for subsequent LoRa transmission and unified processing on the gateway side.

[0108] In actual operation, when a regular monitoring node can establish a stable LoRa link with the gateway aggregation node or the previous hop node, the node data packets can be sent directly. If the transmission fails, it can be retransmitted 1 to 5 times within a preset time. If it still fails to send successfully, the relevant data will be cached in the storage unit for 5 minutes to 24 hours, and will continue to be sent in the next sampling cycle or after the link is restored.

[0109] Example 3: Detailed Implementation of Gateway Aggregation Node

[0110] In this embodiment, the internal structure of the gateway aggregation node is as follows: Figure 5 The gateway aggregation node structure diagram shows that it mainly includes a LoRa communication module, a BeiDou communication module, a core processing unit, a storage and logging unit, a power management unit, and a status display and debugging interface. The LoRa communication module is used to receive data uploaded from multiple ordinary monitoring nodes and forward control commands to the target ordinary monitoring node; the BeiDou communication module is used to send the aggregated monitoring data to the remote monitoring center and receive control commands issued by the remote monitoring center via the BeiDou link.

[0111] In the gateway aggregation node, the core processing unit does not directly transmit all raw data indiscriminately. Instead, it classifies and processes the received data according to preset rules. Specifically, the received data can be divided into periodic ordinary monitoring data and abnormal alarm data. Abnormal alarm data enters a high-priority transmission queue, while periodic ordinary monitoring data enters a timed summary transmission queue. For data from multiple ordinary monitoring nodes within the same time window, it can be merged and packaged according to node number, data type, or time period, and then a return message suitable for BeiDou short message transmission can be generated.

[0112] In one optional implementation, each gateway aggregation node can connect to 5 to 100 ordinary monitoring nodes. For abnormal alarm data, BeiDou rapid backhaul can be initiated immediately upon receipt; for periodic ordinary data, it can be centrally processed and then uniformly backhauled in time windows of 5 to 30 minutes. When the BeiDou link is temporarily unavailable, the gateway aggregation node can cache the data to be backhauled in the storage and log unit for a caching time of 10 minutes to 72 hours, and continue to send it in the order of reception or priority after the link is restored.

[0113] Example 4: Implementation Process of LoRa Multi-hop Convergence and BeiDou Backhaul

[0114] In this embodiment, after the ordinary monitoring node completes data acquisition and generates node data packets, it first determines whether a stable LoRa communication link can be established directly with the gateway aggregation node. If direct communication is possible, the node data packet is sent directly to the gateway aggregation node; if direct communication is not possible, the node data packet is sent to a nearby ordinary monitoring node as a relay node, which then continues to forward the data hop by hop until it reaches the gateway aggregation node. If the previous hop node does not receive an acknowledgment within a preset time, it can retransmit 1 to 3 times; after the preset number of retransmissions is reached, the data is transferred to a local cache to await subsequent retransmission.

[0115] After receiving data packets from nodes, the gateway aggregation node's core processing unit identifies the node's source, timestamps the data, binds node identifiers, filters and organizes the data, and further determines whether the data belongs to abnormal alarm data. If it is abnormal alarm data, a BeiDou backhaul message is generated first and sent immediately; if it is periodic ordinary data, it is written to the buffer and sent uniformly when a preset time window or a preset number of messages is reached.

[0116] In this embodiment, BeiDou backhaul can be performed using methods such as timed backhaul, threshold-triggered backhaul, alarm-triggered backhaul, or remote query-triggered backhaul. When the monitored data is within the normal fluctuation range, it can be reported in batches according to a preset period; when abnormal fluctuations occur, alarm conditions are met, or a remote query request is received, the BeiDou fast backhaul process can be initiated first. If the BeiDou link transmission fails, the unsuccessfully transmitted backhaul messages are retained in the buffer and retransmitted at a subsequent transmission opportunity.

[0117] Example 5: Implementation Process of Remote Command Issuance and Execution Feedback

[0118] In this embodiment, after receiving on-site monitoring data, the remote monitoring center can generate control commands based on the monitoring results, node status, or scheduling requirements, and send the control commands to the gateway aggregation node via the BeiDou short message communication link. Control commands may include sampling frequency adjustment commands, node status query commands, data supplementation commands, parameter update commands, or sleep / wake-up commands. The downlink control relationship can be found in [reference needed]. Figure 7 Diagram illustrating the reverse transmission of remote commands.

[0119] Upon receiving a control command, the gateway aggregation node's core processing unit parses the command, identifies the target ordinary monitoring node number, command type, and execution parameters, and selects between broadcast and targeted transmission methods based on the current LoRa network connection status. If the target ordinary monitoring node is temporarily offline or unreachable, the gateway aggregation node can store the control command to be sent in its local cache and redistribute it after the target node regains connectivity.

[0120] Upon receiving a control command, a regular monitoring node executes the corresponding operation through its local main control processing unit and generates an execution result message. The execution result message may include the node number, execution command type, execution time, and execution result status. The execution result message is returned to the gateway aggregation node via the LoRa link, and the gateway aggregation node then sends it to the remote monitoring center via the BeiDou short message communication link as needed. If no execution feedback is received from the target regular monitoring node within a preset time, the gateway aggregation node can resend the control command 1 to 3 times. If the resending attempt still fails, the abnormal status is recorded and reported to the remote monitoring center.

[0121] Example 6: Exception and Fault Tolerance Handling Example

[0122] In this embodiment, when a LoRa local link anomaly prevents a regular monitoring node from reporting data, the node can first perform a preset number of retransmissions. If it still cannot report, the relevant monitoring data is written to a local cache queue and sent again in the next sampling cycle or after the link is restored. For low-power states, the regular monitoring node can also automatically reduce the sampling frequency, disable unnecessary functional modules, or enter a low-power standby mode to extend its continuous operating time.

[0123] When the gateway aggregation node detects that the BeiDou link is temporarily unavailable, it can write the data to be transmitted back into the pending queue, prioritizing the retention of abnormal alarm data and control feedback data. After the BeiDou link is restored, high-priority messages are sent first, followed by periodic ordinary data. For remotely issued control commands, when the target ordinary monitoring node is temporarily offline, the gateway aggregation node can cache the commands to be issued and re-deliver them after the target node comes back online. If multiple deliveries fail consecutively, the node's disconnection status is recorded and the abnormal information is transmitted back to the remote monitoring center.

[0124] Through the above-mentioned anomaly and fault-tolerance handling methods, this embodiment can maintain data retention, command retransmission and status tracking capabilities under conditions such as LoRa link fluctuations, short-term interruptions of BeiDou links, node offline or insufficient power supply, thereby improving the system's continuous operation capability and engineering adaptability in complex environments.

[0125] Example 7: Typical Application Scenarios

[0126] In one slope monitoring embodiment, 10 to 100 ordinary monitoring nodes can be deployed within a slope area of ​​100 to 1000 meters in length, and 1 to 3 gateway aggregation nodes can be deployed at the slope top, slope shoulder, or adjacent high points. Ordinary monitoring nodes can be connected to displacement sensors, tilt sensors, soil moisture sensors, or environmental monitoring sensors, and perform routine sampling at a cycle of 5 to 30 minutes. When the displacement, tilt value, or other monitoring parameters exceed a preset threshold, the sampling cycle can be automatically adjusted to 1 to 5 minutes, and abnormal data can be marked as high-priority data, preferentially aggregated to the gateway aggregation node via LoRa link, and then the gateway aggregation node immediately reports to the remote monitoring center via BeiDou short message link.

[0127] When implemented at tunnel entrances, riverbanks, forest areas, or field construction sites, 5 to 50 ordinary monitoring nodes can be deployed in key locations, and 1 to 2 gateway aggregation nodes can be set up at on-site duty points, temporary computer rooms, or higher terrain. Ordinary monitoring nodes can be used to acquire information on temperature, humidity, vibration, water level, displacement, or structural status. Under conditions of unstable or even interrupted public network, the system can still use LoRa network and BeiDou link to complete front-end sensing, on-site aggregation, remote scheduling, and data transmission continuation in abnormal situations, thereby meeting the needs of emergency monitoring and rapid response.

[0128] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A method for constructing an emergency data network based on LoRa and BeiDou collaboration, characterized in that, Includes the following steps: S1. Deploy multiple ordinary monitoring nodes within the target monitoring area and deploy at least one gateway aggregation node, with the ordinary monitoring nodes and the gateway aggregation node forming a local sensor network on site; S2. The ordinary monitoring node samples the connected sensors according to a preset sampling strategy, obtains on-site monitoring data, and generates node data messages. The node data messages include at least node identifier, sampling time, monitoring data value, and status information. S3. Ordinary monitoring nodes transmit node data packets to the gateway aggregation node via the LoRa wireless communication link in a single-hop or multi-hop manner; S4. The gateway aggregation node receives node data packets from multiple ordinary monitoring nodes, and performs caching, filtering, classification and packaging of the node data packets according to node source, data type and priority. S5. The gateway aggregation node generates BeiDou backhaul messages according to the preset reporting strategy, and sends the processed monitoring data to the remote monitoring center through the BeiDou short message link to establish a cross-regional wireless communication network in an environment without a public network. S6. The remote monitoring center generates a control command message based on the received monitoring data and sends the control command message to the gateway aggregation node through the Beidou short message link. S7. The gateway aggregation node parses the control command message and sends the command to the target ordinary monitoring node through the LoRa link; after the target ordinary monitoring node performs the corresponding operation, it generates an execution feedback message and reports it to the remote monitoring center through the gateway aggregation node, forming a closed-loop control.

2. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 1, characterized in that, In steps S1 and S2, the sensor interface unit of the ordinary monitoring node is used to connect to sensors of displacement, tilt angle, temperature and humidity, pressure, water level or vibration type; after acquiring the raw monitoring data, the ordinary monitoring node performs data format sorting, time stamping, node identity binding and preliminary filtering of outliers, and generates node data packets suitable for transmission in the local sensor network.

3. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 1, characterized in that, In step S3, the single-hop or multi-hop method refers to: after the ordinary monitoring node is powered on and initialized, it identifies nearby reachable nodes and builds a self-organizing network with dynamic routing based on the LoRa protocol; for ordinary monitoring nodes with direct connection conditions, the data is sent to the gateway aggregation node in a single-hop manner; for nodes without direct connection conditions, the node data packets are sent to the nearby relay nodes in the self-organizing network for tiered forwarding.

4. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 3, characterized in that, During hop-by-hop forwarding, if a hop in the self-organizing network fails to transmit, a retransmission is performed. If the retransmission fails after a preset number of attempts, the node data packet is written into the local cache of the ordinary monitoring node and sent again after the LoRa wireless communication link is restored.

5. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 1, characterized in that, In steps S4 and S5, the core processing unit of the gateway aggregation node has a built-in sensor network operating system. The sensor network operating system schedules the received node data packets, and data that exceeds the threshold, undergoes a sudden change, or has an alarm mark is included in the high-priority sending queue as alarm data, while periodic and routine monitoring data is included in the periodic cache queue as ordinary data.

6. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 5, characterized in that, In step S5, when the gateway aggregation node sends data via BeiDou short message: for alarm data in the high-priority sending queue, BeiDou backhaul messages are generated first and immediate reporting is triggered; for ordinary data in the periodic cache queue, data is periodically summarized, packaged and reported according to a preset time window, message length limit or data number threshold.

7. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 1, characterized in that, In step S6, the control command message includes the target node identifier, control type, execution parameters, and issuance time; the control type includes adjusting the sampling frequency of the sensor, configuring parameters, querying status, supplementing data, switching working modes, or waking up from sleep.

8. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 1, characterized in that, In step S7, after receiving the control command message, the gateway aggregation node parses the target node identifier and determines whether the control command is a broadcast control or a directional control. For target ordinary monitoring nodes that are currently unreachable, the gateway aggregation node writes the corresponding control command into the queue to be sent and resends it after the target node restores connectivity.

9. The method for constructing an emergency data network based on LoRa and BeiDou collaboration according to claim 1, characterized in that, In step S7, the execution feedback message includes the target node identifier, execution result, execution time, and abnormal status information; when the control task is executed successfully, it is used to confirm that the remote instruction has been implemented; when the task fails, it is used to record the reason for the failure or the current node status, thereby ensuring the reliability of the bidirectional scheduling of the entire wireless communication network.

10. A method for constructing an emergency data network based on LoRa and BeiDou collaboration according to any one of claims 1 to 9, characterized in that, When the gateway aggregation node detects that the BeiDou short message communication link is temporarily unavailable, it saves the return message to be reported and the execution feedback information in the storage and log unit on the gateway side. Once the BeiDou link of the wireless communication network is restored, transmission will continue according to priority, thus achieving fault-tolerant processing for multi-node interruption resume transmission in emergency scenarios.