EP3878215A1

EP3878215A1 - Systems and methods for multicast group routing, firmware updating, and next-hop routing in tree-based wireless networks

Info

Publication number: EP3878215A1
Application number: EP19883046.5A
Authority: EP
Inventors: Pinchas Ziv; Reuven Cohen; Eran Ben-Shmuel; Alexander Bilchinsky
Original assignee: Juganu Ltd
Current assignee: Juganu Ltd
Priority date: 2018-11-08
Filing date: 2019-11-08
Publication date: 2021-09-15
Also published as: IL282915A; EP3878215A4; WO2020095114A1; AU2019375082A1

Abstract

Approaches for multicast routing a group packet that includes a payload and routing information (e.g., a target identifier vector and a target multicast group ID) in a network having multiple cells each comprising a parent node and one or more child nodes include establishing and storing one or more child-node multicast group map tables associated with the child node(s) for each cell; receiving a multicast group packet; determining whether to forward the multicast group packet to the child node(s) based at least in part on the child- node multicast group map table(s) associated therewith and the received target identifier vector; and if so, causing the parent node to forward the multicast group packet to the child node(s).

Description

SYSTEMS AND METHODS FOR MULTICAST GROUP ROUTING, FIRMWARE UPDATING, AND NEXT-HOP ROUTING IN TREE-BASED WIRELESS NETWORKS

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of U.S. Provisional Application Nos. 62/757,185 (filed on November 8, 2018), 62/757,186 (filed on November 8, 2018), and 62/757,183 (filed on November 8, 2018); the entire disclosures of which are hereby incorporated by reference.

TECHNICAL FIELD

[0002] The present invention relates generally to tree-based wireless networks, and in various embodiments more specifically to multicast routing, firmware updating and next-hop routing in such networks.

BACKGROUND

[0003] Recent developments of Internet and mobile communication technologies provide diverse multimedia services, which may be provided almost instantaneously over vast distances. The proliferation of compact portable electronic devices such as notebook computers, mobile phones and smart devices have necessitated deployment of such services, which tend to be very data-intensive, over wireless networks.

[0004] One commonly used wireless network has a tree-based structure. This network architecture is often deployed in device networks organized or governed by controllers. For example, tree-based wireless networks are often used when a controller controls a group of network members (or“nodes”); each group member will be reachable via a path across the wireless tree, enabling a point-to-multipoint communication (P2MP) (such as from the controller to the nodes) and multipoint-to-point communication (MP2P) (such as from the nodes to the controller). Common applications include controlled lighting systems, city -wide automatic meter-reading system etc.

[0005] Typically, a network group includes a collection of network nodes that share a certain capability, and a network node may belong to more than one group. For example, the first network group may include all network nodes equipped with sensors for measuring air quality near the nodes, and the second group may include network nodes equipped with streetlight controllers of a specific type. A network node equipped with both the air-quality sensor and the particular streetlight controller may thus belong to both the first and second groups.

[0006] The wireless network may use various random-access algorithms to access the wireless channels. For example, a carrier-sense multiple access with collision avoidance (CSMA/CA) algorithm may be used to access a radio channel for packet delivery (in accordance with, e.g., the IEEE 802.15.4 and 802.11 standards). Generally, the heavier the load on the channel, the more challenging it will be to“acquire” the channel for packet delivery, thereby increasing communication delay and reducing the throughput performance of the wireless network. In addition, the spurious energy from the heavily used channel may “leak” to the adjacent channels and reduce their signal -to-noise ratio, thereby degrading performance. Thus, it is desirable to minimize the load on wireless channels as well as the number of wireless transmissions in order to keep the channels as“clean” as possible. As used herein, the term“channel” is understood as follows. Each node broadcasts within an assigned frequency band of the radio spectrum. Within its assigned band, a node sends and receives data over a smaller band or over a selected one of several smaller bands; each of these smaller bands represents a separate“channel.”

[0007] Conventional approaches for root-originated group packet delivery in a tree network, however, are generally inefficient and may cause heavy loads on the wireless channels. For example, referring to FIG. 1 A, one conventional approach for delivering a packet containing a target group identifier and packet payload from a tree root to a target group is to“flood” the entire tree and broadcast the packet to all nodes thereon. Each node, upon receipt of the broadcast packet, may re-broadcast the received multicast message, compare its group identifiers with that of the received packet, and process the received packet payload in the event of a match to the packet’s group identifiers. But because the broadcasts are not acknowledged, some messages may not reach the target group. In addition, the radio channel may be heavily used across the tree network, i.e., the entire geographical area covered by the tree. Even when a group is collectively located in a specific geographical area and covered by only several nodes, the multicast message is still unnecessarily broadcast across all tree nodes.

[0008] Another conventional approach for multicast delivery of a packet from the tree root to the target group is by individual unicasting. For example, referring to FIG. 1B, the root may generate (or receive from a network management system) a unicast message containing a target multicast group identifier. All nodes along the path to the target node deliver the message as a unicast message with acknowledgement. As a result, the probability that the message will reach the target node is higher than with non-acknowledged delivery via broadcasting. In addition, the radio channel is heavily used only by the nodes that are on the paths to the target nodes. But this approach has its own inefficiencies. A node (e.g., node 102 as depicted) that is on the path to several sub-trees containing the target group member must transmit the packet multiple times, each time for another unicast that propagates on a different path from the root to the target node. For example, the node 102 depicted in FIG.

1B has to deliver two separate unicast messages to the nodes 104 and 106 via the paths 108, 110, respectively.

[0009] Another conventional approach combines unicasting and broadcasting for multicast delivery of a packet from the tree root to the target group. For example, referring to FIG. 1C, the multicast delivery may be performed via unicasting followed by broadcasting.

As depicted, the root node 112 first delivers the message to the“first” node 114 via unicasting; subsequently, the node 114 broadcasts the message to the sub-trees 116, 118 containing the target group members there below. As used herein, the term“first node” refers to the node that receives messages via unicasting. To improve delivery efficiency and reliability, the root node 112 may identify and unicast the message to multiple nodes, which then broadcast the message. For example, as depicted in FIG. 1C, a multicast message can be delivered to node 120 via broadcasting and then to node 122 via unicasting. Although utilization of several“first” nodes may increase the message delivery reliability, it also causes a repeated unicast message delivery across a path that splits into several sub-trees containing, at certain depths, one or more members of the target group. In addition, because the sub-tree delivery still utilizes broadcasting, the reliability of message delivery is worse than that of individual unicasting.

[0010] Thus, conventional schemes for wireless, root-originated group packet delivery have drawbacks, including inefficient and unreliable delivery as well as causing heavy loads on the wireless channels. Consequently, there is a need for approaches that can improve the delivery efficiency and reliability of multicast messages and reduce burdens on the wireless channels.

[0011] In addition, a tree-based wireless network generally includes a collection (e.g., thousands) of network nodes; each node includes a firmware file for performing various functions. The firmware file is typically periodically updated to, for example, provide additional functions and/or update the operating environment for more complex software associated with the nodes. Reliably updating the firmware file throughout thousands of network nodes in the tree-based wireless network, although of the most important and most demanding activities in the wireless network, remains challenging.

[0012] For example, referring to FIG. 1D, one conventional approach for updating the firmware file is to“flood” the entire tree and broadcast an updated firmware file to all nodes thereon. Each node, upon receipt of the broadcast file, may re-broadcast the received file to the“down-the-tree” nodes. But because the broadcasts are not acknowledged, the updated firmware file may not reach some of the nodes.

[0013] Another conventional approach for updating the firmware file in the network is by individual unicasting. For example, referring to FIG. 1E, each node in the network transmits the updated firmware file in a unicasting manner with acknowledgement. As a result, the probability that the firmware file will be received by all nodes is higher than with non- acknowledged delivery via broadcasting. But because the firmware file usually consists of a large amount of payload, it is extremely inefficient to use unicasting to update the firmware file in the tree-based network. A long period of time (e.g., many days) may be required for the firmware file to reach all the thousands of network nodes. Accordingly, there is a need for approaches that can efficiently and reliably update the firmware file in the network nodes in a tree-based wireless network.

[0014] Further, the tree or other network topology over which nodes wirelessly communicate may change dynamically in response to the entry or departure of nodes and changing conditions and constraints. The wireless capabilities of individual nodes may be affected by factors such as effective transmission power, receiver sensitivity, radio interference, hidden terminals, and other factors. Since the wireless environment is constantly changing, so may the route from a source node to a destination node (i.e., the sequence of intermediate nodes, or“hops,” traversed by packets transmitted by the source node en route to the destination node). That route is determined by the routing protocol used by the network; examples include RPL (which uses a DODAG topology and IPv6 for control messages) and Zigbee (which is AODV-based and uses IEEE 802.15.4 MAC for network control messages).

[0015] In general, the routing protocol does not dictate the algorithm used to determine the multi-hop node sequence that a packet will traverse to its destination. The protocol does, however, enable the network nodes to exchange information regarding capabilities and utilization. This allows network nodes to be updated with information about neighboring nodes and their ability to serve as a next hop along a route from source to destination. In one commonly implemented scheme, each node periodically transmits a“beacon” message announcing its capabilities as well as its own neighboring nodes or, in some cases, its internal representation of the network or portion thereof. Beacon messages (or frames) announce the entry of new network nodes, synchronize the nodes, and allow nodes to populate routing tables and make routing decisions based on the capabilities of neighboring nodes. A beacon message may consist of an IEEE 802.11 MAC header, a body, and a frame check sequence. The body includes capability information for the node, e.g., service set ID, support rates, a frequency -hopping parameter set, a direct-sequence parameter set, a contention-free parameter set, an IBSS parameter set, and/or a current traffic-indication map.

[0016] Beacon messages are received by all nodes within“radio distance” of the announcing node, i.e., nodes that can receive direct transmissions from the announcing node and are therefore one-hop neighbors thereof. In order to receive a beacon message, a one-hop neighbor of the announcing node must tune its radio receiver to the radio channel over which the beacon was transmitted. This requirement is easily satisfied if all nodes are use the same channel, but to increase the overall network throughput, radio networks usually use multiple orthogonal (independent) channels. As a result, a beacon will not be received by any one-hop neighbor tuned to a different radio channel during beacon transmission.

[0017] One way to allow nodes to receive beacon announcements in a multi-channel wireless network is to equip each node with two sets of radio receivers. Every node can use one receiver for routine communication over its currently assigned channel and the other receiver to handle beacons. The need for redundant hardware and attendant software is expensive, however. Accordingly, a more common scheme is for a node with a single receiver to temporarily“hold” its activities on its current communication channel and request one-hop neighbors to hold their traffic to the announcing node as well. During the hold, the requesting node switches its receiver to another channel for a certain interval in order to receive beacons over the other channel by one-hop neighbors. This procedure is termed“hold and sniff.” Because normal traffic flow is interrupted during the hold period, it is desirable to minimize that period. Conventional hold-and-sniff protocols, however, generally utilize a fixed period.

SUMMARY

[0018] Various embodiments of the present invention relate to efficient and reliable multicast routing of a group packet in a tree-based wireless network by minimizing wireless transmissions, thereby reducing the loads on the wireless channels. In various embodiments, the group packet includes a payload and routing information (such as a target bit identifier vector and a target multicast group ID). In addition, in each node of the network, a parent- node multicast group map (MGM) table associated with the node (i.e., parent node) and one or more child-node MGM tables associated with the child node(s) of the parent node may be established and stored in memory accessible to a network management system (NMS). The parent-node MGM table and child-node MGM tables may include information, such as one or more identifiers (IDs) associated with the multicast group(s) in which the parent/child node(s) is a member and/or a bit identifier vector(s) for pointing to the bit(s) in the parent-node/child- node MGM tables representing the supporting group ID(s). In various embodiments, upon receipt of a multicast group packet, the parent node retrieves information stored in the parent- node MGM table and/or child-node MGM tables based on routing information in the group packet; the parent node can then determine whether to forward the multicast group packet to any of its child nodes based on the retrieved information. Accordingly, the multicast routing traffic described herein does not reach network nodes that neither contain the target group members nor are a transit node on the path to the target group node(s). As a result, the duration and the number of packet transmissions from the parent nodes to their associated child nodes across the wireless network may be minimized (or at least reduced relative to conventional routing schemes), thereby decreasing the bandwidth consumption and interference. This may significantly increase the overall throughput, reduce the delay performance of the network, and reduce the likelihood of a“punctured” packet due to bit hits, thereby maintaining“clean air” in the wireless channels. In addition, because the group packet is no longer required to include the complete, explicit route required in some conventional routing approaches, embodiments of the invention described herein may advantageously save bandwidth as well as allow for a larger payload in each delivery.

[0019] In addition, the present invention is related to approaches for efficiently and reliably updating a firmware file in a tree-based wireless network by broadcasting the firmware file in the network nodes and allowing the network nodes that transmit and receive the firmware file to communicate so as to ensure receipt of the firmware file in each of the receiving nodes. In various embodiments, the firmware file is divided into multiple chunks (or“blocks”); each chunk is assigned with a sequence number based on its order in the divided firmware file and can be included in a single data packet for transmission from a network node to another network node. In addition, each chunk in the data packet may be preceded by a header that describes, for example, a type of the updated firmware file, a time stamp indicating the release time of the firmware file and/or a sequence number associated with the chunk. In one embodiment, the data packet including the chunk and its associated header can then be broadcast from the root node to its associated child nodes in a transceiver cell. Upon receipt of the data packet, the receiving nodes may determine whether the chunk contained therein is“new” (i.e., an updated version); and if so, the receiving nodes may accept the new chunk and schedule it for future broadcasting to its child nodes in its associated cell.

