WO2021083244A1 - 一种mesh网络设备的多设备批量固件升级的方法 - Google Patents

一种mesh网络设备的多设备批量固件升级的方法 Download PDF

Info

Publication number
WO2021083244A1
WO2021083244A1 PCT/CN2020/124558 CN2020124558W WO2021083244A1 WO 2021083244 A1 WO2021083244 A1 WO 2021083244A1 CN 2020124558 W CN2020124558 W CN 2020124558W WO 2021083244 A1 WO2021083244 A1 WO 2021083244A1
Authority
WO
WIPO (PCT)
Prior art keywords
firmware
node device
upgrade
target node
root node
Prior art date
Application number
PCT/CN2020/124558
Other languages
English (en)
French (fr)
Inventor
詹昭城
李清桥
Original Assignee
乐鑫信息科技（上海）股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 乐鑫信息科技（上海）股份有限公司 filed Critical 乐鑫信息科技（上海）股份有限公司
Publication of WO2021083244A1 publication Critical patent/WO2021083244A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements

Definitions

  • the invention relates to the technical field of wireless mesh networks, in particular to a method for multi-device batch firmware upgrade of mesh network devices.
  • mesh network devices usually use individual devices to upgrade one by one, and the firmware needs to be transferred from the host to the device to be upgraded at a time.
  • this upgrade method once a packet of data is lost during transmission, all data needs to be retransmitted, resulting in slow upgrade speed and low upgrade success rate.
  • this upgrade method does not have a complete firmware checking mechanism.
  • There are usually many different types of devices in the mesh network so it is easy to cause the upgraded firmware and the device to mismatch, which affects the normal operation of the device.
  • Chinese invention patent CN108347346A (a method for upgrading equipment in a mesh network) discloses a method for upgrading the firmware of mesh equipment using a network.
  • the device to be upgraded receives the upgrade command, it requests the new firmware content from its parent node instead of directly from the root node. If the parent node has saved the new firmware, it is directly sent to the device to be upgraded, thereby avoiding the transmission of the new firmware from the host through the root node and saving network traffic. If the parent node does not have the new firmware, the sibling node under the same parent node will be firstly inquired whether there is new firmware.
  • PCT patent WO2015167321A1 discloses a method, which includes 3 main steps. First find out all the devices that need to be upgraded from the network, and then reorganize these devices into a tree network according to various parameters (such as network signal strength), and finally start from the root node of the new tree network and push the firmware from top to bottom. , Until all the equipment is upgraded.
  • This upgrade method requires the network to be reorganized before the upgrade, so it will have an impact on the equipment in the normal working state. In addition, this upgrade method still cannot solve the problem that the firmware needs to be transferred as a whole in the case of a transfer failure.
  • the purpose of the present invention is to provide a method for multi-device batch firmware upgrade of mesh network devices, which mainly solves the above-mentioned problems in the prior art: reducing the size of firmware transmission data, and when the firmware is transmitted in a wireless network, packet loss occurs. At this time, there is no need to retransmit, which solves the problem that the new firmware and the device do not match which cause the upgrade to fail and make the device work incorrectly.
  • the present invention provides a method for multi-device batch firmware upgrade of mesh network devices, which is used to initiate and complete the firmware upgrade of the mesh network devices from a host to multiple mesh network devices in the same network at the same time. , which is characterized in that it includes the following steps:
  • Step 1 The host generates the firmware and compresses the firmware to form a firmware compression package
  • Step 2 The host transmits the firmware compressed package to the root node device of the current mesh network; the root node device decompresses the firmware compressed package, and verifies whether the firmware is correct, if the verification fails, the upgrade fails , Exit the upgrade process;
  • Step 3 The host transmits a list of devices to be upgraded to the root node device; the list of devices to be upgraded includes all target node devices;
  • Step 4 The root node device checks the correctness of the received list of devices to be upgraded, if there is an error, the upgrade fails, and the upgrade process exits;
  • Step 5 The root node device sends an upgrade status request to all the target node devices;
  • Step 6 After receiving the upgrade status request, the target node device erases the existing firmware in the flash partition of the device, and returns a packet loss condition to the root node device;
  • Step 7 The root node device distributes the firmware to the target node device according to the received packet loss; specifically including:
  • Step 7.1 The root node prepares the firmware into a transmission data packet according to the received packet loss; the transmission data packet contains the data compressed content of the firmware; and the root node
  • the device is the parent node device;
  • Step 7.2 The parent node device distributes the transmission data packet to the intermediate transmission node device or the target node device;
  • Step 7.3 The intermediate transmission node device or the target node device receives the transmission data packet
  • Step 7.4 If the current device is the intermediate transmission node device, then take the current node as the new parent node device and skip to step 7.2 to continue; if the current device is the target node device, skip to step 8;
  • Step 8 The target node device receives the transmission data packet, decompresses it and restores it to the firmware, and writes the firmware into the flash partition;
  • Step 9 The target node device marks the flash boot partition that runs after the next restart as the newly upgraded firmware partition
  • Step 10 The target node device sends upgrade completion information to the root node device
  • Step 11 After receiving the upgrade completion information sent by all the target node devices, the root node device sends a restart command to all the target node devices;
  • Step 12 The target node device restarts after receiving the restart command
  • Step 13 After the startup is completed, the target node device reports the version information of its current device to the host;
  • Step 14 The host verifies the version information sent by each target node device, confirms whether the target node device is successfully upgraded, and completes the upgrade of the target node device.
  • the root node device distributing the firmware to the target node device through its direct node device, it supports resumable transmission; the details are as follows:
  • Step 6 is broken down into:
  • Step 6.1 After receiving the upgrade status request, the target node device determines whether the device has an upgrade breakpoint; if there is no upgrade breakpoint, or there is an upgrade breakpoint but the firmware will be upgraded The version of is inconsistent with the firmware version marked by the upgrade breakpoint, and the existing firmware in the flash partition of the device is erased;
  • Step 6.2 The target node device returns the lost packet to the root node device according to the information about whether the upgrade breakpoint exists, and if the upgrade breakpoint exists, the information contained in the upgrade breakpoint happening;
  • step 7 step 7.1 is decomposed into:
  • Step 7.1.1 the root node device determines the firmware content to be transferred according to the received packet loss; the firmware content to be transferred is part or all of the firmware;
  • Step 7.1.2 the root node device divides the firmware to be transmitted into fixed sizes, then compresses them into the transmission data packet, and performs serial number identification on the transmission data packet;
  • Step 8 is broken down into:
  • Step 8.1a The target node device receives the transmission data packet, decompresses it, and writes it into the flash partition;
  • Step 8.2a The target node device records the serial number and upgrade status of the transmission data packet, and writes them into the flash partition to form the upgrade breakpoint in step 6.1;
  • Step 8.3a After the target node device has received all the transmission data packets, splicing to form a complete firmware.
  • step 8.2a' is inserted between step 8.2a and step 8.3a:
  • Step 8.2a' the target node device records the currently saved but unreported transmission data packet size; when the currently saved but unreported transmission data packet size reaches a specific proportion of the firmware size, the target The node device reports the status to the parent node device, and clears the size of the transmission data packet that has been saved but not reported.
  • the specific ratio is 10%.
  • the root node device, the target node device, and the transmission intermediate device write all the contents of the firmware to the flash partition, they will actively verify the firmware, which specifically includes:
  • Step 1.1 The host generates the firmware, and the firmware includes a series of fixed-length firmware identifiers; the firmware identifier is composed of a device type and a version number;
  • Step 1.2 The host compresses the generated firmware to form the firmware compressed package
  • Step 2.1 The host transmits the firmware compressed package to the root node device of the current mesh network
  • Step 2.2 The root node device receives the firmware compressed package
  • Step 2.3 The root node device decompresses the firmware compression package, and writes the firmware into the flash partition;
  • Step 2.4 Check the correctness of the firmware identification through the firmware verification algorithm; if there is an error, return an error to the host;
  • Step 8 is broken down into:
  • Step 8.1b The target node device receives the transmission data packet and decompresses it into the firmware
  • Step 8.2b Check the correctness of the firmware identification through the firmware verification algorithm; if there is an error, return an error to the parent node device and request a retransmission.
  • firmware check algorithm is a CRC check algorithm; the length of the firmware identifier is 128 bytes.
  • step 9 is decomposed into:
  • Step 9.1 The target node device marks the flash startup partition that runs after the next restart as the newly upgraded firmware partition
  • Step 9.2 The target node device clears the number of abnormal restarts to zero;
  • the step 12 is decomposed into:
  • Step 12.1 The target node device restarts after receiving the restart command
  • Step 12.2 the target node device detects its own state; if the state is abnormal, the target node device reads the recorded number of abnormal restarts; if the number of abnormal restarts reaches a preset value, The target node device indicates that the flash boot partition that runs after the next restart is a non-upgraded firmware partition; if the number of abnormal restarts does not reach the preset value, the target node device indicates that the number of abnormal restarts is incremented by one; When the device status of the target node is abnormal, it actively restarts.
  • the host is a server, a mobile terminal or a PC device.
  • connection modes of the host and the root node device are serial port, I2C, SPI, network cable, Wi-Fi and Bluetooth.
  • the compression coding used is differential coding, run-length coding or Huffman coding.
  • the present invention has the following advantages:
  • the firmware Before the firmware is transferred, the firmware is compressed, thereby reducing the consumption of network and storage resources during the firmware transfer process.
  • the firmware is pushed from top to bottom, which avoids direct communication between each device to be upgraded and the host, which improves the speed of batch upgrades.
  • firmware type checking and version rollback mechanism to prevent the firmware and the device to be upgraded from mismatching and causing abnormal device upgrades.
  • the firmware type check is checked before the upgrade, and the version rollback can handle the firmware upgrade abnormality caused by the abnormality in the upgrade process (such as abnormal power failure).
  • Figure 1 is a network topology diagram of the method for upgrading a high-efficiency mesh network device of the present invention
  • FIG. 2 is a diagram of the firmware transmission interaction between the host and the root node device of the method for upgrading the efficient mesh network device of the present invention
  • FIG. 3 is a firmware upgrade interaction diagram of a root node device and a target node device of the method for upgrading a high-efficiency mesh network device of the present invention
  • Fig. 4 is a flowchart of the target node deployment and upgrade firmware of the method for upgrading a high-efficiency mesh network device of the present invention.
  • the present invention discloses a method for multi-device batch firmware upgrade of mesh network devices, which includes initiating from the host 1, updating the firmware of the target node device 3, and finally confirming the firmware of the target node device 3 by the host 1 Version process.
  • the host 1 is a device such as a PC, a mobile device, or a server, and is used to provide and prepare new firmware that needs to be upgraded, and initiate a firmware upgrade request.
  • the host 1 physically only establishes a connection with the root node device 2 in the mesh network 5 where the target node device 3 is located, and this connection is provided by the host root node device connection 4.
  • the host root node device connection 4 includes serial port, I2C, SPI, network cable, Wi-Fi and Bluetooth.
  • the mesh network device upgrade consists of three stages.
  • the first stage is that the host pushes the upgrade firmware and the list of devices to be upgraded to the root node device of the mesh network.
  • the second stage is that the root node device sends the information to the root node device to be upgraded.
  • the target node pushes the upgraded firmware, and the target node receives and saves the upgraded firmware.
  • the third stage is that the target node completes the deployment of the upgraded firmware by restarting, and officially starts working with the upgraded firmware.
  • the first stage of mesh network upgrade from the host initiation to the end of the root node device sending the upgrade request to the target node, the specific steps include:
  • Step 1.1 The host generates the firmware, and the firmware contains a string of 128-byte firmware identification; the firmware identification contains information such as device type and version number.
  • Step 1.2 The host compresses the generated firmware to generate a compressed firmware package.
  • the compression algorithm used includes differential coding, run-length coding or Huffman coding.
  • Step 2.1 The host transmits the compressed firmware package through the root node device of the mesh network.
  • Step 2.2 The root node device receives the compressed firmware package and decompresses the firmware.
  • Step 2.3 The root node device checks the correctness of the firmware identification in the firmware through the firmware verification algorithm; if there is an error, it returns an error to the host and exits the upgrade.
  • the firmware check algorithm is a CRC check algorithm.
  • Step 3 The host transmits a list of devices to be upgraded to the root node device; the list of devices to be upgraded includes the identities of all target node devices.
  • Step 4 The root node device checks the correctness of the received list of devices to be upgraded. If there is an error, the upgrade fails and the upgrade process exits.
  • Step 5 The root node device sends an upgrade status request to all target node devices in the list of devices to be upgraded.
  • the second stage of mesh network upgrade from the target device to be upgraded receiving the upgrade to the end of the target node preparing to deploy the firmware, the specific steps include:
  • Step 6.1 The target node device receives the upgrade status request from the root node.
  • Step 6.2 The target node device judges whether the device has an upgrade breakpoint; if there is no upgrade breakpoint, go to step 6.5, otherwise go to 6.3.
  • Step 6.3 The target node device judges whether the firmware version to be upgraded is consistent with the firmware version saved by the existing upgrade breakpoint. If it is inconsistent, go to step 6.4, otherwise go to step 6.6.
  • Step 6.4 The target node device erases the upgrade breakpoint information of the device.
  • Step 6.5 The target node device erases the existing firmware in the flash partition of the device.
  • Step 6.6 The target node device prepares the breakpoint information (if any) and packet loss information according to whether there is an upgrade breakpoint information, and the information contained in the upgrade breakpoint when the upgrade breakpoint exists.
  • Step 6.7 The target node device returns the packet loss situation to the root node device.
  • Step 7 The root node device distributes the firmware to the target node device according to the received packet loss; specifically including:
  • Step 7.1.1 the root node device determines the content of the firmware to be transferred according to the received packet loss; according to the difference of the packet loss, the content of the firmware to be transferred is part or all of the firmware.
  • Step 7.1.2 the root node device divides the firmware to be transmitted into fixed sizes, then compresses them into transmission data packets, and performs serial number identification on each transmission data packet. And identify the root node device as the parent node device.
  • Step 7.2 The parent node device distributes the transmission data packet to the intermediate transmission node device or the target node device. If the transferred device is an intermediate transfer node device, then take the transferred node as the new parent node device and skip to step 7.2 to continue; if the transferred device is the target node device, skip to step 8;
  • Step 8.1 The target node device receives the transmission data packet, decompresses the received transmission data packet, and writes it into the flash partition.
  • Step 8.2 The target node device records the serial number and upgrade status of the transmission data packet, and writes it into the flash partition to form the upgrade breakpoint in step 6.2 to record the transmission data packet information that has been correctly received.
  • Step 8.3 The target node device updates the currently saved but unreported transmission data packet size, and judges whether the currently saved but unreported transmission data packet size reaches 10% of the entire firmware size. If reached, go to step 8.4, otherwise skip to step 8.1 to continue to receive subsequent transmission data packets.
  • Step 8.4 The target node device reports the status (including the saved transmission packet size information) through its parent node device, and clears the saved but unreported transmission packet size to zero.
  • Step 8.5 The target node device judges whether all transmission data packets have been received, and if it has not been received, it jumps to step 8.1 to continue receiving subsequent transmission data packets.
  • Step 8.6 The target node device checks the correctness of the firmware identification through the firmware verification algorithm (CRC verification algorithm). If there is an error, return an error to the parent node device, request retransmission, and jump to step 8.1 to wait for the retransmitted transmission data packet; otherwise, go to step 8.7.
  • CRC verification algorithm CRC verification algorithm
  • Step 8.7 The target node device marks the flash partition that will run after the next restart as the newly upgraded firmware partition, resets the number of abnormal restarts to zero, and prepares to start deploying new firmware.
  • the third stage of mesh network upgrade from the target device to be upgraded sending the upgrade completion message to the end of the host checking the version number of the deployed firmware reported by the target device, the specific steps include:
  • Step 9 The target node device sends an upgrade completion message to the root node device, indicating that it has completed the acceptance and burning of the new firmware and is ready for deployment.
  • Step 10 The root node device summarizes the upgrade information from each target node, and judges whether all target nodes are ready for deployment. If all target nodes have completed the deployment preparation, go to step 11, otherwise, go to step 5 to push the firmware to the target nodes that have not completed the deployment preparation.
  • Step 11 The root node device sends a restart command to all target node devices to start deploying new firmware.
  • Step 12.1 The target node device restarts after receiving the restart command
  • Step 12.2 During the startup process, the target node device detects its own state.
  • the target node device If the status is abnormal, the target node device reads the recorded number of abnormal restarts. If the number of abnormal restarts reaches the preset value, the target node device identifies the flash partition that will run after the next restart is the non-upgraded firmware partition. If the number of abnormal restarts does not reach the preset value, the number of abnormal restarts is incremented by one and saved. When the device status of the target node is abnormal, it actively restarts again, and in the process of restarting again, it enters step 12.2 to check its own status.
  • Step 13 When the startup state is normal, after the startup is completed, the target node device reports level by level through the parent node device (including the root node device), and finally informs the host of its own current firmware version information.
  • Step 14 The host verifies whether the firmware version information sent by each target node device is consistent with the version of the firmware generated in step 1.1. If they are consistent, it is confirmed that the target node device is successfully upgraded, otherwise, the target node is confirmed that the upgrade failed. Regardless of success or failure, this firmware upgrade process ends.
  • the mesh network devices in this embodiment all have a partition table to define the flash layout of the mesh network device.
  • the size of the flash is 4M bytes, and all mesh network devices are divided into two types, each having a different partition table type.
  • one is a partition table without factory partitions, and the other is a partition table with factory partitions.
  • the partition table without factory partition contains two partitions related to firmware upgrade, OTA_0 and OTA_1.
  • the partition table with factory partition contains three partitions related to firmware upgrade, OTA_, OTA_1 and factory partition.
  • the partition table itself cannot be upgraded by firmware upgrade. Instead, other methods must be used. First, erase the entire flash and then rewrite the partition table.
  • the OTA_0 and OTA_1 partitions are used jointly to implement the version rollback mechanism for mesh network devices.
  • OTA_0 is the active partition, that is, the target node device completes booting from the OTA_0 partition
  • OTA_1 is the inactive partition.
  • the process of changing the status of OTA_0 and OTA_1 partitions is as follows:
  • Step 1 The firmware upgrade starts, and the target node device recognizes and erases the inactive partition.
  • Step 3 The new firmware will be written to the inactive partition.
  • Step 4 After the firmware is written, the verification starts.
  • Step 5 The firmware upgrade is successful, the inactive partition has been updated, and it indicates that the inactive partition is now the active partition.
  • Step 6 The firmware will start from this partition when it is next booted. After restarting, the active partition and the inactive partition are switched.
  • Step 7 Check whether the current inactive partition has been upgraded. If not, repeat steps 1 to 6 to complete the upgrade of the current inactive partition.
  • the factory partition is used by the root node device as a buffer for the upgrade firmware compression package, used to store the firmware compression package from the host, and also subsequently push the firmware compression package to the target node device Foundation.
  • the inactive partition in OTA_0 or OTA_1 will be used as a buffer for the firmware compression package. In this case, if the root node device encounters a version rollback, the firmware after the version rollback may not be the original version.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

