Method and device for reliable broadcast

BACKGROUND OF THE INVENTION

0001In an Unmanned Ground System (UGS) network, the Command and Control (C2) vehicle initiates formation of a mobile ad hoc wireless sensor network. One type of network architecture for a UGS network is a tree-based architecture. The tree-based network architecture takes advantage of the fact that sensor nodes are relatively static and, therefore, do not require frequent routing updates. The C2 vehicle (also called the C2 node), on the other hand, can leave and form the network at any time and any location.

0002The C2 node generates two important commands: an "Activate" command or message to form the network and a "Deactivate" command or message to dissolve the network. The C2 node initiates formation of the UGS network by broadcasting the "Activate" command, and can re-route the existing with the "Activate" command. When the C2 node leaves the UGS network, it broadcasts the "Deactivate" command to sensor nodes so that they reset their stored network topology data in preparation to receive the next "Activate" command.

0003Broadcasting is a common operation in mobile ad hoc networks (MANETs). Broadcasting is used in routing protocols to discover routes and in group communication operations. Broadcasting schemes for MANETs fall into four general categories: Blind flooding, area-based methods, probabilistic scheme, and neighbourhood-knowledge-based methods. In flooding, a broadcast message is forwarded exactly once by every node in the network. Flooding is wasteful, especially in dense networks. Several efforts have targeted reducing the redundancy of flooding broadcasts.

0004In a blind flooding method each node receiving a copy of a broadcast message first checks whether it has already received it. If so, the node silently discards the message. If the message was received by the node for the first time then the node rebroadcasts it to all of its neighbours. Schemes such as probabilistic, counter-based, distance-based, and cluster-based, have been proposed to alleviate the drawbacks of redundant rebroadcasts.

0005In a probabilistic re-broadcasting approach, upon receiving a broadcast message for the first time, a node will rebroadcast it with probability P similar to the gossiping-based approach. The adaptive gossip probability is explored to make the protocol insensitive to a changing environment. However, the reliability of this approach depends on the probability P and the topology of the network.

0006A number of neighbourhood knowledge-based algorithms use the connectivity of the node's k-hop neighbour's information for some small integer (typically 2). The algorithms use this partial topology knowledge to reduce the number of nodes which relay the broadcast message. Two related solutions have been proposed: Self-Pruning and Dominant-Pruning. In the self-pruning-based broadcast protocol, each node collects neighbourhood topology information (i.e., static information) by exchanging "Hello" message and extracts broadcast history information (i.e., dynamic information) from incoming broadcast messages. Each node decides its role in a specific broadcasting event: it is a forward node and forwards the broadcast message, or a non-forward node (i.e., is self-pruned) and discards the message silently. Collectively, forward nodes, including the source node, form a connected dominating set and ensure the coverage. A set of nodes is a dominating set if every node in the network is either in the set or a neighbour of a node in the set. Nodes are selected into this set in such a way that they cover a node's entire two-hop neighbourhood. This requires substantial communication between neighbouring nodes to update the neighbour information.

0007There are several drawbacks associated with using existing broadcast protocols in a UGS network. First, the existing broadcast protocols focus only on the efficient delivery of broadcast message, that is maximizing the probability the message reaches all nodes in the network. Impact of the significant network topology changes that are initiated by the received broadcast message is not considered in the conventional broadcast protocols.

0008Second, the conventional broadcast protocols require large amount of information about the topological or geographical structure of the network when the network topology is changing. This creates significant overhead problems in a sensor network. Third, conventional broadcast and routing techniques are based on optimization at the individual layer (namely link layer or network layer). As a result, neighbour discovery creates racing problems in the network routing updates. Finally, conventional broadcast techniques lead to unwanted power consumption in the nodes which is a significant problem in battery-operated nodes.

0009There is room for significant improvement in broadcast protocols for use in wireless networks, particularly wireless sensor networks.

SUMMARY OF THE INVENTION

0010Briefly, a method is provided broadcasting messages in an ad hoc wireless network having a tree-based architecture. When a node receives a message it first is determining whether the message is a broadcast message. When the message is a broadcast message, a source node of the broadcast message is determeined based on stored data at the node that represents an existing tree-based topology of the network; from the broadcast message a number of node hops to a root node for said source node and deriving therefrom a number of node from said root node to said node is determined; including comparing the number of node hops from said root node to said node with data stored at said node that represents the number of node hops between said root node and said node for said existing tree-based topology of the network. Based on comparing of the number of node hops to the node with data stored, a list of identifiers of other nodes in the network is build from which said node requires reception of a broadcast message as an implicit acknowledgment that said other nodes in the network have received said broadcast message; and said broadcast message being re-broadcasted.

0011Preferably the node builds this implicit acknowledgment list based on stored data pertaining to an existing tree-based topology of the network. After this list is built, the node re-broadcasts the broadcast message. Each node in the network executes this broadcasting protocol and in so doing a broadcast message quickly and efficiently propagates through the network with minimal redundancy and impact on the topology of the network.

BRIEF DESCRIPTION OF THE DRAWINGS

