A firmware upgrading method and a firmware upgrading device

Abstract

The present application relates to a kind of firmware upgrade method and firmware upgrade device, the method includes: receiving upgrade instruction and responding, current firmware offset is set to initial value, and sends firmware data request to first base station;Upgrade instruction carries the firmware identifier and firmware data amount information of the firmware to be upgraded;Firmware data request carries firmware identifier and current firmware offset;Receive firmware data block;Firmware data block is written into corresponding storage area, and current firmware offset is updated based on firmware data block;Updated current firmware offset is not less than firmware data amount information, based on all firmware data that has been written, execute firmware integrity check;And in check success executes restart operation to load and run new firmware, realize the orderly, continuous, reliable firmware upgrade of large-scale terminal in mobile scene, significantly improve upgrade efficiency, success rate and system overall resource utilization.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and more specifically, to a firmware upgrade method and a firmware upgrade device. Background Technology

[0002] With the rapid development of IoT technology, especially in fields such as industrial automation and smart factories, a massive number of intelligent terminal devices (such as personnel positioning tags, environmental sensors, and motion controllers) are being widely deployed. During operation, these devices typically require remote firmware upgrades (OTA, Over-The-Air) to fix vulnerabilities, optimize performance, or add new features.

[0003] Currently, most mainstream OTA upgrade solutions adopt a centralized architecture. In this architecture, the upgrade process is typically managed by a central server (or management platform). When a batch of terminals needs to be upgraded, the central server directly sends upgrade commands to each target terminal. After receiving the command, the terminal directly downloads the complete firmware file from the central server, completes local verification, and then reboots to take effect.

[0004] However, the aforementioned centralized OTA solution exhibits significant technical shortcomings in the following scenarios: Network bandwidth and server load bottlenecks: In large-scale industrial scenarios, the number of terminal devices is enormous, and upgrades may be triggered simultaneously. A large number of terminals simultaneously requesting firmware downloads from the central server will instantly generate massive network traffic, easily causing network congestion and posing a severe challenge to the central server's processing capacity and I / O bandwidth, creating a performance bottleneck. Easy interruption of the upgrade process in mobile scenarios: In environments such as chemical plants and logistics parks, the positioning terminals or mobile devices worn by workers frequently move within the coverage areas of different communication base stations. In centralized solutions, once a terminal moves to a new base station coverage area during firmware download, its connection session with the central server may be interrupted. After the terminal accesses the new network, it often needs to re-initiate a connection with the central server and start downloading from scratch. This not only results in low upgrade efficiency but also wastes network resources due to repeated transmission of downloaded data, and is more prone to overall upgrade failure due to connection instability. Lack of effective local caching and coordination mechanisms: In existing solutions, base stations typically only act as transparent communication relays and lack the ability to cache and distribute firmware data. All firmware data for each terminal must be obtained from the central server across the entire network, making it impossible to utilize the computing and storage resources at the network edge and failing to form a distributed collaborative upgrade capability.

[0005] To address the aforementioned issues, while some existing technologies attempt to incorporate edge caching or fragmented download techniques, they often lack a systematic design for terminal mobility and multi-base station collaborative scenarios. Particularly when terminals roam across base stations, ensuring seamless continuation and efficient completion of firmware download tasks remains a critical technical challenge. Therefore, there is an urgent need for a distributed remote OTA upgrade system and method capable of adapting to large-scale, highly mobile IoT scenarios to overcome the inherent limitations of centralized architectures and achieve efficient, reliable, and network-friendly firmware upgrades. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a firmware upgrade method and a firmware upgrade device to solve the technical problems of centralized OTA upgrade schemes in large-scale, highly mobile IoT scenarios, which result in high network bandwidth and server pressure, easy interruption of the upgrade process and low efficiency when terminals move.

[0007] One aspect of the present invention provides a firmware upgrade method, the method comprising the following steps: The system receives and responds to an upgrade command downloaded over the air from the management platform, sets the current firmware offset to an initial value, and sends a firmware data request to the first base station currently connected. The upgrade command carries the firmware identifier and firmware data volume information of the firmware to be upgraded. The firmware data request carries the firmware identifier and the current firmware offset. The current firmware offset is used to indicate the current location of the data to be downloaded. The system receives firmware data blocks sent by the first base station, and the first base station determines whether to obtain the firmware to be upgraded from the management platform based on whether the firmware to be upgraded is already cached in its local cache. The received firmware data block is written to the corresponding storage area of ​​the local memory, and the current firmware offset is updated based on the size of the firmware data block. If the updated current firmware offset is less than the firmware data volume information, the updated current firmware offset is set to the initial value, and the process jumps to the step of sending firmware data request to continue downloading the firmware data block; until the updated current firmware offset is not less than the firmware data volume information, firmware integrity verification is performed based on all firmware data already written to local storage; and if the verification is successful, a reboot operation is performed to load and run the new firmware.