本发明提供了一种mesh网络设备的多设备批量固件升级的方法，它包括：主机生成带标识的固件压缩包，发送至mesh网络的根节点设备；根节点设备解压缩固件压缩包，校验固件正确性，并重新打包和压缩，以组播的方式向目标节点设备推送固件；升级固件在mesh网络的传输过程中，支持断点续传；目标节点设备解压缩出固件，对固件标识进行CRC校验，通过后进行固件升级并重启。目标节点设备重启异常则回退至旧版本启动。目标节点设备启动后向主机上报版本，由主机确认升级成功与否。本发明通过压缩和断点续传，减少了固件传输过程中对网络和存储资源的消耗，提高了批量升级的速度；通过固件类型检查和版本回退机制，防止固件和待升级设备不匹配导致设备升级异常。

Description

一种mesh网络设备的多设备批量固件升级的方法 技术领域
本发明涉及无线mesh网络技术领域，特别涉及一种mesh网络设备的多设备批量固件升级的方法。
背景技术
现行技术中，mesh网络设备通常使用的是单个设备逐一升级，固件要求一次性从主机传输到待升级设备。这种升级方式，传输过程中一旦有一包数据丢失，则需要重传全部数据，导致升级速度慢，升级成功率低。而且，这种升级方式没有完善的固件检查机制，mesh网络内通常存在多种不同类型的设备，因此容易造成升级的固件和设备不匹配的情况，影响设备的正常工作。
中国发明专利CN108347346A(一种mesh网络内设备升级方法)，公开了一种利用网络进行mesh设备固件升级的方法。在这个方法中，当待升级设备收到升级命令后，向其父节点而不是直接向根节点请求新固件内容。如果父节点已经保存有新固件，那么就直接发送给待升级设备，从而避免了通过根节点从主机传输新固件，节约了网络流量。如果父节点没有新固件，那么优先向同一父节点下的兄弟节点查询是否存在新固件。当待升级设备兄弟节点和父节点都没有新固件的情况下，则递归的向上一级父节点请求，直到请求到根节点，从而向主机请求新固件。这个升级方式，当mesh网络中大部分节点已经得到了新固件的情况下，可以提升固件传输的效率。但是，此方法中， 查询新固件的顺序是从叶子节点向根节点由下向上搜索的。因此，正如该专利自己指出的，如果mesh网络中拥有新固件的设备很少的时候，递归寻找反而会增加获得新固件的时间。因此该专利建议在实施中，应当同时向父节点递归寻找新固件以及直接向根节点请求新固件。
PCT专利WO2015167321A1(一种在无线网状网络中的固件升级方法)公开了一种方式，包含了3个主要步骤。首先将所有需要升级的设备从网络中寻找出来，然后依据各种参数(如网络信号强度)对这些设备重新组成树状网络，最后从新的树状网络的根节点开始，由上至下推送固件，直到所有的设备全部升级完成。这种升级方式，要求在升级前重组网络，因此对正常工作状态的设备会有影响。另外，这种升级方式依然无法解决传输失败的情况下，固件需要整体传输的问题。
发明内容
本发明的目的在于提供一种mesh网络设备的多设备批量固件升级的方法，主要解决上述现有技术存在的问题：减少了固件传输数据的大小、当固件在无线网络中传输中发生丢包的时候无需重新传输、解决了新固件和设备不匹配导致升级失败并使得设备不正确工作的问题。
为了实现上述目的，本发明提供了一种mesh网络设备的多设备批量固件升级的方法，用于从主机向处于同一网络中的多个mesh网络设备同时发起并完成所述mesh网络设备的固件升级，其特征在于，包含以下步骤：
步骤1、所述主机生成所述固件，并压缩所述固件，形成固件压缩包；
步骤2、所述主机向当前mesh网络的根节点设备传输所述固件压缩包；所述根节点设备解压缩所述固件压缩包，并校验所述固件是否正确，若校验失败则升级失败，退出升级流程；
步骤3、所述主机向所述根节点设备传输待升级设备列表；所述待升级设备列表包含全部目标节点设备；
步骤4、所述根节点设备检查收到的所述待升级设备列表的正确性，若错误则升级失败，退出升级流程；
步骤5、所述根节点设备向所有所述目标节点设备发送升级状态请求；
步骤6、所述目标节点设备在收到所述升级状态请求后，擦除本设备的flash分区中的已有固件，并向所述根节点设备返回丢包情况；
步骤7、所述根节点设备根据收到的所述丢包情况，将所述固件分发至所述目标节点设备；具体包含：
步骤7.1、所述根节点根据收到的所述丢包情况，将所述固件准备成传输数据包；所述传输数据包中包含对所述固件进行数据压缩后的内容；以所述根节点设备为父节点设备；
步骤7.2、所述父节点设备将所述传输数据包分发至所述中间传输节点设备或者所述目标节点设备；
步骤7.3、所述中间传输节点设备或者所述目标节点设备接收所述传输数据包；
步骤7.4如果当前设备是所述中间传输节点设备，那么以当前节点为新的所述父节点设备，跳转至步骤7.2继续；如果当前设备是所述目标节点设备， 则跳转到步骤8；
步骤8、所述目标节点设备接收所述传输数据包，解压缩后还原成所述固件，将所述固件写入所述flash分区中；
步骤9、所述目标节点设备标示下一次重启后运行的flash启动分区为新升级固件分区；
步骤10、所述目标节点设备向所述根节点设备发送升级完成信息；
步骤11、所述根节点设备收到所有所述目标节点设备发送的所述升级完成信息后，向所有所述目标节点设备发送重启命令；
步骤12、所述目标节点设备收到所述重启命令后重新启动；
步骤13、启动完成后，所述目标节点设备向所述主机上报自身的当前设备的版本信息；
步骤14、所述主机校验每一个所述目标节点设备发送的所述版本信息，确认所述目标节点设备升级成功与否，完成所述目标节点设备的升级。
进一步地，在所述根节点设备将所述固件通过其直接节点设备分发至所述目标节点设备的过程中，支持断点续传；具体如下：
步骤6分解为：
步骤6.1、所述目标节点设备在收到所述升级状态请求后，判断所述本设备是否存在升级断点；若无所述升级断点，或者存在所述升级断点但将要升级所述固件的版本与所述升级断点标及的固件版本不一致，擦除所述本设备的所述flash分区中的所述已有固件；
步骤6.2、所述目标节点设备根据是否存在所述升级断点的信息，以及在 所述升级断点存在的情况下，所述升级断点中包含的信息，向所述根节点设备返回丢包情况；
在步骤7中，步骤7.1分解为：
步骤7.1.1、所述根节点设备根据收到的所述丢包情况，确定待传输固件内容；所述待传输固件内容是所述固件一部分或者全部；
步骤7.1.2、所述根节点设备将所述待传输固件以固定大小切分，然后压缩成所述传输数据包,并对所述传输数据包进行序号标识；
步骤8分解为：
步骤8.1a、所述目标节点设备接收所述传输数据包，解压缩后写入所述flash分区中；
步骤8.2a、所述目标节点设备记录所述传输数据包的序号和升级情况，并写入所述flash分区中，形成步骤6.1中的所述升级断点；
步骤8.3a、当所述目标节点设备接收完所有所述传输数据包后，拼接形成完整的所述固件。
进一步地，所述步骤8.2a和步骤8.3a之间后插入步骤8.2a’：
步骤8.2a’、所述目标节点设备记录当前已保存但未上报的传输数据包大小；当所述当前已保存但未上报的传输数据包大小达到所述固件大小特定比例的时候，所述目标节点设备向所述父节点设备上报状态，并将所述已保存但未上报的传输数据包的大小清零。
进一步地，所述步骤8.2a’中，所述特定比例是10％。
进一步地，当所述根节点设备、所述目标节点设备以及所述传输中间设 备，在写入所述固件全部内容至所述flash分区后，会主动对所述固件进行校验，具体包含：
将步骤1扩展成：
步骤1.1、所述主机生成所述固件，在所述固件中包含一串固定长度的固件标识；所述固件标识由设备类型和版本号组成；
步骤1.2、所述主机对生成的所述固件进行压缩，形成所述固件压缩包；
将步骤2扩展成：
步骤2.1、所述主机向当前mesh网络的根节点设备传输所述固件压缩包；
步骤2.2、所述根节点设备接收所述固件压缩包；
步骤2.3、所述根节点设备解压缩固件压缩包，并将所述固件写入所述flash分区；
步骤2.4、通过固件校验算法检查所述固件标识的正确性；如果错误，则向主机返回错误；
步骤8分解为：
步骤8.1b、所述目标节点设备接收所述传输数据包，解压缩成所述固件；
步骤8.2b、通过所述固件校验算法检查所述固件标识的正确性；如果错误，向所述父节点设备返回错误，要求重传。
进一步地，所述固件校验算法是CRC校验算法；所述固件标识的长度是128个字节。
进一步地，所述步骤9分解为：
步骤9.1、所述目标节点设备标示下一次重启后运行的所述flash启动分 区为新升级固件分区；
步骤9.2、所述目标节点设备将异常重启次数清零；
所述步骤12分解为：
步骤12.1、所述目标节点设备收到所述重启命令后重新启动；
步骤12.2、启动过程中，所述目标节点设备检测自身状态；如果所述状态异常，所述目标节点设备读取记录的所述异常重启次数；如所述异常重启次数达到预设值，所述目标节点设备标示下一次重启后运行的所述flash启动分区为未升级固件分区；如所述异常重启次数未达到所述预设值，所述目标节点设备标示将所述异常重启次数递增一；所述目标节点设备状态异常时，主动重新启动。
进一步地，所述主机是服务器、移动终端或者PC设备。
进一步地，所述主机和所述根节点设备的连接方式是串口、I2C、SPI、网线有线、Wi-Fi和蓝牙。
进一步地，在步骤1所述的压缩过程中，采用的压缩编码是差分编码、游程编码或者Huffman编码。
鉴于上述技术特征，本发明具有如下优点：
在固件传输前，对固件进行压缩，从而减少了固件传输过程中对网络和存储资源的消耗。
使用组播的方式，在树状mesh网络中，自上向下推送固件，避免了每一个待升级设备都和主机直接通信，提高了批量升级的速度。
支持断点续传机制；当无线网络传输中发生丢包后，无需重传整个固件，而只需要传输尚未成功发送的数据包。
添加固件类型检查和版本回退机制，以防止固件和待升级设备不匹配导致设备升级异常。固件类型检查在升级前加以把关，版本回退则可以处理升级过程中的异常导致的固件升级异常(如非正常断电)。
附图说明
图1是本发明高效mesh网络设备升级方法的网络拓扑图；
图2是本发明高效mesh网络设备升级方法的主机和根节点设备的固件传输交互图；
图3是本发明高效mesh网络设备升级方法的根节点设备和目标节点设备的固件升级交互图；
图4是本发明高效mesh网络设备升级方法的目标节点部署升级固件的流程图。
其中，1–主机、2–根节点设备、3–目标节点设备、4–主机根节点设备连接、5–mesh网络。
具体实施方式
下面结合具体实施方式，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲 授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。
请参阅图1，本发明公开了一种mesh网络设备的多设备批量固件升级的方法，包含了向由主机1发起，更新目标节点设备3的固件，并最后由主机1确认目标节点设备3固件版本的过程。主机1是PC机、移动设备或者服务器等设备，用于提供和准备需要升级的新固件，并发起一次固件升级请求。主机1中物理上，只与目标节点设备3所在的mesh网络5中的根节点设备2建立连接，此连接由主机根节点设备连接4提供。主机根节点设备连接4包含串口、I2C、SPI、网线有线、Wi-Fi和蓝牙。
mesh网络设备升级，包含三个阶段，第一个阶段是主机向mesh网络的根节点设备推送升级固件和待升级设备列表，第二个阶段是根节点设备根据待升级设备列表中的信息，向目标节点推送升级固件，目标节点接收并保存升级固件，第三个阶段是目标节点通过重启的方式，完成升级固件的部署，正式采用升级后的固件开始工作。
请参阅图2，mesh网络升级的第一个阶段，由主机发起开始至根节点设备向目标节点发送升级请求结束，具体步骤包含：
步骤1.1、主机生成固件，在固件中包含一串长度为128个字节的固件标识；固件标识包含设备类型和版本号等信息。
步骤1.2、主机对生成的固件进行压缩，生成压缩固件包，采用的压缩算 法包括差分编码、游程编码或者Huffman编码。
步骤2.1、主机通过mesh网络的根节点设备传输压缩固件包。
步骤2.2、根节点设备接收压缩固件包，并解压缩出固件。
步骤2.3、根节点设备通过固件校验算法检查固件中的固件标识的正确性；如果错误，则向主机返回错误，退出升级。固件校验算法是CRC校验算法。
步骤3、主机向根节点设备传输待升级设备列表；待升级设备列表包含全部目标节点设备的标识。
步骤4、根节点设备检查收到的待升级设备列表的正确性，若错误则升级失败，退出升级流程。
步骤5、根节点设备向待升级设备列表中的所有目标节点设备发送升级状态请求。
请参阅图3，mesh网络升级的第二个阶段，由待升级目标设备收到升级情况开始至目标节点准备部署固件结束，具体步骤包含：
步骤6.1、目标节点设备接收来自根节点的升级状态请求。
步骤6.2、目标节点设备判断本设备是否存在升级断点；若无升级断点进入步骤6.5，否则进入6.3。
步骤6.3、目标节点设备判断要升级的固件版本与已存在的升级断点保存的固件版本是否一致，如果不一致进入步骤6.4，否则进入步骤6.6。
步骤6.4、目标节点设备擦除本设备的升级断点信息。
步骤6.5、目标节点设备擦除本设备的flash分区中的已有固件。
步骤6.6、目标节点设备根据是否存在升级断点的信息，以及在升级断点存在时，升级断点中包含的信息，准备断点信息(如果有)和丢包信息。
步骤6.7、目标节点设备向根节点设备返回丢包情况。
步骤7、根节点设备根据收到的丢包情况，将固件分发至目标节点设备；具体包含：
步骤7.1.1、根节点设备根据收到的丢包情况，确定待传输固件内容；根据丢包情况的不同，待传输固件内容是固件一部分或者全部。
步骤7.1.2、根节点设备将待传输固件以固定大小切分，然后压缩成传输数据包,并对每一个传输数据包进行序号标识。并标识根节点设备为父节点设备。
步骤7.2、父节点设备将传输数据包分发至中间传输节点设备或者目标节点设备。如果被传输设备是中间传输节点设备，那么以被传输节点为新的父节点设备，跳转至步骤7.2继续；如果被传输设备是目标节点设备，则跳转到步骤8；
步骤8.1、目标节点设备接收传输数据包，将收到的传输数据包解压缩后，写入flash分区中。
步骤8.2、目标节点设备记录传输数据包的序号和升级情况，并写入flash分区中，形成步骤6.2中的升级断点，用以记录已经正确接收的传输数据包信息。
步骤8.3、目标节点设备更新当前已保存但未上报的传输数据包大小，并判断当前在当前已保存但未上报的传输数据包大小是否达到整个固件大小 10％。如果达到则进入步骤8.4，否则跳转到步骤8.1继续接收后续传输数据包。
步骤8.4、目标节点设备通过其父节点设备上报状态(包含已保存的传输包大小信息)，并将已保存但未上报的传输数据包大小清零。
步骤8.5、目标节点设备判断是否已经接收完所有传输数据包，如果未接收完则跳转到步骤8.1继续接收后续传输数据包。
步骤8.6、目标节点设备通过固件校验算法(CRC校验算法)检查固件标识的正确性。如果错误，向父节点设备返回错误，要求重传，并跳转到步骤8.1等待接收重传的传输数据包；否则进入步骤8.7。
步骤8.7、目标节点设备标示下一次重启后运行的flash分区为新升级固件分区，将异常重启次数清零，准备开始部署新固件。
请参阅图4，mesh网络升级的第三个阶段，由待升级目标设备发送升级完成信息开始至主机检查目标设备上报的部署固件的版本号结束，具体步骤包含：
步骤9、目标节点设备向根节点设备发送升级完成信息，表示自身已经完成新固件的接受和烧录，做好了部署的准备。
步骤10、根节点设备汇总来自每一个目标节点的升级信息，判断是否全部目标节点完成部署准备。如果全部目标节点完成了部署准备，则进入步骤11，否则进入步骤5，向没有完成部署准备的目标节点推送固件。
步骤11、根节点设备向所有目标节点设备发送重启命令，开始部署新固件。
步骤12.1、目标节点设备收到重启命令后重新启动；
步骤12.2、启动过程中，目标节点设备检测自身状态。
如果状态异常，目标节点设备读取记录的异常重启次数。如异常重启次数达到预设值，目标节点设备标识下一次重启后运行的flash分区为未升级固件分区。如异常重启次数未达到预设值，则将异常重启次数递增一后保存。目标节点设备状态异常时，主动再次重新启动，并在再次重启的过程中进入步骤12.2，检测自身状态。
步骤13、启动状态正常的情况下，待启动完成后，目标节点设备通过父节点设备(包含根节点设备)逐级上报，最后通知主机自身的当前运行的固件版本信息。
步骤14、主机校验每一个目标节点设备发送的固件版本信息是否和步骤1.1中生成的固件的版本一致。如果一致则确认目标节点设备升级成功，反之确认目标节点升级失败。无论成功失败，本次固件升级流程结束。
本实施例中的mesh网络设备，都具有分区表来定义该mesh网络设备的flash布局。本实施例中，flash的大小为4M字节，且全部的mesh网络设备被分为两类，各自具有不同的分区表类型。具体而言，一种是无factory分区的分区表，一种是有factory分区的分区表。其中，无factory分区的分区表包含OTA_0和OTA_1两个和固件升级相关的分区。有factory分区的分区表包含OTA_、OTA_1和factory分区三个和升级固件相关的分区。分区表本身，不能通过固件升级的方式进行升级，而是必须采用其他方式，先擦除 整个flash，然后重写分区表。
其中，OTA_0和OTA_1分区联合使用，实现了mesh网络设备的版本回退机制。默认OTA_0为活动分区，即目标节点设备从OTA_0分区上完成启动，而OTA_1为非活动分区。固件升级过程中，OTA_0和OTA_1分区状态变更的流程为：
步骤1、固件升级开始，目标节点设备识别并擦除非活动分区。
步骤3、新的固件将写入非活动分区。
步骤4、固件写入完毕，开始进行验证。
步骤5、固件升级成功，非活动分区已更新，并指示非活动现在是活动分区。
步骤6、下次启动时，固件将从此分区启动。重新启动后，活动分区和非活动分区完成切换。
步骤7、检查当前非活动分区是否完成升级。如果没有，重复步骤1至6，完成当前非活动分区的升级。
在根节点设备采用有factory分区的分区表的情况下,factory分区被根节点设备作为升级固件压缩包的缓冲区，用于存放来自主机的固件压缩包，也是后续向目标节点设备推送固件压缩包的基础。在根节点设备采用无factory分区的分区表的情况下，OTA_0或者OTA_1中的非活动分区，会被作为固件压缩包的缓冲区。在这种情况下，如果根节点设备遇到版本回退的情 况，版本回退后的固件可能不是原来的版本。
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

  1. 一种mesh网络设备的多设备批量固件升级的方法，用于从主机向处于同一网络中的多个mesh网络设备同时发起并完成所述mesh网络设备的固件升级，其特征在于，包含以下步骤：
    步骤1、所述主机生成所述固件，并压缩所述固件，形成固件压缩包；
    步骤2、所述主机向当前mesh网络的根节点设备传输所述固件压缩包；所述根节点设备解压缩所述固件压缩包，并校验所述固件是否正确，若校验失败则升级失败，退出升级流程；
    步骤3、所述主机向所述根节点设备传输待升级设备列表；所述待升级设备列表包含全部目标节点设备；
    步骤4、所述根节点设备检查收到的所述待升级设备列表的正确性，若错误则升级失败，退出升级流程；
    步骤5、所述根节点设备向所有所述目标节点设备发送升级状态请求；
    步骤6、所述目标节点设备在收到所述升级状态请求后，擦除本设备的flash分区中的已有固件，并向所述根节点设备返回丢包情况；
    步骤7、所述根节点设备根据收到的所述丢包情况，将所述固件分发至所述目标节点设备；具体包含：
    步骤7.1、所述根节点根据收到的所述丢包情况，将所述固件准备成传输数据包；所述传输数据包中包含对所述固件进行数据压缩后的内容；以所述根节点设备为父节点设备；
    步骤7.2、所述父节点设备将所述传输数据包分发至所述中间传输节点设 备或者所述目标节点设备；
    步骤7.3、所述中间传输节点设备或者所述目标节点设备接收所述传输数据包；
    步骤7.4如果当前设备是所述中间传输节点设备，那么以当前节点为新的所述父节点设备，跳转至步骤7.2继续；如果当前设备是所述目标节点设备，则跳转到步骤8；
    步骤8、所述目标节点设备接收所述传输数据包，解压缩后还原成所述固件，将所述固件写入所述flash分区中；
    步骤9、所述目标节点设备标示下一次重启后运行的flash启动分区为新升级固件分区；
    步骤10、所述目标节点设备向所述根节点设备发送升级完成信息；
    步骤11、所述根节点设备收到所有所述目标节点设备发送的所述升级完成信息后，向所有所述目标节点设备发送重启命令；
    步骤12、所述目标节点设备收到所述重启命令后重新启动；
    步骤13、启动完成后，所述目标节点设备向所述主机上报自身的当前设备的版本信息；
    步骤14、所述主机校验每一个所述目标节点设备发送的所述版本信息，确认所述目标节点设备升级成功与否，完成所述目标节点设备的升级。
  2. 根据权利要求1所述的多设备批量固件升级的方法，其特征在于，在所述根节点设备将所述固件通过其直接节点设备分发至所述目标节点设备的过程中，支持断点续传；具体如下：
    步骤6分解为：
    步骤6.1、所述目标节点设备在收到所述升级状态请求后，判断所述本设备是否存在升级断点；若无所述升级断点，或者存在所述升级断点但将要升级所述固件的版本与所述升级断点标及的固件版本不一致，擦除所述本设备的所述flash分区中的所述已有固件；
    步骤6.2、所述目标节点设备根据是否存在所述升级断点的信息，以及在所述升级断点存在的情况下，所述升级断点中包含的信息，向所述根节点设备返回丢包情况；
    在步骤7中，步骤7.1分解为：
    步骤7.1.1、所述根节点设备根据收到的所述丢包情况，确定待传输固件内容；所述待传输固件内容是所述固件一部分或者全部；
    步骤7.1.2、所述根节点设备将所述待传输固件以固定大小切分，然后压缩成所述传输数据包,并对所述传输数据包进行序号标识；
    步骤8分解为：
    步骤8.1a、所述目标节点设备接收所述传输数据包，解压缩后写入所述flash分区中；
    步骤8.2a、所述目标节点设备记录所述传输数据包的序号和升级情况，并写入所述flash分区中，形成步骤6.1中的所述升级断点；
    步骤8.3a、当所述目标节点设备接收完所有所述传输数据包后，拼接形成完整的所述固件。
  3. 根据权利要求2所述的多设备批量固件升级的方法，其特征在于，所述步骤8.2a和步骤8.3a之间后插入步骤8.2a’：
    步骤8.2a’、所述目标节点设备记录当前已保存但未上报的传输数据包 大小；当所述当前已保存但未上报的传输数据包大小达到所述固件大小特定比例的时候，所述目标节点设备向所述父节点设备上报状态，并将所述已保存但未上报的传输数据包的大小清零。
  4. 根据权利要求3所述的多设备批量固件升级的方法，其特征在于，所述步骤8.2a’中，所述特定比例是10％。
  5. 根据权利要求1所述的多设备批量固件升级的方法，其特征在于，当所述根节点设备、所述目标节点设备以及所述传输中间设备，在写入所述固件全部内容至所述flash分区后，会主动对所述固件进行校验，具体包含：
    将步骤1扩展成：
    步骤1.1、所述主机生成所述固件，在所述固件中包含一串固定长度的固件标识；所述固件标识由设备类型和版本号组成；
    步骤1.2、所述主机对生成的所述固件进行压缩，形成所述固件压缩包；
    将步骤2扩展成：
    步骤2.1、所述主机向当前mesh网络的根节点设备传输所述固件压缩包；
    步骤2.2、所述根节点设备接收所述固件压缩包；
    步骤2.3、所述根节点设备解压缩固件压缩包，并将所述固件写入所述flash分区；
    步骤2.4、通过固件校验算法检查所述固件标识的正确性；如果错误，则向主机返回错误；
    步骤8分解为：
    步骤8.1b、所述目标节点设备接收所述传输数据包，解压缩成所述固件；
    步骤8.2b、通过所述固件校验算法检查所述固件标识的正确性；如果错 误，向所述父节点设备返回错误，要求重传。
  6. 根据权利要求5所述的多设备批量固件升级的方法，其特征在于，所述固件校验算法是CRC校验算法；所述固件标识的长度是128个字节。
  7. 根据权利要求1所述的多设备批量固件升级的方法，其特征在于，所述步骤9分解为：
    步骤9.1、所述目标节点设备标示下一次重启后运行的所述flash启动分区为新升级固件分区；
    步骤9.2、所述目标节点设备将异常重启次数清零；
    所述步骤12分解为：
    步骤12.1、所述目标节点设备收到所述重启命令后重新启动；
    步骤12.2、启动过程中，所述目标节点设备检测自身状态；如果所述状态异常，所述目标节点设备读取记录的所述异常重启次数；如所述异常重启次数达到预设值，所述目标节点设备标示下一次重启后运行的所述flash启动分区为未升级固件分区；如所述异常重启次数未达到所述预设值，所述目标节点设备标示将所述异常重启次数递增一；所述目标节点设备状态异常时，主动重新启动。
  8. 根据权利要求1所述的多设备批量固件升级的方法，其特征在于，所述主机是服务器、移动终端或者PC设备。
  9. 根据权利要求1所述的多设备批量固件升级的方法，其特征在于，所述主机和所述根节点设备的连接方式是串口、I2C、SPI、网线有线、Wi-Fi和蓝牙。
  10. 根据权利要求1所述的多设备批量固件升级的方法，其特征在于， 在步骤1所述的压缩过程中，采用的压缩编码是差分编码、游程编码或者Huffman编码。
