Multi-mirror-image remote upgrading method and system for LoRaWAN equipment

Abstract

The invention is applicable to the technical field of Internet of Things communication, and relates to a multi-mirror remote upgrading method and system for LoRaWAN equipment, comprising: splitting firmware of target equipment into a plurality of mirror files, each mirror file corresponding to a mirror, and generating local metadata for each mirror file; when the upgrading operation is executed, the FUOTA server selects at least one mirror image file from the plurality of mirror image files as a current upgrading target module; splitting the file of the target module into a plurality of fragments according to a fragmentation mechanism, and sending the fragments to the target device through a downlink channel; the target device performs integrity verification on the file of the target module according to the verification code in the local metadata; and reading the version number in the local metadata of each mirror image file area from the flash, and feeding back the version number to the FUOTA server through an LoRaWAN uplink message. According to the invention, the problems of long upgrading time and low upgrading success rate of the LoRaWAN equipment in the prior art are solved.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) communication technology, and particularly relates to a method and system for remote upgrade of LoRaWAN devices with multiple mirrors. Background Technology

[0002] During operation, LoRaWAN devices sometimes require remote wireless firmware upgrades to update product features, fix vulnerabilities, and optimize performance. Existing methods for remote firmware upgrades of LoRaWAN devices primarily involve transmitting the entire firmware image file in data frames via multicast / unicast over the LoRaWAN network. The device then verifies and upgrades after receiving all data frames. This method requires transmitting the entire firmware image file regardless of the size of the firmware modification, leading to risks such as wasted LoRaWAN network resources, long upgrade times, and low upgrade success rates.

[0003] Patent application CN110308916A discloses an OTA upgrade method based on the LoRaWAN protocol. The method includes: obtaining the device terminal's code version number through an intermediate device; and when the version number of the sent BIN file is inconsistent with the device terminal's code version number, obtaining the device terminal type; the device terminal type includes Class A, Class B, and Class C types; setting the device terminal from its initial type to Class C and sending the BIN file to the device terminal to upgrade it; obtaining the device terminal's upgrade status during the upgrade process; and when the upgrade status is normal, the communication time with the device terminal has not expired, and the device terminal's upgrade time has not expired, obtaining the device terminal's upgrade success status through the intermediate device, and then switching the device terminal type back to the initial type to complete the OTA upgrade. This patent application describes an upgrade method that transmits the entire firmware image file, but it does not provide a technical solution for addressing the problems of long upgrade times and low success rates for LoRaWAN devices.

[0004] Therefore, how to provide a method that supports firmware image file upgrades, splits the upgrade firmware into multiple image files for selective upgrades, thereby improving the success rate of LoRaWAN device upgrades and shortening the upgrade time, is a problem that urgently needs to be solved by those in this technical field. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the purpose of this invention is to provide a multi-mirror remote upgrade method for LoRaWAN devices, thereby solving the problems of long upgrade times and low success rates in existing LoRaWAN device upgrades; in addition, this invention also provides a multi-mirror remote upgrade system for LoRaWAN devices.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for remotely upgrading a LoRaWAN device using multiple mirrors, comprising the following steps:

[0008] S10. Split the firmware of the target device into multiple image files, each image file corresponds to a bin image, and generate local metadata for each image file;

[0009] S20. When performing the upgrade operation, the FUOTA server selects at least one image file from the multiple image files as the target module for this upgrade according to the upgrade strategy, and sends an upgrade start command to the target device through LoRaWAN downlink commands.

[0010] S30. The file of the target module is split into multiple fragments according to the LoRaWAN FUOTA fragmentation mechanism, and the fragments are sent to the target device through the LoRaWAN downlink channel. The target device receives the fragments and caches them in the specified upgrade temporary cache area. At the same time, it updates the fragment index table in the global metadata to realize breakpoint resume transmission until the reception is completed.

[0011] S40. After receiving the data, the target device performs an integrity check on the target module's file based on the checksum in the local metadata. If the check passes, the complete image is copied to the target module's Bak area, the execution entry point is switched, and then a soft reboot is performed to reload the latest firmware.

[0012] S50. If the write operation fails or the module upgrade fails, the Bootloader will automatically roll back to the last valid module and update the status flag, and then perform a soft reboot.

[0013] S60, after reboot, reads the version number from the local metadata of each image file region in the flash, and feeds it back to the FUOTA server via LoRaWAN uplink message.