[0020] To ensure reliability of the broadcasting (i.e., each node indeed receives the broadcast chunk), in various embodiments, the parent node periodically transmits to its child nodes a negative-acknowledgment (NACK)-request message indicating the types, time stamps and/or sequence numbers associated with all (or at least some) chunks that the parent node has transmitted. In response to the NACK-request message, each child node may identify the chunk(s) that is listed in the NACK-request message but currently missing in the child node, and report the missing chunk(s) to the parent node using aNACK message. In some embodiments, a transmission approach involving drawing of a random time for the child node to wait before it transmits its NACK message to the parent node is implemented to minimize the number of transmissions of the NACK messages from each child node to the parent node, thereby preventing a“NACK storm” in the parent node.

[0021] In some embodiments, upon receipt of the NACK message indicating a list of missing chunks in at least one of its child nodes, the parent node adds the indicated missing chunks to its future schedule for broadcasting. The future schedule may include the missing chunks identified in the NACK messages as well as new chunks that have not been broadcast. In one embodiment, a scheduler logic that classifies the chunks into three states can then be implemented to determine the timing for transmitting a new chunk and/or re-transmitting an old, missing chunk based on the states of the chunks.

[0022] Accordingly, various embodiments provide approaches to efficiently updating the firmware file in the network nodes by broadcasting the chunks of the firmware file in the wireless network. In addition, various embodiments ensure reliability of the broadcasting by using the NACK-request messages transmitted from the parent nodes to their associated child nodes and the NACK messages transmitted from the child nodes to the parent nodes in response to the received NACK-request messages.

[0023] Further, various embodiments of the present invention relate to efficient and reliable communication of beacons among neighboring nodes in a wireless network. In particular, instead of having each node transmit beacons over its operational channel and switch to a different channel to receive its one-hop neighbors’ beacons, nodes transmit beacons over a different channel (i.e., different from the operational channel) and receive beacons over their operational channels. These outgoing“visitor beacons” may contain the usual beacon information but most importantly specify the operating channel of the transmitting node over which conventional beacons may be transmitted and received. In many cases, the fact that a beacon-transmitting node switches channels while a beacon receiving node communicates over its regular channel helps reduce the overall time during which nodes are not available on their regular channels.

[0024] Accordingly, in one aspect, the invention pertains to a method of multicast routing a group packet in a network including multiple cells, each supporting communication among multiple transceiver nodes therein and being capable of receiving and transmitting group packets, each cell including a parent node and one or more child nodes, each group packet including routing information and a payload. In various embodiments, the method includes (a) for each cell, establishing and storing one or more child-node multicast group map tables associated with the child node(s), each of the child-node multicast group map table(s) including (i) an ID associated with at least one multicast group in which the cell is a member and (ii) at least one identifier vector for identifying the multicast group ID in the child-node multicast group map table; (b) receiving a multicast group packet whose routing information includes a target identifier vector and a target multicast group ID; (c) determining whether to forward the multicast group packet to the child node(s) based at least in part on the child- node multicast group map table(s) associated therewith and the received target identifier vector; and (d) if so, causing the parent node to forward the multicast group packet to the child node(s). In one implementation, the identifier vector points to a bit in the child-node multicast group map table and step (c) includes determining whether the bit pointed to by the received target identifier vector is set to a non-zero value, and if so, causing the parent node to forward the multicast group packet to the child node(s).

[0025] The method may further include establishing and storing a parent-node multicast group map table associated with the parent node, the parent-node multicast group map table including (i) an ID associated with each multicast group IDs supported by all of the child node(s) of the parent node and subtrees associated therewith and (ii) at least one identifier vector merging the identifier vectors associated with all of the child node(s) of the parent node. In one embodiment, the parent-node multicast group map table is established by applying a bitwise OR operation on the child-node multicast group map table(s) of the child nodes of the parent node. In addition, the child-node multicast group map table(s) may have a size corresponding to a maximum number of the multicast group supported by the network. [0026] In some embodiments, the forwarding step includes forwarding, by the parent node, the multicast group packet to the child node(s) in a broadcasting or multiple unicasting manner. In addition, the method may further include determining a number of the child nodes to which the multicast group packet is forwarded. In one embodiment, the method further includes causing the parent node to forward the multicast group packet in a broadcasting manner if the number of the child nodes to which the multicast group packet is forwarded exceeds one. In addition, the method may further include causing the parent node to forward the multicast group packet in a unicasting manner if the multicast group packet is forwarded to a single child node. In various embodiments, the method further includes determining whether the target multicast group ID associated with the group packet matches the multicast group ID in the child-node multicast group map table(s); and if so, causing the group packet to be transferred to a higher stack layer within the child node(s).

[0027] In another aspect, the invention relates to a network system for multicast routing a group packet in a network including multiple cells, each supporting communication among multiple transceiver nodes therein and being capable of receiving and transmitting group packets, each cell including a parent node and one or more child nodes, each group packet including routing information and a payload. In various embodiments, the system includes memory for storing one or more child-node multicast group map tables associated with the child node(s), each of the child-node multicast group map table(s) including (i) an ID associated with at least one multicast group and (ii) at least one identifier vector for identifying the multicast group ID in the child-node multicast group map table; and multiple network management systems associated with the network system and each of the transceiver nodes. In one implementation, the network management system associated with the network system is configured to receive a multicast group packet whose routing information includes a target identifier vector and a target multicast group ID; and the network management system associated with each of the nodes is configured to (i) determine whether to forward the multicast group packet to the child node(s) based at least in part on the child-node multicast group map table(s) associated therewith and the received target identifier vector; and (ii) if so, cause the parent node to forward the multicast group packet to the child node(s). In one embodiment, the identifier vector points to a bit in the child-node multicast group map table and the network management system associated with each node is further configured to determine whether the bit pointed to by the received target identifier vector is set to a non zero value, and if so, cause the parent node to forward the multicast group packet to the one or more child nodes. [0028] The network management system associated with each node may be further configured to establish a parent-node multicast group map table associated with the parent node, the parent-node multicast group map table including (i) an ID associated with each multicast group IDs supported by all of the child node(s) of the parent node and subtrees associated therewith and (ii) at least one identifier vector merging the identifier vectors associated with all of the child node(s) of the parent node; and store the parent-node multicast group map in the memory. In addition, the network management system associated with each node may be further configured to establish the parent-node multicast group map table by applying a bitwise OR operation on the child-node multicast group map table(s) of the child nodes of the parent node. The child-node multicast group map table(s) may have a size corresponding to a maximum number of the multicast group supported by the network.

[0029] In some embodiments, the network management system associated with each node is further configured to forward, by the parent node, the multicast group packet to the child node(s) in a broadcasting or multiple unicasting manner. In addition, the network management system associated with each node is further configured to determine a number of the child nodes to which the multicast group packet is forwarded. In one embodiment, the network management system associated with each node is further configured to cause the parent node to forward the multicast group packet in a broadcasting manner if the number of the child nodes to which the multicast group packet is forwarded exceeds one. In addition, the network management system associated with each node is further configured to cause the parent node to forward the multicast group packet in a unicasting manner if the multicast group packet is forwarded to a single child node. In some embodiments, the network management system associated with each node is further configured to determine whether the target multicast group ID associated with the group packet matches the multicast group ID in the child-node multicast group map table(s); and if so, cause the group packet to be transferred to a higher stack layer within the child node(s).

[0030] Another aspect of the invention relates to a method of updating a firmware file in a network including multiple cells, each supporting communication among multiple transceiver nodes therein and being capable of receiving and transmitting the firmware file, each cell including a parent node and one or more child nodes. In various embodiments, the method includes (a) dividing the firmware file into multiple chunks, each chunk being able to be included in a single data packet transmitted between two of the transceiver nodes; (b) transmitting each of the chunks from the first one of the transceiver nodes to the second one of the transceiver nodes; (c) transmitting a request message from the first one of the transceiver nodes to the second one of the transceiver nodes, the request message including information associated with the chunks that have been transmitted in step (b); and (d) transmitting a responding message from the second one of the transceiver nodes to the first one of the transceiver nodes, the responding message including information associated with at least one of the chunks that is included in the request message of step (c) but not received by the second one of the transceiver nodes.

[0031] The method may further include assigning a sequence number to each of the chunks based at least in part on an order of the chunk in the divided firmware file. In addition, each of the chunks in its associated data packet may be preceded by a header including information such as a type of the firmware file, a time stamp indicating a release time of the firmware file, and/or the sequence number associated with the chunk. In some embodiments, the information associated with the chunks in the request message and responding message includes the sequence numbers associated with the chunks. In addition, the method may further include, upon the first one of the transceiver nodes receiving the responding message, storing the sequence number associated with the at least one of the chunks in a delivery queue associated with the first one of the transceiver nodes for further transmission. In one embodiment, the method further includes classifying each of the chunks in the delivery queue into multiple states based at least in part on a status of the chunk in a child node associated with the first one of the transceiver nodes. Further, the method may further include determining a timing for transmitting each of the chunks in the delivery queue based at least in part on its associated state.

[0032] In various embodiments, the method further includes, upon the second one of the transceiver nodes receiving the transmitted chunks, determining whether each of the received chunks is associated with a most recently released version of the firmware file. In addition, the method may further include, upon determining that the chunk is associated with the most recently released version of the firmware file, storing the chunk in a database associated with the second one of the transceiver nodes and causing the second one of the transceiver nodes to transmit the chunk to one or more child nodes associated therewith. In one embodiment, the chunks in step (b) are transmitted in a broadcasting manner.

[0033] In some embodiments, the method further includes, prior to step (d), determining a time interval for the second one of the transceiver nodes to wait before transmitting the responding message to the first one of the transceiver nodes. The time interval may be determined based at least in part on a number of the chunks included in the request message of step (c) that are not received by the second one of the transceiver nodes. In addition, each of the transceiver nodes may store exactly one complete version of the firmware file whose chunks are all received and at most one outstanding version whose chunks are only partially received.

[0034] In yet another aspect, the invention pertains to a network system for updating a firmware file in a network including multiple cells, each supporting communication among multiple transceiver nodes therein and being capable of receiving and transmitting the firmware file, each cell including a parent node and one or more child nodes. In various embodiments, the system includes one or more network management systems associated with one or more of the transceiver nodes; the network management system(s) is configured to (a) divide the firmware file into multiple chunks, each chunk being able to be included in a single data packet transmitted between two of the transceiver nodes; (b) transmit each of the chunks from the first one of the transceiver nodes to the second one of the transceiver nodes; (c) transmit a request message from the first one of the transceiver nodes to the second one of the transceiver nodes, the request message including information associated with the chunks that have been transmitted in step (b); and (d) transmit a responding message from the second one of the transceiver nodes to the first one of the transceiver nodes, the responding message including information associated with one or more chunks that is included in the request message of step (c) but not received by the second one of the transceiver nodes.

[0035] The network management system(s) may be further configured to assign a sequence number to each of the chunks based at least in part on an order of the chunk in the divided firmware file. In addition, each of the chunks in its associated data packet may be preceded by a header including information such as a type of the firmware file, a time stamp indicating a release time of the firmware file, and/or the sequence number associated with the chunk. Further, the information associated with the chunks in the request message and responding message may include the sequence numbers associated with the chunks. In one embodiment, the network system further includes memory for storing a delivery queue associated with the first one of the transceiver nodes; the network management system(s) is further configured to, upon the first one of the transceiver nodes receiving the responding message, store the sequence number associated with the chunk(s) in the delivery queue for further transmission. In addition, the network management system(s) may be further configured to classify each of the chunks in the delivery queue into multiple states based at least in part on a status of the chunk in a child node associated with the first one of the transceiver nodes. In one embodiment, the network management system(s) is further configured to determine a timing for transmitting each of the chunks in the delivery queue based at least in part on its associated state.

[0036] The network management system(s) may be further configured to, upon the second one of the transceiver nodes receiving the transmitted chunks, determine whether each of the received chunks is associated with a most recently released version of the firmware file. In addition, the network system may further include memory for storing the received chunks in a database associated with the second one of the transceiver nodes; the network management system(s) is then further configured to, upon determining that the received chunks are associated with the most recently released version of the firmware file, cause the second one of the transceiver nodes to transmit the chunks to one or more child nodes associated therewith.

[0037] In some embodiments, the chunks in step (b) are transmitted in a broadcasting manner. In addition, the network management system(s) may be further configured to, prior to step (d), determine a time interval for the second one of the transceiver nodes to wait before transmitting the responding message to the first one of the transceiver nodes. In one embodiment, the time interval is determined based at least in part on a number of the chunks included in the request message of step (c) that are not received by the second one of the transceiver nodes. Further, each of the transceiver nodes may store exactly one complete version of the firmware file whose chunks are all received and at most one outstanding version whose chunks are only partially received.

[0038] Still another aspect of the invention relates to a method of efficient beacon communication in a wireless network including multiple nodes, each supporting

communication over multiple distinct channels including at least one operational channel for receiving and transmitting data traffic to and from other nodes. In various embodiments, the method includes, for each node, (a) transmitting conventional beacons over the operational channel, the conventional beacons reaching one-hop neighboring nodes having operational channels matching the operational channel of the node; and (b) transmitting, by the node, visitor beacons to all other neighboring nodes over one or more channels, different from the operational channel of the node, the visitor beacons specifying the operational channel of the node, whereby each of the other neighboring nodes receives conventional beacons from the node over a secondary channel matching the operational channel of the node, the secondary channel being different from the one or more channels utilized to transmit the visitor beacons.