PCT/CN2020/124558 2019-10-29 2020-10-28 一种mesh网络设备的多设备批量固件升级的方法 WO2021083244A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911036462.8A CN110730104A (zh) 2019-10-29 2019-10-29 一种mesh网络设备的多设备批量固件升级的方法
CN201911036462.8 2019-10-29

Publications (1)

Publication Number Publication Date
WO2021083244A1 true WO2021083244A1 (zh) 2021-05-06

Family

ID=69222346

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/124558 WO2021083244A1 (zh) 2019-10-29 2020-10-28 一种mesh网络设备的多设备批量固件升级的方法

Country Status (2)

Country Link
CN (1) CN110730104A (zh)
WO (1) WO2021083244A1 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110730104A (zh) * 2019-10-29 2020-01-24 乐鑫信息科技（上海）股份有限公司 一种mesh网络设备的多设备批量固件升级的方法
CN111541774B (zh) * 2020-05-08 2023-05-02 杭州粒合信息科技有限公司 一种设备升级方法、装置及系统
CN111722852A (zh) * 2020-06-10 2020-09-29 深圳市千分一智能技术有限公司 固件的烧录方法、设备及计算机可读存储介质
CN112152836B (zh) * 2020-08-11 2022-12-13 珠海市一微半导体有限公司 小存储容量设备的远程固件自动升级方法、系统及芯片
CN112087515B (zh) * 2020-09-10 2022-05-27 苏州德姆斯信息技术有限公司 终端固件空中升级系统及空中升级方法
CN112799707A (zh) * 2021-01-18 2021-05-14 福建新大陆通信科技股份有限公司 一种ctid门禁固件升级方法及系统
CN112887146A (zh) * 2021-01-28 2021-06-01 杭州迪普科技股份有限公司 网络节点升级方法、装置与电子设备
CN113031985B (zh) * 2021-02-07 2022-10-14 厦门亿联网络技术股份有限公司 一种无线升级方法
CN113407377B (zh) * 2021-06-21 2023-09-08 英博超算(南京)科技有限公司 一种ota升级失败回退版本方法
CN113452782B (zh) * 2021-06-28 2022-04-26 烽火通信科技股份有限公司 一种mesh组网下的升级方法与装置
CN114245319B (zh) * 2021-12-03 2023-06-23 南京矽力微电子技术有限公司 基于蓝牙Mesh的增强广播并发式OTA固件升级方法
CN114286366B (zh) * 2021-12-23 2023-07-14 深圳创维数字技术有限公司 无线网格网络升级方法、装置、主节点及存储介质
CN115021873A (zh) * 2022-06-13 2022-09-06 浙江大华技术股份有限公司 一种数据重传的方法、装置及电子设备
CN116149713B (zh) * 2023-04-19 2023-12-15 广州擎天实业有限公司 一种树型异构网络下的各级设备的程序升级方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167321A1 (en) * 2014-04-30 2015-11-05 Mimos Berhad A method for upgrading firmware in a wireless mesh network
CN108347346A (zh) * 2017-12-29 2018-07-31 乐鑫信息科技（上海）有限公司 一种mesh网络内设备升级方法
CN109769239A (zh) * 2019-03-06 2019-05-17 乐鑫信息科技（上海）股份有限公司 用于对蓝牙Mesh网络中的节点进行OTA固件升级的方法
CN110365510A (zh) * 2018-04-10 2019-10-22 上海仪电（集团）有限公司中央研究院 一种可对网络节点批量ota升级的物联网网关及ota升级方法
CN110730104A (zh) * 2019-10-29 2020-01-24 乐鑫信息科技（上海）股份有限公司 一种mesh网络设备的多设备批量固件升级的方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107015817B (zh) * 2017-05-25 2021-06-01 北京君泊网络科技有限责任公司 一种设备固件空中升级的方法
CN107453925A (zh) * 2017-09-21 2017-12-08 山东康威通信技术股份有限公司 基于多级通信平台的远程固件升级方法和云平台
US20190138295A1 (en) * 2018-12-28 2019-05-09 Intel Corporation Delivery of firmware updates in a low-power mesh network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167321A1 (en) * 2014-04-30 2015-11-05 Mimos Berhad A method for upgrading firmware in a wireless mesh network
CN108347346A (zh) * 2017-12-29 2018-07-31 乐鑫信息科技（上海）有限公司 一种mesh网络内设备升级方法
CN110365510A (zh) * 2018-04-10 2019-10-22 上海仪电（集团）有限公司中央研究院 一种可对网络节点批量ota升级的物联网网关及ota升级方法
CN109769239A (zh) * 2019-03-06 2019-05-17 乐鑫信息科技（上海）股份有限公司 用于对蓝牙Mesh网络中的节点进行OTA固件升级的方法
CN110730104A (zh) * 2019-10-29 2020-01-24 乐鑫信息科技（上海）股份有限公司 一种mesh网络设备的多设备批量固件升级的方法