[0008] One aspect of the present invention provides another firmware upgrade method, the method comprising the following steps: Receive a firmware data request from the terminal, the firmware data request carrying the firmware identifier of the firmware to be upgraded and the current firmware offset; Based on the firmware identifier, query the firmware to be upgraded in the local cache; and send the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset.

[0009] One aspect of the present invention provides another firmware upgrade method, the method comprising the following steps: Identify the target terminal that needs firmware upgrade and generate the corresponding upgrade command; the upgrade command carries the firmware identifier and firmware data volume information of the firmware to be upgraded. The upgrade command, the firmware identifier, and the firmware data volume information are sent to the target terminal. Receive a data acquisition request from a base station, the data acquisition request carrying the firmware identifier; Based on the firmware identifier, the corresponding firmware to be upgraded is retrieved from the firmware repository and returned to the base station. Another aspect of the present invention provides a firmware upgrade apparatus, the apparatus comprising: The response module is used to receive and respond to upgrade instructions downloaded over the air from the management platform, set the current firmware offset to an initial value, and send a firmware data request to the first base station currently connected. The upgrade instruction carries the firmware identifier and firmware data volume information of the firmware to be upgraded. The firmware data request carries the firmware identifier and the current firmware offset. The current firmware offset is used to indicate the current location of the data to be downloaded. The second receiving module is used to receive firmware data blocks sent by the first base station. The firmware data blocks are obtained by the first base station from the management platform based on whether the firmware to be upgraded is already cached in its local cache. An update module is used to write the received firmware data block into the corresponding storage area of ​​the local memory, and update the current firmware offset based on the size of the firmware data block; The verification module is used to set the updated current firmware offset to an initial value and jump to the step of sending firmware data request to continue downloading the firmware data block if the updated current firmware offset is less than the firmware data volume information; until the updated current firmware offset is not less than the firmware data volume information, perform firmware integrity verification based on all firmware data written to local storage; and if the verification is successful, perform a restart operation to load and run the new firmware.

[0010] Another aspect of the present invention provides a different firmware upgrade device, characterized in that the device comprises: The third receiving module is used to receive a firmware data request from the terminal, wherein the firmware data request carries the firmware identifier of the firmware to be upgraded and the current firmware offset. The query module is used to query the firmware to be upgraded in the local cache based on the firmware identifier; and to send the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset.

[0011] Another aspect of the present invention provides a different firmware upgrade device, characterized in that the device comprises: The determination module is used to determine the target terminal that needs to be upgraded and generate the corresponding upgrade instruction; the upgrade instruction carries the firmware identifier and firmware data volume information of the firmware to be upgraded. The distribution module is used to distribute the upgrade command, the firmware identifier, and the firmware data volume information to the target terminal. The fourth receiving module is used to receive a data acquisition request from the base station, wherein the data acquisition request carries the firmware identifier; The retrieval module is used to retrieve and return the corresponding firmware to be upgraded to the base station from the firmware repository based on the firmware identifier.

[0012] Another aspect of the present invention provides an electronic device, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the firmware upgrade method described in any one of the above descriptions.

[0013] Another aspect of the present invention provides a computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the firmware upgrade method described in any one of the preceding descriptions.

[0014] This invention provides a firmware upgrade method and apparatus. The terminal receives an upgrade command from a management platform, containing a firmware identifier and firmware data volume information. Based on this command, the terminal initializes the firmware offset, used to indicate the data location, to a starting value and sends a firmware data request carrying the firmware identifier and the current offset to the first currently accessed base station. After receiving the corresponding firmware data block returned by the base station based on its local cache state, the terminal writes it to its local memory and updates the offset. Then, it enters a loop: if the updated offset is less than the total firmware data volume, it continues to initiate requests based on the new offset to download the firmware in a loop; until the offset is not less than the total data volume, it performs an integrity check on all written firmware data. If the check is successful, the terminal restarts to run the new firmware. This method systematically solves the problems of central bandwidth bottlenecks and server pressure caused by massive concurrent downloads from terminals in centralized OTA upgrades, as well as the inefficiency and failure rate caused by interrupted upgrade connections due to terminal movement, requiring repeated downloads. By constructing a complete technical closed loop of "block request, offset tracking, cache proxy, loop until completion", orderly, continuous and reliable firmware upgrades for large-scale terminals in mobile scenarios are achieved, significantly improving upgrade efficiency, success rate and overall system resource utilization. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating a firmware upgrade method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating another firmware upgrade method provided according to an exemplary embodiment; Figure 3 This is a flowchart illustrating another firmware upgrade method provided according to an exemplary embodiment; Figure 4 This is a schematic diagram of a firmware upgrade device according to an exemplary embodiment; Figure 5 This is a schematic diagram of another firmware upgrade device provided according to an exemplary embodiment; Figure 6 This is a schematic diagram of another firmware upgrade device provided according to an exemplary embodiment. Detailed Implementation