[0039] In some embodiments, a conventional beacon transmitted by a node includes data specifying capabilities of the node and neighboring nodes. In addition, the conventional beacon may also include data specifying an internal representation of the network or portion thereof. Further, the visitor beacon may also include data specifying capabilities of the node and neighboring nodes. In one embodiment, the operational channel of the node is inactive in step (b). In various embodiments, each node is also configured to operate in a hold-and-sniff mode whereby the node signals its associated parent node in the wireless network to cease, for a defined interval, transmission over the operational channel of the node; the node receives the beacons from one or more one-hop neighboring nodes in the wireless network over one or more tertiary channels thereof during the defined interval, the one or more tertiary channels being different from the operational channels of the node. In addition, the operational channel of the node may be inactive when the node is receiving the beacons over the one or more tertiary channels.

[0040] In another aspect, the invention relates to a node for communicating over a wireless network; the node includes at least one radio transceiver for supporting

communication over at least one operational. In various embodiments, the node is configured for (a) transmitting conventional beacons over the operational channel, the conventional beacons reaching one-hop neighboring nodes having operational channels matching the operational channel of the node, and (b) transmitting visitor beacons to all other neighboring nodes over one or more channels, different from the operational channel of the node, the visitor beacons specifying the operational channel of the node, whereby each of the other neighboring nodes receives conventional beacons from the node over a secondary channel matching the operational channel of the node, the secondary channel being different from the one or more channels utilized to transmit the visitor beacons.

[0041] In some embodiments, a conventional beacon transmitted by the node includes data specifying capabilities of the node and neighboring nodes. In addition, the conventional beacon may also include data specifying an internal representation of the network or portion thereof. Further, the visitor beacon may also include data specifying capabilities of the node and neighboring nodes. In one embodiment, the node is configured such that the operational channel of the node is inactive in step (b). In various embodiments, the node is also configured to operate in a hold-and-sniff mode whereby the node signals its associated parent node in the wireless network to cease, for a defined interval, transmission over the operational channel of the node; the node receives the beacons from one or more one-hop neighboring nodes in the wireless network over one or more tertiary channels thereof during the defined interval, the one or more tertiary channels being different from the operational channels of the node. In addition, the node may be configured such that the operational channel of the node is inactive when the node is receiving the beacons over the one or more tertiary channels.

[0042] As used herein, the term“chunk” refers to a logical partition of data that is smaller than the firmware file and can be included in a single data packet. In addition, the terms “approximately,”“roughly,” and“substantially” mean ±10%, and in some embodiments,

±5%. Reference throughout this specification to“one example,”“an example,”“one embodiment,” or“an embodiment” means that a particular feature, structure, or characteristic described in connection with the example is included in at least one example of the present technology. Thus, the occurrences of the phrases“in one example,”“in an example,”“one embodiment,” or“an embodiment” in various places throughout this specification are not necessarily all referring to the same example. Furthermore, the particular features, structures, routines, steps, or characteristics may be combined in any suitable manner in one or more examples of the technology. The headings provided herein are for convenience only and are not intended to limit or interpret the scope or meaning of the claimed technology.

BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In the drawings, like reference characters generally refer to the same parts throughout the different views. Also, the drawings are not necessarily to scale, with an emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments of the present invention are described with reference to the following drawings, in which:

[0044] FIGS. 1A-1C depict various conventional approaches for multicast delivery of a packet from a root node to a target group of nodes in a tree-based wireless network;

[0045] FIGS. 1D and 1E depict various conventional approaches for updating a firmware file in a tree-based wireless network;

[0046] FIG. 2 conceptually illustrates an exemplary tree-based wireless network having multiple network nodes for multicast routing messages in accordance with various embodiments;

[0047] FIG. 3 is a flow chart illustrating an exemplary approach for multicast routing a group packet in a tree-based wireless network in accordance with various embodiments;

[0048] FIG. 4 illustrates a tree-based wireless network having multiple network nodes, each including a parent-node MGM table and one or more child-node MGM tables in accordance with various embodiments; [0049] FIG. 5 illustrates an exemplary approach for processing a received group packet in a network node in accordance with various embodiments;

[0050] FIG. 6A is a flow chart illustrating an exemplary approach for adding a new multicast group ID to a target network node in accordance with various embodiments;

[0051] FIG. 6B is a flow chart illustrating an exemplary approach for adding a new multicast group ID to all nodes controlled by a target gateway in accordance with various embodiments;

[0052] FIG. 7A is a flow chart illustrating an exemplary approach for removing a multicast group ID from a target network node in accordance with various embodiments;

[0053] FIG. 7B is a flow chart illustrating an exemplary approach for removing a multicast group ID from all nodes controlled by a target gateway in accordance with various embodiments;

[0054] FIG. 8 is a flow chart illustrating an exemplary approach for associating a node with a new parent node in accordance with various embodiments;

[0055] FIG. 9 is a flow chart illustrating an exemplary approach for de-associating a child node from a parent node in accordance with various embodiments;

[0056] FIG. 10 conceptually illustrates an exemplary tree-based wireless network having multiple network nodes in accordance with various embodiments;

[0057] FIG. 11 conceptually depicts an exemplary tree-based wireless network having a parent node and child nodes in a transceiver cell and another nodes outside the transceiver cell in accordance with various embodiments;

[0058] FIG. 12 illustrates three states associated with each chunk of a firmware file in accordance with various embodiments;

[0059] FIG. 13 is a flow chart illustrating an exemplary approach for updating a firmware file in the network nodes in accordance with various embodiments; and

[0060] FIG. 14 is a flow chart illustrating an exemplary approach for minimize the number of message transmissions from the child nodes to the parent nodes in accordance with various embodiments.

[0061] FIG. 15 conceptually illustrates an exemplary tree-based wireless network having multiple network nodes for routing messages in accordance with various embodiments; and [0062] FIG. 16 illustrates a plurality of network nodes configured for operation in accordance with embodiments of the invention. DETAILED DESCRIPTION

Multicast Routing a Group Packet in a Tree-Based Wireless Network

[0063] FIG. 2 conceptually illustrates an exemplary tree-based wireless network 200 comprising multiple network nodes 202, each including one parent node and one child node, for multicast routing of messages such as group packets across the network 200 in accordance herewith; each group packet may include a payload (e.g., a data packet) and routing information (such as target bit identifier vectors, target multicast group IDs, etc.) as further described below.

[0064] Each network node 202 is a member of a transceiver“cell,” i.e., a discrete geographic region having fixed-location transceivers on, for example, lighting poles. A transceiver cell typically includes a“parent” node (e.g., node 204) and one or more child nodes (e.g., nodes 206-210). In addition, each of the parent and child nodes may include one transceiver. The parent node is the“owner” of the cell node(s); a child node may be associated with only one parent node at a time. In one embodiment, the child nodes connect to their parent nodes via a“wireless tree branch.” The child node(s) in a cell are within the radio transmission range of the parent node and vice versa. Typically, the parent node and its child nodes are within a one-hop distance from each other. In each cell, a data packet can be delivered in a“downlinked” manner— i.e., from the parent node to its child node(s) (e.g., using broadcasting to all child nodes or unicasting to a specific child node) and/or in an “uplinked” manner— i.e., from a child node to its associated parent node using, for example, unicasting. If the data packet received by the child node does not originate from its associated parent node, the child node may discard the data packet. Similarly, if the data packet received by the parent node does not originate from one of its associated child nodes, the parent node may discard the data packet.

[0065] In various embodiments, each node acts as both a parent node (defined herein as “DL”) and a child node (defined herein as“UL”). The DL node is an entity contained in a node that acts as a cell parent; and the other cell members are child nodes of the parent node located one hop away from the DL node. Similarly, the UL node is an entity contained in a node and is a cell member“owned” by a DL parent in another node (e.g., one-hop distance away that acts as the parent).

[0066] The tree-based wireless network 200 may be constructed dynamically using one or more conventional protocols and algorithms. In one embodiment, the network 200 is constructed as a spanning tree that interconnects each network node via a unique path to the tree root node. The same path may connect the tree root node to a network node. In some embodiments, the network 200 is constructed as multiple spanning trees with appropriate identifiers per tree; each tree (and thereby its associated identifier) supports a unique path between the tree root node and a network node on that tree. Thus, a downlink data packet that“originates” from the tree root node (or a network management system) may traverse a path across the tree that includes a collection of the network nodes wirelessly interconnected from the parent node of one network node to a child node within the parent’s cell (i.e., one hop away). The destination network node can be reached via multiple hops. For a given tree, the path from the root node to the target node is always the same; in other words, the path acts as a“virtual circuit” for a data packet to be delivered from the root node to a target node. The virtual circuit may maintain the in-order delivery of packets, but does not guarantee that all delivered packets will reach the destination. It should be noted that because the path is created dynamically, the path may change while payload packets are in transit. As a result, the packets may arrive out of sequence. When this occurs, a transport protocol (e.g. TCP/IP) may be implemented to handle such out-of-sequence received packets and organize them to an application in the proper sequence. Similarly, an uplink message may be delivered from a node to the root node via traversing a path therebetween. For example, assuming that nodes X, Y, Z are along the path from the node originating the message to the tree root node, the message may propagate in the uplink manner along the wireless branches— i.e., from the originating node UL (e.g., a child contained within node X) to its associated DL (e.g., the parent contained within node Y), then internally propagate from the receiving DL to the UL contained within the same node (e.g., node Y), then propagate further up to the DL (e.g., contained within node Z) associated with the UL within node Y, and so on.

[0067] In various embodiments, each node contains two radio transceivers: one used by the parent within the node to send and/or receive data packets from the associated child node(s) and the other used by a child node within the node to send and/or receive data packets from the associated parent in another node. In addition, the tree structure may enable (i) each network node to deliver an uplink message directed to the tree root node (using e.g., MP2P) via a path determined by the tree structure, and (ii) the root node to deliver a downlink unicast message to a selected node (using e.g., P2MP) via a path determined by the tree structure.

[0068] In addition, a collection of network nodes that have the same capability (e.g., equipped with a specific type of streetlight controller) may form a group. Each network node may be a member of (and thereby support) one or more groups. For example, a node may be a member of a city wide sensor group and a member of a group corresponding to a specific type of street lighting controller. The group members may be distributed across the tree structure in any fashion. For example, the group members may be concentrated in a geographical area (e.g., light controllers distributed in a specific neighborhood) or may be distributed citywide (e.g., air-quality sensors distributed across a city). In addition, the geographical location of one group may or may not overlap with that of another group. The tree-based network 200 can (but need not necessarily) be optimized for a certain group delivery. In one embodiment, the tree-based network 200 is constructed with various optimization rules without considering the possible group distributions.

[0069] In various embodiments, the delivered message is a“short” message that can be contained in one packet, and each packet is delivered and processed as soon as the packet is received by a node. To allow for multicast message delivery, each node may include a database storing one or more group identifiers (IDs) associated with the group(s) it is a member of. A multicast message may be propagated“down” the tree to a single target group ID. In addition, the child node may accept only messages transmitted from its associated parent. When the root node broadcasts a message, the message received by the receiving node(s) may be re-broadcast without acknowledgement. When the root node unicasts a message to a target node, however, each receiving node on the propagation path may acknowledge the unicasting.

[0070] In various embodiments, a network management system (NMS) 212 is employed in the wireless tree network 200. The NMS 212 may control one or more gateways that act as tree root nodes to the tree-based network. In addition, the NMS 212 may generate a message (e.g., a group packet) to the tree root(s) which then transmits the message to a specific network node or to a group of network nodes. In addition, the NMS 212 may be equipped with memory having a database to store information associated with the tree root nodes, network nodes and groups reachable via the corresponding tree roots. In some embodiments, each node in the network 200 includes an individual network management system 214 for performing various functions, such as multicast routing a group packet in the network, adding a multicast group ID to the network, removing a multicast group ID from the network, associating a node with a new parent node, de-associating a node from its parent node, etc. as further described below. The NMS 212/214 may include or consist essentially of a computing device, e.g., a server, which executes various program modules to perform methods in accordance with embodiments of the present invention. In addition, the memory may include or consist essentially of one or more volatile or non-volatile storage devices, e.g., random-access memory (RAM) devices such as DRAM, SRAM, etc., read-only memory (ROM) devices, magnetic disks, optical disks, flash memory devices, and/or other solid-state memory devices to store, for example, information associated with the tree root nodes and network nodes.

[0071] FIG. 3 illustrates an exemplary approach 300 for multicast routing a group packet in a tree-based wireless network including multiple network nodes. FIG. 4 illustrates a tree- based wireless network 400 including network nodes 402-414, each of which itself includes a parent node and one or more child nodes. In various embodiments, each parent node either broadcasts or unicasts the multicast group packet to its associated child node(s) in another network node(s). For example, the parent node 422 in the network node 402 may broadcast or unicast the multicast group packet to its associated child nodes 424, 426, 428 in the network node 404, 406, 408, respectively; the parent node 430 in the network node 404 may broadcast or unicast the multicast group packet to its associated child node 432 in the network node 410; and the parent node 440 in the network node 406 may broadcast or unicast the multicast group packet to its associated child nodes 442, 444 in the network nodes 412, 414, respectively.

[0072] Referring again to FIG. 3, in various embodiments, prior to routing the group packet in the network, a multicast group map (MGM) table associated with each of the parent and child nodes is established and stored in memory that can be accessed by the NMS 212/214 (step 302). The size of each MGM table equals the maximum number of multicast groups that can be supported by the network. For example, referring to FIG. 4, the network node 402 may include a parent-node MGM table 452 corresponding to the parent node 422 and child-node MGM tables 454, 456, 458 corresponding to its associated child nodes 404, 406, 408, respectively. In one embodiment, each child-node MGM table includes one or more IDs associated with the network group(s) of which the network node is a member and one or more bit identifier vectors. The group ID(s) are represented using a bit map having one or more bits assigned by the NMS 212/214; and the bit identifier vector(s) point to the bit(s) in the child-node MGM table representing the supported multicast group ID(s).

