Rateless Erasure Coding for Multihop Broadcast Transmission in Wireless IoT Networks

Abstract

A network manager for distributing firmware / software programs to multi-mode nodes and single-mode nodes disposed in a multi-hop wireless IoT network is provided. The network manager includes a transceiver configured to perform wireless communication by transmitting encoded packets of the firmware / software program to a first-hop node. The network manager divides the firmware / software program into source blocks, encodes the source blocks into encoded blocks based on a coding scheme, packs the encoded blocks into encoded packets, and transmits the encoded packets to the first-hop node. The first-hop node is configured to receive, decode, re-encode, and retransmit the encoded packets to distribute the firmware / software distribution to other hop nodes. The network manager continues broadcasting the encoded packets to the first-hop node until a predetermined percentage of the first-hop nodes have received the firmware / software program. In response to receiving a retransmission request for missing source blocks of the firmware / software program from the first-hop node, the network manager rebroadcasts the missing source blocks.

Description

[Technical Field]

[0001] The present invention relates generally to transmitting data in wireless communication networks, and more particularly to multi-hop broadcast transmission in wireless IoT networks. [Background technology]

[0002] With the advent of 5G / 6G wireless communication technologies, Internet of Things (IoT) applications are proliferating. As a result, IoT networks have been deployed to meet various application requirements. IoT networks, especially outdoor IoT networks such as smart utility networks and smart city networks, may have one or more network managers, and many other nodes, such as smart meters and urban traffic sensors, function as data nodes, forming a multi-hop network topology. The network manager organizes and maintains the network by performing management functions such as controlling the data nodes, updating firmware / software, discovering routes, and collecting data. In a network such as that shown in Figure 1, some nodes can communicate directly with one or more network managers, while other nodes cannot communicate directly with any network manager and therefore must relay communications in a multi-hop manner.

[0003] In an IoT network, there can be three types of traffic: (1) downlink traffic from the network manager to the data nodes, (2) uplink traffic from the data nodes to the network manager, and (3) peer-to-peer traffic between the data nodes. Uplink traffic is typically for data collection, such as metering data collection in a smart meter network. Peer-to-peer traffic is primarily for information sharing, such as neighbor information exchange during neighbor discovery and route discovery. Downlink traffic is generally for management commands and firmware / software updates. Uplink and peer-to-peer traffic have been widely studied. Downlink traffic has not been thoroughly studied. The present invention addresses the problem of downlink traffic distribution in multi-hop wireless IoT networks by providing an innovative mechanism.

[0004] Downlink traffic is more critical than uplink and peer-to-peer traffic because it is related to network operation. A malfunctioning network may not provide accurate information. For example, if an application requires the network to perform a new function, such as machine learning, the network manager must distribute new firmware / software to all data nodes in the network. Once the data nodes receive the new firmware / software, they can execute the required new function. If such firmware / software distribution fails, the data nodes will not be able to execute the new function. Therefore, it is important to install new firmware / software and update existing firmware / software.

[0005] Additionally, completely replacing deployed devices with new ones is costly. Therefore, updating deployed devices with new features becomes a viable solution. As a result, firmware / software distribution becomes inevitable in modern IoT networks.

[0006] To install or update firmware / software, the firmware / software program must be distributed to all data nodes in the network. Figure 2A shows an example of conventional flooding firmware / software distribution in a multi-hop wireless IoT network, where a network manager (NM) as the firmware / software program source initiates distribution by broadcast transmission. When the first-hop node receives the firmware / software program from the network manager, it rebroadcasts the received firmware / software program to distribute it to the second-hop node. When the second-hop node receives the firmware / software program from the first-hop node, it rebroadcasts the received firmware / software program again. This flooding broadcast process continues until all data nodes in the network receive the firmware / software program. If any node fails to receive the firmware / software program, it will send a retransmission request to the network manager. Upon receiving the request, the network manager retransmits the firmware / software program to the requesting node, as shown in Figure 2B.

[0007] Note that firmware / software programs are typically too large to fit into a single network packet, so the network manager can split the firmware / software data into multiple packets and broadcast multiple data packets.

[0008] The conventional flooding distribution approach has several important problems that need to be addressed. Specifically, (1) redundant transmission: The communication bandwidth is limited. However, the conventional flooding distribution approach is inefficient, and all data nodes rebroadcast the received firmware / software program regardless of whether neighboring devices have already received the program. In fact, if all neighboring devices have already received the firmware / software program, the data node does not need to retransmit the received firmware / software packet. (2) unreliable transmission: In wireless communication networks, many factors can cause packet transmission failure. Figure 5 shows two typical cases in a CSMA-based communication network. (a) CSMA collision: Wireless IoT networks typically adopt a CSMA channel access mechanism, in which packet collisions are unavoidable. (b) poor link quality: The wireless link may be blocked by objects, for example, in outdoor IoT networks, or by moving vehicles on a congested road. In such cases, the distribution of the firmware / software program may not be successful. Therefore, it is necessary to improve transmission reliability. (3) Inefficient request and response: In wireless networks, there is no guarantee that a transmission will be successful. Therefore, a retransmission request must be sent. The traditional request / response process is time-consuming due to the multi-hop relay mechanism, making communication bandwidth inefficient. This request / response approach can also cause network traffic congestion, packet loss, and packet delays. (4) Lack of acknowledgment: Due to the nature of broadcast transmission, there is no acknowledgment in the communication layer. Therefore, the transmitting node does not know whether the firmware / software packet has been received by its neighbors. Therefore, an acknowledgment method must be provided. (5) Lack of consideration of network conditions: A noisy environment can degrade communication link quality. IoT networks are typically deployed in noisy environments where link quality changes dynamically and can become poor.Additional mechanisms are required to transmit packets over poor link quality. However, network conditions have not been considered in traditional distribution approaches. (6) Node Capability Not Considered: Advanced node capabilities can improve delivery efficiency. Multi-mode nodes exist in IoT networks. For example, in a smart meter network, various generations of smart meters coexist. Newer generations of meters have higher capabilities than older generations of meters. Multi-mode nodes can transmit packets at higher transmission rates using modulation adaptation. Therefore, fully utilizing multi-mode nodes can improve delivery efficiency. However, multi-mode nodes have not been considered in traditional distribution approaches.