[0017] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0018] It should be noted that the terms "first," "second," etc., in the specification and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0019] Figure 1 This is a flowchart illustrating a firmware upgrade method according to an exemplary embodiment. This specification provides method operation steps as shown in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 1 As shown, taking the terminal in the firmware upgrade system as the execution subject, an embodiment of a firmware upgrade method according to this application is introduced. The method may include: S101: Response module, used to receive and respond to upgrade instructions downloaded over the air from the management platform, set the current firmware offset to the initial value, and send a firmware data request to the first base station currently connected.

[0020] In one specific embodiment, the upgrade command carries the firmware identifier and firmware data volume information of the firmware to be upgraded; the firmware data request carries the firmware identifier and the current firmware offset; the current firmware offset is used to indicate the current location of the data to be downloaded; specifically, this step is the triggering and initialization stage of the terminal initiating the upgrade process. Specifically, the upgrade command downloaded over-the-air (OTA) by the management platform refers to a remote control command sent by the system's control center (i.e., the management platform) to the target terminal via wireless communication (such as cellular network, Wi-Fi, or proprietary IoT protocols). This command is not the firmware data itself, but a control message used to initiate the upgrade task; the firmware identifier is a unique code (e.g., hash value, version number, or globally unique ID) used to accurately index the target firmware resource throughout the distributed system; the firmware data volume information clearly informs the terminal of the total amount of complete firmware data to be downloaded (usually in bytes), providing a crucial basis for the terminal to subsequently implement chunked downloading, progress calculation, and download completion determination. By receiving and parsing this command, the terminal can confirm the upgrade target and obtain the two core parameters required to initiate the subsequent chunked request process, thereby starting an orderly and controllable distributed OTA upgrade task.

[0021] Specifically, according to the upgrade instruction, setting the current firmware offset to an initial value means that the terminal establishes a state variable—the current firmware offset—in memory or non-volatile storage to track the download progress and initializes it to a preset starting position value (usually 0). Technically, this offset is a "byte-level pointer" to the firmware data stream, and its value represents the byte position in the firmware file from which data should be downloaded next. Following this, sending a firmware data request to the first base station currently connected indicates that the terminal is not requesting the complete firmware, but rather, based on the current position pointed to by the offset, initiating a precise request for a specific data block from the first base station providing network access services. This firmware data request explicitly carries two key parameters: one is a firmware identifier used to globally identify the target firmware resource, and the other is the current firmware offset used to precisely locate the range of data requested. Through this design, the terminal decomposes the complete firmware download task into a series of sequentially initiated, offset-based micro-data block requests, thus laying the technical foundation for subsequent implementation of breakpoint resume, seamless handover across base stations, and network traffic sharing.

[0022] S103: Receive firmware data blocks sent by the first base station. The firmware data blocks are obtained by the first base station from the management platform based on whether the firmware to be upgraded is already cached in its local cache.

[0023] In one specific embodiment, "receiving firmware data blocks sent by the first base station" indicates that the terminal has obtained the required data segment from the first base station it has connected to. The source path of this data block is not fixed or pre-set, but rather determined in real-time by the base station based on its local resource conditions. The core principle is that "the first base station decides whether to obtain the firmware to be upgraded from the management platform based on whether its local cache already contains the firmware to be upgraded." This means that after receiving a request from the terminal, the base station first checks whether its local storage space already contains firmware (usually a complete firmware version) that matches the request. If the firmware data already exists in the base station's local cache, the base station will directly read it from the cache and send it to the terminal, completely avoiding data interaction with the remote management platform. Conversely, if it is not in the local cache, the base station will act as a proxy for the terminal, initiating a request to the management platform (which is the data source) to obtain the data before forwarding it to the terminal.

[0024] S105: Write the received firmware data block into the corresponding storage area of ​​the local memory, and update the current firmware offset based on the size of the firmware data block.

[0025] In one specific embodiment, the terminal persistently saves the data blocks returned by the base station to local non-volatile memory (such as Flash). The "corresponding storage area" here is a physical storage location pre-allocated or dynamically calculated based on the logical structure of the firmware data, ensuring that each data block can be accurately written to its correct position in the complete firmware image, thereby guaranteeing the integrity and executability of the final assembled firmware image. Next, updating the current firmware offset based on the size of the firmware data block indicates that after completing the data writing, the terminal immediately increments the status pointer used to track progress—the "current firmware offset." The update rule is: add the size of the just-written data block (in bytes) to the original offset value to obtain a new offset value. This update action is crucial; it is equivalent to moving the "data pointer" forward, pointing to the starting position of the next data block to be downloaded, thus providing a precise basis for initiating subsequent data requests.

[0026] S107: If the updated current firmware offset is less than the firmware data volume information, set the updated current firmware offset to the initial value and jump to the step of sending firmware data request to continue downloading firmware data blocks; until the updated current firmware offset is not less than the firmware data volume information, perform firmware integrity verification based on all firmware data written to local storage; and if the verification is successful, perform a reboot operation to load and run the new firmware.