Similarly, each parent-node MGM table may include a bit map having one or more bits corresponding to one or more IDs associated with the multicast group(s) supported by all of the associated child nodes and the subtrees associated therewith. In addition, the parent-node MGM table may include one or more bit identifier vectors merging the bit identifier vectors associated with all of its associated child nodes. In one implementation, the bit identifier vector(s) in the parent-node MGM table is obtained by applying a bitwise OR operation on the contents of the child-node MGM tables associated with all the child nodes associated therewith.

[0073] In the parent-node MGM table, when the value in a bit position is set with a non zero value (or“SET,” for ease of reference herein), the path to the target multicast group ID includes one of this node’s child nodes. Similarly, when a value in a bit position of a child- node MGM table is SET (i.e., has a non-zero value), the path to the target multicast group ID includes the child node. Because several child nodes may be on the paths to the target multicast group ID, the corresponding bit positions in the child-node MGM tables can all be SET. It should be noted that if a bit in the parent-node or child-node MGM Table is SET, this does not necessarily mean that this parent/child node supports the corresponding multicast group; rather, it merely means that this parent/child node is on the path to the corresponding multicast group ID.

[0074] In a“leaf’ node (i.e., a node having no child nodes), the content of all bits in the parent-node MGM table and the child-node MGM tables (if exist) is set with the zero value (or“CLEAR,” for ease of reference herein). Again, this does not necessarily mean that the leaf node supports any multicast group ID. In case that the leaf node supports one or more multicast group IDs, a list of the multicast group IDs supported by the node may be stored in a database associated therewith.

[0075] In addition, it should be noted that the NMS 212/214 may create the child-node MGM tables during node initialization or dynamically when the child node is associated with its parent node. Further, the child node may change its associated parent node. When this occurs, the NMS 212/214 may change the child-node MGM table, the prior parent’s parent- node MGM table, the new parent’s parent-node MGM table and/or the gateway(s) involving the child node. In addition, the NMS 212/214 may add or delete multicast group processes as further described below for updating the multicast group IDs associated with the child node, prior parent node and/or new parent node.

[0076] Refer again to FIG. 4, which depicts exemplary parent-node MGM table 452 and child-node MGM tables 454-458. As shown, the network 400 may support up to 16 multicast groups. Each of the parent-node MGM table and child-node MGM tables stored in the database associated with the node 402 is represented by two bytes (e.g., byte 1 followed by byte 2 as depicted); each byte has eight bits, 1-8. In addition, the bit identifier vector is represented by {“row number,”“column number”} in the table. In this example, the row number and column number are represented in the decimal values. Note that for the binary representation, four bits may be necessary for presentation of the bit identifier. Based on the parent-node MGM table 452 stored in the node 402, the node 402, which is a parent node of the child nodes 404-408, is on the paths to (i) a multicast group having an ID = Y with a bit identifier vector = {2,3}, (ii) a multicast group having an ID = Z with a bit identifier vector = {1,5}, and (iii) multicast group having an ID = V with a bit identifier vector = {1,7}.

Similarly, based on the child-node MGM tables 454-458 stored in the node 402, the node 404 is on the paths to (i) the multicast group having the ID = Y with the bit identifier vector = {2,3} and (ii) the multicast group having the ID = V with the bit identifier vector = {1,7}; the node 406 is on the paths to (i) the multicast group having the ID = Y with the bit identifier vector = {2,3} and (ii) the multicast group having the ID = Z with the bit identifier vector = {1,5}; and the node 408 is a“leaf node” having no child nodes and supporting the multicast group having the ID = Y with the bit identifier vector = {2,3}.

[0077] Referring again to FIG. 3, in a second step 304, the NMS 212 may cause a multicast group packet having routing information (such as a target bit identifier vector and/or a target multicast group ID) to be delivered from the NMS 212 or a transmitting node (e.g., root node) to a receiving node in the wireless network. For example, as shown in FIG. 4, the NMS 212 may transmit a group packet to the node 402. Upon receiving the group packet, the receiving node (e.g., node 402) may check the content of the parent-node MGM table and/or the child-node MGM table(s) stored in the database associated therewith to determine whether the bit in the parent-node MGM table and/or child-node MGM tables pointed to by the target bit identifier vector contained in the received group packet is SET (i.e., has a non-zero value) (in a third step 306). If so, at least one of the child nodes (e.g., nodes 404-408) associated with this parent node (e.g., node 402) is on the path to the target multicast group having the ID identified in the routing information of the received group packet, and the parent node (e.g., node 402) may contain at least one subtree that has a node belonging to the target multicast group ID. Subsequently, the receiving node (e.g., node 402) may forward the received group packet to the child node that is on the path to, or has a node belonging to, the target multicast group ID as further described below (step 308). If, however, the bit in the parent-node MGM table and/or child-node MGM tables pointed to by the target bit identifier vector is CLEAR (i.e., has a value of zero), the group packet has reached the target group ID. In other words, this receiving node (e.g., node 402) is a “multicast group leaf node” for the target multicast group ID, and no child nodes associated with the receiving node have subtrees that support the target multicast group ID. As a result, the receiving node may not forward the received group packet to any of its associated cell child nodes (step 310). [0078] After the receiving parent node (e.g., node 402) determines that one or more of the subtrees of its associated child nodes contain the target multicast group ID, the receiving parent node (e.g., node 402) may determine the approach to forwarding the multicast group packet; this may be based on, for example, the number of child nodes to which the multicast group packet is forwarded (step 312). In some embodiments, when the number of the child nodes to which the multicast group packet is forwarded exceeds one, the parent node may forward the multicast group packet in a broadcasting manner (step 314). When the multicast group packet is forwarded to a single child node only, the parent node may forward the multicast group packet in a unicasting manner (step 316). In one implementation, the receiving parent node transmits the multicast group packet to the child node(s) using broadcasting or multiple unicasting. Whether broadcasting or multiple unicasting is used may depend on the distributed fashion of the nodes traversed by the multicast group packet. Alternatively, the receiving parent node (e.g., node 402) may forward the multicast group packet to the child node(s) in a broadcasting or multiple unicasting manner without determining the number of child nodes to which the multicast group packet is forwarded (step 318).

[0079] FIG. 5 illustrates an exemplary approach 500 for processing a received group packet in a network node in accordance herewith. In various embodiments, after the group packet is received by the leaf node and/or the child node(s), the leaf node and/or the child node(s) may compare the target multicast group ID included in the received group packet with the list of multicast group IDs supported by the node (step 502). If the target multicast group ID indicated by the group packet matches one of the group IDs supported by the node, the node may transfer the received group packet to a higher protocol stack layer within the node for further processing (step 504). If, however, the received target multicast group ID does not match any of the group IDs supported by the node, the group packet is not passed up the protocol stack layer for further processing (step 506). When the group packet reaches a leaf node, the leaf node should support the indicated multicast group ID; otherwise a multicast routing error has occurred. The error may result from an error in the MGM tables in one or more of the preceding network nodes on the path to the receiving node. If such a routing error occurs, the leaf node may be configured to issue an alert to the NMS 212 (step 508).

[0080] Accordingly, various embodiments of the present invention reliably and efficiently route a multicast group packet in a tree-based wireless network by establishing and storing parent-node and/or child-node MGM tables in each node and including the routing information (such as a target bit identifier vector and a target multicast group ID) in the delivered group packet. The parent-node and/or child-node MGM tables include information such as the ID(s) associated with the multicast group(s) in which the parent/child node(s) is a member and the bit identifier vector(s) for pointing to the bit(s) in the child-node MGM table(s) representing the supporting group ID(s). These approaches advantageously obviate the need to include a complete, explicit route in the group packet as is required in various conventional routing approaches.

[0081] In addition, because the multicast routing traffic described herein does not reach the network nodes that neither contain the target group members nor are transit nodes on the path to the target group node(s), the duration and the number of packet transmissions from the parent nodes to their associated child nodes across the wireless network may be minimized (or at least reduced relative to conventional approaches). This may

advantageously decrease bandwidth consumption and interference, significantly increase the overall throughput and reduce the delay performance of the network as well as the likelihood of a punctured packet due to bit hits.

Adding a Multicast Group ID to a Network

[0082] The NMS 212 generally maintains a database storing information, such as the gateway that is the root for a selected network node, the multicast group ID(s) supported by the selected network node, the bit identifier vector(s) corresponding to the supporting multicast group ID(s), etc. In addition, the NMS 212 may search and modify information in the database when necessary. In various embodiments, the NMS 212 can add a new multicast group ID to the wireless network it controls. The NMS 212 may first identify a gateway that supports the new multicast group ID to be added and then perform the following procedures to add the new multicast group ID to (i) a node, (ii) all nodes rooted to the identified gateway, and (iii) all network nodes in all gateways of the wireless network.

1) Adding a Multicast Group ID to a Node

[0083] FIG. 6A illustrates an exemplary approach 600 for adding a new multicast group ID to a target network node for supporting the new multicast group ID in accordance herewith. Typically, the command is initiated by the NMS 212 and directed to the target node. In a first step 602, the NMS 212 identifies a gateway that is the root for the target node. In a second step 604, the NMS 212 delivers an“adding multicast group ID” command to the identified gateway. The command may include the pair information {bit identifier vector, multicast group ID} as well as the route to the target node. In a third step 606, the gateway identifies the child node(s) of the gateway to which the command is to be delivered based on, for example, the conventional“source routing” information. In a fourth step 608, the gateway then transmits the command to the child node(s) identified in step 606. In a fifth step 610, upon receipt of the command, the child node determines whether it is itself the target node identified in the command. If so, the child node may add the indicated multicast group ID to the list of the multicast group IDs supported thereby (step 612). If the node is not the target node, the child node may identify the next child node(s) on the route to the target node (using, for example, source routing information contained in the received command), identify the child-node MGM table(s) corresponding to the next child node(s), check the value(s) of the bit(s) pointed to by the bit identifier vector(s) in the child-node MGM table(s) (step 614). If the bit is SET, the child node(s) identified in step 606 propagates the command packet to the next child node(s) identified in step 614 using, for example, source routing procedures (step 616). If, however, the pointed-to bit value is CLEAR, the child node(s) identified in step 606 may (i) set the pointed-to bit in the identified child-node MGM table to be a non-zero value (i.e.,“SET”) and propagate the packet to the next node on the path to the target node using conventional source routing procedures and (ii) set the pointed-to bit in the parent-node MGM table to a non-zero value (step 618). Steps 614-618 may be iteratively performed until the command packet reaches the target node (identified according to source routing procedures). In one embodiment, after the target node is reached, step 612 may be performed. In various embodiments, the NMS 212 may add the new multicast group ID to one or more nodes selected based on criteria such as geographical locations.

2) Adding a Multicast Group ID to All Nodes Rooted to an Identified Gateway

[0084] FIG. 6B illustrates an exemplary approach 630 for adding a new multicast group ID to all the nodes controlled by a target gateway so that the nodes become members of the new multicast group. In a first step 632, the NMS 212 delivers an“adding multicast group ID” command to the target gateway. The command may include the pair information {bit identifier vector, multicast group ID}. In a second step 634, the gateway forwards the command to all of its cell child nodes (receiving nodes). Such forwarding may be performed in (i) a cell-broadcasting manner or (ii) an individual unicasting manner In a third step 636, upon receipt of the command, the receiving nodes may add the new group ID to the list of the multicast group IDs supported thereby. In addition, the receiving nodes may set the bits pointed to by the bit identifier vectors in the parent-node MGM tables and the child-node MGM tables of the child nodes associated with the receiving nodes, and forward the command to each of the child nodes. Again, the forwarding may be performed in (i) a cell broadcasting manner or (ii) an individual unicasting manner. Steps 634 and 636 may continue until the command is received by a leaf node (i.e., a node having no child nodes). Once the leaf node is reached, the NMS 212/214 updates the list of multicast group IDs supported by the leaf node (step 638) and sets the bit pointed to by the bit identifier vector in all the child-node MGM tables of the leaf node to be zero (“CLEAR”) (step 640). In general, a leaf node has no child-node MGM tables; thus, if a child-node MGM table exists for a leaf node, all the bits of the child-node MGM tables associated therewith are cleared (since the leaf node is not on the path to any multicast groups).

3) Adding a Multicast Group ID to All Nodes in All Gateways of the Wireless Network

[0085] In various embodiments, steps 632-640 in the approach 630 are sequentially or substantially simultaneously performed for all gateways in the network so as to add a new multicast group ID to all nodes in all gateways of the network.

Removing a Multicast Group ID from a Network

[0086] As described above, the NMS 212 may maintain a database storing information, such as the gateway that is the root for a selected network node, the multicast group ID(s) supported by the selected network node, the bit identifier vector(s) corresponding to the supporting multicast group ID(s), etc. The NMS 212 may search and modify information in the database when necessary. In various embodiments, the NMS 212 can remove a multicast group ID from the wireless network it controls. To do so, the NMS 212 may first identify one or more gateways that support the to-be-removed multicast group ID and then perform the following procedures to remove the multicast group ID from (i) a node, (ii) all nodes rooted to the target gateway, and (iii) all network nodes in all gateways of the wireless network.

1) Removing a Multicast Group ID from a Node