[0009] Therefore, it is desirable to provide a more efficient and more reliable firmware / software distribution method for multi-hop IoT networks to efficiently reduce the number of redundant transmissions by providing an innovative multi-hop relay protocol and acknowledgment mechanism for broadcast transmissions, improve packet transmission reliability by fully considering dynamic wireless network conditions, and increase the speed of firmware / software distribution by fully utilizing the existence of multi-mode nodes. Summary of the Invention

[0010] Some embodiments of the present invention recognize that downlink firmware / software distribution is necessary in multi-hop IoT networks where at least one network manager manages tens, hundreds, or thousands of data nodes and at least one data node cannot communicate directly with the network manager. Traditional firmware / software distribution starts with the network manager and distributes to data nodes in a multi-hop manner. In this case, the network manager may split firmware / software data into multiple data packets, broadcast these data packets to one-hop data nodes, and then rebroadcast the received data packets to distribute the distribution to two-hop data nodes. This process continues until all data nodes receive the firmware / software. If a data node does not receive any packets, it will unicast a request packet to the network manager via hop-by-hop relays. Upon receiving the request, the network manager unicasts the missing data packets to the requesting node via hop-by-hop relays. Such a flooding firmware / software distribution approach has several problems to address, including the following (1) to (5). (1) inefficiencies in delivery, (2) unreliable transmission, (3) inefficiencies in requests and responses, (4) lack of an acknowledgment mechanism, (5) failure to consider network conditions, and (5) failure to consider multi-mode nodes.

[0011] One objective of various embodiments of the present invention is to provide an efficient multi-hop broadcast transmission protocol, called the dynamic relay point (DRP) protocol, for efficient firmware / software distribution in multi-hop wireless IoT networks. The protocol consists of five key features: 1) a dynamic neighbor classification method, 2) a passive / active acknowledgment mechanism, 3) a packet scheduling method, 4) a hybrid packet transmission mechanism, and 5) a rateless erasure coding scheme based on network conditions.

[0012] To achieve this, each node in the network dynamically classifies its neighbors into two classes: (1) Class R neighbors, which are neighbors that have received the firmware / software program; and (2) Class U neighbors, which are neighbors that have not yet received the firmware / software program. Those that have received the firmware / software program are defined as having successfully received all firmware / software packets, while those that have not received the firmware / software program are defined as having at least one firmware / software packet still missing. The Class R and Class U sets are dynamically updated. Initially, a node classifies all its neighbors except the network manager as Class U neighbors, and the network manager classifies them as Class R neighbors. As the firmware / software distribution progresses, if a node overhears an acknowledgment from a Class U neighbor using the hybrid acknowledgment method, the node reclassifies the neighbor as a Class R neighbor.

[0013] Thus, some embodiments of the present invention provide a passive / active acknowledgment mechanism, where sending firmware / software packets acts as a passive acknowledgment and sending broadcast acknowledgment packets acts as an active acknowledgment. Unlike traditional acknowledgment packets that are unicast, embodiments of the present invention provide broadcast acknowledgments to accommodate broadcast transmissions.

[0014] Some embodiments of the present invention are based on the recognition that it is important to reduce redundant transmissions and firmware / software delivery latency. Therefore, nodes with more Class U neighbors and good link quality must retransmit firmware / software packets earlier to speed up delivery. In other words, nodes with fewer Class U neighbors or poor link quality must retransmit firmware / software packets later to give other nodes a chance to transmit.

[0015] To do this, the network manager broadcasts the firmware / software packet without delay, and all data nodes rebroadcast the firmware / software packet with a delay.

[0016] Therefore, some embodiments of the present invention provide a distributed transmission delay computation mechanism, where a data node computes a transmission delay based on the number of class U neighbors and their link qualities to those class U neighbors, such that the transmission delay is inversely proportional to the number of class U neighbors and the link qualities to those class U neighbors.

[0017] Some embodiments of the present invention are based on the recognition that, upon receiving a firmware / software program, to reduce redundant transmissions, a node rebroadcasts the firmware / software packet only if it has at least one class U neighbor. If not, the node does not rebroadcast the firmware / software packet, but instead broadcasts an acknowledgement packet.

[0018] Some embodiments of the present invention are based on the recognition that firmware / software must be distributed to all data nodes in the network.

[0019] Therefore, if any data node does not receive the firmware / software program, it will unicast a retransmission request packet to the selected class R neighbor. When the class R neighbor receives the request, it will perform the role of network manager by broadcasting the requested firmware / software packet. Even if the request is unicast, the response is broadcast to benefit more data nodes.

[0020] Some embodiments of the present invention are based on the recognition that dynamic network conditions, such as link quality, in wireless IoT networks change dynamically due to many factors, such as noise, collisions, interference, etc. Transmission of packets over links with poor link quality is unreliable due to packet loss or packet errors. Therefore, there is a need to provide a method for nodes with poor link quality to improve the reliability of packet transmission.

[0021] Additionally, some embodiments of the present invention are based on the recognition that IoT devices are typically resource constrained. As a result, methods for improving transmission reliability must be lightweight.