[0027] In a specific embodiment, this is a decision-making process based on conditional judgment and loop control using "firmware offset" and "firmware data volume information." First, if the updated current firmware offset is less than the firmware data volume information, the system compares the updated offset (i.e., the total amount of data already downloaded) with the total firmware size. If the former is less than the latter, it means the firmware has not yet been completely downloaded. At this point, the terminal does not start from the beginning but sets the updated current firmware offset to an initial value. This "initial value" should be understood as the starting offset (i.e., the new starting point) for data requests in the next loop. Further, it jumps to the step of sending firmware data requests, and based on this new offset, it again initiates a request for the next data block from the base station, forming a "request-receive-write-update-judgment" loop until the firmware data is downloaded block by block.

[0028] When the condition changes to the updated current firmware offset being no less than the firmware data size, it indicates that the cumulative downloaded data size has reached or exceeded the total firmware size, meaning the download phase is complete. At this point, the process exits the loop and enters the final stage: based on all firmware data written to local storage, a firmware integrity check is performed. This verifies the entire assembled firmware image (e.g., calculating and comparing hash values) to ensure that no errors or tampering occurred during transmission and storage. If the check is successful, a reboot operation is performed to load and run the new firmware. That is, after the terminal passes the verification, it executes the reboot process, loads and starts the new firmware from the corresponding location in storage, thus completing the entire OTA upgrade.

[0029] In an optional embodiment, performing firmware integrity verification based on all firmware data already written to local storage includes: Based on all the firmware data already written to the local memory, calculate the check code of the written firmware data to obtain the firmware check code. The firmware verification code is compared with the baseline verification code. If the comparison is successful, the verification is successful. The baseline verification code is obtained from the upgrade command, the first base station, or the management platform.

[0030] In one specific embodiment, "based on all firmware data already written to local storage, a checksum of the written firmware data is calculated to obtain the firmware checksum." This means that after all firmware data blocks have been written to the terminal's local storage, the terminal does not directly reboot. Instead, it performs a cryptographic or mathematical operation (such as calculating a SHA-256 hash value or a CRC32 cyclic redundancy checksum) on the entire firmware image to generate a unique "fingerprint" representing that specific data set, i.e., the firmware checksum. This operation aims to detect whether any unexpected changes (such as bit errors, data corruption, or malicious tampering) have occurred during data transmission or storage.

[0031] Furthermore, the firmware checksum is compared with the baseline checksum; if the comparison is successful, the verification is considered successful. Here, a trusted reference standard—the "baseline checksum"—is introduced. This baseline checksum is pre-calculated and securely stored by the firmware publisher (usually the management platform) during firmware generation. The terminal rigorously compares its calculated firmware checksum with this authoritative baseline checksum. If they match perfectly, it proves that the downloaded firmware data is complete, undamaged, and fully matches the expected version; that is, "verification successful." If they do not match, it indicates that the firmware data may be corrupted or incomplete, the upgrade process will be aborted, and an error recovery mechanism may be triggered.

[0032] Specifically, "the baseline checksum is obtained from the upgrade command, the first base station, or the management platform," which reflects the flexibility and robustness of obtaining the checksum. The baseline checksum can be directly sent to the terminal with the upgrade command, provided by a cached base station (obtained and cached along with the firmware from the management platform), or returned in real time by the management platform when requested by the terminal. This multi-source acquisition mechanism enhances adaptability to changes in network status and system architecture, ensuring the reliability of the verification process.

[0033] In the above embodiments, the terminal calculates a checksum (such as a hash value) on all downloaded data and compares it with a baseline checksum obtained from a reliable source (command, base station, or platform). This effectively verifies that the firmware data has not been corrupted or tampered with during transmission and storage before rebooting. This provides crucial security for the system, preventing device startup failure or malfunction due to data errors.

[0034] In an optional embodiment, the above method further includes: When moving from the coverage area of ​​the first base station to the coverage area of ​​the second base station, a resume request is sent to the second base station. The resume request includes the firmware identifier and the current firmware offset maintained by the terminal at the time of the migration.

[0035] In a specific embodiment, the application scenario is "when moving from the coverage area of ​​the first base station to the coverage area of ​​the second base station," that is, during the firmware download process, the network access point changes due to the movement of the user or carrier, moving from the wireless signal coverage area of ​​the first base station (the original serving base station) to the coverage area of ​​the second base station (the new serving base station). In this case, traditional centralized upgrade connections are often interrupted and require restarting, while this method actively achieves task continuity by "sending a resume request to the second base station." This "resume request" is not a new upgrade instruction, but a continuation request for the original upgrade task. Its core lies in the two key parameters carried in the request: one is the "firmware identifier" used to uniquely identify the upgrade target, ensuring that the new base station can accurately identify which firmware upgrade the terminal is performing; the other is the "current firmware offset maintained by the terminal at the time of migration," which accurately records the amount of data that the terminal has successfully downloaded and written to memory at the last moment before switching base stations, i.e., the real-time progress of the upgrade task. By submitting this offset to the new base station, the terminal is essentially telling the new base station: "Please continue providing subsequent data blocks of the same firmware, starting from the next byte of my completed progress." This mechanism enables firmware download tasks to be performed seamlessly and continuously across different network access points, completely solving the problems of upgrade interruption and inefficiency caused by terminal mobility. It is an important technical guarantee for realizing distributed, mobile-friendly OTA upgrades.