0012<dl id="dl0001" compact="compact"><dt>FIG. 1</dt><dd>is a block diagram of conventional tree-based network architecture for a mobile wireless ad hoc network.</dd><dt>FIG. 2A</dt><dd>illustrates a conventional local repair process for a tree-based network. <figref idref="f0002">FIG. 2B</figref> illustrates a conventional re-route process for a tree-based network.</dd><dt>FIG. 3A</dt><dd>illustrates a conventional network de-activation process for a tree-based network.</dd><dt>FIG. 4</dt><dd>is a flow chart of a tree-based broadcast process according to one embodiment of the invention.</dd><dt>FIG. 5</dt><dd>is a flow chart of a network de-activation process according to an embodiment of the invention.</dd><dt>FIG. 6</dt><dd>is a flow chart of a network activation process according to an embodiment of the invention.</dd><dt>FIG. 7</dt><dd>is a flow chart of a re-routing process according to an embodiment of the invention.</dd><dt>FIG. 8</dt><dd>is a block diagram of wireless communication device that may perform the broadcast protocol according to the present invention.</dd><dt>FIG. 9</dt><dd>is a block diagram of an exemplary tree-based network used for analyzing performance of the techniques according to the present invention.</dd><dt>FIG. 10</dt><dd>illustrates performance plots for a conventional broadcast process in the network shown in <figref idref="f0009">FIG. 9</figref>.</dd><dt>FIG. 11</dt><dd>illustrates performance plots for another conventional broadcast process in the network shown in <figref idref="f0009">FIG. 9</figref>.</dd><dt>FIGs. 12 and 13</dt><dd>illustrate performance plots resulting from the tree-based broadcast process according to the present invention in the network of <figref idref="f0009">FIG. 9</figref>.</dd><dt>FIG. 14</dt><dd>illustrates a bar chart that compares a conventional broadcast process with the tree-based broadcast processing according to the present invention.</dd></dl>

DETAILED DESCRIPTION

0013<figref idref="f0001">FIG. 1</figref> illustrates a conventional wireless ad-hoc network 10 having a tree-based network topology. The network 10 comprises sensor nodes R1, R2, ..., R12 and a root node C2. A host computing device H connects to the network 10 at the C2 node. The host H may be any computing device that is used to set up as well as receive and analyze data gathered by the nodes in the network 10. The host H may connect to any node, and when doing so, that node then becomes a root node (C2 node) for the network. The host device H may connect by wired or wireless means to the root node. It should be understood that any node in the network may be connected to a host device H. Furthermore, any node with a host device can become the C2 node if an activation command supplied by its host device.

0014Each node in the tree-based network 10, other than the root node C2, has an upstream node that attaches it to the tree. Also, each node in is itself the root of a sub-tree that includes that node and all of the nodes downstream from it. The tree-based topology may need to be updated because of the root node C2 is mobile and because the deployment environment of the network may change. Thus, a node can be an upstream node, a downstream node or a neighbour node with respect to another node in the network 10. For example, Node R7 is an upstream node with respect to node R12 and node R12 is a downstream node with respect to node R7. On the other hand, node R6 is a neighbour node to node R7 and vice versa. The nodes may be sensor devices that form a UGS network, for example.

0015Formation of the network is primarily driven by inputs through a process called "neighbour discovery" whereby nodes learn about the existence of other nodes. Neighbour discovery involves a node transmitting a so-called "Hello" message that includes provides neighbour information when changes in the status of the bi-directional neighbour links are detected. When neighbour information updates are received, a node stores them in its local neighbour database. The initial neighbour database consumes the most extensive computation time and its update occurs rarely since most of the nodes, except the root node C2, are stationary in an UGS network.

0016In general, sensor networking requires two functions: <ul id="ul0001" list-style="bullet" compact="compact"><li>Initial Network Formation to allow the sensor nodes to detect the neighbours and form the tree-based topology at startup.</li><li>Network Maintenance to perform on-going adaptation to changes in the network environment.</li></ul>

0017The C2 node broadcasts two command messages to the sensor nodes: (1) "Activate" and (2) "Deactivate". The "Activate" message is an initiation network formation message initiated by the C2 node to make the sensor nodes that are in an "Out-Of-Net" state start to create the tree-based topology. The C2 node always transmits a "Hello" message, e.g., Hello(C2), indicating that it is forming a network thereby causing a node to switch to the so-called "In-Net" state. If a sensor network already exists, then the C2 node net-time-synchronizes to the existing network and broadcasts an "Activate" message so that sensor nodes re-route to the root node C2.

0018The purpose of the "Deactivate" message is to allow the C2 node to place the entire network, including sensors, into a deactivated or dormant state. The dormant state is intended to conserve battery power and prevent spoofing when the C2 node is not present to receive data. The "Deactivate" message requires sensor nodes to purge (or clear) their tree-based topology information and start to transmit the "Hello" message that indicates there is no-upstream-node, often called referred to as the "Hello(0)" message.

Initial Network Formation