[0014] Furthermore, in S10, the multiple image files include the communication module comm.bin, the application module app.bin, and the configuration module cfg.bin; the local metadata includes the module identifier, version number, dependency relationship, total number of fragments, module size, checksum, and target write address.

[0015] Furthermore, in S20, the upgrade start instruction contains local metadata information of the selected image. After receiving the upgrade start instruction, the device switches the working module to Class C, enters the long-term receiving mode, and initializes the upgrade cache and index table.

[0016] Furthermore, the specific steps of S30 are as follows:

[0017] S301. Initialization phase: When the Bootloader starts, it first reads the global metadata area to determine whether it is in an upgrade state. If it is in an upgrade state, it enters the fragment receiving phase.

[0018] S302, Fragment Reception and Verification Phase: The device receives fragment packets through the LoRaWAN link. Each fragment contains a fragment number frag_id and a data payload. At the same time, the fragment index table in the global metadata is updated.

[0019] S303, Power Loss and Reboot Recovery Phase: If the device loses power or restarts during transmission, the Bootloader reads the index table after powering on;

[0020] S304, Full Mirror Verification Stage: After all fragments are marked as received, proceed to the next verification stage.

[0021] Furthermore, in step S301, if an index table with the same upgrade session identifier is detected, the system enters the breakpoint resume mode; otherwise, the index table is cleared and the status bits are initialized.

[0022] Furthermore, in step S303, a missing fragment bitmap is generated based on the frag_status field and reported to the FUOTA server via LoRaWAN. The FUOTA server only retransmits fragments that were not received or failed to be verified, thereby avoiding duplicate transmissions.

[0023] Furthermore, in S40, the Flash partition is pre-divided into Bootloader, Comm communication image, CommBak communication image backup, App application image, AppBak application image backup, Config image, ConfigBak configuration image backup, MetaData global metadata, and Temp temporary buffer.

[0024] Furthermore, the header 256 bytes of each type stores the local metadata of that type of image. After receiving the upgrade package, it is placed in the Temp temporary buffer. After receiving, the CRC32 checksum of the upgrade package and the local metadata is compared and passed. Then, it is copied to the corresponding Bak partition according to the local metadata module identifier of the received image, and the global metadata image FUOTA state machine is updated to PENDING. The entry address is changed to the Bak partition. After soft reboot, the global metadata is read. If it is found to be in the PENDING state, it is marked as ACTIVE after passing the CRC32 again and the execution entry point is switched to start running.

[0025] Furthermore, in S60, the FUOTA server, based on the reported results, compiles the upgrade success results and the missing bitmap, and determines whether it is necessary to retransmit the packet and attempt the upgrade again.

[0026] Secondly, the present invention also provides a system employing the above method, comprising: a FUOTA server, a LoRaWAN network server, and a LoRaWAN gateway connected in sequence, wherein the LoRaWAN gateway is connected in communication with multiple target LoRaWAN devices.

[0027] Compared with existing technologies, the multi-image remote upgrade method and system for LoRaWAN devices provided by this invention have at least the following advantages:

[0028] Existing technologies for LoRaWAN devices suffer from long upgrade times and low success rates. This invention splits the firmware into independent image files, allowing the server to distribute only the actually changed modules, directly reducing downlink traffic and transmission time, and avoiding repeated writing of unchanged modules. This significantly improves upgrade efficiency and reduces energy consumption on limited LoRaWAN channels. Furthermore, this invention couples the Bootloader with the FUOTA process (including reading the FUOTA session state at startup, reporting verification results, and performing atomic switching / rollback), extending the previously isolated local boot logic into an end-to-cloud closed-loop control. This enables timely error detection and feedback, supports remote retries or policy adjustments, and significantly reduces the risk of device failure due to version incompatibility or download failures. Addressing the low bandwidth and high interruption characteristics of LoRaWAN, this invention incorporates a persistent fragmented receive buffer, session ID, and fragmented bitmap into the Bootloader, supporting breakpoint resumption and on-demand retransmission of missing fragments. This mechanism allows the device to gradually complete fragmented reception within a low-power wake-up window and resume progress after power failure, significantly improving the upgrade success rate under unreliable links and strict duty-cycle constraints. In summary, this invention not only reduces network overhead and energy consumption in terms of performance, but also provides end-to-end assurance in terms of reliability and maintainability—enabling large-scale LoRaWAN terminals to be remotely maintained in a shorter time, at a lower cost, with a higher success rate, and in a more controllable manner. Attached Figure Description