[0036] In the above embodiments, the "identifier + real-time offset" continuation mechanism enables the new base station to accurately locate and continue providing subsequent data blocks of the same firmware when the terminal moves and switches base stations. This completely solves the problems of download interruption and repeated downloads caused by handover in traditional solutions, ensuring the seamless continuity of the upgrade task during cross-base station roaming and significantly improving the upgrade efficiency and success rate in mobile scenarios.

[0037] In an optional embodiment, the above method further includes: If the upgrade process is interrupted due to an unexpected event, the system determines whether the current upgrade process can continue based on the recovery conditions, obtains the upgrade judgment result, and acquires the breakpoint location. If the upgrade determination result indicates that the upgrade can continue, the last valid firmware offset stored locally is read, and the firmware data request is re-initiated based on the last valid firmware offset to continue the upgrade from the breakpoint position.

[0038] In one specific embodiment, "in the event of an unexpected interruption during the upgrade process" encompasses unplanned events such as unexpected power outages to the terminal, program crashes, or unexpected network connection drops, which force the upgrade process to abort. In this case, the system does not simply consider the downloaded data invalid and require a restart; instead, it initiates a smart recovery process.

[0039] First, the system "determines whether the current upgrade process can continue based on the recovery conditions, obtains the upgrade judgment result, and acquires the breakpoint location." These "recovery conditions" may include: the terminal being powered on again, the system restarting completely, and the communication link being re-established. The system will assess factors such as the integrity of the storage medium and the state of the firmware data blocks before the interruption to safely determine whether and should the upgrade resume from the interruption point, rather than starting from the beginning. Simultaneously, it needs to accurately locate the "breakpoint location," that is, the last data position successfully processed when the interruption occurred.

[0040] Furthermore, "if the upgrade assessment indicates that the upgrade can continue, the last valid firmware offset stored locally is read, and a firmware data request is re-initiated based on the last valid firmware offset." This is the core operation of the recovery mechanism. The terminal reads and restores the "last valid firmware offset" that was safely saved before the interruption from its non-volatile memory. This offset represents the position after the last data block that was completely and correctly written to memory before the interruption, i.e., the starting point of data that has not yet been downloaded or written. Then, the terminal uses this offset as the new request starting point to re-initiate a firmware data request to the currently accessed base station. This means that the download request will start from the breakpoint without repeating the request and writing of the part that was successfully completed before the interruption.

[0041] In the above embodiments, the mechanism "continues the upgrade from the breakpoint" effectively avoids the waste of downloaded data and the repeated consumption of network bandwidth caused by unexpected interruptions, greatly improving the reliability and efficiency of the upgrade process, and is especially suitable for industrial environments where network conditions are unstable or equipment may shut down unexpectedly.

[0042] Figure 2 This is a flowchart illustrating a firmware upgrade method according to an exemplary embodiment, specifically as follows: Figure 2 As shown, taking the base station in the firmware upgrade system as the execution subject, an embodiment of a firmware upgrade method according to this application is introduced. The method may include: S201: Receive a firmware data request from the terminal. The firmware data request carries the firmware identifier of the firmware to be upgraded and the current firmware offset. S203: Based on the firmware identifier, query the firmware to be upgraded in the local cache; and send the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset.

[0043] In one specific embodiment, firstly, a firmware data request is received from the terminal. This "firmware data request" carries a "firmware identifier" that uniquely identifies the target firmware, used to accurately locate resources when the base station may cache multiple different firmwares. Simultaneously, it also carries a "current firmware offset," which explicitly indicates the precise starting byte position of the data the terminal needs to acquire in the target firmware file, thus breaking down a complete firmware request into a precise request for a specific data segment.

[0044] Subsequently, the base station executes the command "Query the firmware to be upgraded in the local cache based on the firmware identifier". The base station uses the received firmware identifier as an index to search its local storage space to confirm whether the requested firmware has been cached.

[0045] After confirming that the firmware has been cached, the base station executes the action of "sending the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset". This operation involves two precise steps: First, the base station locates the corresponding starting position from its cached firmware data based on the position parameter of "current firmware offset"; second, the base station reads a continuous data block of a preset size (or a reasonable size determined according to the context) from the starting position, i.e., the "firmware data block", and then sends it to the requesting terminal through the network.

[0046] In an optional embodiment, the above-mentioned querying the firmware to be upgraded in the local cache based on the firmware identifier and sending the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset includes: If the firmware to be upgraded corresponding to the firmware identifier is found in the local cache, the firmware data block of a preset data size is read based on the current firmware offset, and the firmware data block is sent to the terminal. If the firmware to be upgraded corresponding to the firmware identifier is not found in the local cache, a data acquisition request is sent to the management platform based on the firmware identifier. The system receives the firmware to be upgraded from the management platform, stores the firmware to be upgraded in the local cache, and reads the firmware data block of the preset data size based on the current firmware offset, and sends the firmware data block to the terminal.