[0022] To this end, some embodiments of the present invention provide a Luby Transform (LT)-based lightweight coding scheme for nodes with poor link quality to improve packet transmission reliability, where nodes with poor link quality encode firmware / software packets by adding redundancy. The amount of redundancy added is based on the number of class-U neighbors and the link quality to the class-U neighbors. The worse the link quality, the more redundancy is added. The more class-U neighbors there are, the more redundancy is added.

[0023] Additionally, some embodiments of the present invention provide a hybrid packet transmission mechanism for multi-hop firmware / software distribution in wireless IoT networks, where if a node has good link quality to its class U neighbors, the node rebroadcasts firmware / software packets without coding, i.e., rebroadcasts simple firmware / software packets, otherwise the node rebroadcasts firmware / software packets with coding, i.e., rebroadcasts encoded firmware / software packets.

[0024] Some embodiments of the present invention are based on the recognition that conventional LT coding is designed for an end-to-end topology from an encoder to a decoder without considering a multi-hop broadcast topology. In conventional LT coding, the encoder continues transmitting encoded packets until an acknowledgment is received from the decoder. This makes it unfeasible for multi-hop broadcast transmission in an IoT network where a node can receive firmware / software packets from multiple class R neighbors. Therefore, a node does not need to ensure that all of its class U neighbors, especially class U neighbors with poor link quality, receive the firmware / software program.

[0025] Therefore, some embodiments of the present invention provide a firmware / software packet transmission mechanism whereby a node stops firmware / software packet transmission if R percent (R%) of its class U neighbors have received the firmware / software program. This stopping mechanism is based on the fact that in a broadcast environment, with conventional LT coding, a node can receive firmware / software packets from multiple class R neighbors rather than a single transmitter. Stopping transmission can improve communication bandwidth efficiency by avoiding packet transmission over links with poor link quality.

[0026] Some embodiments of the present invention further provide a network manager for distributing firmware / software programs to multi-mode nodes and single-mode nodes arranged in a multi-hop wireless IoT network, the network manager including a transceiver configured to perform wireless communication by transmitting encoded data packets of the firmware / software program to a first-hop node, the first-hop node being configured to communicate directly with the network manager, other nodes other than the first-hop node being referred to as other-hop nodes, the network manager further including at least one processor associated with the transceiver and a memory storing the firmware / software program and instructions, the instructions causing the at least one processor to: divide the firmware / software program into firmware / software program source blocks; encode the firmware / software program source blocks into encoded blocks based on a rateless erasure coding scheme; pack the encoded blocks into encoded data packets; and configure a dynamic relay point. and transmitting the encoded data packet to the first hop node based on a (DRP) protocol, the first hop node being configured to receive the encoded data packet, decode the received encoded data packet, re-encode the firmware / software program source block, and retransmit the encoded data packet to distribute the firmware / software distribution to other hop nodes, the network manager continuing to broadcast the encoded data packet to the first hop node until R percent (R%) of the first hop nodes have received the entire firmware / software program. The instructions further cause the at least one processor to rebroadcast the missing source block to the first hop node in response to receiving a retransmission request for the missing source block of the firmware / software program from the first hop node.

[0027] According to some embodiments of the present invention, a multimode node for distributing firmware / software programs over a multi-hop wireless IoT network including a network manager, other multimode nodes, and single-mode nodes is provided. The multimode node includes a transceiver configured to perform wireless communication with neighboring objects, including the network manager, other multimode nodes, and single-mode nodes, by receiving encoded packets of the firmware / software program from the network manager and transmitting encoded firmware / software program source blocks to the other multimode nodes and single-mode nodes, at least one processor associated with the transceiver, and a memory having instructions stored thereon, the instructions causing the at least one processor to classify the neighboring objects into Class R neighboring objects and Class U neighboring objects. In this case, a class R neighbor is a neighbor node that has received the entire firmware / software program encoded packet, a class R neighbor is a neighbor node that has received the entire firmware / software program source block successfully decoded from the received encoded source block, a class U neighbor is a neighbor node that has not received the entire firmware / software program source block, and a class U neighbor is a neighbor node that is missing at least one of the firmware / software program source blocks, all neighbors other than the network manager are initially classified as class U neighbors, and the network manager is classified as a class R neighbor by its neighbors, and at least one processor reclassifies the class U neighbors to class R neighbors based on the hybrid acknowledgment method.

[0028] Additionally, to ensure that a data node successfully receives firmware / software, some embodiments of the present invention provide a timer mechanism, where a data node starts a timer upon receiving the first firmware / software packet. If the timer times out and the node is still missing some firmware / software packets, the node sends a retransmission request to selected class R neighbors to retransmit the missing firmware / software packets.

[0029] Some embodiments of the present invention are based on the recognition that multi-mode devices may be present in modern IoT networks: high transmission rate links take less time to transmit packets than low transmission rate links.

[0030] Additionally, some embodiments of the present invention provide a mode adaptive transmission method such that if a node is a multimode node and all of its class U neighbors are multimode nodes, the node will rebroadcast firmware / software packets using a mode with a higher transmission rate.

[0031] Embodiments of the present disclosure are further described with reference to the accompanying drawings, in which the drawings are not necessarily to scale, with emphasis generally being placed upon illustrating the principles of embodiments of the present disclosure. [Brief explanation of the drawings]