[0087] FIG. 7A illustrates an exemplary approach 700 for removing a multicast group ID from a target network node in accordance herewith. In a first step 702, the NMS 212 transmits a“removing multicast group ID” command to a gateway(or, in some embodiments, multiple gateways due to a node transition from one gateway to another) that supports the target node. The command may include the target node ID and the pair information {multicast group ID, corresponding bit identifier vector}. In a second step 704, the gateway(s) delivers the command to the target node in a unicasting manner. In one embodiment, the gateway(s) utilizes the conventional source routing procedures for the unicasting delivery. Note that the removing command may propagate transparently via the path to the target node, and no processing may be performed to the command until it reaches the target node. Once the removing command is received by the target node, the target node may first check the content of the bit in the node MGM table pointed to by the bit identifier vector in the received command (step 706). If the bit is set with a non-zero value (“SET”), one or more of the subtrees associated with the node is on the path to the indicated multicast group ID. Thus, the node may remove the indicated multicast group ID from the list of the multicast groups IDs it supports (step 708) and deliver a packet to the gateway indicating that the removal procedure is complete (step 710). If, however, the bit in the node MGM table pointed to by the bit identifier vector identified in the command is CLEAR (i.e., has a zero value), none of the subtrees associated with this node is on the path to the indicated multicast group ID. Thus, the node removes the indicated multicast group ID from the list of the multicast groups IDs it supports (step 712) and delivers an“uplink deleting multicast group” command to its parent uplink (step 714). In one embodiment, the command includes information such as the multicast group ID, the corresponding bit identifier vector, the address associated with the target node, etc.

[0088] In various embodiments, upon receipt of the“uplink deleting multicast group” command from one of its child nodes (or“reporting child node”), the receiving uplink parent node may CLEAR (i.e., set to zero) the bit in the child-node MGM table associated with the reporting child node pointed to by the bit identifier vector (step 716). In addition, the parent may perform a logical OR operation on the bit pointed to by the bit identifier vector on all the child-node MGM tables associated therewith; the resulting value is then stored in its parent- node MGM table (step 718). In one implementation, the parent node verifies the value of the bit in the parent-node MGM table pointed to by the bit identifier vector corresponding to the indicated to-be-removed multicast group ID (step 720). If the bit is SET, the parent node delivers a packet to the gateway indicating that the removal process is complete (step 722). If the bit is CLEAR (which means that the node is not on the path to the indicated to-be- removed multicast group ID), the parent node delivers an“uplink deleting multicast group” command to its“up-the-tree” parent (step 724), which then performs steps 716-724 described above. 2) Removing a Multicast Group ID from All Nodes Rooted to an Identified Gateway

[0089] In one embodiment, the approach 700 described above may be performed on all nodes rooted to a target gateway in order to remove the multicast group ID therefrom. This approach, however, may require longer process times and wastes network resources.

Alternatively, the target gateway may broadcast the“removing multicast group ID” command, directing each node that receives this broadcast (and supports the to-be-removed multicast group ID) to remove the indicated multicast group ID from its list of the supporting multicast groups. This approach, however, is also inefficient since the broadcast command propagates down the tree structure regardless of whether the traversed nodes are on the path to the indicated to-be-removed multicast group ID.

[0090] FIG. 7B illustrates an exemplary approach 730 for efficiently removing a multicast group ID from all the nodes controlled by a target gateway (or root node) by propagating the removing command only via nodes that are on the path to the indicated to-be- removed multicast group ID. Typically, a single command is sufficient to remove the to-be- removed multicast group ID from the gateway as well as all nodes supported by the gateway. Again, the removing command may include the multicast group ID that is to be removed and the corresponding bit identifier vector. For clarity, a“multicast group leaf node” meets the following conditions: (i) the value of the bit that corresponds to the indicated to-be-removed multicast group ID in the parent-node MGM table is CLEAR (i.e., this node is not on the path to other nodes supporting the multicast group ID) and (ii) the node supports the to-be- removed multicast group ID. For a given multicast group ID, there may be one or more multicast group leaf nodes.

[0091] In a first step 732, the NMS 212 delivers a“removing multicast group ID” command to the target gateway (or root node). In a second step 734, the gateway delivers the command to its child nodes that are on the path to the to-be-removed multicast group (as identified by the child-node MGM tables of the gateway). In a third step 736, the child nodes propagate the command“down the tree” via all nodes that are on the path to the to-be- removed multicast group until a node that contains a multicast group leaf node is reached. In a fourth step 738, after the command reaches the multicast group leaf node, the multicast group leaf node removes the to-be-removed multicast group ID from the list of the multicast group IDs it supports. In addition, the multicast group leaf node delivers a“deleting multicast group ID” command“up-the-tree” to its parent node (step 740). In one

embodiment, the command includes the pair information {multicast group ID, bit identifier vector}. The receiving parent node may then CLEAR the value of the bit pointed to by the bit identifier vector in the child-node MGM table(s) associated with the reporting child (step 742). In addition, the parent node may remove the indicated to-be-removed multicast group ID from its list of the supporting multicast groups (step 744). In some embodiments, the parent node performs a logical OR operation on the bit pointed to by the bit identifier vector of the command on all its child-node MGM tables (including that of the reporting child node); the resulting value is then stored in the parent-node MGM table (step 746).

[0092] In various embodiments, the parent node checks, in the parent-node MGM table, the value of the bit pointed to by the bit identifier vector that corresponds to the indicated to- be-removed multicast group ID (step 748). If the bit is SET and the node is not the root node, the node is on the path to other members of the to-be-removed group ID that can be identified and processed when their multicast group leaf nodes are reached; thus, the process may be terminated (step 750). Similarly, if the bit is SET and the node is the root node, the root node is on the path to other members of the indicated group ID that can be identified and processed when their multicast group leaf nodes are reached; thus, the process may be terminated here as well (step 750). If, however, the bit is CLEAR and the node is not the root node, the node delivers an“uplink deleting multicast group” command” to its“up-the-tree” parent node (containing the same“uplink deleting multicast group” command received by the parent node from its reporting child) (step 752). In addition, steps 742-752 may be repeated. If the bit is CLEAR and the node is the root node, the removal process is completed and no further processing is necessary (step 750).

3) Removing a Multicast Group ID from All Nodes in All Gateways of the Wireless Network

[0093] In various embodiments, the NMS delivers the“removing” command as described above to all the gateways that may support the to-be-removed multicast group ID and then performs the approach 730 described above so as to remove the multicast group ID from all nodes in all gateways of the network.

Associating a Node with a New Parent Node

[0094] FIG. 8 illustrates an exemplary approach 800 for allowing a node, A, that is successfully registered with the NMS 212 to be associated with a new parent node, Pl, in accordance with various embodiments, In a first step 802, the node A transfers its parent- node MGM table to the parent node Pl. In a second step 804, the parent node Pl stores the received child-node MGM table, and generates an updated parent-node MGM table (e.g., by merging all of its child-node MGM tables). If the newly generated parent-node MGM table is different from the parent-node MGM table created before the update, the process is stopped (step 806); otherwise, the parent node Pl may deliver the resulting table to its parent node, P2 (step 808). When P2 receives from its child node (the node that contains Pl) an“updated” child-node MGM table (which already reflects the node A being associated with Pl), P2 merges its child-node MGM tables and update its parent-node MGM table (step 810). Again, if the updated parent-node MGM table is different from the parent-node MGM table created prior to the update, the process is stopped (step 806); otherwise, the parent node P2 delivers its newly generated parent-node MGM table to the next node“up the tree” (step 812). Steps 804-812 may be iteratively performed such that the parent-node MGM table can be continuously updated“up the tree” by each receiving parent node (Pi). When the root node eventually receives an updated child-node MGM table from one of its associated child nodes, the root node generates and updates the root MGM table (by, e.g., merging its child-node MGM tables including the newly received child-node MGM table) (step 814). If the newly generated root MGM table is different from that created before the update, the root node delivers the updated root table to the NMS 212 for storage therein (step 816). If, however, the newly generated root MGM table is the same as that created before the update, there is no need for the root node to deliver the updated root table to the NMS (step 818).

[0095] It should be noted that the NMS 212 in the approach 800 need not know the specific path to the multicast group supported by each root node. In order to deliver a message to a target multicast group ID, the NMS 212 may have to use only the bit identifier vector corresponding to the target multicast group ID and identify the root MGM table in which this bit is SET. The message can then be delivered by the NMS 212 to those gateways in which the bit is SET. Subsequently, each gateway that receives the message may follow the procedure for multicast group delivery as described above.

[0096] In some embodiments, a non-loss compression approach is implemented to save the uplink bandwidth when the MGM table is propagated up the tree to the root node. An exemplary compression scheme takes advantage of the fact that parent-node MGM tables become sparse when going down the tree network. For example, an MGM table can be delivered by rows (i.e., from row 1, row 2, ... , to the last row); each row contains a bit string from the MGM table. Delivery of the bit string in each row may be preceded by a one-bit “compression indicator.” If the compression indicator is set to zero, all the row bits of this row are CLEAR and are not transmitted. If the compression indicator is set to one, the following row bits represent the actual values of the bits in the current row (some may be CLEAR and some may be SET). As the number of SET bits in an MGM table increases, and depending on the way the SET bits are distributed across the rows in the table, it may be more efficient to deliver the MGM table in its uncompressed format. In one embodiment, the node that delivers the MGM table may determine whether to deliver the table in a compressed or uncompressed format and then inform the target node (up the tree) of the format selection.

De-associating a Node from Its Parent Node

[0097] A child node engaged with a parent node (or“old” parent) that switches to a “new” parent node is actually removed from the old parent node. FIG. 9 illustrates an exemplary approach 900 performed by the old parent after it determines that the child node has left. In a first step 902, the old parent node populates the child-node MGM table associated with the child that left with“zero” entries and name this table a“removed child- node MGM table.” In a second step 904, the old parent node merges the“old” parent-node MGM table (i.e., created before the child left) and the“removed child-node MGM table.” If the resulting parent-node MGM table is different from the existing parent-node MGM table, the old parent node propagates the merged table uplink to its parent node (step 906).

Subsequently, the process continues as described above for the approach 800 (step 908).

Multicast Routing When a Node Is in a Transitional State

[0098] During transition of a child node (e.g., when the node is associating with a new parent node or leaving an old parent node), the multicast group packet may still be delivered to or via the child node that no longer belongs to the correct multicast path. Two events may then occur: First, the multicast packet may be erroneously delivered to a node that does not support the target multicast group ID; this does not result in any harm as the decision whether to process the multicast packet is made by the application in the receiving node based on the explicit multicast group ID contained in the received packet. Second, the multicast group packet may not reach the target node due to removal of the node (and thereby the multicast path); as a result, the multicast packet may be lost. In various embodiments, when the state of the receiving node is indicated as“in transition,” the child-node MGM tables associated therewith are ignored, and the received packet is simply forwarded to all child nodes associated therewith using, for example, the approach described in connection with FIG. 6B (adding a new multicast group ID to a gateway), where all the child nodes are considered to include the path to the target multicast group ID. This approach may effectively minimize (or at least reduce) the number of lost multicast packets during node transitions. In addition, because node transitions typically do not occur frequently, the efficiency and reliability gain using this approach can be significantly larger than the efficiency loss occurring during the actual transition (e.g., due to the unnecessary forwarding of the packet to a child that may not be on the path).

Implement a Unicast Routing Table for Efficient Unicast Delivery

[0099] The approaches described above for efficiently delivering a multicast group packet may be implemented to efficiently deliver a unicast packet after a route is established between a network node and the root node (using, e.g., the conventional source routing information for packet delivery). In various embodiments, a unicast routing table associated with each node is created to replace the conventional source routing information; each bit in the unicast routing table may correspond to one child node on the tree. In one

implementation, each bit in the unicast routing table corresponds to a unicast child table entry; the content of the pointed-to entry in the unicast child table indicates the number of the child node to which the packet is to be forwarded. The number of each child node may correspond to the MAC address thereof. In addition, a unicast packet may include a bit identifier vector that points to a bit in the unicast routing table.

[00100] In various embodiments, after the node receives the packet, the receiving node may determine whether the bit pointed to in the unicast routing table is SET. If so, the receiving node may access the unicast child table, retrieve the child number associated with the entry pointed to by the bit identifier vector, and, based thereon, unicast a MAC frame to the child node. If, however, the bit pointed to in the unicast routing table is CLEAR, the packet has reached the target node. The receiving node may then check the content of the received unicast packet to determine if the indicated target destination address matches the node address. If so, the packet can be processed by the node; otherwise, a routing error is issued.

[00101] The approaches for creating the unicast routing tables are similar to those described above for creating the MGM tables. Again, the unicast routing tables may be populated during node association and registration processes. Advantages of using the unicast routing table and unicast child tables include that a packet only has to include the bit identifier vector as the route without having a complete, explicit route required in

conventional source routing approaches. In addition, because routing the packet based on the routing tables may result in a shorter packet (since the source routing information is no longer required), the approaches described herein may advantageously save the bandwidth and allow for a larger payload in each delivery.

An Example of Routing a Packet in a Tree-Based Wireless Network Using MGM Tables and Unicast Routing Tables

[00102] In an example illustrating efficient delivery of a packet in a tree-based wireless network using the MGM tables and unicast routing tables described above, the network is assumed to support 1024 multicast groups; the gateway is assumed to support 4,000 nodes; and each parent node can support up to 16 child nodes (a nibble (four bits) is required in order to represent one of the 16 child nodes). As a result, the string that indicates the route to a unicast target contains 12 bits for the MGM bit position (e.g., 9 bits for the row number and 3 bits for the column number). Thus, 2⁹ = 512 bytes are required to store a unicast MGM bit map. In addition, because 2,000 bytes are required for the unicast child table (in order to support the 4,000 nibbles), the total storage required for the unicast routing approach is approximately 2,500 bytes only. In addition, the string that indicates the route for a multicast target contains 10 bits for the MGM bit position (e.g., 7 bits for the row number and 3 bits for the column number). Because each node maintains up to 16 child-node MGM tables, 2⁷ *