[0047] In one specific embodiment, this step details the complete decision-making and service chain of the base station responding to the terminal's data request, demonstrating its core logic as a distributed intelligent caching node. This logic is divided into two execution branches based on whether the requested complete firmware (not just data blocks) is cached: First branch: Cache hit (complete firmware already cached). When "the firmware to be upgraded corresponding to the firmware identifier is found in the local cache," it indicates that the base station has fully or partially cached the target firmware. At this time, the base station "reads a firmware data block of a preset data size based on the current firmware offset." That is, the base station uses the offset provided by the terminal as a precise pointer to extract a continuous byte sequence starting from the offset and with a length of "preset data size" (e.g., 4KB) from its cached complete firmware data. Subsequently, "the firmware data block is sent to the terminal," achieving a fast local response to the data.

[0048] The second branch: Cache miss (complete firmware not cached). When the base station cannot find the firmware to be upgraded corresponding to the firmware identifier in the local cache, it will not allow the request to fail. It first sends a data retrieval request to the management platform based on the firmware identifier, pulling the entire target firmware from an authoritative data source. After receiving the firmware to be upgraded from the management platform, the base station performs a crucial operation: storing the firmware to be upgraded in the local cache. This completes the "filling" or "warming up" of the local cache, making the firmware available for future requests. Finally, similar to the first branch, the base station reads a firmware data block of a preset size based on the current firmware offset and sends the firmware data block to the terminal, ensuring that the terminal's request is satisfied.

[0049] In the above embodiments, the pressure of firmware data requests from massive terminals is distributed from the central management platform to various base stations at the network edge through a dual path of "cache hit - direct response" and "miss - platform acquisition - cache backup". This effectively avoids the central bandwidth bottleneck, and at the same time, reduces duplicate transmissions through cache reuse, significantly improving the overall data distribution efficiency and network resource utilization of the system.

[0050] Figure 3 This is a flowchart illustrating a firmware upgrade method according to an exemplary embodiment, specifically as follows: Figure 3 As shown, taking the management platform in the firmware upgrade system as the execution entity, an embodiment of a firmware upgrade method according to this application is introduced. The method may include: S301: Determine the target terminal that needs firmware upgrade and generate the corresponding upgrade command; the upgrade command carries the firmware identifier and firmware data volume information of the firmware to be upgraded. S303: Sends the upgrade command, firmware identifier, and firmware data volume information to the target terminal; S305: Receives a data acquisition request from the base station, the data acquisition request carrying a firmware identifier; S307: Based on the firmware identifier, retrieve and return the corresponding firmware to be upgraded to the base station from the firmware repository.

[0051] In one specific embodiment, the system "determines the target terminal that needs firmware upgrade and generates a corresponding upgrade command." This indicates that the management platform is the initiator and decision-maker of the upgrade task. It may identify a group or a single terminal, i.e., the "target terminal," based on preset strategies (such as by batch, by region, or by device model), manual operation, or external events (such as new firmware releases or security vulnerability patching requirements). Furthermore, the platform generates a dedicated "upgrade command" for these terminals. This command is not the firmware data itself, but a control command designed to notify and instruct the target terminal to initiate the upgrade process. The command precisely carries two key metadata elements: a "firmware identifier" to uniquely identify the firmware version to be upgraded and "firmware data volume information" to inform the terminal of the full size of the firmware.

[0052] Furthermore, the upgrade command, firmware identifier, and firmware data volume information are sent to the target terminal. This completes the distribution of the upgrade task. The management platform accurately pushes the generated upgrade command and its contained information to each identified target terminal via the wireless network, thereby initiating the upgrade task at the edge node (terminal) of the distributed network.

[0053] Furthermore, the management platform's role shifts from task initiator to data service provider. It "receives data acquisition requests from base stations." These requests originate from the base stations and occur when their local cache misses and they need to retrieve data from authoritative data sources to serve the terminals. The data acquisition requests carry a "firmware identifier," enabling the management platform to accurately understand which firmware the base station (actually representing the terminal) needs to acquire.

[0054] Furthermore, the management platform "retrieves and returns the corresponding firmware to be upgraded to the base station from the firmware repository based on the firmware identifier." The platform uses the received identifier to locate the target firmware file in its own "firmware repository" (such as a database or file system) and returns it to the requesting base station via the network. This step ensures the authority, consistency, and reliability of the firmware data source throughout the distributed system.