[0032] [Figure 1] 1 is a schematic diagram illustrating a multi-hop wireless IoT network consisting of a network manager, multiple multi-mode nodes, and multiple single-mode nodes. [Figure 2A] FIG. 1 illustrates an example of conventional firmware / software distribution in a multi-hop wireless IoT network with hop-by-hop relaying, where the network manager acts as the data source and other nodes act as data destinations. [Figure 2B]FIG. 1 illustrates an example of a conventional retransmission request and response process when a data delivery does not reach a node. [Figure 3] FIG. 10 is a diagram illustrating an example of dynamic neighbor classification according to some embodiments of the invention, in which node N6 is a class U neighbor of node N0 at time t1, and node N6 is reclassified as a class R neighbor of node N0 at time t2. [Figure 4A] FIG. 1 illustrates an efficient broadcast data distribution method according to some embodiments of the invention, in which a network manager broadcasts firmware / software packets without delay and data nodes rebroadcast firmware / software packets with a delay calculated based on the number of class U neighbors and the link quality to the class U neighbors. [Figure 4B] A diagram illustrating an efficient retransmission request and response method according to some embodiments of the invention, in which a node that fails to receive a firmware / software program sends a retransmission request to selected class R neighbors on behalf of the network manager. [Figure 5] FIG. 1 illustrates an example of packet transmission failures caused by road traffic and packet collisions in a multi-hop IoT network. [Figure 6A] FIG. 1 illustrates a bipartite graph of conventional Luby transform coding for generating encoded packets (EPs) from source blocks (SBs). [Figure 6B] FIG. 1 illustrates a conventional Luby transform-based encoding and decoding process over a wireless communication network. [Figure 7A] FIG. 1 illustrates a continuous unicast transmission of encoded packets in a conventional end-to-end coding mechanism. [Figure 7B] FIG. 1 illustrates parallel unicast transmission of encoded packets in a conventional end-to-end coding mechanism. [Figure 8]FIG. 10 illustrates a multi-input, multi-output broadcast transmission of encoded firmware / software packets in a multi-hop broadcast network according to some embodiments of the invention, in which a node receives encoded firmware / software packets from various class R neighbors and then rebroadcasts the re-encoded firmware / software packets to all class U neighbors. [Figure 9] FIG. 1 illustrates hybrid packet transmission decisions made by nodes in a multi-hop IoT network for firmware / software distribution, according to some embodiments of the invention. [Figure 10A] FIG. 1 illustrates an encoding and transmission process by a relay data node for firmware / software program distribution in a multi-hop wireless IoT network, according to some embodiments of the invention. [Figure 10B] FIG. 1 illustrates a packet format for firmware / software distribution in a multi-hop wireless IoT network according to some embodiments of the invention. [Figure 10C] FIG. 1 illustrates multi-mode adaptive packet transmission in a multi-hop wireless IoT network of multi-mode and single-mode nodes, according to some embodiments of the invention. [Figure 11A] FIG. 1 illustrates a receiving and decoding process by a data node for firmware / software distribution in a multi-hop wireless IoT network according to some embodiments of the invention. [Figure 11B] FIG. 1 illustrates a timer handling mechanism in the receiving and decoding process of firmware / software distribution in a multi-hop wireless IoT network according to some embodiments of the invention. [Figure 12A] FIG. 1 illustrates retransmission request vectors for firmware / software distribution in a multi-hop wireless IoT network according to some embodiments of the invention. [Figure 12B] FIG. 1 illustrates a retransmission request handling mechanism when a class R node receives a retransmission request from a class U neighboring object for firmware / software distribution in a multi-hop wireless IoT network, according to some embodiments of the invention. DETAILED DESCRIPTION OF THE INVENTION

[0033] The following description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments will provide those skilled in the art with an enablement description for implementing one or more exemplary embodiments. Various changes are contemplated that may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosed subject matter as set forth in the appended claims.

[0034] In the following description, specific details are provided to provide a thorough understanding of the embodiments. However, those skilled in the art will understand that the embodiments may be practiced without these specific details. For example, systems, processes, and other elements of the disclosed subject matter may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known processes, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments. Furthermore, like reference numbers and names in the various drawings indicate like elements.

[0035] Also, particular embodiments may be described as a process that is depicted as a flowchart, flow diagram, data flow diagram, structure diagram, or block diagram. While a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process may terminate when its operations are completed, but may include additional steps not disclosed or included in the diagram. Moreover, not all operations in any specifically described process may be performed in all embodiments. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, the end of the function may correspond to a return of the function to the calling function or the main function.

[0036] Furthermore, embodiments of the disclosed subject matter may be implemented, at least in part, either manually or automatically. Manual or automatic implementations may be performed or at least assisted by the use of machines, hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments to perform the necessary tasks may be stored on a machine-readable medium. A processor may perform the necessary tasks.

[0037] Internet of Things (IoT) applications are proliferating. IoT networks have been deployed to meet various application requirements. In an IoT network, there can be one or more network managers and hundreds of data nodes to form a multi-hop network topology. FIG. 1 shows an example of a multi-hop IoT network including a network manager 100, a set of single-mode nodes 110, and a set of multi-mode nodes 120. The single-mode link 130 transmits using a low data rate mode, and the multi-mode link 140 can transmit using either a low data rate mode or a high data rate mode. Some data nodes can communicate directly with the network manager, while the remaining nodes cannot communicate directly with the network manager and therefore must relay communications in a multi-hop manner.

[0038] In modern IoT networks, firmware / software installation and updates are inevitable, in addition to control and management commands. The delivery of such firmware / software data is downlink traffic from the network manager to the data nodes. Downlink data traffic is critical to maintaining normal operation of the IoT network.

