OTA upgrading method and system based on Zigbee neighbor table and dynamic multicast

Abstract

The invention relates to the field of equipment upgrading, and discloses an OTA upgrading method and system based on a Zigbee neighbor table and dynamic multicast, and the method comprises the steps: taking initial source equipment as a coordinator, loading the neighbor table of the coordinator, querying each neighbor node of the neighbor table in a unicast manner by the coordinator, and screening out candidate nodes meeting requirements; the coordinator generates a temporary group address and sends a group joining instruction to each candidate node; the coordinator carries out fragmentation on the upgrade data packet and sends fragmented data to the temporary group through a multicast instruction; the coordinator sends an installation instruction to each candidate node of the temporary group through a multicast instruction, the successfully upgraded candidate nodes are automatically switched to a new coordinator, and the new coordinator is utilized to load a neighbor table for upgrading; and after each candidate node of the temporary group is upgraded, the coordinator notifies each candidate node to exit from the temporary group through a multicast instruction. The Zigbee equipment upgrading method has the advantages that efficient and reliable upgrading of the Zigbee equipment can be achieved, and the batch upgrading requirement is met.

Description

Technical Field

[0001] This invention relates to the field of equipment upgrade technology, specifically to an OTA upgrade method and system based on Zigbee neighbor table and dynamic multicast. Background Technology

[0002] With the rapid development of IoT technology, Zigbee technology is being accepted by more and more users, and various Zigbee devices are being widely used in IoT. Zigbee devices require OTA (Over-The-Air) upgrades during actual use. Currently, upgrades are typically performed using a coordinator in a one-to-one or one-to-many manner. Because all Zigbee devices depend on the coordinator, the entire upgrade process is very time-consuming and inefficient.

[0003] Of course, to improve upgrade efficiency, Chinese invention patent application number CN202210125833.5 discloses an OTA upgrade method and system based on ZigBee networks. This method involves each router node obtaining the latest upgrade program from the coordinator node after a first random delay following the establishment of a connection between the coordinator node and the router node; and each terminal node obtaining the latest upgrade program from the router node after a second random delay following the establishment of a connection between the router node and the terminal node. However, because each router node and each terminal node need to set a delay time to wait when obtaining the latest upgrade program from the coordinator node, and because each router node only acts as a forwarder and the upgrade initiation still relies on the coordinator node, this reduces upgrade efficiency to some extent. Therefore, there is an urgent need to provide a more efficient and reliable OTA upgrade solution to better meet the batch upgrade needs of ZigBee devices. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides an OTA upgrade method and system based on Zigbee neighbor tables and dynamic multicast, which can achieve efficient and reliable upgrades of Zigbee devices and meet the needs of batch upgrades.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] Firstly, an OTA upgrade method based on Zigbee neighbor tables and dynamic multicast is provided, the method comprising the following steps:

[0007] Neighbor table initialization and node filtering: The initial source device is used as the coordinator, and the neighbor table of the coordinator is loaded; the coordinator unicasts a query on each neighbor node in the neighbor table and filters out candidate nodes that meet the requirements.

[0008] Temporary group creation: The coordinator generates a temporary group address and sends a group join instruction to each candidate node, enabling each candidate node to join the created temporary group;

[0009] Multicast data transmission and verification: The coordinator obtains the upgrade data packet, fragments the upgrade data packet, and sends the fragmented data to each candidate node in the temporary group through multicast commands; the coordinator counts the missing data of each fragment and retransmits the missing fragments according to the set retransmission policy; after the coordinator has sent all fragmented data, it notifies each candidate node in the temporary group to perform integrity verification through multicast commands.

[0010] Firmware installation and hierarchical diffusion: The coordinator sends installation instructions to each candidate node in the temporary group via multicast commands, enabling each candidate node to initiate the upgrade operation according to the installation instructions; the candidate node that has successfully upgraded is automatically switched to the new coordinator, and the new coordinator loads the neighbor table to perform the upgrade; when all candidate nodes in the temporary group have been upgraded, the coordinator notifies each candidate node to leave the temporary group via multicast commands.

[0011] Furthermore, the neighbor table of the load coordinator is specifically as follows:

[0012] After the coordinator is powered on, it automatically loads the native neighbor table and polls for device information. The neighbor table contains at least one or more fields among the following: short address of neighbor node, signal strength, and hop count; the device information contains at least one or more fields among the following: firmware version, hardware model, device type, and last communication time.

[0013] The coordinator actively refreshes the neighbor table via Zigbee protocol commands at preset refresh intervals.

[0014] Furthermore, the coordinator unicast-queries each neighbor node in the neighbor table to filter out candidate nodes that meet the requirements, specifically as follows:

[0015] The coordinator traverses the neighbor table and sends a unicast query command to each neighbor node in the neighbor table according to the set sending parameters. The sending parameters include at least the sending power, timeout time or retransmission number, and the unicast query command includes at least the target upgrade version and hardware model requirements.

[0016] Upon receiving a unicast query command, each neighboring node compares its own firmware version and hardware model with the target upgrade version and hardware model requirements in the unicast query command. If its own firmware version is lower than the target upgrade version and the hardware model matches, it returns an upgrade-allowed response message to the coordinator via a unicast command. If its own firmware version is greater than or equal to the target upgrade version or the hardware model does not match, it returns an upgrade-rejected response message to the coordinator via a unicast command. The upgrade-allowed response message must contain at least its own short address, current signal strength, or maximum transmission unit (MTU) of received data.

[0017] The coordinator selects candidate nodes based on the response messages from each neighbor node and preset filtering conditions. If the number of candidate nodes is 0, the upgrade process ends; if the number of candidate nodes is greater than or equal to 1, the process continues to the next step.

[0018] Furthermore, the coordinator generates temporary group addresses specifically as follows: the coordinator generates temporary group addresses based on its own short address and random numbers generated by a random number generator, and performs validity verification through Zigbee multicast temporary group addresses; at the same time, the coordinator records relevant information about the temporary group addresses, including at least the temporary group address, creation time, candidate node list, and target upgrade version.

[0019] Furthermore, the step of sending group join instructions to each candidate node, so that each candidate node joins the created temporary group, specifically involves:

[0020] The coordinator sends a group join instruction to each candidate node. The group join instruction must include at least the temporary group address, the multicast data encryption key, and the total size of the upgrade data packet. After receiving the group join instruction, each candidate node verifies the validity of the multicast data encryption key. If valid, it joins the created temporary group, updates its own multicast address list, and returns a confirmation message to the coordinator via unicast. If invalid, it refuses to join the temporary group and sends an error code to the coordinator via unicast.

[0021] The coordinator waits for each candidate node to confirm its participation according to the set timeout period. After the set timeout period is reached, the coordinator removes any unconfirmed candidate nodes from the candidate node list. The coordinator then resends the group join command to the unconfirmed candidate nodes, and after the set timeout period is reached again, the coordinator excludes any candidate nodes that are still unconfirmed. At the same time, the coordinator sends the final member list to each candidate node that has joined the group via multicast command, so that each candidate node that has joined the group can confirm that it is in the final member list, thereby completing the creation of the temporary group.

[0022] Furthermore, the specific steps of sending fragmented data to each candidate node of the temporary group via multicast commands are as follows:

[0023] After fragmentation is completed, the coordinator sends the fragmented data to each candidate node of the temporary group via multicast commands according to the configured sending parameters. The sending order is incremented according to the fragment index. The configured sending parameters include at least one or more of the following: sending interval, sending power, number of times each fragment is repeatedly sent, and encryption algorithm used for multicast data.