[0055] This invention provides a firmware upgrade method and apparatus. The core of this method lies in its three-layer collaborative architecture: centralized management by a management platform, distributed caching and proxying by base stations, and on-demand requests from terminals. This architecture systematically solves the network bottleneck and mobility interruption problems encountered during large-scale mobile IoT terminals' over-the-air (OTA) firmware downloads. The management platform, acting as both control and data source, is responsible for formulating upgrade strategies, issuing upgrade instructions containing firmware identifiers and total size, and responding to on-demand data requests from base stations. Based on the instructions, the terminal initializes a firmware offset pointing to the starting position of the data to be downloaded and cyclically sends data requests carrying this offset to the base stations it is connected to. The base station, acting as an intelligent edge node, upon receiving a request, first checks its local cache. If a match is found, it responds directly; otherwise, it retrieves and caches the data from the management platform before responding, thus distributing the data source pressure from the center to the network edge. This method systematically solves the two core contradictions of traditional centralized OTA solutions: network bandwidth and server performance bottlenecks caused by massive numbers of terminals simultaneously downloading firmware from a central server, and low efficiency and high failure rates caused by interrupted upgrade connections and repeated downloads when terminals move between base stations. By constructing a complete technical closed loop of "platform command triggering - terminal block offset request - base station cache proxy response - seamless terminal mobile switching", it has achieved efficient, reliable, and mobile-enabled seamless upgrades of large-scale terminals without the need for massive central bandwidth support. This significantly improves the operation and maintenance efficiency, upgrade success rate, and network resource utilization of IoT systems, and has outstanding industrial practical value and economic benefits.

[0056] Figure 4 This is a schematic diagram of a firmware upgrade device according to an exemplary embodiment. The following describes an embodiment of a firmware upgrade device according to this application, specifically, as follows... Figure 4 As shown, the device includes: The response module 401 is used to receive and respond to the upgrade command downloaded over the air from the management platform, set the current firmware offset to an initial value, and send a firmware data request to the first base station currently connected; the upgrade command carries the firmware identifier and firmware data volume information of the firmware to be upgraded; the firmware data request carries the firmware identifier and the current firmware offset; the current firmware offset is used to indicate the current location of the data to be downloaded; The second receiving module 403 is used to receive firmware data blocks sent by the first base station. The firmware data blocks are obtained by the first base station from the management platform based on whether the firmware to be upgraded is already cached in its local cache. The update module 405 is used to write the received firmware data block into the corresponding storage area of ​​the local memory, and update the current firmware offset based on the size of the firmware data block; The verification module 407 is used to set the updated current firmware offset to an initial value and jump to the step of sending firmware data request to continue downloading the firmware data block if the updated current firmware offset is less than the firmware data volume information; until the updated current firmware offset is not less than the firmware data volume information, perform firmware integrity verification based on all firmware data written to local storage; and if the verification is successful, perform a restart operation to load and run the new firmware.

[0057] Figure 5 This is a schematic diagram of another firmware upgrade device provided according to an exemplary embodiment. The following describes an embodiment of a firmware upgrade device according to this application, specifically, as follows... Figure 5 As shown, the device includes: The third receiving module 501 is used to receive a firmware data request from the terminal, wherein the firmware data request carries the firmware identifier of the firmware to be upgraded and the current firmware offset. The query module 503 is used to query the firmware to be upgraded in the local cache according to the firmware identifier; and send the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset.

[0058] Figure 6 This is a schematic diagram of another firmware upgrade device provided according to an exemplary embodiment. The following describes an embodiment of a firmware upgrade device according to this application, specifically, as follows... Figure 6 As shown, the device includes: The determination module 601 is used to determine the target terminal that needs to be upgraded and generate a corresponding upgrade instruction; the upgrade instruction carries the firmware identifier and firmware data volume information of the firmware to be upgraded. The sending module 603 is used to send the upgrade instruction, the firmware identifier, and the firmware data volume information to the target terminal; The fourth receiving module 605 is used to receive a data acquisition request from the base station, wherein the data acquisition request carries the firmware identifier; The retrieval module 607 is used to retrieve and return the corresponding firmware to be upgraded to the base station from the firmware repository based on the firmware identifier.

[0059] In an exemplary embodiment, an electronic device is also provided, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement a firmware upgrade method as described in the embodiments of this disclosure.

[0060] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein when the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the firmware upgrade method of the present disclosure embodiments.

[0061] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the firmware upgrade method provided in the various optional implementations described above.

[0062] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0063] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the foregoing claims.

[0064] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims. The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A firmware upgrade method, applied to a base station, the method comprising: Receive and respond to upgrade instructions downloaded over the air from the management platform, set the current firmware offset to the initial value, and send a firmware data request to the first base station currently connected. The upgrade command carries the firmware identifier and firmware data volume information of the firmware to be upgraded; The firmware data request carries the firmware identifier and the current firmware offset; The current firmware offset is used to indicate the current location of the data to be downloaded; The system receives firmware data blocks sent by the first base station, and the first base station determines whether to obtain the firmware to be upgraded from the management platform based on whether the firmware to be upgraded is already cached in its local cache. The received firmware data block is written to the corresponding storage area of ​​the local memory, and the current firmware offset is updated based on the size of the firmware data block. If the updated current firmware offset is less than the firmware data volume information, the updated current firmware offset is set to the initial value, and the process jumps to the step of sending firmware data request to continue downloading the firmware data block. Until the updated current firmware offset is not less than the firmware data amount information, a firmware integrity check is performed based on all firmware data already written to the local storage. If the verification is successful, a reboot will be performed to load and run the new firmware.