[0039] However, traditional flooding firmware / software distribution in a multi-hop IoT network is inefficient. Figure 2A shows an example of traditional firmware / software distribution in a multi-hop wireless IoT network, where a network manager (NM) 100 is the firmware / software data source and data nodes are the firmware / software data destinations. The network manager initiates firmware / software distribution by broadcast transmission. When a one-hop node 201 receives firmware / software from the network manager, it rebroadcasts the received firmware / software to distribute the distribution to two-hop nodes 202. When a two-hop node 202 receives firmware / software from the one-hop node 201, it rebroadcasts the received firmware / software to distribute the distribution to three-hop nodes 203. This flooding broadcast process continues until all nodes in the network receive the firmware / software. If any node fails to receive the firmware / software, it sends a retransmission request to the network manager, which then retransmits the firmware / software to the requesting node as shown in Figure 2B; however, if a three-hop node 203 does not receive the firmware / software, it sends a retransmission request packet 204 to the network manager 100. This retransmission request packet is relayed hop-by-hop to the network manager 100, which in turn responds with a retransmission response packet 205. Similarly, the response packet 205 is relayed hop-by-hop to the three-hop node 203.

[0040] The traditional flooding distribution approach has several problems, namely: (1) redundant transmission, (2) unreliable transmission, (3) inefficient request and response, (4) lack of acknowledgement, (5) no consideration of the network environment, and (6) no consideration of multi-mode node capabilities.

[0041] Firmware / software programs are typically large and cannot be packed into a single data packet. Therefore, firmware / software programs are typically divided into multiple blocks, packed, and transmitted in multiple data packets. As a result, there are various ways for a data node to rebroadcast firmware / software data packets: 1) rebroadcast when all packets are received; 2) rebroadcast packets as they are received; and 3) other methods. The present invention will be described using method 1) as an example because method 1) provides intermediate data nodes with the opportunity to re-encode firmware / software packets based on dynamic network conditions they observe. Dynamic Relay Point (DRP) Protocol for Efficient Broadcast Transmission in Multi-hop IoT Networks

[0042] To address the inefficiency issues in traditional delivery, an efficient transmission method called Dynamic Relay Point (DRP) protocol is provided. The key function of DRP is to reduce the number of redundant firmware / software packet transmissions and improve the reliability of firmware / software packet transmissions.

[0043] First, for efficient transmission, a dynamic neighbor classification method is provided in which nodes classify their neighbors into two dynamic classes: (1) a class R set including neighbors that have received all firmware / software packets, and (2) a class U set including neighbors that have not received all firmware / software packets. Initially, each node classifies all of its neighbors except the network manager as class U neighbors, and the network manager is classified by its neighbors as class R neighbors. As the firmware / software distribution process progresses, the class R set and class U set are dynamically updated. Each node monitors packet transmissions from its class U neighbors. When a node first overhears a firmware / software packet from a class U neighbor, the node reclassifies the neighbor as a class R neighbor. When a node overhears a broadcast acknowledgment packet from a class U neighbor in addition to the firmware / software packet, the node also reclassifies the neighbor as a class R neighbor. 3 illustrates a dynamic neighbor set update, where node N0 300 has its class R set 301 and class U set 302. At time t1, node N6 303 is in node N0's class U set, but at time t2, node N6 303 has been reclassified as a class R neighbor and therefore moved from the class U set to the class R set.

[0044] There are many existing neighbor discovery methods that can be used to discover neighbors, for example, a node broadcasts a neighbor discovery request packet and neighbors unicast a neighbor discovery response packet back, or neighbors can be discovered during the route discovery process.

[0045] Second, to ensure efficient transmission, an acknowledgment method for broadcast transmission is provided. In this case, all nodes, including the network manager, monitor packet transmissions from their neighbors. Acknowledgment is realized in a hybrid manner. Specifically, (1) passive acknowledgment: A node's transmission of a firmware / software packet indicates the node's receipt of the firmware / software program. Therefore, the transmission of the firmware / software packet functions as a passive acknowledgment. (2) active acknowledgment: A node broadcasts an actual acknowledgment packet upon receiving the firmware / software program, and this broadcasted acknowledgment packet functions as an active acknowledgment. Upon receiving the firmware / software program, based on the provided passive / active acknowledgment mechanism, the data node rebroadcasts the firmware / software packet only if the node has at least one class U neighbor. Otherwise, the data node broadcasts an acknowledgment packet.

[0046] Third, for firmware / software distribution in a multi-hop wireless IoT network, nodes compete for channel access using the CSMA mechanism, which does not guarantee which node will transmit early and which node will transmit late. However, it is desirable that nodes with more Class U neighbors and good link quality relay firmware / software programs early, and nodes with fewer Class U neighbors or poor link quality relay firmware / software programs late.

[0047] The DRP protocol provides instructions to nodes about packet transmission. This mechanism is illustrated in the two-hop network of FIG. 4A, where the network manager (NM) 100, as the firmware / software program source, initiates the broadcast of firmware / software packets without scheduling delay. The link quality 406 from the network manager to node 1 401, node 2 402, and node 3 403 is 0.9, which is a good link quality. Therefore, nodes 1, 2, and 3 simultaneously receive firmware / software from the network manager 100. Upon receiving the data packet from the network manager, nodes 1, 2, and 3 need to rebroadcast the firmware / software packet without scheduling delay because they all have class U neighbors, e.g., nodes 4, 5, and 6 are class U neighbors of node 1. However, which of these should be rebroadcast first, second, and last?

[0048]

number