16 = 2048 bytes are required for storage of the MGM tables. In addition, the node maintains 2⁷ bytes for the parent-node MGM table. As a result, the total storage required for the multicast group routing approach is 2176 bytes.

[00103] It should be noted that the routing approaches described herein utilize existing tree-based wireless networks without requiring any tree construction or re-construction. The tree structure need not be optimized for a specific multicast group and the same tree structure may be used for all multicast group message deliveries. In addition, although the approaches described herein generally assume that the tree-based wireless network is stable, they can accommodate changes in the tree structure (e.g., caused by self-improving or self-healing procedures) by providing fast changes in the multicast group routing approaches as described above. Further, the terms“gateway” and“root node” are used interchangeably herein.

Updating a Firmware File in a Tree-Based Wireless Network

[00104] In one embodiment, a firmware file can be periodically updated in a tree-based wireless network 200 as depicted in FIG. 2. For example, FIG. 10 depicts a tree-based wireless network 1000 that has the same structure as the network 200 depicted in FIG. 2; FIG. 10 differs from FIG. 2 in that an updated firmware is transmitted in the network 1000.

In addition, the NMS 1014 associated with each network node 1002 in the network 1000 may perform various functions (such as broadcasting a received chunk of a firmware file 1015 to its associated child nodes, transmitting a NACK-request message to its child nodes, transmitting aNACK message to its parent node, etc.) as further described below. In one embodiment, an updated firmware file 1015 is provided to the root node (e.g., node 1004) in the tree-based network 1000. The NMS associated with the root node may then divide the firmware file 1015 into multiple chunks (or“blocks”) such that the root node can transmit each of the chunks in a single data packet to its associated child nodes. Upon receiving the chunks, the NMS associated with each child node is responsible for delivering each of the chunks to its associated child nodes; this process can then propagate throughout the entire tree network.

[00105] As described above, in some embodiments, the firmware file 1015 is divided (e.g., by the NMS associated with the root node) into multiple chunks 1016; each chunk is assigned a sequence number based on its order in the divided firmware file 1015 and can be included in a single data packet 1018 for transmission in the wireless network 1000. In addition, each chunk 1016 may be preceded by a header 1020 in the data packet 1018; the header 1020 may include information, such as a type of the broadcast firmware file, a time stamp (e.g., a GMT date and time, such as Nov. 6, 2015, 08:00 GMT) indicating the release time of the firmware file 1015, and/or a sequence number of the associated chunk in the firmware file 1015. In addition, each chunk may be propagated independently from other chunks in the same version of the file 1015.

[00106] In various embodiments, for each type of the firmware file, each node 1002 in the wireless network 1000 holds exactly one complete version of the firmware file 1015 and at most one outstanding version (i.e., receiving in-progress) of the file 1015. For example, the outstanding version is a newer (or“updated”) version than the complete version. In one embodiment, when the node receives a chunk of a newer version of the file, but the previous version of the file is still incomplete (i.e., not all chunks have been received), the node discards the chunks of the incomplete previous version and starts to collect the chunks associated with the new version for completing the new version. In addition, each node 1002 may identify the newest version (i.e., the most recently released version) of the received chunks, and subsequently transmit them to its associated child node(s) regardless whether the most recently released file is complete or still in-progress. For example, referring again to FIG. 10, the node 1006 is a parent node of the node 1024; assuming that the parent node 1006 has a complete fourth version and incomplete fifth version of the firmware file, while the child node 1024 has a complete third version and incomplete fourth version of the firmware file (this may occur when, for example, the node 1024 is disconnected from the network 1000 for some time), the parent node 1006 may transmit the chunks of the firmware file associated with the fifth version (as opposed to the fourth version) to the child node 1024. Accordingly, each node 1002, upon receiving or identifying the newest version of a chunk, may store the chunk therein and subsequently transmit the chunk to its associated child node(s) in its cell using broadcasting. The child node(s) that receives the broadcast chunk may then determine whether the received chunk is the newest version it has, and if so, accepts the chunk and forwards it to the child node(s) it associated within in its own cell.

[00107] It should be noted that not all the child nodes are able to accept the chunk. For example, some child nodes may miss the chunk due to a transmission error or a dynamic topology change in the tree structure (e.g., when the currently connected parent node broadcasted the chunk but the child nodes were still connected to previous parent nodes that are different from the currently connected parent node). In addition, some of the nodes may miss the broadcast chunk due to a“hidden terminal problem.” For example, FIG. 11 illustrates a node A being a parent node and nodes B and C being the child nodes of node A in a cell 1102; nodes D and E are network nodes outside the cell 1102. Typically, before node A broadcasts a chunk of the firmware file to its associated child nodes B and C, node A may first determine whether the child nodes are“silent” (i.e., not transmitting or receiving any data packets); and if so, node A can then transmit the chunk to its child nodes B and C. But in some situations, nodes D and E, which are not child nodes of node A, are active; thus, transmissions from nodes D and E, while not detectable by node A, can still be detected by nodes B and C, respectively. Thus, transmission collisions may occur in nodes B and C. As a result, both nodes B and C may fail to receive the broadcast chunk from node A.

[00108] To avoid the hidden terminal problem and/or missing chunks in the receiving nodes due to, for example, a dynamic topology change in the tree structure described above, in various embodiments, the parent node sends its associated child nodes in the cell a “NACK-request message” periodically (e.g., every time interval, TNACK (e.g., 5 minutes)); the NACK-request message requests the child nodes to identify and report to the parent node which of the chunk(s) indicated in the NACKjequest message is missing in the receiving child nodes. The NACK-request message may be an independently transmitted message or incorporated into a BEACON message. For ease of explanation, approaches for reliably updating the firmware file in the network nodes described herein assume that the NACK- request message is transmitted as an independent message, but one of skill in the art would understand that the same approaches may be utilized when the NACK-request message is incorporated into a BEACON message and are thus within the scope of the present invention.

[00109] In various embodiments, the child nodes, upon receipt of the NACK-request message, identify the missing chunks therein and report them to the parent node via transmission of a“NACK message.” In various embodiments, it is desired to minimize the number of transmissions of the NACK messages from the child nodes to the parent node so as to prevent a“NACK storm” (e.g., too many NACK messages being received at the same time) in the parent node. In addition, transmissions of NACK messages may be scheduled to occur when the tree-based network is relatively idle. As further described below, in some embodiments, scheduling transmission of the NACK message can be controlled by the parent node based on the NACK-request messages transmitted therefrom.

[00110] In various embodiments, upon receiving a list of missing chunks from its child nodes, the parent node adds the list to its future schedule. Thus, the list of chunks in the future schedule may include the missing chunks (which are identified in a NACK message sent from at least one of its child nodes) and one or more new chunks (which have not yet been broadcast). Referring to FIG. 12, to determine the timing for transmitting the new chunks and re-transmitting the missing chunks, in various embodiments, each chunk at the parent node is classified into one of three states: (i) a“missing” state indicating that at least one of the child nodes does not have the chunk, (ii) a“requested” state indicating that a child node needs to broadcast the chunk, and (iii) a“transmitted” state indicating that the parent node has broadcast this chunk to the child nodes but a NACK message has not been received since last transmission. Typically, all the chunks in the in-progress firmware file are in one of the above-identified three states.

[00111] In various embodiments, based on the classified state associated therewith, the timing for transmitting each chunk can be determined. For example, when the parent’s scheduler is invoked to put new data packets in the delivery queue, the parent node may first select the chunks having a“requested” state; the parent node may then create a data packet from each selected chunk and deliver the packets to a queue for broadcasting. After the chunks are broadcast, the parent node may change the state of the selected chunks to “transmitted,” indicating that the chunks have not been requested since they were transmitted last time. The“transmitted” state may be changed to the“requested” state at a later time. For example, while a broadcast chunk has been received by all child nodes that are currently associated with the parent node, a new child node may join the cell at a later time (e.g., one hour later) and need to broadcast the chunk to its associated child nodes. Thus, the chunk’s state may have to be changed to“request” in order to be placed in the queue for broadcasting.

[00112] In one embodiment, the parent node sends a NACK-request message only when all the following conditions are satisfied: (i) there are no more“requested” chunks therein;

(ii) at least a predetermined time interval (e.g., TNACK) has elapsed since the last NACK- request message was sent or at least a predetermined number (e.g., 50) of the chunks have been transmitted since the last transmission of a NACK-request message; and (iii) the parent node knows that there may be at least one receiving child node that has not received one or more of the chunks (thus, if the parent node knows that all the receiving child nodes have received all the chunks, there is no need for the parent node to send the NACK-request message).

[00113] The NACK-request message may include information associated with the chunks that have been transmitted by the parent node. For example, the NACK-request message may include a complete set of the sequence numbers associated with all the transmitted chunks. In various embodiments, only a subset of the sequence numbers associated with the transmitted chunks is indicated in a NACK-request message (e.g., for saving space). This may occur when, for example, the length of the NACK-request message is limited and the broadcast firmware file contains a large amount of chunks. The parent node may thus reduce the length of the MACK-request message by including only a subset of the sequence numbers in each message and having different sets of the sequence numbers included in different MACK- request messages transmitted at different times. To achieve this, in one embodiment, the parent node includes a database maintaining a cyclic pointer for indicating the sequence number of the last chunk in the last-sent NACK-request message. Based thereon, the parent node can then include the sequence numbers of the following chunks in a new NACK-request message. In a simplified example, there are 100 chunks in the updated firmware file and the parent node has received and broadcast the chunks having sequence numbers {1-8, 9, 11, 13- 20, 21, 22, 23-40, 41, 44-47, 50-52, 54-60, 70-85, 86, 87, 89-100}. Assuming that the cyclic pointer at the parent node points to the sequence number 24, and that the NACK-request message has space for encoding six numbers only, the parent node may transmit a NACK- request message having the sequence numbers of 25-40, 41, 44-47, 50, and adjusts the cyclic pointer to number 50 after transmission of the NACK-request message. Similarly, if the cyclic pointer indicates that the sequence number of the last transmitted chunk is 91, then the parent node may transmit the next NACK-request message with the sequence numbers of 92- 100, 1-8, 9, 11. [00114] It should be noted that in some situations, the chunks are already transmitted by the parent node but because there is no need for the parent node to receive a NACK message, the sequence numbers of these chunks will not be listed on the NACK-request message. For example, when the parent node has already received a NACK message for a specific sequence number and the chunk associated therewith is currently awaiting retransmission, there may be no need to receive a NACK message for it.

[00115] As described above, upon receiving the NACK-request message from the parent node, the child node may respond by transmitting a NACK message to the parent node. In various embodiments, the child node implements a transmission approach for minimizing the number of transmissions of the responding NACK messages to the parent node and spreading the NACK messages as equally as possible over a predetermined time period (e.g., in the next TNACK period). In one embodiment, the transmission approach starts by determining the number of chunks identified in the NACK-request message but missing in the child node. Based thereon, fractions of the missing chunks and non-missing chunks (FNMC) can be computed. For example, if the NACK-request message includes the sequence numbers 92- 100, 1-8, 9, 11 (i.e., 19 chunks in total) and the child node is missing only chunks 1-3 (i.e., 3 chunks in total), then the fraction of missing chunks is 3/19 = 0.15, and the fraction of non missing chunks is FNMC = 0.85. The child node then draws a random time between 0 and (FNMC ^XTNAC) before transmitting its NACK message to the parent node. Using this approach, the child nodes that miss more chunks may access the wireless channel before the child nodes that miss fewer chunks. In addition, this approach may significantly reduce the expected number of transmissions of the responding NACK messages to the parent node. For example, in the above example, assuming that TNAC is five minutes, there is a random time between 0 and 0.85x5 = 4.25 minutes before the child node sends a response to the parent node. While the child node awaits the drawn time to elapse, it may realize that all its missing sequence numbers have been reported by other child nodes; as a result, the child node can cancel the transmission of its NACK message. In some embodiments, after the child node’s waiting time has elapsed, the node child can update its NACK message to cover the sequence numbers associated with the chunks that are still missing therein and have not been reported by other child nodes.

[00116] The transmission approach described above requires each child node to be aware of the NACK messages transmitted by other child nodes. This may be achieved by, for example, broadcasting each NACK message to all nodes in the vicinity of the transmitting child node, or allowing other child nodes to“spoof’ the NACK message when it is transmitted to the parent node. Alternatively, the parent node may periodically broadcast messages summarizing the sequence numbers associated with the missing chunks that are indicated in the received NACK messages. Based thereon, the child nodes can update or cancel their NACK messages to the parent node as described above.

[00117] FIG. 13 is a flow chart illustrating an exemplary approach 1300 for updating a firmware file in a tree-based wireless network in accordance herewith. In a first step 1302, the firmware file is divided into multiple chunks such that each chunk can be included in a single data packet. In a second step 1304, each chunk is broadcast from a node to its child nodes in a transceiver cell. Upon receiving the chunk, the child nodes may determine whether the chunk is new (i.e., an most recently updated version); and if so, the child nodes may store the chunk and broadcast the chunk to their associated child nodes (step 1306). If, however, the chunk is not new, the child nodes may discard the chunk without forwarding it to the child nodes (step 1308). In various embodiments, each parent node periodically transmits aNACK-request message indicating information such as the types, time stamps and/or sequence numbers associated with all (or at least some) chunks that it has already transmitted to its child nodes (step 1310). In response to the NACK-request message, each child node may identify the chunk(s) that are listed in the NACK-request message but currently missing in the child node, and report the identified missing chunk(s) to the parent node using a NACK message (step 1314). In one embodiment, prior to step 1314, a transmission approach involving drawing of a random time for the child node to wait before it transmits its NACK message to the parent node is implemented to minimize the number of transmissions of the NACK messages, thereby preventing a“NACK storm” in the parent node (step 1312). In addition, upon receipt of the NACK message indicating a list of missing chunks in the child node, the parent node may add the indicated missing chunks to its future schedule for broadcasting (step 1316). In one embodiment, a scheduler logic that classified the chunks into three states is then implemented to determine the timing for broadcasting a new chunk and/or re-transmitting a missing chunk (step 1318).