0019Upon initial network formation, a sensor node initializes its net formation database and waits for the "Activate" broadcast message initiated from the C2 node, while building a bi-directional neighbour table by exchanging the "Hello" messages with other nodes. Upon the reception of the "Activate" message, a node selects the best upstream node candidate from the its net formation database and attempts to execute a so-called "affiliation operation" in which it transmits a join message to a candidate upstream node and waits to receive an acceptance message from that node indicating that the candidate upstream node has accepted and registered that node as one of its downstream nodes. Once the affiliation process is successful, the upstream node (i.e. adjacency) is selected and the node now enters the "In-Net" state. The net formation database contains the tree-based topology information.

Network Maintenance - Local Repair

0020The procedure for a so-called "tree repair" is depicted in <figref idref="f0002">FIG. 2A</figref>. In a tree repair process, an attempt is first made to locally repair the tree-based network architecture as long as an upstream node candidate is available by re-affiliating with another upstream node. This is called a "local tree repair" process. This process ends once the node is able to affiliate with a new upstream node. The adjacency node list is updated after the upstream node is changed.

0021The local tree repair operation, for node R3 as an example, terminates (fails) when the list of upstream node candidates (R1, R2 and R4) available for tree affiliation has been exhausted without successful repair. The local node sets the upstream node and the C2 node to 0 in the net formation database and initiates the neighbour discovery process, transmitting a "Hello" message that indicates no-upstream-node, the aforementioned "Hello(0)" message. Receiving Hello(0) message from its upstream node R3, the sub-tree node R5 starts to re-affiliate to node R4 using the local tree repair process.

Network Maintenance - Re-Route

0022In a "re-route" network maintenance procedure shown in <figref idref="f0002">FIG. 2B</figref>, one of the sensor nodes, e.g., node R2, is designated as a root node proxy in the absence of the C2 node. At some point later in time, when the C2 node wants to be the root of the existing networking tree, the C2 node broadcasts an "Activate" message to the sensor network. Upon receiving the "Activate" message, nodes R1 and R2 execute the re-affiliation procedure to the C2 node, while the remaining nodes keep the existing upstream node, for example. The re-route process could make the net formation procedure update significantly dependent upon the C2 node's location. When a node changes the upstream node, it starts transmitting "Hello(0)" messages because the existing upstream node is not valid. Receiving the Hello(0) message, downstream nodes may start local repair processes. This will trigger unwanted overhead in the network. A more timely approach is needed for repair.

0023When the C2 node does not move to a new location from where it formed the tree-based topology, the tree-based topology information may be used to broadcast efficiently. Otherwise, the use of "obsolete" or "incorrect" tree-based topology information will make the messaging broadcast scheme extremely unreliable and inefficient.

0024<figref idref="f0003">FIGs. 3A and 3B</figref> illustrate scenarios of possible locations of the C2 node from where it may broadcast a message to the sensor network. <figref idref="f0003">FIG. 3A</figref> illustrates scenarios when the C2 node broadcasts a Deactivate message from various locations with respect to the network and <figref idref="f0003">FIG. 3B</figref> illustrates scenarios when the C2 node broadcasts an Activate message from various locations.

0025There are two critical events to update the routing tree topology after the local node receives the broadcast ("Activate" and "Deactivate")command messages. One event is an external event and the other is an internal event.

0026The external event occurs when a node is in the "Out-Of-Net" state and it transmits a "Hello(0)" neighbour discovery message. Upon a local node receiving the "Hello(0)" message from an upstream node the local node clears its tree-topology data and starts the local repair process whereby it looks for another upstream node from available candidate upstream nodes.

0027The internal event occurs when a node receives the Activate" or "Deactivate" broadcast commands and the node needs to determine a new route (re-routing process) in order to find a better upstream node.

0028Using conventional techniques, the route would be updated by the change of neighbour information, local repair or both without using any information pertaining to the overall tree-based topology. This results in increased overhead for route discovery and maintenance and could create loops of local repair events.

0029According to the present invention, a cross-layer optimization protocol is provided to for a reliable and robust sensor system.

0030According to one aspect of the invention, a tree-based broadcast protocol with "implicit acknowledgment" ("implicit ACK") is provided. This broadcast protocol can be used as a basis for an overall more robust and stable networking protocol. The tree-based broadcast protocol with implicit ACK generally operates as follows. When a node receives a broadcast message for re-broadcasting to other nodes in the network, it builds a list of identifiers of other nodes in the network from which the node requires reception of a broadcast message as an implicit acknowledgment that said other nodes in the network have received said broadcast message. The node builds this implicit acknowledgment list based on stored data pertaining to an existing tree-based topology of the network. After this list is built, the node re-broadcasts the broadcast message. Each node in the network executes this broadcasting protocol and in so doing a broadcast message quickly and efficiently propagates through the network with minimal redundancy and impact on the topology of the network.

0031With reference to <figref idref="f0004">FIG. 4</figref>, the tree-based broadcast protocol with "implicit ACK" according to one embodiment of the invention is described in greater detail. Command messages, such as the "Deactivate" and "Activate" broadcast command messages contain the following fields, which may be included in a request-to-send (RTS) packet: <ul id="ul0002" list-style="bullet" compact="compact"><li>C2 Address</li><li>Sender Node Address</li><li>HopCountToC2</li></ul>