[0029] To more clearly illustrate the solution of the present invention, a brief introduction will be given to the drawings used in the description of the embodiments below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0030] Figure 1A flowchart illustrating a multi-image remote upgrade method for a LoRaWAN device provided in an embodiment of the present invention;

[0031] Figure 2 This is a schematic diagram of the Flash partition in a multi-image remote upgrade method for a LoRaWAN device provided in an embodiment of the present invention;

[0032] Figure 3 A logic diagram of a multi-image remote upgrade method for a LoRaWAN device provided in an embodiment of the present invention;

[0033] Figure 4 This is a framework diagram of a multi-image remote upgrade system for a LoRaWAN device provided in an embodiment of the present invention. Detailed Implementation

[0034] 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. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. For example, terms such as “length,” “width,” “upper,” “lower,” “left,” “right,” “front,” “rear,” “vertical,” “horizontal,” “top,” “bottom,” “inner,” and “outer” indicate orientations or positions based on the accompanying drawings and are for ease of description only, and should not be construed as limiting the technical solution. The terms “comprising” and “having,” and any variations thereof, in the specification, claims, and accompanying drawings of this invention, are intended to cover non-exclusive inclusion. The terms “first,” “second,” etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects and not to describe a particular order. In the specification, claims, and accompanying drawings of this invention, when an element is referred to as “fixed to,” “mounted to,” “set on,” or “connected to” another element, it may be directly or indirectly located on that other element. For example, when an element is referred to as “connected to” another element, it may be directly or indirectly connected to that other element. Furthermore, the reference to "embodiment" herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0035] This invention provides a multi-mirror remote upgrade method for LoRaWAN devices, which is executed collaboratively between a FUOTA (Firmware Update Over The Air) server and the target terminal device. This method enables modular, low-power, and highly reliable firmware upgrades for devices. The multi-mirror remote upgrade method for LoRaWAN devices includes the following steps:

[0036] S10. Split the firmware of the target device into multiple image files, each image file corresponding to a bin image, and generate local metadata for each image file; S20. When performing the upgrade operation, the FUOTA server selects at least one image file from the multiple image files as the target module for this upgrade according to the upgrade strategy, and sends an upgrade start command to the target device via LoRaWAN downlink commands; S30. Split the target module's files according to LoRaWAN... The FUOTA fragmentation mechanism splits the data into multiple fragments and sends them to the target device via the LoRaWAN downlink channel. The target device receives the fragments and caches them in a designated upgrade temporary buffer. It uses a fragment index table and CRC check mechanism to resume transmission from interruption until the reception is complete. S40: After reception, the target device performs integrity verification on the target module's files based on the checksum in the local metadata. If the verification passes, the complete image is copied to the target module's Bak area, the execution entry point is switched, and then a soft reboot is performed to reload the latest firmware. S50: If the write fails or the module upgrade is abnormal, the bootloader automatically rolls back to the previous valid module and updates the status flag, and then performs a soft reboot. S60: After rebooting, the version number in the local metadata of each image file area is read from the flash and fed back to the FUOTA server via LoRaWAN uplink messages.

[0037] This invention solves the problems of long upgrade time and low upgrade success rate of LoRaWAN devices in the prior art.

[0038] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0039] This invention provides a multi-mirror remote upgrade method for LoRaWAN devices, which is executed collaboratively between a FUOTA (Firmware Update Over The Air) server and the target terminal device. This method enables modular, low-power, and highly reliable firmware upgrades for devices, combined with... Figures 1 to 3 In this embodiment, the multi-image remote upgrade method for the LoRaWAN device includes the following steps:

[0040] S10. Module Division and Local Metadata Establishment: The overall firmware of the target device is divided into functional modules, each corresponding to an independent image file (bin file), such as: communication module (comm.bin), application module (app.bin), configuration module (cfg.bin), etc. For each image file, the FUOTA server generates corresponding module local metadata, which includes: module identifier, version number, dependencies, total number of fragments, module size, checksum, and target write address. Each image file and the local metadata together constitute a complete upgrade session package.

[0041] In this embodiment, the device's Flash storage maintains two levels of metadata simultaneously:

[0042] Local metadata (level 1 metadata) is stored at the beginning of each image partition, describing the module's own module identifier, version number, dependencies, total number of fragments, module size, checksum, and target write address. Global metadata (level 2 metadata) is centrally stored in a separate metadata area, used to maintain module identifiers, upgrade session identifiers (session_id), fragment index tables, and FUOTA state machine states. The two are associated through the module identifier. When the bootloader starts, it first reads the global metadata area to determine whether it is in an upgrade state, and then accesses the corresponding image header metadata based on the module identifier for integrity verification, enabling fine-grained management of multiple images and breakpoint recovery.

[0043] S20. FUOTA Server Selects Upgrade Target and Issues Start Command: When performing a remote upgrade operation, the FUOTA server selects a target module from multiple image files as the target module for this upgrade based on the upgrade strategy (such as version differences, module dependencies, and energy consumption constraints). The server sends an upgrade start command (Upgrade_Start_CMD) to the target device through LoRaWAN downlink commands (FPort is the specific upgrade port). The upgrade start command contains local metadata information of the image. After receiving it, the device prepares for the upgrade.

[0044] Specifically, in this embodiment, the device performs the following operations after receiving the instruction:

[0045] Switch the working mode to Class C;

[0046] Enter long-term reception mode;

[0047] Initialize and upgrade the cache and index table;

[0048] If only the application module is being upgraded this time, only app.bin will be transferred to avoid transferring irrelevant modules, thereby reducing the downlink load of LoRaWAN.

[0049] S30. File Fragmentation and Caching Mechanism: The FUOTA server splits the selected module file into multiple fragments according to the LoRaWAN FUOTA fragmentation mechanism. The target device receives the data fragment by fragment and caches it in the temporary upgrade buffer (Temp area) of Flash. To address the characteristics of low downlink bandwidth and easy communication interruption in LoRaWAN, this embodiment introduces updating the fragment index table in the global metadata after receiving data to achieve breakpoint resumption, ensuring integrity under low-speed links until reception is complete. This mechanism is particularly suitable for the low bandwidth and high interruption environment of LoRaWAN, achieving highly reliable FUOTA transmission and power-loss safe breakpoint resumption.

[0050] Specifically, in this embodiment, the fragment index table structure is defined.

[0051] The bootloader maintains the following structure in Flash non-volatile memory:

[0052] typedef struct {

[0053] uint16_t total_frags; / / Total number of fragments

[0054] uint8_t frag_status[MAX_FRAG]; / / Status of each fragment: 0 - not received, 1 - receiving, 2 - verification passed

[0055] uint16_t frag_crc16[MAX_FRAG]; / / CRC checksum for each fragment

[0056] uint16_t last_frag_id; / / The last received fragment number

[0057] uint32_t received_bytes; / / Count of bytes received

[0058] uint32_t last_update_tick; / / Last update time

[0059] uint8_t checksum; / / Index table integrity check

[0060] }frag_table_t;

[0061] The index table is written in fixed pages (e.g., 4KB) and uses a double-buffered page write mechanism to ensure that the index data is not corrupted in the event of power failure or write interruption.

[0062] Furthermore, in this embodiment, the specific steps of S30 are as follows:

[0063] S301. Initialization Phase: When the Bootloader starts the FUOTA module, it first reads the global metadata area. If an index table with the same session identifier (session_id) is detected, it means that the previous upgrade was not completed, and then it enters the breakpoint resume mode; otherwise, it clears the index table and initializes the status bits.

[0064] S302, Fragment Reception and Verification Stage: The device receives FUOTA fragment packets. Each fragment contains a fragment number (frag_id) and a data payload. The Bootloader performs a CRC32 check on it, and updates the index table content after the check passes.

[0065] S303, Power Loss and Reboot Recovery Phase: If the device loses power or restarts during transmission, the Bootloader reads the index table after powering on, generates a missing fragment bitmap based on frag_status, and reports it to the FUOTA server via the LoRaWAN network. The server only retransmits the fragments that were not received or failed to be verified, thus achieving breakpoint resumption and bandwidth saving.

[0066] S304, Full Image Verification Stage: When all fragment statuses in the index table are marked as "received", the Bootloader calculates the CRC32 of the entire temporary image and compares it with the checksum in the local metadata. After the verification is successful, it enters the writing stage.

[0067] S40, Bootloader Verification and Image Writing: After all fragments have been received and verified, the target device performs the following operations:

[0068] Verify the integrity of the cache image based on the checksum (CRC32) of the local metadata;

[0069] If the verification passes, the complete image will be copied from the Temp temporary area to the corresponding backup area (Bak area).