[00118] FIG. 14 is a flow chart illustrating an exemplary transmission approach 1400 for minimize the number of message transmissions from the child nodes to the parent nodes in accordance herewith. In a first step 1402, a number of the chunks that is identified in the received NACK-request message but missing in a child node is determined. Based thereon, fractions of the missing chunks and non-missing chunks (FNMC) can be computed (step 1404). In a third step 1406, a drawn time that the child node has to wait before transmitting the NACK message to its parent node is determined based on the fractions of the missing chunks and non-missing chunks computed in step 1404. In a fourth step 1408, the child node can cancel or update its NACK message to the parent node while awaiting the drawn time to elapse. In a fifth step 1410, after the drawn time has elapsed, the child node can transmit the MACK message (if not cancelled) to its parent node.

[00119] Various embodiments described herein provide advantages over conventional approaches for updating the firmware file in a wireless tree network. For example, the approaches described herein allow a transmitting node to transmit a file even before it receives all the chunks of the file. This means that the transmitting node may transmit the chunks in an out-of-order manner. In this situation, the transmitting node can use the NACK- request message described above to inform all its receiving nodes about the chunks it wants to receive in the NACK messages. This feature is not included in any conventional approach. For example, in the negative-acknowledgment-oriented reliable multicast (NORM) approach, the transmitting node is required to have a complete firmware file such that it can transmit the data in order. Thus, a receiving node that receives a chunk having a sequence number i knows that the NACK messages can be sent for all preceding chunks (i.e., 1 ... /- 1 ). And if a receiving node in NOAM receives the chunk of number 5 before the chunk of number 4, the receiving node will indicate that the chunk of number 4 is missing. In contrast, the approaches described herein allow the transmitting node to receive, from its parent node, the chunk of number 5 before the chunk of number 4, and subsequently transmit the chunk of number 5 before the chunk of number 4 to its receiving nodes. Because allowing the chunks to be distributed out of order may complete the file transfer more rapidly by avoiding the head-of-the-line blocking, the approaches described herein are more efficient than NORM.

[00120] It should be noted that approaches described herein for reliably updating a firmware file can be implemented in any wireless network that has an underlying logical tree- based structure. In addition, these approaches do not require the tree to be static. If the network is dynamic, the tree structure may periodically change; the approaches described herein can automatically adapt to the new network topology. For example, as described above, when a new child node joins the network and needs to broadcast a chunk to its associated child nodes, the chunk’s state may be changed from“transmitted” to“requested;” subsequently, a data packet can be created for the“requested” chunk and delivered to a queue for broadcasting. Further, implementation of the NACK-request messages from the parent nodes to the child nodes and NACK messages from the child nodes to the parent nodes may advantageously guarantee that each node connected to the tree network can eventually receive the broadcast firmware file. Next-Hop Routing in a Tree-Based Wireless Network

[00121] In one embodiment, beacon messages can be communicated among neighboring nodes in a tree-based wireless network 200 as depicted in FIG. 2. For example, FIG. 15 depicts a tree-based wireless network 1500 that has the same structure as the network 200 depicted in FIG. 2; FIG. 15 differs from FIG. 2 in that a beacon message is transmitted in the network 1500.

[00122] In various embodiments, each node contains one or more radio transceivers. FIG. 16 illustrates nodes configured for traditional beacon operation and operation in accordance with embodiments of the present invention. A first node U (indicated at 1610) includes a parent node portion, DL, 1612 and a child node portion, UL, 1614; the DL and UL have operational channels Cl and C2, respectively, for transmitting and receiving data packets to and from other nodes in the network. In this embodiment, each of the channels Cl and C2 may be served by a separate transceiver. Alternatively, both UL 1612 and DL 1614 of the node U may share one operational channel; as a result, only one transceiver may be equipped with the node U. Assume that there are two one-hop nodes V and W (indicated at 1615,

1620, respectively) neighboring the node U, and nodes V and W use channels Cl and C3, respectively, as their UL operational channels. Beacons transmitted by node U will always be received by node V, since both the DL in the node U and the UL in the node V use the same operational channel Cl— that is, node V is always“listening” to node U. But because the operational channel of the DL in node U is different from the operational channel of the UL in node W, beacons transmitted by node U will not be received by node W. To solve this problem, in one embodiment, the DL 1612 in node U transmits a“visitor beacon” on the operational channel C3 associated with the UL of node W; this way node W can then listen for beacons from node U over its regular operational channel C3 without switching to a different channel. As a result, both nodes V and W can receive beacons (for node V) or visitor beacons (for node W) over their regular operational channels Cl and C3, respectively, without the need of switching to different channels. This may significantly reduce the overall time during which nodes V and W are not available on their regular operational channels using conventional approaches. It should be noted that in a dense network, there may be tens or hundreds of nodes that are one-hop away from the node U and these neighboring nodes may have different operation channels. To transmit visitor beacons to all these nodes, in one embodiment, the DL portion of node U can transmit the visitor beacons on all channels in the network system, except its operational channel Cl.

[00123] This visitor-beacon scheme may be compared with the hold-and-sniff scheme as follows. As noted, the hold-and-sniff scheme requires the sniffing node to pause activity on its operational channel and request that neighboring nodes also pause their conventional traffic directed at the“sniffing” node; the pause defines the duration of the sniff. Generally, the sniffing duration is quite long as it has to allow reception of at least one beacon message; this is particularly so when the beacon periodicity is low. On the other hand, the transmitter of a visitor beacon pauses activity on its operational channel only for the time it takes to transmit a visitor beacon, which can involve much less time than a sniff.

[00124] Let BTintervai be the time interval between beacons and let BTiength be the transmission time of an individual beacon. To minimize consumption of network bandwidth by beacon traffic, BTintervai should be maximized. Assume that when the visitor-beacon scheme is used, a node transmits visitor beacons over k channels and that BTiength for each visitor beacon is t seconds. The time t is the sum of the average channel access duration using the relevant channel access scheme (e.g., the commonly used CSMA/CA protocol), plus the time required for radio tuning to another channel, plus the actual time needed to transmit the packets corresponding to a visitor beacon. Thus, the total time required to deliver visitor beacons on all channels is k x t, meaning that the normal activity of the beacon sender is interrupted for visitor beacon delivery for a duration of k x t seconds. Note that the duration t is affected by the channel load— in fact, exponentially increasing as a function of the channel load.

[00125] In hold-and-sniff scheme, the network nodes are not synchronized and beacons may be delivered by each node at any time as determined by a beacon-transmitting node. Each node sniffs for a duration the order of BTiength + BTintervai to receive at least one beacon from each announcing node in the vicinity. Again assuming k channels in total, each node needs to switch its receiver through k channels and sniff each of them independently, so the total time spent by each node for a round of sniffing is equals to k x (BTiength + BTintervai). A comparative ratio R may be defined as the ratio of the hold time for sniffing all channels to the hold time for delivery of visitor beacons over all channels, which is equal to [00126] For example, if BTiength + BTintervai is on the order of 1 second, and the time required for delivery of each visitor Beacon is in the order of 20 milliseconds, R = 1000/20 = 50, which demonstrates that the visitor-beacon scheme is more efficient since it interrupts normal node traffic for a shorter time duration. It is possible to reduce the ratio R by, for example, decreasing BTiength or adding beacon-related information to each normally delivered data message, thereby avoiding the sniffing time but increasing wasted network bandwidth due to increased data message overhead). Even with these ameliorations, the visitor-beacon scheme requires fewer interruptions.

[00127] The“cost” of the visitor-beacon scheme is the increased channel overhead due to the additional delivery of visitor beacons by every node. Each receiving node is affected by this increased load, and the load per receiving node varies as a function of the network topology and radio propagation. Assuming N nodes are within radio distance of a receiving node, and assuming that each node delivers one visitor beacon per visitor beacon interval, the

N Dockets

added load on the channel used by the receiving node is - . If N is large, this is a non-

BTjnterval

negligible load.

[00128] To reduce the channel load due to visitor beacons, the rate of visitor beacon delivery may be dynamically adjusted according to, for example, the following algorithm. When a node has to a visitor beacon to deliver, it delivers it with probability 1 - p, where p is a function of the channel utilization, for example, p = channel utilization (so that the higher the channel utilization, or channel load, the lower the probability of delivery). Assuming a beacon interval of BTintervai, the total number of beacons plus visitor beacons that are delivered during a beacon interval is 1 + N x p, a“self-adjusting” load that varies with N and p. It is noted that in order to estimate the channel load, a node must tune to the channel. It is reasonable to assume that the duration required for channel load measurement is short, but this duration nonetheless adds to the total duration t required for delivery of each visitor beacon and hence affects the ratio R. For a system with a given number of channels, as the network density (i.e., N) increases, the channel load imposed by visitor beacons increases as well, whereas for a system that uses the hold-and-sniff scheme, the channel load imposed by beacon delivery remains constant and is a function only of the beacon Interval BTintervai and the number of channels k.

[00129] It is possible to combine both the visitor-beacon and hold-and-sniff schemes.

Both require tuning to a different channel, either for beacon sniffing or for transmission of visitor beacons, and both require a node to stop its normal activity and switch to another channel in order to receive (in the case of sniffing) or transmit (in the case of visitor beacons). The optimal ratio between the two schemes may be determined in advance or dynamically based on network performance.

[00130] One example of mixed usage is as follows. A visitor beacon is first transmitted by each node to all other nodes within radio distance, thereby publishing each node’s capabilities to its neighbors. Once all nodes have been apprised of the capabilities of their neighbors, each node can, based on the received visitor beacons, filter out nodes with which it cannot communicate. Each receiving node thereupon checks the quality of the radio channel used to receive visitor beacons. In order to do this, a receiving node applies“sniff’ procedure on the channel used to receive visitor beacons, monitoring received beacons (and optionally data traffic) delivered on the sniffed channel. The sniff duration per node and channel combination can be very short since the sniffing node can use for its quality analysis any data packet delivered on the sniffed channel. The sniffing node is only interested in the quality of the radio link between it and the node that is sniffed. At worst, if the sniffed node does not deliver any data packets, at least it will deliver beacons, so the longest required sniffing duration is on the order of BTiength + BTintervai per sniffed channel and node combination. Following the sniff and quality analysis, the sniffing node has all the requisite information about the node that transmitted the visitor beacon as well as the actual radio channel quality between the measuring node and the node that transmitted the visitor beacon.

[00131] The NMS 212/214/1012/1014/1512/1514 described herein may include one or more modules implemented in hardware, software, or a combination of both for performing the functions described above (e.g., steps in FIGS. 3, 5-9, 13 and 14). In addition, programming to implement the functions associated with channel switching and visitor beacon generation and transmission may have the form of one or more modules implemented in hardware, software, or a combination of both. For embodiments in which the functions are provided as one or more software programs, the programs may be written in any of a number of high level languages such as PYTHON, FORTRAN, PASCAL, JAVA, C, C++, C#, BASIC, various scripting languages, and/or HTML. Additionally, the software can be implemented in an assembly language directed to the microprocessor resident on a target computer; for example, the software may be implemented in Intel 80x86 assembly language if it is configured to run on an IBM PC or PC clone. The software may be embodied on an article of manufacture including, but not limited to, a floppy disk, a jump drive, a hard disk, an optical disk, a magnetic tape, a PROM, an EPROM, EEPROM, field-programmable gate array, or CD-ROM. Embodiments using hardware circuitry may be implemented using, for example, one or more FPGA, CPLD or ASIC processors.

[00132] The terms and expressions employed herein are used as terms and expressions of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described or portions thereof. In addition, having described certain embodiments of the invention, it will be apparent to those of ordinary skill in the art that other embodiments incorporating the concepts disclosed herein may be used without departing from the spirit and scope of the invention. Accordingly, the described embodiments are to be considered in all respects as only illustrative and not restrictive.

[00133] What is claimed is:

Claims

1. A method of multicast routing a group packet in a network comprising a plurality of cells each supporting communication among a plurality of transceiver nodes therein and being capable of receiving and transmitting group packets, each cell comprising a parent node and one or more child nodes, each group packet comprising routing information and a payload, the method comprising:

(a) for each cell, establishing and storing one or more child-node multicast group map tables associated with the one or more child nodes, each of the one or more child-node multicast group map tables comprising (i) an ID associated with at least one multicast group in which the cell is a member and (ii) at least one identifier vector for identifying the at least one multicast group ID in the child-node multicast group map table;

(b) receiving a multicast group packet whose routing information comprises a target identifier vector and a target multicast group ID;

(c) determining whether to forward the multicast group packet to the one or more child nodes based at least in part on the one or more child-node multicast group map tables associated therewith and the received target identifier vector; and

(d) if so, causing the parent node to forward the multicast group packet to the one or more child nodes.