0032The RTS packet is a short burst and as a result contributes to reducing the collision problem encountered in conventional k-hop neighbour-based-information approach.

0033The tree-based broadcast protocol with "implicit ACK" is shown generally at 100 in <figref idref="f0004">FIG. 4</figref> and is designed to exploit the existing tree-based topology information and local node's neighbour table for reliable and efficient broadcast. At 105, the C2 node can broadcast a command message (e.g., an Activate or a Deactivate message) at any time and at any location with respect to sensor nodes in the network. When the C2 node broadcasts a command message, it sets HopCountToC2 to 0 in the command message. At 110, a local sensor node in the network receives the broadcast message. At this time, the local node does not know whether the broadcast message was received directly from the C2 node or another node in the network. Thus, at 110 the local node determines the source node of the received broadcast message using its stored data representing the existing tree-based topology of the network. Also at 110, using the data extracted from the received message, the local node updates its node hop count to the C2 node, My HopCountToC2. This computation is made by adding "1" to the sender's HopCountToC2.

0034At 115, the local node compares its node hop count, My HopCountToC2, with a configured parameter of a maximum number of node hops to the C2 node, MaxHopCountToC2. If the local node determines at 115 that My HopCountToC2 is greater than MaxHopCountToC2, then the process goes to 120 to stop the re-broadcasting process thereby minimizing redundant broadcasts in the UGS network. The value of MaxHopCountToC2 controls how fast the commands propagate throughout the networks. Otherwise, if at 115 the local node determines that My HopCountToC2 is less than or equal to MaxHopCountToC2, then the process continues to 125 wherein the local node builds a list of nodes that it should transmit an ACK message to depending on certain criteria. This list is referred to herein as an ACK list. As explained hereinafter, the local node uses this ACK list to keep track of which other nodes from which the local node is required to receive a broadcast message as an implicit acknowledgement that the other nodes have received the broadcast message. The local node will delete entries from this list after it begins to re-broadcast the broadcast message until the ACK list is empty of a maximum number of broadcast attempts is met, as represented by the loop 130-160.

0035The conventional approach to building an ACK list involves the local node deleting the sender node address (identifier) from its list of neighbours. When a local node receives a rebroadcast of the ACK message from a node in its neighbour list, the local node considers that an "implicit" acknowledgment from the neighbour node that the neighbour node received the broadcast message re-broadcasted from the local node.

0036In accordance with an aspect of the present invention, a tree-based broadcast with implicit ACK is provided that exploits the tree-based topology data stored in the nodes for a more reliable and efficient broadcast mechanism. At 125, the local node further analyzes the data derived from the received broadcast message and determines whether the existing tree-based topology for the network is still valid and generates the ACK list accordingly. That is, at 125, the local node builds a list of identifiers of other nodes in the network from which the local node requires reception of a broadcast message as an implicit acknowledgment that the other nodes in the network have received the broadcast message.

0037The pseudo-code logic for the process occurring at 125 is as follows. <pre listing-type="program-listing"> If local node is "In-Net" If (HopCountToC2 = = Number-Of-Hops-To-C2) ACK List = {Downstream Node} else if (Sender Node ID is among My Sub-Tree Member) ACK List = {Upstream Node} else ACK List = {Upstream Node and Downstream Node} If local node is "Out-Of-Net" ACK List = {All RF Neighbours deleting Sender Node ID}</pre>

0038To explain further, at 125, the local node first determines whether the sender node address is a node address that is in the local node's stored network formation database. If the sender node is in the local node's database, then the local node determines that it is in the "In-Net" state. When the local node is "In-Net", the local node builds its ACK list depending upon whether or not the computed HopCountToC2 (at 110) equals the NumberOfHopsToC2 stored in its network formation database for the existing tree-based topology of the network.

0039When the local node determines that the computed HopCountToC2 equals NumberOfHopsToC2, the local node knows that the existing tree-based network topology is still valid. In this case, the local node adds to its ACK list the identifier of the downstream node(s) in the existing tree-based network topology. On the other hand, if the local node determines that HopCountToC2 does not equal NumberOfHopsToC2, then the local node determines if the identifier or address of the source node from which the local node received the broadcast message is a node that is one of the local node's sub-tree members. If the local node determines that the sender node address is in the local node's sub-tree, then the local node knows that the C2 node has moved and has broadcasted the message through a downstream node in the existing tree-based topology with respect to the local. In this case, the local node assigns to its ACK list the identifier of the upstream node(s) in the existing tree-based network topology.

0040Further still, if the local node determines that HopCountToC2 does not equal NumberOfHopsToC2 and the sender node address is not in the local node's sub-tree, then the local node assigns the identifiers of both upstream and downstream nodes to its ACK list.

0041Finally, when a local node determines that the sender node address is an address that is not in the network formation database for the existing tree-based topology, the local node is in an "Out-Of-Net" state and therefore builds an ACK list that contains all nodes of the network except the sender node. This is the conventional broadcast with "implicit ACK" protocol.