[0049] As shown in Figure 4A, node 1 has three class U neighbors 4, 5, and 6, so N USince D(1) = 3, the link qualities from node 1 to its class U neighbors 4, 5, and 6 are 0.8, 0.9, and 0.9, respectively. Taking ms as the time unit, D(1) = 0.1282 ms, similarly, D(2) = 0.0513 ms, and D(3) = 0.3333 ms. Therefore, node 2 must rebroadcast the firmware / software packet first, node 1 must rebroadcast second, and node 3 must rebroadcast last. Upon receiving firmware / software packets from nodes 1, 2, and 3, the network manager accepts the receipt as a passive acknowledgment and moves them from the class U set to the class R set. Similarly, upon receiving the firmware / software packet from node 2, nodes 6, 7, 8, 9, and 10 update their class R and class U sets by moving node 2 from the class U set to the class R set. As a result, nodes 7, 8, and 9 do not have class U neighbors. Therefore, they broadcast an acknowledgement packet instead of the firmware / software packet. When node 2 receives the acknowledgement, it moves nodes 7, 8, and 9 from the class U set to the class R set. However, nodes 6 and 10 still have nodes 1 and 3 as their class U neighbors, respectively. Therefore, they rebroadcast the firmware / software packet, and nodes 1 and 3 will move nodes 5 and 10 from the class U set to the class R set, respectively. A similar procedure is applicable to the node 1 branch and node 3 branch.

[0050] Note that leaf nodes may need to rebroadcast the firmware / software packet rather than the acknowledgement packet. For example, node 10 404 is a leaf node, but when it receives the firmware / software packet from node 2, node 3 has not yet started broadcasting. As a result, node 3 is still a class U neighbor of node 10 and must rebroadcast the firmware / software packet rather than the acknowledgement packet. However, the situation is different for leaf node 11 405. When node 11 receives the firmware / software packet from node 3, it does not have a class U neighbor. Therefore, it must broadcast the acknowledgement packet rather than the firmware / software packet.

[0051] The efficient transmission mechanism provided also avoids unnecessary data packet transmission due to the acknowledgement mechanism provided. Sending a small acknowledgement packet is much more efficient than sending an entire firmware / software program.

[0052] Link quality can be expressed in various ways, such as expected transmission count (ETX) and received signal strength indicator (RSSI). Choosing the link quality expression and calculating link quality is an implementation option, as it is a well-studied topic.

[0053] 4B illustrates a request and response mechanism provided where a node 407 that fails to receive a firmware / software packet sends a retransmission request 204 to a selected Class R neighbor 408 rather than to the network manager, and the Class R neighbor 408 assumes the role of the network manager by sending a retransmission response 205 to the requesting node. This mechanism is a one-hop transmission, reducing delivery delays and communication bandwidth requirements, especially for large IoT networks.

[0054] There are various ways to select a Class R neighbor, for example, one option is to select the Class R neighbor with the best link quality, and another option is to select a Class R neighbor via a default degree-of-pair routing protocol in the RPL routing protocol. A rateless erasure coding scheme based on dynamic network conditions for improving the reliability of firmware / software distribution in noisy multi-hop wireless IoT networks

[0055] In wireless communication networks, there are many factors that can cause packet transmission failure. Figure 5 shows two typical cases in a CSMA-based communication network. (a) Poor link quality: The wireless link may be blocked by an object. For example, in an outdoor IoT network, the wireless link may be blocked by a vehicle moving on a congested traffic road 502. As a result, the third-hop node 503 cannot receive the firmware / software packet from the second-hop node 501. (b) CSMA collision: Wireless IoT networks typically adopt a CSMA channel access mechanism, in which packet collisions are inevitable. For example, transmissions from the second-hop nodes 504 and 505 collide (506), and thus the third-hop node 507 does not receive the firmware / software. In such cases, the delivery of the firmware / software program may not be successful. Therefore, it is necessary to improve transmission reliability.

[0056] Coding techniques have been widely applied to improve transmission reliability in lossy wireless networks. However, unlike traditional powerful devices such as computers, IoT devices typically have limited computational resources. Therefore, designing lightweight coding techniques is important for IoT networks.

[0057] There are various types of coding techniques, including network coding and rateless erasure coding. Network coding is more versatile than rateless erasure coding but is more complex, making it impractical for IoT devices. Rateless erasure coding is less complex and therefore more feasible for wireless IoT networks. Luby Transform (LT) codes and Raptor codes are two currently popular rateless erasure codes and candidate coding schemes for IoT devices. LT, which is the basis for rateless erasure codes that use only XOR operations, is better suited for IoT devices.

[0058] FIG. 6A shows the encoding process of a conventional LT code. In this case, source data 600 to be transmitted is divided into source blocks (SBs) 601 of equal size, and these source blocks 601 are used to generate encoded blocks (EBs) 602 of the same size as the SBs through an exclusive-or (XOR) operation. The encoded blocks 602 are then packed into network packets as payloads along with headers, as shown in FIG. 10B. The constructed network packets are known as encoded packets (EPs) 603 to be transmitted to the network. More specifically, to generate EBs, the LT randomly selects a degree d for the EBs from a degree distribution, i.e., the number of SBs to use. The LT then randomly selects d distinct SBs uniformly as input blocks for the EBs. The value of EB is the XOR of d's neighbors. For example, EB-1 has degree 1, SB-1 is its only source block, and EB-2 has degree 2, with source blocks SB-1 and SB-2. Depending on the size of the EBs and EPs, there are various ways to pack the EBs into an EP. Figure 6A shows one EB per EP. There are also various decoding techniques for LT codes. Belief propagation and Gaussian elimination are two typical decoding methods for LT codes.

[0059] 6B shows the LT encoding and decoding process over a wireless communication network such as a wireless IoT network, where an encoder 604 performs a) source data division 606, b) source data encoding and encoded packet construction 607, and c) transmitting the encoded packets over a wireless communication network 608, and a decoder 605 performs a) receiving the encoded packets 609, b) decoding the encoded packets 610, and c) source data construction 611. Note that for firmware / software distribution in a multi-hop IoT network, the network manager is a pure encoder, data nodes with class U neighbors are both decoders and encoders, and data nodes without class U neighbors are pure decoders.