Also Published As

Publication number Publication date
CN110730104A (zh) 2020-01-24

Similar Documents

Publication Publication Date Title
WO2021083244A1 (zh) 一种mesh网络设备的多设备批量固件升级的方法
CN107179909B (zh) 软件升级方法、装置及计算机可读存储介质
CN109460245B (zh) 一种嵌入式系统的远程升级方法
RU2419839C2 (ru) Система и способ обновления программы для мобильного терминала с поддержкой ота
US10268471B2 (en) Method for upgrading terminal system, terminal, and system
WO2016090846A1 (zh) 一种网络版本升级的方法及装置
WO2010135897A1 (zh) 一种独占闪存组合设备空中固件升级方法及装置
CN107547245B (zh) 一种版本升级方法和装置
CN106843933A (zh) 一种应用程序的漏洞修复方法、移动终端及补丁服务器
CN109951842B (zh) 一种蓝牙固件升级中保留ble名称及mac地址的方法
US10469620B2 (en) Method for transferring a new software version to at least one electricity meter via a communication network
CN107015817B (zh) 一种设备固件空中升级的方法
CN103248424A (zh) 光模块固件升级方法及系统
CN111240713A (zh) 一种用电检测远程断点续传的方法
CN103391215A (zh) 一种基于链状网的远程软件下载与更新方法、装置及系统
WO2022241918A1 (zh) 一种物联网设备远程升级方法及装置
WO2011076058A1 (zh) 分布式数据库升级的方法、升级处理装置及升级控制装置
CN101056209A (zh) 一种无线终端映像文件维护方法及设备
CN110580167A (zh) 一种系统升级方法、智能设备及服务器
CN113315797A (zh) 一种局域网批量远程升级方法、系统及节点
CN114915671A (zh) 一种基于NB-IoT的路灯控制器的远程升级方法
CN113138788A (zh) 空调程序升级方法及空调系统
CN104185199A (zh) 一种基站自启动及其控制方法及装置
JP2006227763A (ja) データ共有システム、データ共有方法及びプログラム
CN111198698B (zh) 基于EtherCAT的多设备固件程序并行下载方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20881819

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20881819

Country of ref document: EP

Kind code of ref document: A1