2. The method according to claim 1, characterized in that, The method further includes: When moving from the coverage area of ​​the first base station to the coverage area of ​​the second base station, a resume request is sent to the second base station. The resume request includes the firmware identifier and the current firmware offset maintained by the terminal at the time of the migration.

3. The method according to claim 1, characterized in that, The firmware integrity verification based on all firmware data already written to local storage includes: Based on all the firmware data already written to the local memory, calculate the check code of the written firmware data to obtain the firmware check code. The firmware verification code is compared with the baseline verification code. If the comparison is successful, the verification is successful. The baseline verification code is obtained from the upgrade command, the first base station, or the management platform.

4. The method according to claim 1, characterized in that, The method further includes: If the upgrade process is interrupted due to an unexpected event, the system determines whether the current upgrade process can continue based on the recovery conditions, obtains the upgrade judgment result, and acquires the breakpoint location. If the upgrade determination result indicates that the upgrade can continue, the last valid firmware offset stored locally is read, and the firmware data request is re-initiated based on the last valid firmware offset to continue the upgrade from the breakpoint position.

5. A firmware upgrade method, characterized in that, Includes the following steps: Receive a firmware data request from the terminal, the firmware data request carrying the firmware identifier of the firmware to be upgraded and the current firmware offset; Based on the firmware identifier, query the firmware to be upgraded in the local cache; and send the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset.

6. The method according to claim 5, characterized in that, The step of querying the firmware to be upgraded in the local cache based on the firmware identifier and sending the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset includes: If the firmware to be upgraded corresponding to the firmware identifier is found in the local cache, the firmware data block of a preset data size is read based on the current firmware offset, and the firmware data block is sent to the terminal. If the firmware to be upgraded corresponding to the firmware identifier is not found in the local cache, a data acquisition request is sent to the management platform based on the firmware identifier. The system receives the firmware to be upgraded from the management platform, stores the firmware to be upgraded in the local cache, and reads the firmware data block of the preset data size based on the current firmware offset, and sends the firmware data block to the terminal.

7. A firmware upgrade method, characterized in that, Includes the following steps: Identify the target terminal that needs firmware upgrade and generate the corresponding upgrade command; The upgrade command carries the firmware identifier and firmware data volume information of the firmware to be upgraded; The upgrade command, the firmware identifier, and the firmware data volume information are sent to the target terminal. Receive a data acquisition request from a base station, the data acquisition request carrying the firmware identifier; Based on the firmware identifier, the corresponding firmware to be upgraded is retrieved from the firmware repository and returned to the base station.

8. A firmware upgrade device, characterized in that, The device includes: The response module is used to receive and respond to upgrade instructions downloaded over the air from the management platform, set the current firmware offset to an initial value, and send a firmware data request to the first base station currently connected. The upgrade instruction carries the firmware identifier and firmware data volume information of the firmware to be upgraded. The firmware data request carries the firmware identifier and the current firmware offset. The current firmware offset is used to indicate the current location of the data to be downloaded. The second receiving module is used to receive firmware data blocks sent by the first base station. The firmware data blocks are obtained by the first base station from the management platform based on whether the firmware to be upgraded is already cached in its local cache. An update module is used to write the received firmware data block into the corresponding storage area of ​​the local memory, and update the current firmware offset based on the size of the firmware data block; The verification module is used to set the updated current firmware offset to an initial value and jump to the step of sending firmware data request to continue downloading the firmware data block if the updated current firmware offset is less than the firmware data volume information; until the updated current firmware offset is not less than the firmware data volume information, perform firmware integrity verification based on all firmware data written to local storage; and if the verification is successful, perform a restart operation to load and run the new firmware.

9. A firmware upgrade device, characterized in that, The device includes: The third receiving module is used to receive a firmware data request from the terminal, wherein the firmware data request carries the firmware identifier of the firmware to be upgraded and the current firmware offset. The query module is used to query the firmware to be upgraded in the local cache based on the firmware identifier; and to send the firmware data block corresponding to the firmware to be upgraded to the terminal based on the current firmware offset.

10. A firmware upgrade device, characterized in that, The device includes: The determination module is used to determine the target terminal that needs to be upgraded and generate the corresponding upgrade instruction; the upgrade instruction carries the firmware identifier and firmware data volume information of the firmware to be upgraded. The distribution module is used to distribute the upgrade command, the firmware identifier, and the firmware data volume information to the target terminal. The fourth receiving module is used to receive a data acquisition request from the base station, wherein the data acquisition request carries the firmware identifier; The retrieval module is used to retrieve and return the corresponding firmware to be upgraded to the base station from the firmware repository based on the firmware identifier.

Images