0042After the local node builds the ACK list in 125, the local node computes a transmit delay interval, BcastXmtDelay based on a first fixed (but programmable) value and a second random value: BcastXmtDelay = BcastDelay_fixed + (BcastDelay_ran), where BcastDelay_fixed is the first fixed value and BcastDelay_ran is a second random value. The BcastDelay_fixed value is configured or programmed in local node so as to avoid or minimize collisions of broadcast messages from neighbour nodes.

0043After computing the transmit delay interval, the local node waits a period of time equal to the transmit delay interval at 135, and transmits the broadcast message (in other words re-broadcasts the broadcast message it received) at the expiration of the BcastXmtDelay time interval, at 140.

0044In the course of the broadcast message propagating through the network, each node keeps track of those nodes from which it has received a broadcast message, and deletes the address or identifier of that sender node from its ACK list until its ACK list is empty.

0045Thus, the local node performs the procedure represented by the loop at 145, 150 and 155 until the ACK list is empty or a broadcast receive delay time interval, BcastRcvDelay, expires. The BcastRcvDelay time interval allows the local node to receive neighbour nodes' re-broadcasted messages, and also takes into account signal propagation delay. For example, the BcastRcvDelay time interval may be computed from the first fixed value and the second random value referred to above, according to the computation: <maths id="math0001" num=""><math display="block"><mi>BcastRcvDelay</mi><mo>=</mo><mn>1.1</mn><mo>*</mo><mfenced separators=""><mi>BcastDelay_fixed</mi><mo>+</mo><mi>BcastDelay_ran</mi></mfenced></math><img file="EP1978670A2_D0001.tif" /></maths>

0046When the local node determines at the expiration of the BcastRcvDelay time interval that the ACK List is not empty, the process continues to 130, 135 and 140 such that the local node continues to broadcast the message. This loop continues for up to a maximum number of broadcast attempts, MaxNumBcastTrials, at which point the procedure 100 terminates even if the implicit ACK did not complete fully.

0047Turning to <figref idref="f0005">FIG. 5</figref>, a network deactivation procedure 200 is described in accordance with a further aspect of the present invention that is more robust and stable than procedures heretofore known and prevents unnecessary message routing throughout the network.

0048After the C2 node has initiated and formed the network, the C2 node may decide to leave the network at any time. When the C2 node leaves the network, it broadcasts a "Deactivate" command message to the network at any location (as shown in <figref idref="f0003">FIG. 3</figref>) to command all sensor nodes to purge their existing tree-based topology. Sensor nodes closer to the C2 node will receive the "Deactivate" message first. If they start to purge their topology database and transmit the neighbour discovery packet "Hello(0)" indicating that they purged their database, then their downstream nodes will start the "local repair" procedure because they have not yet received the "Deactivate" message. This would trigger the neighbouring nodes to execute unnecessary local repair procedures, causing a racing problem and creating significant message overhead among the sensor nodes. The process flow that is performed when a local node receives an over-the- air (OTA) Deactivate message is shown on the right side of <figref idref="f0005">FIG. 5</figref>.

0049It is also possible that a node may be the C2 node and receive a "C2 Leave" message from the host device rather than from another node. This situation is shown on the left side of <figref idref="f0005">FIG. 5</figref>.

0050The right side of the flow chart shown in <figref idref="f0005">FIG. 5</figref> is described first. When a local node receives an OTA Deactivate message, at 205, the local node determines whether it has already re-broadcasted the received Deactivate message or whether this is the first time it will re-broadcast it. When the local node determines that it has not already re-broadcasted the Deactivate message, then the local node performs the tree-based broadcast with implicit ACK procedure 100 shown in <figref idref="f0004">FIG. 4</figref> with respect to the re-broadcasting of the Deactivate message.

0051After the procedure 100 is completed with the Deactivate message, then the local node waits a deactivate reset delay time interval, DeactivateNfdResetDelay, at 210 before it purges stored tree-based network topology database. A local node computes the DeactivateNfdResetDelay timer using the its HopCountToC2 and a broadcast delay value, TBcastDelay, using the computation: <maths id="math0002" num=""><math display="block"><mi>DeactivateNfdDelay</mi><mo>=</mo><mi>TBcastDelay</mi><mo>*</mo><mfenced separators=""><mi mathvariant="normal">MaxHopsToCé</mi><mo>+</mo><mn>1</mn><mo>-</mo><mi>Hop</mi><mo>-</mo><mi mathvariant="normal">CountToCé</mi></mfenced></math><img file="EP1978670A2_D0002.tif" /></maths> where <maths id="math0003" num=""><math display="block"><mi>TBcastDelay</mi><mo>=</mo><mfenced separators=""><mi>BcastDelay_fixed</mi><mo>+</mo><mi>BcastDelay_ran</mi></mfenced><mo>*</mo><mi>MaxNumBcast</mi><mo>-</mo><mi>Trials</mi></math><img file="EP1978670A2_D0003.tif" /></maths>