[0024] After receiving the fragmented data, each candidate node in the temporary group verifies the checksum of the fragmented data. If the verification passes, the fragmented data is stored in the local cache according to the fragment index, and the received fragment index is recorded. If the verification fails, the fragmented data is discarded, and the missing fragment index is recorded. At the same time, after receiving a set number of fragmented data, each candidate node in the temporary group sends a progress feedback message to the coordinator via unicast. The progress feedback message contains the number of fragments received and the list of missing fragment indexes.

[0025] Furthermore, the retransmission of missing data fragments according to the set retransmission strategy specifically involves:

[0026] After the coordinator calculates the missing data for each data segment, if the number of missing data segments for a particular segment is greater than or equal to a preset value, the coordinator will retransmit the missing data segment via multicast. If the number of missing data segments for a particular segment is less than the preset value, the coordinator will retransmit the missing data segment to the corresponding candidate node via unicast. Simultaneously, the coordinator will retransmit the missing data segments according to an assigned retransmission priority, which includes, but is not limited to, at least one of the following: A) Prioritizing retransmission to candidate nodes with strong signals and few missing data segments, and delaying retransmission to candidate nodes with weak signals and many missing data segments; B) Retransmitting the missing data segments in ascending order of their segment index.

[0027] The process of notifying each candidate node in the temporary group to perform integrity verification via multicast instructions is as follows: The coordinator notifies each candidate node in the temporary group via multicast instructions, so that each candidate node assembles all received fragmented data into a complete upgrade data packet according to the fragment index order, and verifies the checksum of the entire upgrade data packet. If the verification passes, a verification success response message is sent to the coordinator via unicast; if the verification fails, a verification failure response message is sent back to the coordinator via unicast, so that the coordinator retransmits the fragmented data according to the feedback.

[0028] Furthermore, the specific steps of initiating the upgrade operation for each candidate node according to the installation instructions are as follows:

[0029] The installation command includes an installation delay time and a restart time after installation. After receiving the installation command, each candidate node will start the installation mode to perform the installation operation when the installation delay time is reached. When the installation is completed and the restart time after installation is reached, each candidate node will start automatically and send an installation response message to the coordinator via unicast after starting.

[0030] The coordinator calculates the installation success rate based on the installation response message. If the installation success rate is greater than or equal to the preset success rate, the process proceeds to the next step. If the installation success rate is less than the preset success rate, the coordinator resends the installation command.

[0031] Furthermore, the upgrade using the new coordinator to load the neighbor table specifically involves:

[0032] Each new coordinator loads its own neighbor table and, according to preset device priority rules, initiates upgrades to un-upgraded neighbor nodes in its own neighbor table. The preset device priority rules include at least: sorting the number of nodes in the neighbor tables loaded by each new coordinator and prioritizing the new coordinator with more nodes to initiate the upgrade.

[0033] Secondly, an OTA upgrade system based on Zigbee neighbor table and dynamic multicast, the system including an initialization module, a temporary group creation module, a data transmission verification module and an installation and dissemination module;

[0034] The initialization module is used for neighbor table initialization and node filtering: the initial source device is used as the coordinator, and the neighbor table of the coordinator is loaded; the coordinator unicast queries each neighbor node in the neighbor table and filters out candidate nodes that meet the requirements.

[0035] The temporary group creation module is used to create temporary groups: the coordinator generates a temporary group address and sends a group join instruction to each candidate node, so that each candidate node joins the created temporary group;

[0036] The data transmission verification module is used for multicast data transmission and verification: the coordinator obtains the upgrade data packet, fragments the upgrade data packet, and sends the fragmented data to each candidate node of the temporary group through multicast instructions; the coordinator counts the missing data of each fragment and retransmits the missing fragmented data according to the set retransmission strategy; after the coordinator has sent all fragmented data, it notifies each candidate node in the temporary group to perform integrity verification through multicast instructions.

[0037] The installation diffusion module is used for firmware installation and hierarchical diffusion: the coordinator sends installation instructions to each candidate node in the temporary group via multicast instructions, so that each candidate node starts the upgrade operation according to the installation instructions; the candidate node that has been successfully upgraded is automatically switched to the new coordinator, and the new coordinator loads the neighbor table to perform the upgrade; when all candidate nodes in the temporary group have been upgraded, the coordinator notifies each candidate node to leave the temporary group via multicast instructions.

[0038] By adopting the above-described technical solution of the present invention, at least the following beneficial effects are achieved:

[0039] 1. It can effectively and reliably perform OTA upgrades on Zigbee devices and meet the needs of batch upgrades.

[0040] 2. By directly embedding core data such as the short address, signal strength, and hop count of neighbor nodes into the neighbor table, and only when a neighbor node responds to a unicast query command, matches its firmware version and hardware model, and meets the preset filtering conditions for its current signal strength and hop count, a neighbor node will be selected as a candidate node. Therefore, it can not only select highly reliable neighbor nodes for upgrades, thereby improving the upgrade success rate, but also effectively reduce the risk of broadcast storms by multicasting data within temporary groups created based on the selected candidate nodes during use, based on the unicast data within the selected candidate nodes.

[0041] 3. By utilizing selected candidate nodes to create ephemeral groups and excluding candidate nodes with invalid verification or those that have timed out and not been confirmed, the upgrade success rate can be further improved. Furthermore, the ephemeral group address is generated from its own short address and a random number, and its validity is verified through Zigbee multicast ephemeral group address verification, ensuring the uniqueness of the ephemeral group address and preventing it from occupying fixed group address resources. During subsequent upgrades, multicast data is only transmitted among the candidate nodes within the ephemeral group, and once the upgrade is complete, the coordinator immediately notifies each candidate node to leave the ephemeral group and releases the ephemeral group address resources. By deeply binding the creation, use, and deletion of ephemeral groups with the upgrade process, a dynamic group full lifecycle management mechanism is achieved.

[0042] 4. By recording the received fragment indices and missing fragment indices in each candidate node, and then unicasting this information to the coordinator after a certain number of repetitions, missing fragment data can be accurately located, while avoiding frequent feedback that consumes bandwidth. Furthermore, when the number of missing fragment data is greater than or equal to a preset value, targeted retransmission is performed via multicast; when the number of missing fragment data is less than the preset value, independent retransmission is performed via unicast. Retransmission priorities are also assigned to missing fragment data; therefore, retransmission bandwidth consumption can be effectively reduced, and network flooding can be avoided.

[0043] 5. After the coordinator completes the upgrade operation for the candidate nodes, the successfully upgraded candidate nodes are automatically switched to the new coordinator without manual configuration. The new coordinator loads the neighbor table and performs the diffusion upgrade. Therefore, it can not only effectively improve the overall upgrade efficiency, but also has excellent fault tolerance. If a new coordinator fails, the subgroup nodes it manages can be taken over by the adjacent new coordinator, which can effectively improve the stability of the batch upgrade process. Attached Figure Description

[0044] Figure 1 This is a flowchart illustrating the execution process of an OTA upgrade method based on Zigbee neighbor table and dynamic multicast according to the present invention.

[0045] Figure 2 This is a schematic diagram illustrating the structural principle of an OTA upgrade system based on Zigbee neighbor table and dynamic multicast according to the present invention. Detailed Implementation

[0046] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] Example 1