[0070] Based on the module type (Comm / App / Config), update the corresponding global metadata area information (change the status indicator to PENDING);

[0071] Modify the module's execution entry address to the Bak section;

[0072] Trigger a soft reboot to load the latest firmware.

[0073] In this embodiment, the Flash partition is pre-divided into Bootloader, Comm communication image, CommBak communication image backup, App application image, AppBak application image backup, Config image, ConfigBak configuration image backup, MetaData global metadata, and Temp temporary buffer. The header 256 bytes of each type store the local metadata of that type of image. After receiving the upgrade package, it is uniformly placed in the Temp temporary buffer. After reception, the CRC32 checksum of the upgrade package and the local metadata is compared and passes, and then copied to the corresponding Bak partition according to the local metadata module identifier of the received image. The global metadata image status is updated to PENDING, and the entry address is modified to the Bak partition. After restarting, the global metadata is read. If it is found to be in PENDING state, it passes the CRC32 checksum again, is marked as ACTIVE, and the execution entry point is switched to start running.

[0074] Furthermore, in this embodiment, a fixed partition is used to store the global metadata (MetaData) of this upgrade session, including the upgrade session identifier (session_id), module identifier, fragment index table, and FUOTA state machine state. After the device restarts, the bootloader reads the global metadata: if a module's state is PENDING, a CRC32 check is performed again; if the check passes, the state is updated to ACTIVE, and the execution entry point is switched; the latest image is then started.

[0075] S50. Rollback and Exception Handling: If a verification failure, write error, or runtime exception occurs during the write process, the Bootloader will automatically rollback.

[0076] Restore the status of the corresponding module to the previous valid version;

[0077] Switch the entry point to the previous ACTIVE image;

[0078] Report the error status and perform a soft reboot to recover.

[0079] This rollback mechanism ensures that the device can be automatically restored to a working state in the event of any interruption or upgrade failure, preventing the device from becoming "bricked".

[0080] S60 Reporting and Server Verification: After the upgrade is complete, the device boots up and runs the new image. The bootloader reads the version number and FUOTA status from the global and local metadata of all modules in the Flash, and reports it to the FUOTA server via LoRaWAN uplink messages. The FUOTA server calculates the upgrade success rate and confirms the upgrade result based on the version information and missing fragment bitmap reported by the device; if it finds that some devices still have missing fragments or verification failures, it selectively retransmits the corresponding fragments according to the missing fragment bitmap to complete the packet replacement upgrade.

[0081] This invention also provides a system employing the multi-image remote upgrade method for LoRaWAN devices described in the above embodiments, combined with... Figures 1 to 4 In this embodiment, the LoRaWAN device multi-mirror remote upgrade system includes: a FUOTA server, a LoRaWAN network server, and a LoRaWAN gateway that are connected in sequence, and the LoRaWAN gateway is connected in communication with multiple target LoRaWAN devices.

[0082] Compared with existing technologies, the multi-image remote upgrade method and system for LoRaWAN devices described in the above embodiments have a longer upgrade time and lower success rate. This invention splits the firmware into independent image files, allowing the server to only send out the modules that are actually changed, directly reducing downlink traffic and transmission time, avoiding repeated writing of unchanged modules, thereby significantly improving upgrade efficiency and reducing energy consumption on limited LoRaWAN channels. This invention couples the Bootloader with the FUOTA process (including reading the FUOTA session state at startup, reporting verification results, and performing atomic switching / rollback), extending the originally isolated local boot logic into an end-to-cloud closed-loop control, enabling timely detection and feedback of errors, supporting remote retries or policy adjustments, thereby significantly reducing the risk of device bricking due to version incompatibility or download failures. Addressing the low bandwidth and high interruption characteristics of LoRaWAN, this invention incorporates a persistent fragmented receive buffer, session ID, and fragmented bitmap into the Bootloader, and supports breakpoint resumption and on-demand retransmission of missing fragments. This mechanism allows devices to gradually complete fragmented reception within a low-power wake-up window and resume progress after power failure, significantly improving upgrade success rates under unreliable links and strict duty-cycle constraints. In summary, this invention not only reduces network overhead and energy consumption in terms of performance but also provides end-to-end guarantees in terms of reliability and maintainability—enabling large-scale LoRaWAN terminals to be remotely maintained in a shorter time, lower cost, higher success rate, and more controllable manner.

[0083] Obviously, the embodiments described above are merely preferred embodiments of the present invention, and not all embodiments. The accompanying drawings illustrate preferred embodiments of the present invention, but do not limit the scope of the patent. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this invention.