0052The DeactivateNfdResetDelay timer allows leaf nodes to reset their network topology database first, then their Upstream Node and reset the network topology databases and so on throughout the entire network. During the transition waiting period set by the DeactivateNfdResetDelay timer, a local node ignores all Hello(0) messages it receives and thus will not invoke a local repair procedure.

0053Upon expiration of the DeactivateNfdResetDelay timer, at 215 the local node clears its network topology database so that it is in the "Out-of-Net" state and ready to form a new network topology from a C2 node. Thereafter, at 220 the local node activates an affiliate delay timer, AfifiliateDelay, to prevent executing an unwanted affiliation procedure. The AfifiliateDelay timer may be based on the broadcast delay time interval according to the equation: <maths id="math0004" num=""><math display="block"><mi>AffiliateDelay</mi><mo mathvariant="normal">=</mo><mi>TBcastDelay</mi><mo mathvariant="normal">*</mo><mfenced separators=""><mi>MaxHopsToC</mi><mo>⁢</mo><mn mathvariant="normal">2</mn><mo mathvariant="normal">+</mo><mn mathvariant="normal">1</mn></mfenced></math><img file="EP1978670A2_D0004.tif" /></maths>

0054When a node receives a "C2 Leave" message from a host device, the process follows the left side of <figref idref="f0005">FIG. 5</figref>, where at 225, the node determines whether it is the C2 node. If the node is the C2 node, then at 230 it generates a Deactivate message (with HopCountToC2 = 0) and broadcasts it into the network according to the procedure 100 shown in <figref idref="f0004">FIG. 4</figref>. Otherwise, if the local node is not the C2 node, then the process continues to 230.

0055Likewise, when at 205 a local node determines that it has already re-broadcasted the Deactivate message, the process continues to 230. At 230, the local node ignores the Deactivate message received either OTA or from a host device.

0056The total time needed for the Deactivate command to propagate through a network using the procedure shown in <figref idref="f0005">FIG. 5</figref> is: <maths id="math0005" num=""><math display="block"><mi>DeactivateNetConvergeTime</mi><mo mathvariant="normal">=</mo><mn>2</mn><mo>*</mo><mi>TBcastDelay</mi><mo mathvariant="normal">*</mo><mfenced separators=""><mi>MaxHopsToC</mi><mo>⁢</mo><mn mathvariant="normal">2</mn><mo mathvariant="normal">+</mo><mn mathvariant="normal">1</mn></mfenced></math><img file="EP1978670A2_D0005.tif" /></maths>

0057Turning to <figref idref="f0006">FIG. 6</figref>, a process is described for network formation or activation procedure 300 according to an embodiment of the invention. The purpose of the Activate message is to provide the C2 node with the ability to form the network. The left side of <figref idref="f0006">FIG. 6</figref> illustrates the process flow when a local node receives the Activate command from a host device. When a local node receives an Activate message from the host device, it becomes the C2 node. The right side of <figref idref="f0006">FIG. 6</figref> illustrates the process flow when the local node receives an OTA Activate message.

0058The left side of the <figref idref="f0006">FIG. 6</figref> is described first. Again, when a local node receives the Activate message from the host, at 305 it configures itself as the C2 node. If there is an existing network, the C2 node will net-time-synchronize with the existing network at 305. Then, at 310, the C2 node waits a re-route discovery delay time interval, RerouteNbrDiscDelay, during which the local node (now the C2 node) attempts to find as many neighbour nodes as possible through the exchange of Hello packets, before engaging in the neighbour discovery and affiliation procedure. After the RerouteNbrDiscDelay interval, at 315 the node determines whether it has detected any neighbour nodes. If the C2 node has no neighbour(s), then at 320 the node sends a message to the host indicating the node is isolated. This message is known as the "C2Isolated" message. Otherwise, when the node has discovered neighbour nodes during the RerouteNbrDiscDelay interval, at 325 the node generates an Activate message (setting HopCountToC2 to 0) and broadcasts this message using the tree-based broadcast with implicit ACK procedure 100 shown in <figref idref="f0004">FIG. 4</figref>.

0059At 330 after a node receives an OTA Activate message, the node determines whether or not it is "In-Net", that is whether it is has already received the OTA broadcast message. If the node has already received the OTA broadcast message and therefore is already part of a network, the node proceeds to execute a re-route process 400, described in detail hereinafter in connection with <figref idref="f0007">FIG. 7</figref>. On the other hand, the first time the node receives the Activate message it is in the "Out-of-Net" state and at 335 it initiates a network formation process. At 340 the node determines whether it has already re-broadcasted the Activate message. If it has, then at 345 it ignores the received Activate message. If the node has not yet re-broadcasted the Activate message, then it performs the tree-based broadcast with implicit ACK procedure 100 shown in <figref idref="f0004">FIG. 4</figref>.