[0048] Please see the appendix Figure 1 As shown, this invention provides an OTA upgrade method based on Zigbee neighbor tables and dynamic multicast, the method comprising the following steps:

[0049] Step S1, Neighbor Table Initialization and Node Filtering: The initial source device is used as the coordinator (i.e., the Zigbee coordinator), and the coordinator's neighbor table is loaded; the coordinator unicasts a query on each neighbor node in the neighbor table and filters out candidate nodes that meet the requirements to ensure the success rate of the upgrade.

[0050] Step S2, Creation of Temporary Group: The coordinator generates a temporary group address and sends a group join instruction to each candidate node, so that each candidate node joins the created temporary group, so that the coordinator can upgrade each candidate node in the temporary group in a multicast manner;

[0051] Step S3, Multicast Data Transmission and Verification: The coordinator acquires the upgrade data packet, fragments the upgrade data packet, and sends the fragmented data to each candidate node in the temporary group via multicast commands; the coordinator counts the missing data of each fragment and retransmits the missing fragments according to the set retransmission strategy; after the coordinator has sent all fragmented data, it notifies each candidate node in the temporary group to perform integrity verification via multicast commands; in specific implementation of this invention, after the coordinator reads the upgrade data packet (such as V2.0 firmware, 5128 bytes) from local storage, it can fragment it into 64-byte transmission units. Of course, the last transmission unit after fragmentation may be less than 64 bytes;

[0052] Step S4, Firmware Installation and Layered Propagation: The coordinator sends installation instructions to each candidate node in the temporary group via multicast commands, enabling each candidate node to initiate the upgrade operation according to the installation instructions; the upgraded candidate node is automatically switched to the new coordinator, and the new coordinator loads the neighbor table for upgrade; when all candidate nodes in the temporary group have been upgraded, the coordinator notifies each candidate node to leave the temporary group via multicast commands.

[0053] By adopting the above-mentioned technical solution of the present invention, it is possible to achieve efficient and reliable OTA upgrades for Zigbee devices and meet the needs of batch upgrades.

[0054] In some embodiments of the present invention, the neighbor table of the load coordinator is specifically:

[0055] After the coordinator powers on, it automatically loads the native neighbor table and polls for device information. The neighbor table contains at least one or more fields, including the neighbor node's short address (2 bytes, such as 0x0002), signal strength (i.e., RSSI value, in dBm), and hop count. Of course, in specific implementations, other fields can be added to the neighbor table as needed. The device information contains at least one or more fields, including the firmware version (2 bytes, such as V1.0=0x0100), hardware model (2 bytes, such as 0x0001), device type, and last communication time (timestamp, accurate to the second). Of course, in specific implementations, other fields can be added to the device information as needed.

[0056] The coordinator actively refreshes the neighbor table via Zigbee protocol commands (ZDO_Neighbor_Discovery_Req) ​​at preset refresh intervals to ensure data timeliness. The preset refresh interval can be set according to actual needs; for example, it can be set to 30 seconds to avoid frequent refreshes that consume bandwidth.

[0057] This invention embeds core data such as short address, signal strength, and hop count of neighbor nodes directly into the neighbor table. This allows the coordinator to directly filter out highly reliable neighbor nodes without performing additional calculations during actual use, thereby avoiding the inclusion of neighbor nodes with weak signals in temporary groups and preventing data transmission and upgrade failures.

[0058] In some embodiments of the present invention, the coordinator unicast queries each neighbor node in the neighbor table to filter out candidate nodes that meet the requirements, specifically as follows:

[0059] The coordinator traverses the neighbor table and sends a unicast query command (custom opcode: 0x10 "OTA_Condition_Query") to each neighbor node in the table according to the set sending parameters. The sending parameters include at least the sending power, timeout time or retransmission count, and the unicast query command includes at least the target upgrade version (e.g., V2.0=0x0200) and hardware model requirements. Of course, in specific implementations of this invention, the fields in the sending parameters and unicast query command can be added according to actual needs. As a specific implementation of this invention, the sending power in the sending parameters is set to 5dBm (covering a range of 100 meters), the timeout time in the sending parameters is set to 100ms, and the retransmission count in the sending parameters is 2 (i.e., after the first retransmission times out, a retransmission is performed again; if there is still no response after the second retransmission, the neighbor node is determined to be an offline node).

[0060] Upon receiving a unicast query command, each neighboring node compares its own firmware version and hardware model with the target upgrade version and hardware model requirements in the unicast query command. If its own firmware version is lower than the target upgrade version and the hardware model matches, it returns an upgrade-allowing response message to the coordinator via a unicast command (opcode: 0x11 "OTA_Condition_Ack"). If its own firmware version is greater than or equal to the target upgrade version or the hardware model does not match, it returns an upgrade-rejecting response message to the coordinator via a unicast command (opcode: 0x12 "OTA_Condition_Reject"). The upgrade-allowing response message contains at least its own short address, current signal strength (i.e., RSSI value), or maximum transmission unit (MTU, 127 bytes) for receiving data. The upgrade-rejecting response message carries the reason for rejection, such as the version is already up-to-date.

[0061] The coordinator selects candidate nodes based on the response messages from each neighbor node and preset filtering conditions. If the number of candidate nodes is 0, the upgrade process ends; if the number of candidate nodes is greater than or equal to 1, the process continues. The preset filtering conditions include at least the current signal strength being greater than or equal to the preset strength and the number of hops being less than or equal to the preset value. For example, RSSI ≥ -70dBm and the number of hops ≤ 2 can be set.

[0062] This invention embeds core data such as the short address, signal strength, and hop count of neighbor nodes directly into the neighbor table. A neighbor node is only considered a candidate node if it responds to a unicast query command, its firmware version and hardware model match, and its current signal strength and hop count meet preset filtering conditions. Therefore, it not only selects highly reliable neighbor nodes for upgrades, improving the upgrade success rate, but also effectively reduces the risk of broadcast storms by having the coordinator only multicast data within temporary groups created based on the selected candidate nodes.

[0063] In some embodiments of the present invention, the coordinator generates temporary group addresses specifically as follows: the coordinator generates temporary group addresses based on its own short address (e.g., 0x0000) and a random number generated by a random number generator (the random number range is 0x0001-0xFFFF). The specific format is "short address + random number" (e.g., 0x0000 + 0x0005 = 0x00000005), and performs legality verification through Zigbee multicast temporary group addresses to ensure that the temporary group addresses do not conflict with existing fixed group addresses. At the same time, the coordinator records relevant information about the temporary group addresses, including at least the temporary group address, creation time, candidate node list (i.e., short address set), and target upgrade version. In specific implementations of the present invention, the relevant information about the temporary group addresses can be recorded in local non-volatile memory (e.g., Flash) to prevent loss in the event of power failure.

[0064] In some embodiments of the present invention, sending group join instructions to each candidate node, so that each candidate node joins the created temporary group, specifically involves:

[0065] The coordinator sends a group join instruction (opcode: 0x13 "OTA_Group_Join_Req") to each candidate node. This instruction must include at least the temporary group address, the multicast data encryption key (which can be AES-128 encryption and dynamically generated), and the total size of the upgrade packet (e.g., 5120 bytes). Other required fields may also be included. Upon receiving the instruction, each candidate node verifies the validity of the multicast data encryption key (using Zigbee application-layer security mechanisms). If valid, it joins the created temporary group, updates its multicast address list, and returns a unicast confirmation message (opcode: 0x14 "OTA_Group_Join_Ack") to the coordinator. If invalid, it refuses to join the temporary group and sends an error code to the coordinator via unicast.