2. The method of claim 1, wherein the at least one identifier vector points to a bit in the child-node multicast group map table and step (c) comprises determining whether the bit pointed to by the received target identifier vector is set to a non-zero value, and if so, causing the parent node to forward the multicast group packet to the one or more child nodes.

3. The method of claim 1, further comprising establishing and storing a parent-node multicast group map table associated with the parent node, the parent-node multicast group map table comprising (i) an ID associated with each multicast group IDs supported by all of the one or more child nodes of the parent node and subtrees associated therewith and (ii) at least one identifier vector merging the identifier vectors associated with all of the one or more child nodes of the parent node.

4. The method of claim 3, wherein the parent-node multicast group map table is established by applying a bitwise OR operation on the one or more child-node multicast group map tables of the child nodes of the parent node.

5. The method of claim 1, wherein the one or more child-node multicast group map tables have a size corresponding to a maximum number of the multicast group supported by the network.

6. The method of claim 1, wherein the forwarding step comprises forwarding, by the parent node, the multicast group packet to the one or more child nodes in a broadcasting or multiple unicasting manner.

7. The method of claim 1, further comprising determining a number of the child nodes to which the multicast group packet is forwarded.

8. The method of claim 7, further comprising causing the parent node to forward the multicast group packet in a broadcasting manner if the number of the child nodes to which the multicast group packet is forwarded exceeds one.

9. The method of claim 7, further comprising causing the parent node to forward the multicast group packet in a unicasting manner if the multicast group packet is forwarded to a single child node.

10. The method of claim 1, further comprising:

determining whether the target multicast group ID associated with the group packet matches the at least one multicast group ID in the one or more child-node multicast group map tables; and

if so, causing the group packet to be transferred to a higher stack layer within the one or more child nodes.

11. A network system for multicast routing a group packet in a network comprising a plurality of cells each supporting communication among a plurality of transceiver nodes therein and being capable of receiving and transmitting group packets, each cell comprising a parent node and one or more child nodes, each group packet comprising routing information and a payload, the system comprising:

memory for storing one or more child-node multicast group map tables associated with the one or more child nodes, each of the one or more child-node multicast group map tables comprising (i) an ID associated with at least one multicast group and (ii) at least one identifier vector for identifying the at least one multicast group ID in the child-node multicast group map table; and

a plurality of network management systems associated with the network system and each of the transceiver nodes;

wherein the network management system associated with the network system is configured to receive a multicast group packet whose routing information comprises a target identifier vector and a target multicast group ID; and the network management system associated with each of the nodes is configured to (i) determine whether to forward the multicast group packet to the one or more child nodes based at least in part on the one or more child-node multicast group map tables associated therewith and the received target identifier vector; and (ii) if so, cause the parent node to forward the multicast group packet to the one or more child nodes.

12. The system of claim 11, wherein the at least one identifier vector points to a bit in the child-node multicast group map table and the network management system associated with each node is further configured to determine whether the bit pointed to by the received target identifier vector is set to a non-zero value, and if so, cause the parent node to forward the multicast group packet to the one or more child nodes.

13. The system of claim 11, wherein the network management system associated with each node is further configured to:

establish a parent-node multicast group map table associated with the parent node, the parent-node multicast group map table comprising (i) an ID associated with each multicast group IDs supported by all of the one or more child nodes of the parent node and subtrees associated therewith and (ii) at least one identifier vector merging the identifier vectors associated with all of the one or more child nodes of the parent node; and

store the parent-node multicast group map in the memory.

14. The system of claim 13, wherein the network management system associated with each node is further configured to establish the parent-node multicast group map table by applying a bitwise OR operation on the one or more child-node multicast group map tables of the child nodes of the parent node.

15. The system of claim 11, wherein the one or more child-node multicast group map tables have a size corresponding to a maximum number of the multicast group supported by the network.

16. The system of claim 11, wherein the network management system associated with each node is further configured to forward, by the parent node, the multicast group packet to the one or more child nodes in a broadcasting or multiple unicasting manner.

17. The system of claim 11, wherein the network management system associated with each node is further configured to determine a number of the child nodes to which the multicast group packet is forwarded.

18. The system of claim 17, wherein the network management system associated with each node is further configured to cause the parent node to forward the multicast group packet in a broadcasting manner if the number of the child nodes to which the multicast group packet is forwarded exceeds one.

19. The system of claim 17, wherein the network management system associated with each node is further configured to cause the parent node to forward the multicast group packet in a unicasting manner if the multicast group packet is forwarded to a single child node.

20. The system of claim 11, wherein the network management system associated with each node is further configured to:

determine whether the target multicast group ID associated with the group packet matches the at least one multicast group ID in the one or more child-node multicast group map tables; and

if so, cause the group packet to be transferred to a higher stack layer within the one or more child nodes.

21. A method of updating a firmware file in a network comprising a plurality of cells each supporting communication among a plurality of transceiver nodes therein and being capable of receiving and transmitting the firmware file, each cell comprising a parent node and one or more child nodes, the method comprising: (a) dividing the firmware file into a plurality of chunks, each chunk being able to be included in a single data packet transmitted between two of the transceiver nodes;

(b) transmitting each of the chunks from a first one of the transceiver nodes to a second one of the transceiver nodes;

(c) transmitting a request message from the first one of the transceiver nodes to the second one of the transceiver nodes, the request message comprising information associated with the chunks that have been transmitted in step (b); and

(d) transmitting a responding message from the second one of the transceiver nodes to the first one of the transceiver nodes, the responding message comprising information associated with at least one of the chunks that is included in the request message of step (c) but not received by the second one of the transceiver nodes.

22. The method of claim 21, further comprising assigning a sequence number to each of the chunks based at least in part on an order of the chunk in the divided firmware file.

23. The method of claim 22, wherein each of the chunks in its associated data packet is preceded by a header comprising information of at least one of a type of the firmware file, a time stamp indicating a release time of the firmware file, or the sequence number associated with the chunk.

24. The method of claim 22, wherein the information associated with the chunks in the request message and responding message comprises the sequence numbers associated with the chunks.

25. The method of claim 24, further comprising, upon the first one of the transceiver nodes receiving the responding message, storing the sequence number associated with the at least one of the chunks in a delivery queue associated with the first one of the transceiver nodes for further transmission.

26. The method of claim 25, further comprising classifying each of the chunks in the delivery queue into a plurality of states based at least in part on a status of the chunk in a child node associated with the first one of the transceiver nodes.

27. The method of claim 26, further comprising determining a timing for transmitting each of the chunks in the delivery queue based at least in part on its associated state.

28. The method of claim 21, further comprising, upon the second one of the transceiver nodes receiving the transmitted chunks, determining whether each of the received chunks is associated with a most recently released version of the firmware file.

29. The method of claim 28, further comprising upon determining that the chunk is associated with the most recently released version of the firmware file, storing the chunk in a database associated with the second one of the transceiver nodes and causing the second one of the transceiver nodes to transmit the chunk to one or more child nodes associated therewith.

30. The method of claim 21, wherein the chunks in step (b) are transmitted in a broadcasting manner.

31. The method of claim 21, further comprising, prior to step (d), determining a time interval for the second one of the transceiver nodes to wait before transmitting the responding message to the first one of the transceiver nodes.

32. The method of claim 31, wherein the time interval is determined based at least in part on a number of the chunks included in the request message of step (c) that are not received by the second one of the transceiver nodes.

33. The method of claim 21, wherein each of the transceiver nodes stores exactly one complete version of the firmware file whose chunks are all received and at most one outstanding version whose chunks are only partially received.

34. A network system for updating a firmware file in a network comprising a plurality of cells each supporting communication among a plurality of transceiver nodes therein and being capable of receiving and transmitting the firmware file, each cell comprising a parent node and one or more child nodes, the system comprising:

at least one network management system associated with at least one of the transceiver nodes, the at least one network management system being configured to: (a) divide the firmware file into a plurality of chunks, each chunk being able to be included in a single data packet transmitted between two of the transceiver nodes;

(b) transmit each of the chunks from a first one of the transceiver nodes to a second one of the transceiver nodes;

(c) transmit a request message from the first one of the transceiver nodes to the second one of the transceiver nodes, the request message comprising information associated with the chunks that have been transmitted in step (b); and

(d) transmit a responding message from the second one of the transceiver nodes to the first one of the transceiver nodes, the responding message comprising information associated with at least one of the chunks that is included in the request message of step (c) but not received by the second one of the transceiver nodes.

35. The network system of claim 34, wherein the at least one network management system is further configured to assign a sequence number to each of the chunks based at least in part on an order of the chunk in the divided firmware file.

36. The network system of claim 35, wherein each of the chunks in its associated data packet is preceded by a header comprising information of at least one of a type of the firmware file, a time stamp indicating a release time of the firmware file, or the sequence number associated with the chunk.

37. The network system of claim 35, wherein the information associated with the chunks in the request message and responding message comprises the sequence numbers associated with the chunks.

38. The network system of claim 37, further comprising memory for storing a delivery queue associated with the first one of the transceiver nodes, the at least one network management system being further configured to, upon the first one of the transceiver nodes receiving the responding message, store the sequence number associated with the at least one of the chunks in the delivery queue for further transmission.

39. The network system of claim 38, wherein the at least one network management system is further configured to classify each of the chunks in the delivery queue into a plurality of states based at least in part on a status of the chunk in a child node associated with the first one of the transceiver nodes.

40. The network system of claim 39, wherein the at least one network management system is further configured to determine a timing for transmitting each of the chunks in the delivery queue based at least in part on its associated state.

41. The network system of claim 34, wherein the at least one network management system is further configured to, upon the second one of the transceiver nodes receiving the transmitted chunks, determine whether each of the received chunks is associated with a most recently released version of the firmware file.

42. The network system of claim 31, further comprising memory for storing the received chunks in a database associated with the second one of the transceiver nodes, the at least one network management system being further configured to, upon determining that the received chunks are associated with the most recently released version of the firmware file, cause the second one of the transceiver nodes to transmit the chunks to one or more child nodes associated therewith.

43. The network system of claim 34, wherein the chunks in step (b) are transmitted in a broadcasting manner.

44. The network system of claim 34, wherein the at least one network management system is further configured to, prior to step (d), determine a time interval for the second one of the transceiver nodes to wait before transmitting the responding message to the first one of the transceiver nodes.

45. The network system of claim 44, wherein the time interval is determined based at least in part on a number of the chunks included in the request message of step (c) that are not received by the second one of the transceiver nodes.

46. The network system of claim 34, wherein each of the transceiver nodes stores exactly one complete version of the firmware file whose chunks are all received and at most one outstanding version whose chunks are only partially received.

47. A method of efficient beacon communication in a wireless network comprising a plurality of nodes each supporting communication over a plurality of distinct channels including at least one operational channel for receiving and transmitting data traffic to and from other nodes, the method comprising, for each node:

(a) transmitting conventional beacons over the operational channel, the conventional beacons reaching one-hop neighboring nodes having operational channels matching the operational channel of the node; and

(b) transmitting, by the node, visitor beacons to all other neighboring nodes over one or more channels, different from the operational channel of the node, the visitor beacons specifying the operational channel of the node, whereby each of the other neighboring nodes receives conventional beacons from the node over a secondary channel matching the operational channel of the node, the secondary channel being different from the one or more channels utilized to transmit the visitor beacons.

48. The method of claim 47, wherein a conventional beacon transmitted by a node comprises data specifying capabilities of the node and neighboring nodes.

49. The method of claim 47, wherein the conventional beacon also comprises data specifying an internal representation of the network or portion thereof.

50. The method of claim 47, wherein the visitor beacon also comprises data specifying capabilities of the node and neighboring nodes.

51. The method of claim 47, wherein the operational channel of the node is inactive in step (b).

52. The method of claim 47, wherein each node is also configured to operate in a hold- and-sniff mode whereby the node signals its associated parent node in the wireless network to cease, for a defined interval, transmission over the operational channel of the node, the node receiving the beacons from one or more one-hop neighboring nodes in the wireless network over one or more tertiary channels thereof during the defined interval, the one or more tertiary channels being different from the operational channels of the node.

53. The method of claim 52, wherein the operational channel of the node is inactive when the node is receiving the beacons over the one or more tertiary channels.

54. A node for communicating over a wireless network, the node comprising at least one radio transceiver for supporting communication over at least one operational, the node being configured for (a) transmitting conventional beacons over the operational channel, the conventional beacons reaching one-hop neighboring nodes having operational channels matching the operational channel of the node, and (b) transmitting visitor beacons to all other neighboring nodes over one or more channels, different from the operational channel of the node, the visitor beacons specifying the operational channel of the node, whereby each of the other neighboring nodes receives conventional beacons from the node over a secondary channel matching the operational channel of the node, the secondary channel being different from the one or more channels utilized to transmit the visitor beacons.

55. The network node of claim 54, wherein a conventional beacon transmitted by the node comprises data specifying capabilities of the node and neighboring nodes.

56. The network node of claim 54, wherein the conventional beacon also comprises data specifying an internal representation of the network or portion thereof.

57. The network node of claim 54, wherein the visitor beacon also comprises data specifying capabilities of the node and neighboring nodes.

58. The network node of claim 54, wherein the node is configured such that the operational channel of the node is inactive in step (b).

59. The network node of claim 54, wherein the node is also configured to operate in a hold-and-sniff mode whereby the node signals its associated parent node in the wireless network to cease, for a defined interval, transmission over the operational channel of the node, the node receiving the beacons from one or more one-hop neighboring nodes in the wireless network over one or more tertiary channels thereof during the defined interval, the one or more tertiary channels being different from the operational channels of the node.

60. The network node of claim 59, wherein the node is configured such that the operational channel of the node is inactive when the node is receiving the beacons over the one or more tertiary channels.