0060Turning to <figref idref="f0007">FIG. 7</figref>, the re-route process 400 is now described. At 405, the node determines whether the received Activate message is the first one that it received. If it is not the first message, then at 410 the node ignores it. On the other hand, if it is the first time it has received the Activate message, then at 415 the node reads the Activate message to extract the C2 node address, the sender node address and the HopCountToC2. Then, at 420, the local node computes an activate reset delay time interval, ActivateNfdRestDelay. The ActivateNfdResetDelay timer at the local node is computed by: <maths id="math0006" num=""><math display="block"><mi>ActivateNfdResetDelay</mi><mo mathvariant="normal">=</mo><mfenced separators=""><mi>MaxHopsToC</mi><mo>⁢</mo><mn mathvariant="normal">2</mn><mo mathvariant="normal">+</mo><mn mathvariant="normal">1</mn><mo mathvariant="normal">-</mo><mi>HopCountToC</mi><mo>⁢</mo><mn mathvariant="normal">2</mn></mfenced><mo mathvariant="normal">*</mo><mi>Max</mi><mfenced separators=""><mi>TBcastDelay</mi><mo>⁢</mo><mi>TAffiliationDelay</mi></mfenced><mo mathvariant="normal">;</mo></math><img file="EP1978670A2_D0006.tif" /></maths> where TBcastDelay = (BcastDelay_fixed + BcastDelay_ran) * MaxNumBcastTrials and TAffiliationDelay is the affiliation delay time interval computed as:

0061TAffiliationDelay = NeighborDisclnterval + AffiliationResInterval * Max-NumAffiliationJoinTries, where NeighborDiscInterval is a neighbour discovery time interval, AffiliatonResInterval is an affiliation reset interval and MaxNumAffiliationJoinTries is a maximum number of affiliation join attempts.

0062While waiting for expiration of the ActivateNfdResetDelay timer, the node receives "Hello" neighbour discovery message and determines whether the C2 node address in the received neighbour discovery message is same as that of the first "Activate" message. If no neighbour discovery message is received (having a matching C2 node address) before the ActivateNfdResetDelay timer expires, then at 440 the node purges its stored network formation (topology) data and goes into the "Out-of-Net" state at 442, ready to re-affiliate. On the other hand, when a neighbour discovery message is received that has a matching C2 node address, then the process continues to 430 where the node waits for expiration of the NeighborDiscInterval timer, and then at 435 executes a upstream node selection process. The NeighborDiscInterval timer allows for the neighbour discovery process to achieve adequate discovery before making an upstream node selection. Using knowledge of its neighbour nodes, the node then selects one of these neighbour nodes to be its upstream node. At 445, it determines whether the newly selected upstream node is the same as the upstream node that it had been using. If it is a different upstream node that is selected, then at 450 the node executes the affiliation process to join the network with that new upstream node. On the other hand, if it is the same upstream node, then the node uses its existing network topology data and the process skips to 460. If the node cannot successful affiliate with the new upstream node, then the node goes into the "Out-of-Net" state at 442. Once the node has successfully joined with the new upstream node, then at 460, the node updates its stored network formation database to reflect the new tree-based topology and at 465 where the node informs its neighbour nodes of updates to the tree-based network topology.

0063<figref idref="f0008">FIG. 8</figref> illustrates a block diagram for a wireless communication device 500 that may function as a sensor node or C2 node in the wireless ad-hoc network described herein. The device The communication device 500 comprises a radio transceiver 510, a modem 514, a controller 520 and a memory 530. The radio transceiver 510 transmits and receives signals via an antenna 512 and the modem performs baseband signal processing (modulation and demodulation) of the transmit and receive signals. The controller 520 may be embodied by a microprocessor or other programmable processing device that executes a program stored in memory 530 for controlling operation of the communication device 500. For example, a tree-based broadcast with implicit ACK program 540 (as well as programs for the other processes described herein) may be stored in the memory 530 such that when the controller 520 executes the program 540, it performs the processes described above in connection with <figref idref="f0004 f0005 f0006 f0007">FIGs. 4-7</figref>. Alternatively, the controller 520 may be an application specific integrated circuit that is designed with logic to execute the functions of the program 540. The memory 530 stores the data for the tree-based topology that the device is aware of as a node in a network. For example, the memory 530 may store tree-based network topology data for an existing tree-based network comprising node identifier/addresses of other nodes in the network, indications of which nodes are upstream or downstream nodes, which nodes are in a sub-tree, the number of hops between the node and the root node, etc.

0064With reference to <figref idref="f0009 f0010 f0011 f0012 f0013 f0014">FIGs. 9-14</figref>, a summary of performance analysis is provided to illuminate the effectiveness of the tree-based with "implicit ACK" procedures according to the present invention. <figref idref="f0009">FIG. 9</figref> illustrates a 15-node network comprising a root node C2 and 14 sensor nodes R1, R2, ..., R14.