[0060] In conventional end-to-end LT coding, encoded packets (EPs) 603 are transmitted sequentially, as shown in Figure 7A, or in parallel, as shown in Figure 7B, depending on the number of communication channels between the encoder 604 and the decoder 605. In conventional LT coding, the encoder continues transmitting EPs until the decoder acknowledges them. This can be a serious problem in lossy wireless networks, where link failures can cause the encoder to transmit an infinite number of EPs, which is practically unfeasible, due to lost acknowledgements.

[0061] There are several problems with applying conventional LT coding techniques to multi-hop broadcast network topologies: (1) LT is designed for end-to-end topologies with only one encoder and one decoder, (2) LT does not consider network conditions such as link quality, (3) LT does not consider broadcast transmissions without acknowledgements, and (4) LT does not adapt to network topologies.

[0062] Multi-hop broadcast transmission provides an opportunity to address these issues. As shown in Figure 8, a node 800 in a multi-hop broadcast network can receive EPs from multiple class R neighbors 801 and broadcast EPs to neighbors 802 in both the class R set and the class U set. In such a topology, all class R neighbors are encoders. As a result, a node does not need to receive all EPs from a single encoder, but can instead receive EPs from alternate encoders.

[0063] Upon receiving the firmware / software program, each data node first determines whether it needs to rebroadcast the firmware / software program. FIG. 9 shows a hybrid packet transmission decision 900 provided for firmware / software distribution in a multi-hop IoT network, where a node does not rebroadcast the firmware / software packet if it has no class U neighbors 901, but instead broadcasts an acknowledgement packet 902. Otherwise, the node needs to rebroadcast the firmware / software program. The next step is to determine whether the firmware / software packet needs to be encoded (903). Coding can improve transmission reliability, but also adds redundancy. It has been shown that simple transmission is more efficient than coding when the link quality is sufficiently good. Therefore, a threshold Q for good link quality is G If a node has class U neighbors and the link quality to all class U neighbors is less than a threshold Q GIf the link quality exceeds , the node rebroadcasts the firmware / software packet without encoding (904). Otherwise, if a node has class U neighbors and the link quality to any class U neighbors is poor, the node rebroadcasts the firmware / software packet with encoding (905) using method 1000 as shown in Figure 10A where the firmware / software program is the source data.

[0064] Threshold Q G The determination of q depends on the link quality representation such as ETX or RSSI. For example, 0 ≤ q t If (i)≦1, then Q G can be set to 0.9.

[0065]

number

[0066] Threshold Q R The determination of q depends on the link quality representation such as ETX or RSSI. For example, 0 ≤ q t If (i)≦1, then Q R can be set to 0.6.

[0067] The R% stall mechanism is intended to reduce redundant transmissions by considering multi-source reception in broadcast transmissions. It also takes into account network conditions; for example, if a node has poor link quality to some class-U neighbors, the node will tend to add more redundancy to increase the chances of successful decoding, but the added redundancy may not be useful. By stalling transmissions, scenarios where link quality is so poor that packet arrival rates are very low are avoided.

[0068] In this case, continuing to transmit would consume communication bandwidth without significant gain. Stopping transmission would give other nodes an opportunity to transmit, and these nodes may have good link quality to Class U neighbors with poor link quality.

[0069] FIG. 11A illustrates a receiving and decoding method 1100 provided for firmware / software distribution in a multi-hop IoT network, in which a data node first starts a timer (1101) to send a retransmission request. When an encoded packet is received (1102), the node first checks the CRC (1103). If the CRC check fails, the packet is discarded. Otherwise, the number of encoded packets received is incremented by one (1104). If the number of encoded packets received is less than K 1105, node n continues receiving packets (1102). Otherwise, the node applies a decoding method, such as Gaussian elimination or belief propagation, to decode the firmware / software program 1106. If the decoding is successful (1107), the node makes a rebroadcast decision (900) as shown in FIG. 9. Otherwise, the node continues receiving packets (1102).

[0070] With the hybrid transmission mechanism and multi-source reception, a data node may receive encoded packets from some class R neighbors and unencoded packets from other class R neighbors, which are treated as degree-1 encoded packets.

[0071] Figure 11B shows a procedure for handling the timer in the receiving and decoding method shown in Figure 11A. When the timer times out (1108), the node checks whether the number of such encoded packets received is greater than or equal to K (1109). If no, the node proceeds to the request sending process, where the node selects a class R neighbor (1111), builds a request packet for the missing block, sends the request (1112), and proceeds to receive the packet (1100). If not, the node checks whether the decoding was successful (1110). If yes, the node proceeds to the rebroadcast decision process 900. If no, the node proceeds to the request sending process.

[0072] There are various methods for selecting a Class R neighbor, such as selecting the Class R neighbor with the best link quality, or selecting an RPL default parent if an RPL routing protocol is implemented.

[0073] To send a request, the requestor includes a retransmission request vector 1200 in the request packet to indicate the missing source blocks. If a firmware / software program is divided into K source blocks, the retransmission request vector 1200 has K bit elements, as shown in Figure 12A, where bit 1 indicates that the corresponding source block is requested and bit 0 indicates that the corresponding source block is not needed; for example, in Figure 12A, source block 3 and source block K-1 are requested.

[0074] 12B shows a retransmission request processing method in which a class R node 1201 receives a retransmission request packet (1202) and broadcasts the requested source block, which can be sent with or without encoding (1203). While the retransmission request is unicast, the retransmission response is broadcast so that other nodes may also need the requested source block. Multi-mode operation for firmware / software distribution in multi-hop IoT networks

[0075] It is common for multi-mode devices to exist in modern IoT networks. High-transmission-rate links take less time to transmit packets than low-transmission-rate links. Note that a high-transmission-rate link can be formed by two multi-mode nodes. A multi-mode node and a single-mode node can only form a low-transmission-rate link. Similarly, two single-mode nodes can only form a low-transmission-rate link.