[0066] The coordinator waits for confirmation from each candidate node according to a set timeout period (e.g., the timeout period can be set to 200ms, but the specific timeout period can be adjusted according to actual needs). After the set timeout period is reached, unconfirmed candidate nodes are removed from the candidate node list. The coordinator resends the group join command to the unconfirmed candidate nodes, and when the set timeout period is reached again, the candidate nodes that still do not confirm are excluded. That is, if the candidate node still does not confirm after the coordinator retransmits the group join command once, it will be excluded directly. At the same time, the coordinator sends the final member list to each candidate node that has joined through a multicast command (opcode: 0x15 "OTA_Group_Member_Sync"), so that each candidate node that has joined confirms that it is in the final member list, thereby completing the creation of the temporary group.

[0067] This invention improves the upgrade success rate by creating temporary groups using selected candidate nodes and excluding candidate nodes with invalid verification or those that have timed out and not been confirmed. The temporary group address is generated from its own short address and a random number, and its validity is verified using Zigbee multicast, ensuring the uniqueness of the temporary group address and preventing it from occupying fixed group address resources. Furthermore, during subsequent upgrades, multicast data is only transmitted among the candidate nodes within the temporary group, and once the upgrade is complete, the coordinator immediately notifies each candidate node to leave the temporary group and releases the temporary group address resources. By deeply binding the creation, use, deletion, and upgrade processes of temporary groups, a dynamic group lifecycle management mechanism is achieved, with the group lifecycle compressed to as short as 3 minutes (in a scenario with 10 nodes in a single group), and the utilization rate of group address resources can be increased by more than 85%.

[0068] In some embodiments of the present invention, sending fragmented data to each candidate node of the temporary group via multicast instructions specifically involves:

[0069] After fragmentation is completed, the coordinator sends the fragmented data to each candidate node of the temporary group via multicast command (opcode: 0x16 "OTA_Data_Fragment") according to the configured sending parameters. The sending order is incremented according to the fragment index (e.g., 0x0000→0x0001→...→0x002A). The configured sending parameters include at least one or more of the following: sending interval, sending power, number of retransmissions for each fragment, and encryption algorithm used for the multicast data. Of course, the configured sending parameters may also include other required fields. As a specific embodiment of the present invention, the sending interval is set to 20ms to ensure that candidate nodes have sufficient time for reception and verification; the sending power is set to 5dBm to ensure coverage; the number of retransmissions for each fragment is set to 2 to avoid packet loss due to single transmission; the multicast data is encrypted using the AES-128 encryption algorithm, and the key is a key dynamically generated in the group joining command.

[0070] After receiving fragmented data, each candidate node in the temporary group verifies the checksum of the fragmented data. If the verification passes, the fragmented data is stored in the local cache according to the fragment index, and the received fragment index is recorded. If the verification fails, the fragmented data is discarded, the missing fragment index is recorded, and feedback information is not immediately sent to the coordinator to avoid frequent feedback consuming bandwidth. Simultaneously, after receiving a set number of fragmented data, each candidate node in the temporary group sends a progress feedback message (opcode: 0x17 "OTA_Data_Progress") to the coordinator via unicast. The progress feedback message contains the number of fragments received and a list of missing fragment indexes (e.g., "missing 0x0003, 0x0005"). For example, each candidate node sends a progress feedback message after receiving 10 fragmented data. In specific implementations, each fragmented data contains a CRC16 checksum. After receiving the fragmented data, each candidate node needs to verify the CRC16 checksum to ensure the integrity of the received fragmented data.

[0071] In some embodiments of the present invention, the retransmission of missing data fragments according to a set retransmission strategy specifically includes:

[0072] After the coordinator calculates the missing data for each data shard, if the number of missing data shards is greater than or equal to a preset value, the coordinator will retransmit the data shard via multicast, that is, retransmit it to each candidate node that is missing the data shard via multicast. If the number of missing data shards is less than the preset value, the coordinator will retransmit the data shard via unicast. For example, in a specific implementation of this invention, if the number of missing data shards is greater than or equal to 30% of the total number of nodes in the temporary group, the coordinator will retransmit the data shard via multicast (opcode: 0x18 "OTA_Data_Retransmit") to each candidate node that is missing the data shard. If the number of missing data shards is less than 30% of the total number of nodes in the temporary group, the coordinator will retransmit the data shard via unicast.

[0073] Meanwhile, the coordinator also retransmits missing fragment data according to the assigned retransmission priority. The assigned retransmission priority includes, but is not limited to, at least one of the following: A) Prioritize retransmission of candidate nodes with strong signals and few missing fragments, and delay retransmission of candidate nodes with weak signals and many missing fragments. For example, prioritize retransmission of candidate nodes with signal strength ≥ -60dBm and ≤ 3 missing fragments, while delay retransmission of candidate nodes with signal strength < -80dBm and > 10 missing fragments, to avoid candidate nodes with weak signal strength occupying too many retransmission resources; B) Retransmit missing fragment data in ascending order of fragment index to ensure that candidate nodes can better splice the fragments in order after receiving them. The retransmission interval can also be set, for example, a retransmission interval of 50ms, to avoid conflicts with the transmission of normal fragments.

[0074] The process of notifying each candidate node in the temporary group to perform integrity verification via multicast command specifically involves the coordinator notifying each candidate node in the temporary group via multicast command. Each candidate node then concatenates all received fragmented data into a complete upgrade data packet according to the fragment index order, verifies the checksum of the entire upgrade data packet, and if the verification passes, sends a verification success response message (opcode: 0x1A "OTA_Check_Success") to the coordinator via unicast. If the verification fails, it sends a verification failure response message (opcode: 0x1B "OTA_Check_Fail") to the coordinator via unicast, causing the coordinator to retransmit the fragmented data based on the feedback. In a specific implementation of this invention, when the coordinator notifies each candidate node in the temporary group via multicast command, the command includes the CRC32 checksum (4 bytes) of the entire upgrade data packet. After concatenating all fragmented data, each candidate node calculates the overall CRC32 value and compares it with the checksum in the command for verification. Meanwhile, the verification failure response message carries the shard status of its own cache. The coordinator can initiate retransmission of abnormal shard data based on the feedback verification failure response message. If the candidate node still fails verification after reaching the set number of retransmissions (e.g., 3 retransmissions), the candidate node will be directly removed.

[0075] This invention records the received fragment indices and missing fragment indices in each candidate node, and then feeds them back to the coordinator via unicast after a certain number of repetitions. This not only accurately locates missing fragment data but also avoids frequent feedback consuming bandwidth. Furthermore, when the number of missing fragment data is greater than or equal to a preset value, targeted retransmission is performed via multicast; when the number of missing fragment data is less than the preset value, independent retransmission is performed via unicast. Retransmission priorities are also assigned to missing fragment data. Therefore, this effectively reduces retransmission bandwidth consumption and avoids network flooding.

[0076] In some embodiments of the present invention, the step of initiating the upgrade operation according to the installation instructions for each candidate node specifically includes:

[0077] The installation command (opcode: 0x1C "OTA_Install_Cmd") includes the installation delay time and the restart time after installation. For example, the installation delay time can be set to 5 seconds and the restart time after installation to 1 second, which can be set according to actual needs. After receiving the installation command, each candidate node can continue to complete its current business (such as sensor data upload) within the installation delay time. When the installation delay time is reached, each candidate node starts the installation mode to perform the installation operation. The installation process is executed silently in the background and will not affect core functions (such as power supply and basic communication). When the installation is completed and the restart time after installation is reached, each candidate node starts automatically and sends an installation response message to the coordinator via unicast after starting. In specific implementation of this invention, when the installation is successful and the node starts automatically, the candidate node sends an installation success response message (opcode: 0x1D) to the coordinator via unicast. The "OTA_Install_Success" message indicates a successful installation. This message contains information such as the current firmware version (e.g., V2.0) and installation time (e.g., 3 seconds). If the installation fails (e.g., due to firmware corruption), the candidate node sends an installation failure response message (opcode: 0x1E "OTA_Install_Fail") to the coordinator via unicast. This message contains the reason for the failure (e.g., verification failed).

[0078] The coordinator calculates the installation success rate based on the installation response message. If the installation success rate is greater than or equal to the preset success rate (which can be set according to actual needs, for example, the preset success rate can be set to 90%), then the subsequent process is initiated. If the installation success rate is less than the preset success rate, the coordinator resends the installation command. In specific implementations of this invention, the number of times the installation command is retransmitted can be set, for example, the installation command can be retransmitted only once.

[0079] In some embodiments of the present invention, the upgrade using a new coordinator to load the neighbor table specifically involves:

[0080] Each new coordinator loads its own neighbor table and, according to preset device priority rules, initiates upgrades to un-upgraded neighbor nodes in its own neighbor table. Specifically, the new coordinator creates a sub-temporary group and initiates a multicast upgrade to each neighbor node within that sub-temporary group. The preset device priority rules include at least sorting the neighbor tables loaded by each new coordinator by the number of nodes, prioritizing new coordinators with more nodes to initiate upgrades. This avoids multiple new coordinators simultaneously sending instructions to the same neighbor node, effectively reducing the conflict rate. In practical implementation, the new coordinator re-executes steps S1-S4. Furthermore, after a new coordinator completes the upgrade operation for the next-level candidate nodes, the upgraded candidate nodes at the next level automatically switch to the new coordinator. This layered diffusion effectively improves the overall upgrade efficiency.

[0081] Furthermore, in a specific implementation of this invention, when the coordinator notifies each candidate node to leave the temporary group via a multicast instruction (opcode: 0x1F "OTA_Group_Delete"), each candidate node will delete the temporary group address and delete the cached related upgrade data; at the same time, the coordinator itself will delete the cached information related to the temporary group address and release the resources of the temporary group address.

[0082] This invention automatically switches the successfully upgraded candidate nodes to the new coordinator after the coordinator completes the upgrade operation, without requiring manual configuration. The new coordinator loads the neighbor table for diffusion upgrade. Therefore, it can not only effectively improve the overall upgrade efficiency, but also has excellent fault tolerance. If a new coordinator fails, the subgroup nodes it manages can be taken over by the adjacent new coordinator, which can effectively improve the stability of the batch upgrade process.

[0083] Additionally, it should be noted that the entire upgrade process of this invention only relies on the local Zigbee network, without relying on the core network or base stations, thus providing excellent support for offline upgrades. At the same time, data transmission adopts Zigbee multicast + fragmented transmission + CRC check, and a single fragment packet can be <1MB, which can well adapt to the upgrade needs of low-resource IoT devices.

[0084] Example 2

[0085] Please see Figure 2 As shown, the present invention also provides an OTA upgrade system based on Zigbee neighbor table and dynamic multicast, the system including an initialization module, a temporary group creation module, a data transmission verification module and an installation and dissemination module;

[0086] The initialization module is used for neighbor table initialization and node filtering: the initial source device is used as the coordinator (i.e., the Zigbee coordinator), and the coordinator's neighbor table is loaded; the coordinator unicast queries each neighbor node in the neighbor table and filters out candidate nodes that meet the requirements to ensure the upgrade success rate.

[0087] The temporary group creation module is used to create temporary groups: the coordinator generates a temporary group address and sends a group join instruction to each candidate node, so that each candidate node joins the created temporary group, so that the coordinator can upgrade each candidate node in the temporary group in a multicast manner;

[0088] The data transmission verification module is used for multicast data transmission and verification: the coordinator acquires the upgrade data packet, fragments the upgrade data packet, and sends the fragmented data to each candidate node in the temporary group via multicast instructions; the coordinator counts the missing data of each fragment and retransmits the missing fragmented data according to the set retransmission strategy; after the coordinator has sent all fragmented data, it notifies each candidate node in the temporary group to perform integrity verification via multicast instructions; in a specific implementation of this invention, after the coordinator reads the upgrade data packet (such as V2.0 firmware, 5128 bytes) from the local storage, it can fragment it into 64-byte transmission units. Of course, the last transmission unit after fragmentation may be less than 64 bytes.

[0089] The installation diffusion module is used for firmware installation and hierarchical diffusion: the coordinator sends installation instructions to each candidate node in the temporary group via multicast instructions, so that each candidate node starts the upgrade operation according to the installation instructions; the candidate node that has been successfully upgraded is automatically switched to the new coordinator, and the new coordinator loads the neighbor table to perform the upgrade; when all candidate nodes in the temporary group have been upgraded, the coordinator notifies each candidate node to leave the temporary group via multicast instructions.

[0090] By adopting the above-mentioned technical solution of the present invention, it is possible to achieve efficient and reliable OTA upgrades for Zigbee devices and meet the needs of batch upgrades.

[0091] In some embodiments of the present invention, the neighbor table of the load coordinator is specifically:

[0092] After the coordinator powers on, it automatically loads the native neighbor table and polls for device information. The neighbor table contains at least one or more fields, including the neighbor node's short address (2 bytes, such as 0x0002), signal strength (i.e., RSSI value, in dBm), and hop count. Of course, in specific implementations, other fields can be added to the neighbor table as needed. The device information contains at least one or more fields, including the firmware version (2 bytes, such as V1.0=0x0100), hardware model (2 bytes, such as 0x0001), device type, and last communication time (timestamp, accurate to the second). Of course, in specific implementations, other fields can be added to the device information as needed.

[0093] The coordinator actively refreshes the neighbor table via Zigbee protocol commands (ZDO_Neighbor_Discovery_Req) ​​at preset refresh intervals to ensure data timeliness. The preset refresh interval can be set according to actual needs; for example, it can be set to 30 seconds to avoid frequent refreshes that consume bandwidth.

[0094] This invention embeds core data such as short address, signal strength, and hop count of neighbor nodes directly into the neighbor table. This allows the coordinator to directly filter out highly reliable neighbor nodes without performing additional calculations during actual use, thereby avoiding the inclusion of neighbor nodes with weak signals in temporary groups and preventing data transmission and upgrade failures.

[0095] In some embodiments of the present invention, the coordinator unicast queries each neighbor node in the neighbor table to filter out candidate nodes that meet the requirements, specifically as follows:

[0096] The coordinator traverses the neighbor table and sends a unicast query command (custom opcode: 0x10 "OTA_Condition_Query") to each neighbor node in the table according to the set sending parameters. The sending parameters include at least the sending power, timeout time or retransmission count, and the unicast query command includes at least the target upgrade version (e.g., V2.0=0x0200) and hardware model requirements. Of course, in specific implementations of this invention, the fields in the sending parameters and unicast query command can be added according to actual needs. As a specific implementation of this invention, the sending power in the sending parameters is set to 5dBm (covering a range of 100 meters), the timeout time in the sending parameters is set to 100ms, and the retransmission count in the sending parameters is 2 (i.e., after the first retransmission times out, a retransmission is performed again; if there is still no response after the second retransmission, the neighbor node is determined to be an offline node).