0065With flooding, each node has a number of common nodes (=c) and will retransmit the broadcast packet up to MaxNumBcastTrials (= w) times. The probability of a successful broadcast transmission at the i^th hop from C2 is: <maths id="math0007" num=""><math display="block"><msub><mi mathvariant="normal">P</mi><mi mathvariant="normal">S</mi></msub><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">=</mo><msub><mi mathvariant="normal">P</mi><mi mathvariant="normal">S</mi></msub><mo>⁢</mo><mfenced separators=""><mi mathvariant="normal">i</mi><mo mathvariant="normal">-</mo><mn mathvariant="normal">1</mn></mfenced><mo mathvariant="normal">*</mo><mfenced open="{" close="}" separators=""><mn mathvariant="normal">1</mn><mo mathvariant="normal">-</mo><msup><mfenced open="[" close="]" separators=""><mn mathvariant="normal">1</mn><mo mathvariant="normal">-</mo><msup><mfenced separators=""><mn mathvariant="normal">1</mn><mo mathvariant="normal">-</mo><msub><mi mathvariant="normal">P</mi><mi mathvariant="normal">f</mi></msub></mfenced><mrow><mn mathvariant="normal">2</mn><mo>⁢</mo><mi mathvariant="normal">N</mi></mrow></msup></mfenced><mrow><mi mathvariant="normal">C</mi><mo mathvariant="normal">*</mo><mi mathvariant="normal">W</mi></mrow></msup></mfenced></math><img file="EP1978670A2_D0007.tif" /></maths> where P_S(i-1) is the probability of success that nodes at (i-1)^th Hops from the root node C2 will receive the broadcast packet and P_f is the probability that a link failure causes a broadcast packet not to be delivered.

0066Performance of the four broadcast with "implicit ACK" schemes is estimated for the network topology shown in <figref idref="f0009">FIG. 9</figref>.

0067<figref idref="f0010">FIG. 10</figref> illustrates plots for performance using conventional broadcast with "implicit ACK". In this case, a local node generates its ACK list from neighbours by deleting the source node address. The C2 node starts to broadcast the message throughout the network. If any neighbour fails to rebroadcast, the sender retransmits up to w (=3 in this estimate) times. Node R6 has two common nodes R2 and R3. <figref idref="f0010">FIG. 10</figref> illustrates the probability of success of a message (P_s) versus the probability of link failure (P_f from 1 % up to 20 %) for all the nodes of the network shown in <figref idref="f0009">FIG. 9</figref>. The nodes that are farther from the C2 node have less probability of success (P_s), as expected.

0068<figref idref="f0011">FIG. 11</figref> illustrates plots for performance using the well known double-covered broadcast (DCB) protocol that selects forwarding nodes to reduce the redundant broadcasts with k-hop neighbour information. Applying the simple DCB method to the network shown in <figref idref="f0009">FIG. 9</figref>, node R6 does not forward the broadcast message. Nodes R10 and R11 lose one common node (R6). <figref idref="f0011">FIG. 11</figref> illustrates the probability of success of a message (P_s) versus the probability of link failure (P_f from 1 % up to 20 %).

0069<figref idref="f0012">FIGs. 12</figref> and <figref idref="f0013">13</figref> illustrate plots for performance of the tree-based broadcast with implicit ACK methodology according to the present invention. Assuming C2 broadcasts the message at the same location where the tree-based topology is built, the local node's ACK list is built by from a downstream node. The performance for this scenario is shown in <figref idref="f0012">FIG. 12</figref>. <figref idref="f0013">FIG. 13</figref> illustrates the performance when a local node's ACK list is built from upstream and downstream nodes, caused by movement of the C2 node to a new location.

0070<figref idref="f0014">FIG. 14</figref> illustrates a chart comparing performance of broadcast protocol of the present invention with the conventional broadcast protocols. <figref idref="f0014">FIG. 14</figref> shows that the tree-based broadcast protocol technique according to the present invention is 13%, 24 % and 16 % better than the DCB method at nodes R6, R10 and R11, respectively, and is 19%, 18% and 13% better than the conventional broadcast method at nodes R6, R10 and R11, respectively.

0071In summary, according to the techniques of the present invention, a local node waits to perform broadcast commands ("Deactivate" or "Activate") based on the local node's HopCountToC2. This coordinated net formation based on the local node's HopCountToC2 prevents unnecessary local repair throughout the network. The "Deactivate" command starts for the farthest nodes from the C2 node (k-hops) and the next k-1 hops away nodes follow and so on, in a "bottom-up" manner. The "Activate" command starts net formation for the nearest nodes to the C2, then 1-hop away nodes follow and so on, in a "top-down" manner. The speed of net formation can be optimized by controlling the duration of this waiting period.

0072No technique is heretofore known in which cross-layer optimization is performed to coordinate network formation using a tree-based broadcast with "implicit ACK" protocol so that the network is stable and robust when the C2 may move about with respect to nodes of the network. The techniques according to the present invention prevent unnecessary exchanges of k-hop neighbour's information, lower energy consumption of the nodes, avoid racing problems caused by local repair procedures, and employ a re-route process that significantly reduces the OTA traffic. These techniques can be used in other coordinated network management operations through the sequential "bottom-up" and "top-down" procedures.

0073The techniques for the present invention are useful in any sensor network that uses a tree-based topology, including but not limited, to tactical (ground-based) UGS sensor networks, but to military ad-hoc sensor networks in general as well as any other commercial sensor network applications.

0074The system and methods described herein may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative and not meant to be limiting.