[0076] 10C shows a hybrid packet transmission process 1020 in which if the node is a single-mode node 1021, it transmits 1022 firmware / software packets using a low transmission rate. Otherwise, if the node is a multimode node and all of its class U neighbors are multimode nodes 1023, it transmits 1024 firmware / software packets using a high transmission rate. Otherwise, if the node is a multimode node and any class U neighbors are single-mode nodes, it transmits 1025 firmware / software packets using a lower transmission rate.

Claims

1. a multi-mode node and a single-mode node arranged in a multi-hop wireless IoT network; a network manager for distributing firmware / software programs to the multi-mode nodes and the single-mode nodes; The network manager includes a transceiver configured to perform wireless communication by transmitting encoded data packets of the firmware / software program to a first hop node, the first hop node being configured to communicate directly with the network manager, other nodes other than the first hop node being referred to as other hop nodes, and the network manager further includes: at least one processor associated with the transceiver; a memory having the firmware / software program and instructions stored therein, the instructions causing the at least one processor to: dividing the firmware / software program into firmware / software program source blocks; encoding the firmware / software program source blocks into encoded blocks based on a rateless erasure coding scheme; packing the encoded blocks into encoded data packets; and transmitting the encoded data packet to the first-hop node based on a Dynamic Relay Point (DRP) protocol, wherein the first-hop node: and a network manager configured to receive the encoded data packet, decode the received encoded data packet, re-encode the firmware / software program source block, and re-transmit the encoded data packet to distribute the firmware / software distribution to the other hop nodes, wherein the network manager continues to broadcast the encoded data packet to the first hop nodes until R percent (R %) of the first hop nodes have received the entire firmware / software program. The instructions to the at least one processor further include: Missing firmware / software program from the first hop node rebroadcasting the missing source block to the first-hop node in response to receiving a retransmission request for the missing source block; the multi-mode nodes and the single-mode nodes are prioritized into earlier nodes and later nodes, with the earlier nodes attempting to retransmit the firmware / software program source blocks earlier and the later nodes attempting to retransmit the firmware / software program source blocks later; The system, wherein the earlier nodes are defined as those that have more class U neighbors and maintain good link quality to class U neighbors, and the later nodes are defined as those that have fewer class U neighbors or poor link quality to class U neighbors.

2. 2. The system of claim 1, wherein the network manager communicates with the multi-mode nodes and the single-mode nodes in the multi-hop wireless IoT network, and the multi-mode nodes and the single-mode nodes classify their respective neighboring nodes into Class R neighbors and Class U neighbors, wherein the Class R neighbors are neighboring nodes that have successfully received the entire firmware / software program source block from the received encoded data packet, the Class U neighbors are neighboring nodes that have not received the entire firmware / software program source block, and the Class U neighbors have at least one of the firmware / software program source blocks missing.

3. 3. The system of claim 2, wherein the multi-mode node and the single-mode node initially classify all their respective neighboring nodes other than the network manager as the class U neighbors, and the network manager is classified as a class R neighbor by the neighboring nodes of the network manager, and the class R neighbors and the class U neighbors are dynamically updated as the firmware / software distribution progresses.

4. 4. The system of claim 3, wherein the multi-mode node and the single-mode node dynamically update the class-R neighbors and the class-U neighbors based on a hybrid acknowledgment method, wherein transmitting a firmware / software program source block serves as a passive acknowledgment and transmitting a broadcast acknowledgment (ACK) packet serves as an active acknowledgment, and wherein each of the multi-mode node and the single-mode node reclassifies the class-U neighbor to a class-R neighbor upon receiving the passive acknowledgment or the active acknowledgment from a class-U neighbor.

5. 5. The system of claim 4, wherein upon receiving an entire firmware / software program source block successfully decoded from the received encoded data packet, the multimode node and the single-mode node retransmit the firmware / software program source block based on a hybrid packet transmission decision, the multimode node and the single-mode node retransmit the firmware / software program source block only if a class U neighbor exists, and if a class U neighbor does not exist, the multimode node and the single-mode node broadcast an acknowledgement packet.

6. The good link quality threshold QG is set so that the multi-mode node and the single-mode node can encode if the link quality of the multi-mode node and the single-mode node to the class U neighbor object is greater than the good link quality threshold QG.

6. The system of claim 5, wherein the system is defined to retransmit the encoded firmware / software program source block without encoding, and wherein the multimode node and the single-mode node retransmit the encoded firmware / software program source block if the link quality of the multimode node and the single-mode node to the class U neighbor object is less than or equal to the good link quality threshold QG.

7. The system of claim 6 , wherein the good link quality threshold QG is defined based on link quality representations such as expected transmission count (ETX) and received signal strength indicator (RSSI).

8. 2. The system of claim 1, wherein the multi-mode node and the single-mode node stop transmitting the firmware / software program source block when the R % of the class U neighbors have received the firmware / software program source block in its entirety.

9. 2. The system of claim 1, wherein the multimode node and the single-mode node start a timer upon receiving a first firmware / software program source block, and when the timer times out, if the multimode node and the single-mode node have not received the entire firmware / software program source block, send a retransmission request to selected class-R neighbors, the retransmission request including a retransmission request vector of bits including a one bit indicating that the corresponding source block is required and a zero bit indicating that the corresponding source block is not required.

10. 10. The system of claim 9, wherein a class R neighbor is selected for the retransmission request if the class R neighbor has the best link quality or if the class R neighbor is a default parent node in a routing protocol. 【Request Item 11】 【Number 1】 [Request Item 12] [Number 2]

Images