[0097] Upon receiving a unicast query command, each neighboring node compares its own firmware version and hardware model with the target upgrade version and hardware model requirements in the unicast query command. If its own firmware version is lower than the target upgrade version and the hardware model matches, it returns an upgrade-allowing response message to the coordinator via a unicast command (opcode: 0x11 "OTA_Condition_Ack"). If its own firmware version is greater than or equal to the target upgrade version or the hardware model does not match, it returns an upgrade-rejecting response message to the coordinator via a unicast command (opcode: 0x12 "OTA_Condition_Reject"). The upgrade-allowing response message contains at least its own short address, current signal strength (i.e., RSSI value), or maximum transmission unit (MTU, 127 bytes) for receiving data. The upgrade-rejecting response message carries the reason for rejection, such as the version is already up-to-date.

[0098] The coordinator selects candidate nodes based on the response messages from each neighbor node and preset filtering conditions. If the number of candidate nodes is 0, the upgrade process ends; if the number of candidate nodes is greater than or equal to 1, the process continues. The preset filtering conditions include at least the current signal strength being greater than or equal to the preset strength and the number of hops being less than or equal to the preset value. For example, RSSI ≥ -70dBm and the number of hops ≤ 2 can be set.

[0099] This invention embeds core data such as the short address, signal strength, and hop count of neighbor nodes directly into the neighbor table. A neighbor node is only considered a candidate node if it responds to a unicast query command, its firmware version and hardware model match, and its current signal strength and hop count meet preset filtering conditions. Therefore, it not only selects highly reliable neighbor nodes for upgrades, improving the upgrade success rate, but also effectively reduces the risk of broadcast storms by having the coordinator only multicast data within temporary groups created based on the selected candidate nodes.

[0100] In some embodiments of the present invention, the coordinator generates temporary group addresses specifically as follows: the coordinator generates temporary group addresses based on its own short address (e.g., 0x0000) and a random number generated by a random number generator (the random number range is 0x0001-0xFFFF). The specific format is "short address + random number" (e.g., 0x0000 + 0x0005 = 0x00000005), and performs legality verification through Zigbee multicast temporary group addresses to ensure that the temporary group addresses do not conflict with existing fixed group addresses. At the same time, the coordinator records relevant information about the temporary group addresses, including at least the temporary group address, creation time, candidate node list (i.e., short address set), and target upgrade version. In specific implementations of the present invention, the relevant information about the temporary group addresses can be recorded in local non-volatile memory (e.g., Flash) to prevent loss in the event of power failure.

[0101] In some embodiments of the present invention, sending group join instructions to each candidate node, so that each candidate node joins the created temporary group, specifically involves:

[0102] The coordinator sends a group join instruction (opcode: 0x13 "OTA_Group_Join_Req") to each candidate node. This instruction must include at least the temporary group address, the multicast data encryption key (which can be AES-128 encryption and dynamically generated), and the total size of the upgrade packet (e.g., 5120 bytes). Other required fields may also be included. Upon receiving the instruction, each candidate node verifies the validity of the multicast data encryption key (using Zigbee application-layer security mechanisms). If valid, it joins the created temporary group, updates its multicast address list, and returns a unicast confirmation message (opcode: 0x14 "OTA_Group_Join_Ack") to the coordinator. If invalid, it refuses to join the temporary group and sends an error code to the coordinator via unicast.

[0103] The coordinator waits for confirmation from each candidate node according to a set timeout period (e.g., the timeout period can be set to 200ms, but the specific timeout period can be adjusted according to actual needs). After the set timeout period is reached, unconfirmed candidate nodes are removed from the candidate node list. The coordinator resends the group join command to the unconfirmed candidate nodes, and when the set timeout period is reached again, the candidate nodes that still do not confirm are excluded. That is, if the candidate node still does not confirm after the coordinator retransmits the group join command once, it will be excluded directly. At the same time, the coordinator sends the final member list to each candidate node that has joined through a multicast command (opcode: 0x15 "OTA_Group_Member_Sync"), so that each candidate node that has joined confirms that it is in the final member list, thereby completing the creation of the temporary group.

[0104] This invention improves the upgrade success rate by creating temporary groups using selected candidate nodes and excluding candidate nodes with invalid verification or those that have timed out and not been confirmed. The temporary group address is generated from its own short address and a random number, and its validity is verified using Zigbee multicast, ensuring the uniqueness of the temporary group address and preventing it from occupying fixed group address resources. Furthermore, during subsequent upgrades, multicast data is only transmitted among the candidate nodes within the temporary group, and once the upgrade is complete, the coordinator immediately notifies each candidate node to leave the temporary group and releases the temporary group address resources. By deeply binding the creation, use, deletion, and upgrade processes of temporary groups, a dynamic group lifecycle management mechanism is achieved, with the group lifecycle compressed to as short as 3 minutes (in a scenario with 10 nodes in a single group), and the utilization rate of group address resources can be increased by more than 85%.

[0105] In some embodiments of the present invention, sending fragmented data to each candidate node of the temporary group via multicast instructions specifically involves:

[0106] After fragmentation is completed, the coordinator sends the fragmented data to each candidate node of the temporary group via multicast command (opcode: 0x16 "OTA_Data_Fragment") according to the configured sending parameters. The sending order is incremented according to the fragment index (e.g., 0x0000→0x0001→...→0x002A). The configured sending parameters include at least one or more of the following: sending interval, sending power, number of retransmissions for each fragment, and encryption algorithm used for the multicast data. Of course, the configured sending parameters may also include other required fields. As a specific embodiment of the present invention, the sending interval is set to 20ms to ensure that candidate nodes have sufficient time for reception and verification; the sending power is set to 5dBm to ensure coverage; the number of retransmissions for each fragment is set to 2 to avoid packet loss due to single transmission; the multicast data is encrypted using the AES-128 encryption algorithm, and the key is a key dynamically generated in the group joining command.

[0107] After receiving fragmented data, each candidate node in the temporary group verifies the checksum of the fragmented data. If the verification passes, the fragmented data is stored in the local cache according to the fragment index, and the received fragment index is recorded. If the verification fails, the fragmented data is discarded, the missing fragment index is recorded, and feedback information is not immediately sent to the coordinator to avoid frequent feedback consuming bandwidth. Simultaneously, after receiving a set number of fragmented data, each candidate node in the temporary group sends a progress feedback message (opcode: 0x17 "OTA_Data_Progress") to the coordinator via unicast. The progress feedback message contains the number of fragments received and a list of missing fragment indexes (e.g., "missing 0x0003, 0x0005"). For example, each candidate node sends a progress feedback message after receiving 10 fragmented data. In specific implementations, each fragmented data contains a CRC16 checksum. After receiving the fragmented data, each candidate node needs to verify the CRC16 checksum to ensure the integrity of the received fragmented data.

[0108] In some embodiments of the present invention, the retransmission of missing data fragments according to a set retransmission strategy specifically includes:

[0109] After the coordinator calculates the missing data for each data shard, if the number of missing data shards is greater than or equal to a preset value, the coordinator will retransmit the data shard via multicast, that is, retransmit it to each candidate node that is missing the data shard via multicast. If the number of missing data shards is less than the preset value, the coordinator will retransmit the data shard via unicast. For example, in a specific implementation of this invention, if the number of missing data shards is greater than or equal to 30% of the total number of nodes in the temporary group, the coordinator will retransmit the data shard via multicast (opcode: 0x18 "OTA_Data_Retransmit") to each candidate node that is missing the data shard. If the number of missing data shards is less than 30% of the total number of nodes in the temporary group, the coordinator will retransmit the data shard via unicast.

[0110] Meanwhile, the coordinator also retransmits missing fragment data according to the assigned retransmission priority. The assigned retransmission priority includes, but is not limited to, at least one of the following: A) Prioritize retransmission of candidate nodes with strong signals and few missing fragments, and delay retransmission of candidate nodes with weak signals and many missing fragments. For example, prioritize retransmission of candidate nodes with signal strength ≥ -60dBm and ≤ 3 missing fragments, while delay retransmission of candidate nodes with signal strength < -80dBm and > 10 missing fragments, to avoid candidate nodes with weak signal strength occupying too many retransmission resources; B) Retransmit missing fragment data in ascending order of fragment index to ensure that candidate nodes can better splice the fragments in order after receiving them. The retransmission interval can also be set, for example, a retransmission interval of 50ms, to avoid conflicts with the transmission of normal fragments.

[0111] The process of notifying each candidate node in the temporary group to perform integrity verification via multicast command specifically involves the coordinator notifying each candidate node in the temporary group via multicast command. Each candidate node then concatenates all received fragmented data into a complete upgrade data packet according to the fragment index order, verifies the checksum of the entire upgrade data packet, and if the verification passes, sends a verification success response message (opcode: 0x1A "OTA_Check_Success") to the coordinator via unicast. If the verification fails, it sends a verification failure response message (opcode: 0x1B "OTA_Check_Fail") to the coordinator via unicast, causing the coordinator to retransmit the fragmented data based on the feedback. In a specific implementation of this invention, when the coordinator notifies each candidate node in the temporary group via multicast command, the command includes the CRC32 checksum (4 bytes) of the entire upgrade data packet. After concatenating all fragmented data, each candidate node calculates the overall CRC32 value and compares it with the checksum in the command for verification. Meanwhile, the verification failure response message carries the shard status of its own cache. The coordinator can initiate retransmission of abnormal shard data based on the feedback verification failure response message. If the candidate node still fails verification after reaching the set number of retransmissions (e.g., 3 retransmissions), the candidate node will be directly removed.

[0112] This invention records the received fragment indices and missing fragment indices in each candidate node, and then feeds them back to the coordinator via unicast after a certain number of repetitions. This not only accurately locates missing fragment data but also avoids frequent feedback consuming bandwidth. Furthermore, when the number of missing fragment data is greater than or equal to a preset value, targeted retransmission is performed via multicast; when the number of missing fragment data is less than the preset value, independent retransmission is performed via unicast. Retransmission priorities are also assigned to missing fragment data. Therefore, this effectively reduces retransmission bandwidth consumption and avoids network flooding.

[0113] In some embodiments of the present invention, the step of initiating the upgrade operation according to the installation instructions for each candidate node specifically includes:

[0114] The installation command (opcode: 0x1C "OTA_Install_Cmd") includes the installation delay time and the restart time after installation. For example, the installation delay time can be set to 5 seconds and the restart time after installation to 1 second, which can be set according to actual needs. After receiving the installation command, each candidate node can continue to complete its current business (such as sensor data upload) within the installation delay time. When the installation delay time is reached, each candidate node starts the installation mode to perform the installation operation. The installation process is executed silently in the background and will not affect core functions (such as power supply and basic communication). When the installation is completed and the restart time after installation is reached, each candidate node starts automatically and sends an installation response message to the coordinator via unicast after starting. In specific implementation of this invention, when the installation is successful and the node starts automatically, the candidate node sends an installation success response message (opcode: 0x1D) to the coordinator via unicast. The "OTA_Install_Success" message indicates a successful installation. This message contains information such as the current firmware version (e.g., V2.0) and installation time (e.g., 3 seconds). If the installation fails (e.g., due to firmware corruption), the candidate node sends an installation failure response message (opcode: 0x1E "OTA_Install_Fail") to the coordinator via unicast. This message contains the reason for the failure (e.g., verification failed).

[0115] The coordinator calculates the installation success rate based on the installation response message. If the installation success rate is greater than or equal to the preset success rate (which can be set according to actual needs, for example, the preset success rate can be set to 90%), then the subsequent process is initiated. If the installation success rate is less than the preset success rate, the coordinator resends the installation command. In specific implementations of this invention, the number of times the installation command is retransmitted can be set, for example, the installation command can be retransmitted only once.

[0116] In some embodiments of the present invention, the upgrade using a new coordinator to load the neighbor table specifically involves:

[0117] Each new coordinator loads its own neighbor table and, according to preset device priority rules, initiates upgrades to un-upgraded neighbor nodes in its own neighbor table. Specifically, the new coordinator creates a sub-temporary group and initiates a multicast upgrade to each neighbor node within that sub-temporary group. The preset device priority rules include at least sorting the neighbor tables loaded by each new coordinator by the number of nodes, prioritizing new coordinators with more nodes to initiate upgrades. This avoids multiple new coordinators simultaneously sending instructions to the same neighbor node, effectively reducing the conflict rate. In practical implementation, the new coordinator re-executes the initialization module, temporary group creation module, data transmission verification module, and installation diffusion module. Furthermore, after a new coordinator completes the upgrade operation for the next-level candidate nodes, the upgraded candidate nodes at the next level automatically switch to the new coordinator. This layered diffusion effectively improves the overall upgrade efficiency.

[0118] Furthermore, in a specific implementation of this invention, when the coordinator notifies each candidate node to leave the temporary group via a multicast instruction (opcode: 0x1F "OTA_Group_Delete"), each candidate node will delete the temporary group address and delete the cached related upgrade data; at the same time, the coordinator itself will delete the cached information related to the temporary group address and release the resources of the temporary group address.

[0119] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An OTA upgrade method based on Zigbee neighbor table and dynamic multicast, characterized in that, The method includes the following steps: Neighbor table initialization and node filtering: The initial source device is used as the coordinator, and the neighbor table of the coordinator is loaded; the coordinator unicasts a query on each neighbor node in the neighbor table and filters out candidate nodes that meet the requirements. Temporary group creation: The coordinator generates a temporary group address and sends a group join instruction to each candidate node, enabling each candidate node to join the created temporary group; Multicast data transmission and verification: The coordinator obtains the upgrade data packet, fragments the upgrade data packet, and sends the fragmented data to each candidate node in the temporary group through multicast commands; the coordinator counts the missing data of each fragment and retransmits the missing fragments according to the set retransmission policy; after the coordinator has sent all fragmented data, it notifies each candidate node in the temporary group to perform integrity verification through multicast commands. Firmware installation and hierarchical distribution: The coordinator sends installation instructions to each candidate node in the temporary group via multicast commands, enabling each candidate node to initiate the upgrade operation according to the installation instructions; Successful candidate nodes will be automatically switched to the new coordinator, which will then load the neighbor table for the upgrade. Once all candidate nodes in the temporary group have been upgraded, the coordinator will notify each candidate node to leave the temporary group via multicast.

2. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The neighbor table of the load coordinator is specifically as follows: After the coordinator is powered on, it automatically loads the native neighbor table and polls for device information. The neighbor table contains at least one or more fields among the following: short address of neighbor node, signal strength, and hop count; the device information contains at least one or more fields among the following: firmware version, hardware model, device type, and last communication time. The coordinator actively refreshes the neighbor table via Zigbee protocol commands at preset refresh intervals.

3. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The coordinator unicast-queries each neighbor node in the neighbor table and filters out candidate nodes that meet the requirements as follows: The coordinator traverses the neighbor table and sends a unicast query command to each neighbor node in the neighbor table according to the set sending parameters. The sending parameters include at least the sending power, timeout time or retransmission number, and the unicast query command includes at least the target upgrade version and hardware model requirements. Upon receiving a unicast query command, each neighboring node compares its own firmware version and hardware model with the target upgrade version and hardware model requirements in the unicast query command. If its own firmware version is lower than the target upgrade version and the hardware model matches, it returns an upgrade-allowed response message to the coordinator via a unicast command. If its own firmware version is greater than or equal to the target upgrade version or the hardware model does not match, it returns an upgrade-rejected response message to the coordinator via a unicast command. The upgrade-allowed response message must contain at least its own short address, current signal strength, or maximum transmission unit (MTU) of received data. The coordinator selects candidate nodes based on the response messages from each neighbor node and preset filtering conditions. If the number of candidate nodes is 0, the upgrade process ends; if the number of candidate nodes is greater than or equal to 1, the process continues to the next step.

4. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The coordinator generates temporary group addresses in the following ways: the coordinator generates temporary group addresses based on its own short address and random numbers generated by a random number generator, and performs validity verification through Zigbee multicast temporary group addresses; at the same time, the coordinator records relevant information about the temporary group addresses, including at least the temporary group address, creation time, candidate node list, and target upgrade version.

5. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The specific steps of sending group join instructions to each candidate node, so that each candidate node joins the created temporary group, are as follows: The coordinator sends a group join instruction to each candidate node. The group join instruction must include at least the temporary group address, the multicast data encryption key, and the total size of the upgrade data packet. After receiving the group join instruction, each candidate node verifies the validity of the multicast data encryption key. If valid, it joins the created temporary group, updates its own multicast address list, and returns a confirmation message to the coordinator via unicast. If invalid, it refuses to join the temporary group and sends an error code to the coordinator via unicast. The coordinator waits for each candidate node to confirm its participation according to the set timeout period. After the set timeout period is reached, the coordinator removes any unconfirmed candidate nodes from the candidate node list. The coordinator then resends the group join command to the unconfirmed candidate nodes, and after the set timeout period is reached again, the coordinator excludes any candidate nodes that are still unconfirmed. At the same time, the coordinator sends the final member list to each candidate node that has joined the group via multicast command, so that each candidate node that has joined the group can confirm that it is in the final member list, thereby completing the creation of the temporary group.

6. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The specific steps of sending fragmented data to each candidate node of the temporary group via multicast commands are as follows: After fragmentation is completed, the coordinator sends the fragmented data to each candidate node of the temporary group via multicast commands according to the configured sending parameters. The sending order is incremented according to the fragment index. The configured sending parameters include at least one or more of the following: sending interval, sending power, number of times each fragment is repeatedly sent, and encryption algorithm used for multicast data. After receiving the fragmented data, each candidate node in the temporary group verifies the checksum of the fragmented data. If the verification passes, the fragmented data is stored in the local cache according to the fragment index, and the received fragment index is recorded. If the verification fails, the fragmented data is discarded, and the missing fragment index is recorded. At the same time, after receiving a set number of fragmented data, each candidate node in the temporary group sends a progress feedback message to the coordinator via unicast. The progress feedback message contains the number of fragments received and the list of missing fragment indexes.

7. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The specific steps for retransmitting missing data fragments according to the set retransmission strategy are as follows: Once the coordinator has tallied the missing data for each data segment, if the number of missing data segments for a particular data segment is greater than or equal to a preset value, the coordinator will retransmit that data segment via multicast. If the number of missing data fragments in a certain data segment is less than a preset value, the coordinator retransmits the data segment to the corresponding candidate node via unicast. At the same time, the coordinator also retransmits the missing data segment according to the assigned retransmission priority, which includes, but is not limited to, at least one of the following: A. Prioritize retransmission for candidate nodes with strong signals and few missing data fragments, and delay retransmission for candidate nodes with weak signals and many missing data fragments; B. Retransmit the missing data segment in ascending order of fragment index. The process of notifying each candidate node in the temporary group to perform integrity verification via multicast instructions is as follows: The coordinator notifies each candidate node in the temporary group via multicast instructions, so that each candidate node assembles all received fragmented data into a complete upgrade data packet according to the fragment index order, and verifies the checksum of the entire upgrade data packet. If the verification passes, a verification success response message is sent to the coordinator via unicast; if the verification fails, a verification failure response message is sent back to the coordinator via unicast, so that the coordinator retransmits the fragmented data according to the feedback.

8. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The specific steps for initiating the upgrade operation for each candidate node according to the installation instructions are as follows: The installation command includes an installation delay time and a restart time after installation. After receiving the installation command, each candidate node will start the installation mode and perform the installation operation when the installation delay time is reached. Once the installation is complete and the post-installation restart time has elapsed, each candidate node will start automatically and send an installation response message to the coordinator via unicast after startup. The coordinator calculates the installation success rate based on the installation response message, and if the installation success rate is greater than or equal to the preset success rate, it proceeds to the next step. If the installation success rate is lower than the preset success rate, the coordinator will resend the installation instructions.

9. The wireless debugging method for a tracking controller according to claim 1, characterized in that, The upgrade using the new coordinator to load the neighbor table specifically involves: Each new coordinator loads its own neighbor table and, according to preset device priority rules, initiates upgrades to un-upgraded neighbor nodes in its own neighbor table. The preset device priority rules include at least: sorting the number of nodes in the neighbor tables loaded by each new coordinator and prioritizing the new coordinator with more nodes to initiate the upgrade.

10. An OTA upgrade system based on Zigbee neighbor table and dynamic multicast, characterized in that, The system includes an initialization module, a temporary group creation module, a data transmission verification module, and an installation and diffusion module. The initialization module is used for neighbor table initialization and node filtering: the initial source device is used as the coordinator, and the neighbor table of the coordinator is loaded; the coordinator unicast queries each neighbor node in the neighbor table and filters out candidate nodes that meet the requirements. The temporary group creation module is used to create temporary groups: the coordinator generates a temporary group address and sends a group join instruction to each candidate node, so that each candidate node joins the created temporary group; The data transmission verification module is used for multicast data transmission and verification: the coordinator obtains the upgrade data packet, fragments the upgrade data packet, and sends the fragmented data to each candidate node of the temporary group through multicast instructions; the coordinator counts the missing data of each fragment and retransmits the missing fragmented data according to the set retransmission strategy; after the coordinator has sent all fragmented data, it notifies each candidate node in the temporary group to perform integrity verification through multicast instructions. The installation and diffusion module is used for firmware installation and hierarchical diffusion: the coordinator sends installation instructions to each candidate node of the temporary group through multicast instructions, so that each candidate node starts the upgrade operation according to the installation instructions; Successful candidate nodes will be automatically switched to the new coordinator, which will then load the neighbor table for the upgrade. Once all candidate nodes in the temporary group have been upgraded, the coordinator will notify each candidate node to leave the temporary group via multicast.

Images