Claims

1. A method for remotely upgrading a LoRaWAN device using multiple mirrors, characterized in that, Includes the following steps: S10. Split the firmware of the target device into multiple image files, each image file corresponds to a bin image, and generate local metadata for each image file; S20. When performing the upgrade operation, the FUOTA server selects at least one image file from the multiple image files as the target module for this upgrade according to the upgrade strategy, and sends an upgrade start command to the target device through LoRaWAN downlink commands. S30. The file of the target module is split into multiple fragments according to the LoRaWAN FUOTA fragmentation mechanism, and the fragments are sent to the target device through the LoRaWAN downlink channel. The target device receives the fragments and caches them in the specified upgrade temporary cache area. At the same time, it updates the fragment index table in the global metadata to realize breakpoint resume transmission until the reception is completed. S40. After receiving the data, the target device performs an integrity check on the target module's file based on the checksum in the local metadata. If the check passes, the complete image is copied to the target module's Bak area, the execution entry point is switched, and then a soft reboot is performed to reload the latest firmware. S50. If the write operation fails or the module upgrade fails, the Bootloader will automatically roll back to the last valid module and update the status flag, and then perform a soft reboot. S60, after reboot, reads the version number from the local metadata of each image file region in the flash, and feeds it back to the FUOTA server via LoRaWAN uplink message.

2. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 1, characterized in that, In S10, multiple image files include the communication module comm.bin, the application module app.bin, and the configuration module cfg.bin; local metadata includes module identifier, version number, dependency relationship, total number of fragments, module size, checksum, and target write address.

3. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 1, characterized in that, In S20, the upgrade start command contains local metadata information of the selected image. After receiving the upgrade start command, the device switches the working module to Class C, enters the long-term receiving mode, and initializes the upgrade cache and index table.

4. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 1, characterized in that, The specific steps of S30 are as follows: S301. Initialization phase: When the Bootloader starts, it first reads the global metadata area to determine whether it is in an upgrade state. If it is in an upgrade state, it enters the fragment receiving phase. S302, Fragment Reception and Verification Phase: The device receives fragment packets through the LoRaWAN link. Each fragment contains a fragment number frag_id and a data payload. At the same time, the fragment index table in the global metadata is updated. S303, Power Loss and Reboot Recovery Phase: If the device loses power or restarts during transmission, the Bootloader reads the index table after powering on; S304, Full Mirror Verification Stage: After all fragments are marked as received, proceed to the next verification stage.

5. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 4, characterized in that, In step S301, if an index table with the same upgrade session identifier is detected, the interrupted resume mode is entered; otherwise, the index table is cleared and the status bits are initialized.

6. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 4, characterized in that, In step S303, a missing fragment bitmap is generated based on the frag_status field and reported to the FUOTA server via LoRaWAN. The FUOTA server only retransmits fragments that were not received or failed to be verified, thereby avoiding duplicate transmissions.

7. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 1, characterized in that, In S40, the Flash partition is pre-divided into Bootloader, Comm communication image, CommBak communication image backup, App application image, AppBak application image backup, Config image, ConfigBak configuration image backup, MetaData global metadata, and Temp temporary buffer.

8. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 7, characterized in that, The header 256 bytes of each type stores the local metadata of that type of image. After receiving the upgrade package, it is placed in the Temp temporary buffer. After receiving, the CRC32 checksum of the upgrade package and the local metadata is compared and passed. Then, according to the local metadata module identifier of the received image, it is copied to the corresponding Bak partition, and the global metadata image FUOTA state machine is updated to PENDING. The entry address is changed to the Bak partition. After soft reboot, the global metadata is read. If it is found to be in the PENDING state, it is marked as ACTIVE after passing the CRC32 again and the execution entry point is switched to start running.

9. The method for remote upgrade of a LoRaWAN device with multiple mirrors according to claim 1, characterized in that, In step S60, the FUOTA server calculates the upgrade success result and missing bitmap based on the reported results. The FUOTA server then determines whether it needs to retransmit packets and attempt the upgrade again based on the reported information.

10. A system employing the method as described in any one of claims 1 to 9, characterized in that, include: The system consists of a FUOTA server, a LoRaWAN network server, and a LoRaWAN gateway that are connected in sequence. The LoRaWAN gateway is connected in communication with multiple target LoRaWAN devices.

Images