WO2011083389A1

WO2011083389A1 - Election of broadcast routers in a multihop network

Info

Publication number: WO2011083389A1
Application number: PCT/IB2010/056044
Authority: WO
Inventors: Philip Andrew Rudland; David M Avery; Philip Anthony Jamieson; Bozena Erdmann; Armand Michel Marie Lelkens
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2010-01-06
Filing date: 2010-12-23
Publication date: 2011-07-14

Abstract

A method for defining broadcast routers in a wireless multihop mesh network of nodes comprising a plurality of routing nodes potentially able to repeat a broadcast message comprises: • determining (11) for each routing node the number of neighboring routing nodes and the quality of each link between the routing node and the neighboring routing nodes; • selecting (13) a subset of the plurality of routing nodes comprising a reduced number of routing nodes so that only routing nodes belonging to the subset are allowed to perform selected operations.

Description

ELECTION OF BROADCAST ROUTERS IN A MULTIHOP NETWORK.

Field of the invention

The invention relates to the field of wireless multihop mesh networks, such as ZigBee networks and more particularly a method for defining broadcast routers in such a network, i.e. routers that participate in broadcast forwarding.

Background of the invention

ZigBee (a trademark of the ZigBee Alliance) is a standard for low cost, low power wireless connectivity, suited for control and monitoring applications in Lighting, Medical, Building Automation and other fields. It is based on the IEEE 802.15.4 standard. It employs multi-hop routing algorithms with the goal of providing reliable communications even in large, dense networks. Typical deployment scenarios are a large office, a supermarket, or a hospital in which each of the lights, temperature, occupancy, light level and other sensors may be ZigBee enabled to reduce installation time and costs. ZigBee might also be used for basic location awareness.

ZigBee has three types of messages/communication modes:

• Unicasts - sent from one node to another single node. End-to-end unicast messages can be sent over multiple hops, as a series of single-hop unicast transmissions. Generally these transmissions are acknowledged immediately at each hop (at MAC level), and they may also be acknowledged end-to-end with a further uni c ast rep ly (APS acknowledgement or APPL layer response).

• Multicasts - ZigBee multicasts are closely related to ZigBee broadcasts. There are two varieties. One involves a broadcast which some nodes are configured to ignore (i.e. drop without forwarding to the Next Higher Layer) at the application layer. The other involves a broadcast which some nodes are configured to ignore (i.e. drop without forwarding to NHL or other nodes) at the network layer.

• Broadcasts - a broadcast transaction typically goes to all nodes in the network (unless radius limited). ZigBee further has different broadcasts for different node types (to address all routers, all low-power routers, all non-sleeping devices, and all devices in the network, respectively). Technically all transmissions are "broadcast" locally, but for unicast and multicast transmissions the addressing fields in each message allow nodes to ignore messages which are not intended for them already on MAC or NWK layer.

During broadcast and multicast messaging the message is generally heard by more than one node, and is then repeated by those multiple nodes, until all intended nodes have heard it. Jitter, i.e. random delays, and the CSMA (carrier sense multiple access) protocol, including clear channel assessment and further backoff, are used to ensure nodes don't all transmit at the same time.

In a dense network, some nodes do typically end up transmitting at the same time, despite these algorithms. This can result in collisions, in which receiving nodes do not receive one or even either transmission correctly. The ZigBee/IEEE802.15.4 specification describes the use of retries to reduce, generally to an acceptable level, the number of nodes not receiving the message.

The large number of messages involved in the broadcast/multicast, as well as other effects, can result in other, unrelated messages also being lost.

The ZigBee specification discusses one simple algorithm to reduce the number of transmissions in broadcast communication mode, called the "passive acknowledgement mechanism". In this mechanism each router node keeps a record of which of its neighbors have retransmitted each broadcast/multicast message (based on a message ID contained in the message). Once all of its immediate neighbors have retransmitted it then any sending of further retries is aborted. This mechanism however is not used by ZigBee route discovery; there, each device retries the prescribed number of times.

Recent technical studies have suggested that in particularly dense networks the standard ZigBee algorithms for broadcasting/multicasting data and for discovering new multi-hop routes (again using a broadcast flood) result in so many transmissions that other messages in transit within the network can get trampled and lost.

Indeed, the ZigBee operation is targeting at self-organizing operation, allowing for discovery of information about and paths to selected destination nodes, despite possible node failure, mobility and changing propagation conditions. However, this means, that ZigBee network maintenance relies heavily on traffic- intensive broadcast messages (e.g. for device and service discovery, device announce, address conflict discovery and resolution, network maintenance, and application layer multicast; not to mention routing), which - repeated at least once by each and every router in the network - create a network wide "broadcast storm" (Sze-Yao et al. "The broadcast storm problem in a mobile ad hoc network", Proceeding of the 5^th annual ACM/IEEE international conference on Mobile computing and networking, ed. ACM, 1999, p. 151-162), as depicted in Figure 1. Such a broadcast storm may not be a problem for non-real time applications in a low duty-cycle network and periodically sent information/infinite amount of retries (like one for structural monitoring or asset tracking), but may unacceptably impact performance of real-time control systems like building lighting. The ZigBee Broadcast Transaction Table, aiming at limiting the amount of broadcasts being on in the network at any particular time, does not remove the problem, at least in large dense networks. This is especially the case for the route discovery itself, in which case the unicast route reply sent back along the found path may be completely jammed by the still ongoing broadcast storm of route discovery. Summary of the invention

It would be advantageous to achieve a method to improve the network performance by reducing the "broadcast storm" effect at least.

To better address one or more concerns, in a first aspect of the invention a method for defining broadcast routers in a wireless multihop mesh network of nodes comprising a plurality of routing nodes potentially able to repeat a broadcast message, comprises:

· determining for each routing node the number of neighboring routing nodes and the quality of each link between said routing node and said neighboring routing nodes;

selecting a subset of said plurality of routing nodes comprising a reduced number of routing nodes so that only routing nodes belonging to said subset are allowed to perform selected operations. By using a reduced number of routing nodes that broadcast messages, the impact of broadcast storm of both route discovery and other broadcast communications is reduced by reducing the density of re-broadcasting nodes and thus shortening the duration of broadcast storms. Furthermore, the energy consumption by the network is minimized by concentrating the communication and routing capabilities in selected routing nodes.

In a particular embodiment, the total number of routing nodes in the network is limited, the routing nodes are selected among all routing capable devices on the quality of service and network status criteria by keeping only routing nodes having average, or above average, quality links, and allowing the other full-function devices to degrade during operation into non-routing nodes. The routing operation is thus optimized by establishing only good-quality links between the selected routers while maintaining the appropriate network connectivity and overall network performance.

In another particular embodiment, the number of routing nodes participating in forwarding broadcast messages is limited by selecting the minimum number of re- broadcasting routers required for the broadcast message to reach every device in the network.

Other embodiments are disclosed in the dependant claims.

Depending on the type of network and network topology, a particular embodiment may be preferred as easier to adapt or as giving a better result. Aspects of these particular embodiments may be combined or modified as appropriate or desired, however.

In a second aspect of the invention, a computer software product stored on a recording media comprises a set of instructions to enable a computer to practice the method disclosed here above when the computer executes the set of instructions.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment described hereafter where:

- Figure 1 is diagram showing a "broadcast storm" in a ZigBee network according to the prior art;

- Figure 2 is a schematic view of a wireless multihop mesh network;

- Figure 3 is a flowchart of a method according to an embodiment of the invention;

- Figure 4 is a flowchart of a method according to a second embodiment of the invention;

- Figure 5 is a schematic view of a simple network according to an embodiment of the invention;

- Figure 6 is a diagram of information exchange between nodes of the network of Figure 5 for a method according to a third embodiment of the invention; and

- Figure 7 is a schematic view of a dense network in which nodes have been selected to act as routers according to an embodiment of the invention.

In the particular embodiment disclosed hereafter, a ZigBee network is used as example of a wireless multihop mesh network. However, the invention is applicable to all types to multihop mesh networks. In reference to Figure 2, a ZigBee network comprises nodes 1 which have routing capabilities, and which are designated in the ZigBee terminology as ZigBee Routers and in IEEE802.15.4 terminology as Full Function Devices (FFD). It comprises also some simple nodes 3 used as ZigBee End Devices (IEEE802.15.4 Reduced Function Devices RFD). Particularly, an RFD has no routing capability and is thus always joining the network as a ZigBee End Device ZED. Depending on the network configuration, a FFD may operate as a ZigBee Router ZR or as a ZED.

In the ZigBee specification, an FFD is allowed to associate as ZED, instead of as ZR, when the preferred parent of the FFD has exhausted its ZR child address space.

In the case of broadcast messages, only ZR with the parameter macRxOnWhenldle at TRUE will rebroadcast a received broadcast message after a random delay. To simplify the description, without limiting its generality, all ZR are able to rebroadcast a message excepted otherwise noted, by hypothesis.

A particular ZR has the role of Personal Area Network - PAN coordinator 5 and is the single central controller of the network.

To discover multi-hop route, the ZigBee network comprises a route discovery mechanism using specific broadcast messages.

To avoid the "broadcast storm" effect, only a subset of routing nodes is authorized to repeat, or rebroadcast, these specific broadcast messages. Still, the broadcast, and more generally all messages, should be able to reach all nodes in the network.

To define this subset, Figure 3 :

• For each routing node ZR, the number of neighboring routing nodes ZR is determined, step 11, as well as the quality of each link between the routing node and its neighboring routing nodes.

• A subset of routing nodes ZR is selected, step 13, so that only routing nodes belonging to the subset are allowed to perform selected operations.

• The routing nodes of the subset are configured, step 15, for performing the selected operations.

Specifically, the selected operations comprise broadcast operations or a subset of broadcast operations. Consequently, broadcast messages being repeated by a limited number of selected nodes, the "broadcast storm" is reduced. Nodes not belonging to the subset would still receive broadcast messages and act on them locally, but would not be required to repeat them. This will result in fewer messages being sent in a given period of time, and in an increase in the chance of other messages to successfully transit the network.

Step 1 1 of detection of surrounding nodes and connection quality may be based, for instance, on information collected by all nodes using the ZigBee neighbor table related commands (Link Status for local and Mgmt Lqi rsp for remote information exchange, respectively).

Particularly, in a ZigBee network, the link cost is defined by an integer ranging from 1, for the highest quality, to 7, for the lowest quality.

A good criterion for selecting the subset is select nodes with an average connection quality, i.e. a quality in the range 3-5. Indeed, a very high quality generally means that nodes are very close and thus achieving the network coverage will require many nodes. At the opposite, a low quality means numerous errors and failures in message transmission and thus, a low reliability or a network loaded by resent messages.

Step 15 of configuration can be achieved through different embodiments which are detailed here after. In a first solution, ZR not being a member of the subset does not participate in broadcast forwarding but are still able to route messages for its children nodes. Alternatively, in a second solution, step 15 may be achieved in a ZigBee network by allowing the FFD not being a member of the subset to join the network as ZED instead of as ZR, and consequently is unable to have children nodes, the FFD members of the subset being the ZRs of the network.

In its simplest embodiment, the subset selection 13 is manually done by taking into account the network topology and the quality of service of each connection.

The subset selection may also be embodied in a centralized fashion or a decentralized fashion or a mix of both.

Centralized embodiments

A first centralized method of selection uses the following algorithm, Figure

4:

• Construct, step 21 , a table with an entry representing each node in the network; • For each node, store, step 22, information about other nodes in its radio range and particularly knowledge of nodes in range of the considered node;

• For each node, store, step 23, a flag "repeat" and a flag "connected". The "repeat" flag of ZED nodes is marked permanently FALSE;

• Select, step 25, a starting routing node ZR randomly or use the PAN coordinator;

• Mark, step 27, its flags TRUE and the flags of all other nodes FALSE;

• Mark, step 29, the "connected" flag of all nodes in range of the starting node TRUE;

• Randomly, and/or based on the link quality, select, step 31, a routing node ZR with its "connected" flag being TRUE and its "repeat" flag being FALSE.

• Mark, step 33, its "repeat" flag TRUE et the "connected" flag of all nodes in range of this node TRUE;

• Repeat steps 31, 33 until all nodes have their "connected" flag equal to TRUE;

• Designate, step 35, all routing nodes ZR with the "repeat" flag still equal to FALSE as nodes that are not part of the subset, for instance by setting macRxOnWhenldle at FALSE.

In the preliminary steps of data collection, all FFDs could initially associate as ZRs, and collect data about their neighborhood: the number of other ZRs in their range and the link quality to those nodes; the number of ZED children and ZR children each of them has (and the link quality indication for each of those). Then, they could submit all this information to a central infrastructure node (e.g. to the ZigBee PAN Coordinator ZC, using the Mgmt Lqi rsp message). Based on this data, the ZC could decide, which of the FFDs should re-associate as ZEDs (and optionally also: to which parent).

The random selection of step 31 may be limited to routing nodes having an average, i.e. not too high, not too low, link quality to the routing node in their neighborhood.

The method may be repeated several times until the number of routing nodes in the subset is minimized, or optimized to some other criteria, for instance, based on the reliability of the network to deliver a broadcast message even if any routing node fails.

In another centralized embodiment, the selection of routing nodes is based on a 3D floor plan, taking into account the distances between the devices, as well as obstacles and the attenuation caused by them to define the quality of each link. For example, an equal distribution of ZRs could be attempted, by choosing, starting from the PAN coordinator, routers in such a way that any ZR has, in 3D, exactly 6 neighboring routing nodes at a distance corresponding to link quality of 2-4 and located at 90° angles.

In a particular implementation of the second solution of step 15, i.e. the configuration step, the FFDs selected to be part of the subset, should be instructed to associate as routers and the remaining FFDs should be instructed to associate as ZEDs. This parameter is not part of the Startup Attribute Set of the Commissioning Cluster. The cluster would have been extended or a special command would need to be defined.

However, the Capabilitylnformation field, transmitted as part of the Mgmt Direct Join req command according to the current ZigBee standard [rl7], sent by the PAN coordinator, also called ZigBee PAN coordinator ZC, or by the Commissioning Tool, CT, to configure the parent with the information about its future child, allows for prescribing the role, using the device type subfield, as depicted in the figure below.

This method alone allows for complete network formation, with the ZigBee PAN Coordinator accepting only selected FFDs as ZR children, and instructing them, once they are associated, which children must be accepted as ZR.

There could be various algorithms to choose the FFDs to re-associate as ZEDs as, for instance, the decentralized methods disclosed here after. However, in some cases, it may be necessary to enforce a re-association.

In one embodiment or enforced re-association, all FFD nodes could be considered for role re-assignment, but the ZED(RFD) children will not be DirectJoined (because of missing link quality input data), but will be allowed to pick the parent themselves. Alternatively, since the information about the link quality to the ZED device is only available in the (RFD) ZED's parent, only those FFDs could be considered for role re-assignment, which don't have ZED (RFD) children. This would help limit the maintenance hassle related with ZED (RFD) re-association.

In another embodiment, the ZRs could keep in their neighbor tables the information also about those ZEDs, which are in their neighborhood, but are not associated to them. This information could be collected by storing the information from beacon requests sent by ZED devices, with the Relationship field set to "0x03= none of the above" (indicating no relation, neither a sibling, nor a child, nor a parent). Thus, the ZC could take the ZED "visibility" into account by role re-assignment. This may however require that the ZEDs only try to join the network, once the network "skeleton" consisting of ZRs is already formed. Alternatively, before reporting to the ZC, all the ZRs should send a rejoin to their (RFD) ZED children, while all neighbor ZR listen to assess the LQI to the RFD.

In yet another embodiment, only those FFDs could be considered for role reassignment, which don't route traffic on behalf of other nodes. This would require that the ZC considers further information, i. e. the routes, reportable with the Mgmt_Rtg_rsp message.

Decentralized embodiments

In the decentralized embodiments disclosed here after, the decision to become a routing node ZR is taken by the each of the nodes individually and not by the PAN coordinator or any other central system such as the ZigBee Trust Center TC or the ZigBee Network Manager NM. Generally, the decentralized embodiments have the advantage to adjust more easily to any network change.

In a first decentralized embodiment, a parent ZR could decide, after receiving an association request or a network (re-)join request from a FFD device, whether to accept this child and in which role.

In a simplest implementation, the parent could just take a random decision for every FFD child. This may however lead to sub-optimal distribution of ZR in the networks and thus the necessity of role adjustment once the network becomes operational. However, the adjustments are anyway unavoidable, due to changing network surroundings, and propagation and traffic conditions. In a more advanced implementation, taking into account, that the child itself chooses the parent according to the ZigBee rules, i.e. parents with child acceptance capabilities AND with smallest link cost never higher than 3 AND smallest tree depth, the parent should analyze the following information:

• The number of other ZR children the parent already has (and link cost to those);

• The number of other ZRs in the parent's vicinity (and link cost to those);

• Parent's child acceptance capability;

• The link quality to the potential child requesting association;

• The number, the device type FFD/RFD and link cost for the other potential children requesting association at roughly the same time;

• In extension, the child could provide the parent with the information, how many alternative potential parents the child still can try.

The parent ZR according to the more advanced implementation could decide to associate the child as a ZED if:

• The parent already sees at least N associated ZRs in its vicinity (so that a minimum density of routers in any neighborhood is guaranteed) AND the parent still has capability of accepting ZED children AND the link cost to the FFD joiner is < LCoptimum

• The parent just has 1 ZR address left, and the parent decides that another joiner should be associated as ZR.

The parent could decide to associate the child as a ZR if:

• The parent sees less than N other ZRs in its vicinity AND the parent still has capability of accepting ZR children AND the link cost to the FFD joiner is exactly LCoptimum,

• The parent just has 1 ZED address left and the parent decides that another (RFD) joiner should be associated as ZED

The parent must decide to deny association to the child, if the parent doesn't have child acceptance capability. The parent could further decide to deny association to the child, if the parent still has child acceptance capability but the link cost to the FFD joiner is < LCoptimum or > LCoptimum

Where:

• N>1; and preferably For a 3D network, N = min (6, neighbor table size of the joiner))

For a 2D network (e.g. like the lighting installation in the ceiling or a wireless sensor network spread over a desert), N = min (4, neighbor table size of the joiner))

· LCoptimum is a configurable link cost threshold value; preferably

LCoptimum = 3 (as for ZigBee association)

The parent could then communicate its decision to the joining child.

For example, the parent could use the status codes in the Association Status field of the Association Response command [IEEE802.15.4-2003] (if ZigBee association process is used) or the Rejoin Status field of the Rejoin Response command [ZB] (if the NWK join process is used): 0x00 ASSOCIATION SUCCESFUL to indicate acceptance of child as ZR; 0x02 PAN ACCESS DENIED to indicate that it will not associate the child; and 0x03 (now reserved) ROLE CHANGE to indicate that the device should change the role, i.e. associate as a ZED.

Alternatively, on receipt of joiner's beacon request, the potential parents could delay the transmission of their beacon, with the delay time dependent on the link cost (RSSI-based measurement) to the joiner and the parent's willingness to accept the joiner as child.

Furthermore, the parent could modify the child acceptance capability bits in its beacon, to indicate, in which role the joiner should associate. This will speed up the association process, as the joiner will preferably receive only one beacon - from the right parent; and will directly start with association in the proper role. Then, however, the parent must be made aware of the child's role (FFD vs. RFD), as well as the chi l d ' s ro l e switching c ap abi litie s , e . g . using one o f the re s erve d Capabilitylnformation/MAC frame control bits.

As an addition, the decision to associate an FFD as ZED could also be sent to the parent's neighboring ZRs (e.g. as a separate one-hop broadcast), which however would require defining a separate command. The successful association of FFD as ZR could be announced with Link Status messages, if used. The neighboring ZRs could then also take this information into account when deciding on the association request they themselves may get from this joiner. In an optimization, the Link Status messages don't have to be sent out periodically, but on a change in the ZR's neighbor table: whenever a ZR's neighbor device disappears, appears, or changes its status. If the joiner FFD associates as a ZED, the parent should store the information on the child's capability to operate as ZR.

It could be realized, for example, as an additional field in the parent's neighbor table. Or a new value in the Device Type field 0x03 (now reserved) 'ZED that could be ZR' could be defined.

In variant of this embodiment:

• During network operation, the parent could monitor the number of the ZRs in its vicinity.

For example, on the following events, the parent could instruct the FFD child associated as ZR to re-associate as ZED:

• when the number of ZRs in the vicinity of the parent has increased to more than P (where P is an integer, 1<N<P, and preferably P=8); OR

• when the parent doesn't have a ZR child capability anymore AND it wishes to associate another potential child as a ZR (according to the rules above); AND

• when the FFD child associated as ZR doesn't have too many children associated; AND/OR

• when the FFD child associated as ZR doesn't route for any other nodes in the network (In the case when the routes are symmetric, this can be deduced by lack of backward route. In a generic case, it may require maintenance of additional information, in least-cost implementation a Boolean variable, indicating route being used (also) for other device's traffic.) and is not a source or destination of intensive traffic itself; OR

• FFD child associated as ZR itself has less than M ZR neighbors (where M is an integer, 1<M<N, and preferably M=2).

For example, on the following events, the parent could instruct the FFD child associated as ZED to re-associate as ZR:

• when the number of routers in parent's vicinity drops below M (where M is an integer, 1<M<N, and preferably M=2); OR

• when parent notices, that it has to route (too) many messages on behalf of this child;

• when quality of parent's link(s) (in terms of signal strength or packet success rate) degrades. To accomplish the role switch of an already associated FFD, the parent can send to the joiner an unsolicited NWK Rejoin Response with appropriate Status code (0x03 (now reserved) ROLE CHANGE).

In a second variant, a ZR could also instruct ZRs in its neighborhood other than its own children, to analyze the possibility of role switching. To accomplish this, a ZR could send a leave command. Since leave command can usually only be received from infrastructure devices and own parent, the FFD could immediately understand, that this is a role switching request. To make this explicit, one of the reserved bits of the Command Options field could be used.

In a second decentralized embodiment, the FFD is capable to decide upon joining the network -and based on the current situation in the network and in its neighborhood- whether it should associate itself as a ZigBee Router (ZR) or a ZigBee End Device (ZED).

In the simplest variant, the FFD could just decide randomly (50-50), whether to associate as ZR or ZED. On average, this will reduce the number of ZRs in the network by half. Deviations from the 50-50 probability could for instance be based on the number of potential parents (i.e. already associated ZRs in joiner's range). The more potential parents, the higher the probability for deciding to associate as ZED. In the operation phase, the FFD would still have the chance to change the role during operation, if required, as described hereafter.

In a more advanced variant, the FFD joiner collects - during the association process - the beacons from the already associated ZigBee Routers in its range (and potentially also observes the traffic in its vicinity), to derive the following information:

· The number of already associated ZigBee routers in its vicinity,

• link quality to each of those

• and the tree depth at which they are associated;

• The number of potential parents among those routers (i.e. routers with appropriate link quality, as well as router and ZED child acceptance capabilities),

• and the tree depth at which they are located.

The joiner should consider it would be required in the router role in this vicinity, if: • the joiner sees more than N routers in its vicinity AND

• some of them are at link cost > LC₀pti_mUm AND all N are located at one depth level

The joiner associates then as a ZR, choosing as a parent the ZR with link cost of exactly LC_opti_mUm and biggest possible tree depth level.

• the joiner sees router devices, most of which are spread over two depths, whereby the average link cost to the routers on the higher depth is close to LCoptimum and much better than the average link cost for the lower depth The joiner should then associate as a ZR, choosing as a parent the ZR with link cost of exactly LC_opti_mUm and biggest possible tree depth level.

• the joiner sees less that N routers in its vicinity AND

• One of those routers is the ZC, at a link cost of exactly LC_opti_mUm

The joiner should then associate as a ZR, choosing as a parent the ZR with link cost of exactly LC_opti_mUm and smallest possible tree depth level.

The joiner considers that there are enough routers in the vicinity, if:

• the joiner sees router devices, most of which are spread over two depths with approximately the same average link cost per depth level

• the joiner sees less than N routers in its vicinity AND

• One of those routers is ZC, with link cost of < LC_opti_mUm to the joiner OR

• All those N routers have link cost to the joiner of < LC_opti_mUm AND are located on at most two depth levels OR

• those routers are located on three tree depth levels and some of them have a link cost to the joiner of > LC_opti_mUm

• the joiner sees more than N routers in its vicinity AND

where:

• N>1; and preferably

• For a 3D network, N = min(6, neighbor table size of the joiner)

• For a 2D network (e.g. like the lighting installation in the ceiling or a wireless sensor network spread over a desert), N=MIN(4, neighbor table size of the joiner)) • LCoptimum = 3 (preferably).

The joiner should then associate itself as ZED, choosing the parent according to the usual ZigBee rules (i.e., the parent capable of accepting children, with the best link cost, whereby link cost cannot be bigger than 3, and if there are several, the one with the smallest tree depth).

An FFD device associated to the network as ZED, in general behaves as a ZED with TxOnWhenIdle=T JJE. Thus, it transmits the packets only via its parent, it doesn't participate in route discovery or broadcast forwarding, yet it can directly receive broadcast/multicast commands sent in its vicinity (but not re-transmit them).

However, this FFD associated to the network as ZED may -in extension- retain parts of ZR functionality despite operating as a ZED. Thus, the FFD according to the current invention would become a ZED++: appearing to the other devices to be ZED, but capable of almost seamlessly assuming the more advanced ZR operation, when required.

For example, the ZED++ could keep a list of ZR neighbors, with current information about them like (incoming) link cost and children acceptance capability, to be able to find a parent quickly, when it needs to re-associate as ZR. Such information can be collected e.g. by analyzing the Link Status messages, if used in the network.

Announcing its ZED++/role switching capabilities to other devices (not only parent, but also neighbor ZR), would allow those devices to treat the ZED++ differently, e.g. keep the link cost to this device in the neighbor table (for potential future use), while not using it for routing, broadcasting, etc.

Furthermore, the ZED++ could keep track of beacon requests and/or association requests/network join requests being sent in its vicinity. If it would notice a device in its vicinity, that repetitively (e.g. for already third time) tries to join the network and fails (e.g. due to exhausted child capacity space or due to inappropriate link cost of other candidate parents), AND when this ZED++ itself has a link cost of at most 2 to this device (if this device is a ZED) or of 2-4 (if this device is a ZR or ZED++ capable FFD), the ZED++ may re-join the network as ZR, to allow the new device to associate.

Note that the re-joining process of the ZED++ will consume minimal time and thus have minimal impact on the network performance, since

• the ZED++ already knows the neighborhood; • the ZED++ already knows the required network parameters (PANId, EPID, channel, even NWK key and TC-MK);

• the ZED++ was already on the network and performed all required maintenance operations (e.g. address resolution, TC-authentication, route establishment, etc.; and the update-device command sent by the parent on behalf of newly associated child doesn't contain the Capabilitylnformation; only the Device_annce command sent to the entire network, but this information is not used in any way, so Device _annce doesn't have to be repeated).

On re-associating to the network as ZR, the ZED++ should initially keep the maintenance actions to the minimum (e.g. avoid rediscovering existing routes and temporarily use the routes going via its previous parent). The only exception is made for routing destinations being neighbors of the role switching FFD, with which it previously communicated via the parent: the role switching FFD can immediately start routing to them directly provided the LQI values are satisfactory.

Analogously, an FFD associated as ZR should monitor its neighborhood to determine, whether its router operation is still required. If it looses all children, or stops routing on behalf of other devices, or the number of routers in the vicinity increases, the FFD may decide to switch to ZED++ operation.

The device - when switching from ZR to ZED++ - may try to limit the impact of the switch on the network, by postponing role switching, until the necessary information is re-distributed. It could reassign its children to new parents, e.g. using Mgmt directjoin command for the new parent and Leave command with rejoin option for the child. Further, it could reassign the routes it hosts on behalf of the children. It would require sending a packet with a payload containing the following information "route (from X) to Y: next hop is Z, previous hop is Q", to the previous/next hop, respectively. If the neighbor would have own/better routes to those destinations, it could ignore those sent by the FFD (but confirm reception). The child shifting may be coupled with shifting of routes held on behalf of that child:

• ask neighbor, whether willing to accept child (incl. 16-bit address);

• on neighbors acceptance ask child to leave;

• move the corresponding routes. During network operation phase, the ZED++ node may keep track of the messages exchanged in its vicinity, especially the messages it routes via the parent to one of its other neighbors. If it notices link performance degradation between nodes, to which it has itself links of good quality, or if it notices messages routed around it with too-big a cost, it could re-join the network as ZR, to improve the routing and the network performance.

FFDs capable of ZED++ operation may advertise this capability, using one of the 2 reserved bits of the Capabilitylnformation field of the association request frame, or one of the reserved fields in the MAC FrameControl field of the beacon request frame.

When the ZED++ capability of an FFD is known to its communication partners (e.g. included in the Capabilitylnformation field of the Device annc command), those remote devices (e.g. devices bound to the ZED++ device) may store it for future use. For instance, those remote devices may instruct the ZED++ capable device associated as a ZED that it should re-associate as ZR due to, for instance, increasing end-to-end communication delay, increasing packet failure rate or increasing communication frequency.

In a third decentralized embodiment of the method of Figure 3, after the network is formed, the device being root of the network, NR, initializes establishment of the subset of routing nodes which will be called in this embodiment a "minimum broadcast tree" (MBT).

In ZigBee, the NR role could be performed either by the ZigBee PAN Coordinator (ZC), ZigBee Trust Centre (TC), and ZigBee Network Manager (NM) or by a device performing several of those roles. In fact, it could be started from any node as it doesn't require any special capabilities or resources; neither during MBT discovery initialization nor MBT operation, but it is easier if there is one designated device.

To this end, the NR broadcasts a message, triggering minimum broadcast tree (MBT) formation.

To implement this function in a most ZigBee-transparent way, the "MBT formation" message could take a form of a many-to-one route request command (which NWK payload is shown below), Octets: 1 1 2 1 S

Command Route Destination Pa tli cost Destination options request

identifier Addr ss

IN WK cosiiisiiKid payload

With:

• Destination address in MAC layer header set to broadcast address;

• Source address in MAC layer header set to the network address of the NR;

• Destination address in NWK layer header set to the broadcast address for all devices where macRxOnWhenldle = TRUE;

• The source address field of the NWK header should contain the broadcast address;

• The source IEEE address sub-field of the frame control field of the NWK header shall be set to 0 and the source IEEE address field of the NWK header shall NOT be present;

• The Many-to-one sub-field of the Command Options field of the NWK command payload should be set to Ob 10, indicating that "the route request is a many-to-one route request and the sender does not support a route record table." [ZigBee-2007 specification; 053474 rl7; Table 3.41, p. 316]

• The Destination address field of the NWK command payload should contain the broadcast address;

• The Destination IEEE Address field of the NWK command payload should NOT be present and thus the Destination IEEE address sub-field of the Command Options field of the NWK command payload set to 0;

• The path cost field of the NWK command payload shall contain the hop- count, instead of the total path cost;

• In addition, the Command options field of the NWK command payload shall contain a "Preferred node" sub-field of one -bit length, to indicate, whether the node considers itself MBT node (based on the cost and other nodes behavior) or not. The NR sends the message with this "Preferred node" bit set.

The broadcast "MBT formation" message will be received by all macRxOnWhenldle = TRUE nodes in the radio range of NR (assuming there were no collisions with other packets). In standard ZigBee [053474 rl7] each and every one of them would try to re-broadcast the packet after a random delay; and the NR would keep track of its neighbors re-broadcasting ("passive acknowledgement") and retransmit the "MBT formation" message itself, if not all neighbors did it in a given nwkPassiveAckTimeout time.

The behavior of the "MBT formation" receiving nodes is modified in the following way. Of the nodes receiving the broadcast "MBT formation" message for the first time, those are preferred (to become another MBT node), which are located at appropriate distance from the transmitting node (to assure minimum density of the MBT), but still have reasonable reception quality from the transmitting node (to assure reliability of the links in the MBT).

This is achieved by:

• introducing a re-broadcast delay as a function of the link cost to the transmitting device (and preferably: cost of the bidirectional link, i.e. to and from the transmitting device), where the optimum link cost (e.g. 5 in the 1-7 link cost scale of ZigBee) results in a minimum delay and link costs both bigger and smaller result in scheduling a re-broadcast with appropriately larger delay; and

• setting a "Preferred node" sub-field in the Command options field of "MBT formation" message according to the optimal/sub-optimal status. The node re-broadcasting the "MBT formation" message with the sub- field set is then called the MBT node.

A node with sub-optimum link cost, and thus much delayed re-broadcast, would postpone the re-broadcasting even further when it observes the message being forwarded by one of its neighbors with the optimum cost. A node with optimum link cost would postpone the re-broadcasting when it observes the message being forwarded by one of its neighbors with the same link cost to the original sender (known from Link Status messages, when used) and the same hop count (in the "MBT formation" command payload).

Conversely, a node with sub-optimum link cost, and thus much delayed re- broadcast, may become MBT node, if - within the scheduled re-broadcast time - it doesn't see any of its neighbor nodes re-broadcast (with equal or better cost).

For example, the re-broadcast delay function could be specified as

re-broadcast delay = (ThresholdLC-LC) * 25ms + rand jitter, for LC<ThresholdLC; or re-broadcast delay =∞, for LC>ThresholdLC

where

• ThresholdLC is a constant for the optimum acceptable MBT-link quality, for instance 5;

· "MBT formation" re-tries by the MBT nodes could be changed to 10ms

(while for non-MBT nodes they stay at 0.5s); and

• additional delay when receiving "MBT formation" rebroadcast by optimal-cost neighbor of 100ms.

Note that varying the re-broadcast delay is different from other limiting schemes such as the bounding algorithm, where only nodes farther away than a certain threshold distance re-broadcast the packet.

Non-MBT nodes

• include the "MBT formation" message in their routing table and route discovery table to keep track of the optimum cost and avoid duplicates; and

• mark in the neighbor table those of its neighbors that have become MBT nodes (with "Preferred node" subfield set).

The "MBT formation" message will propagate so though the network and the MBT nodes will be automatically selected.

When a node receives an MBT formation frame with the PreferredNode bit not set, it shall start a timer of nwkMBTFormationTimeout ms, e.g. 500ms. If it does not receive within that time an MBT formation frame with the PreferredNode bit set, it retriggers the MBT formation by sending an MBT formation frame with

• the PreferredNode bit unset; and

· very high cost.

Based on this high cost, a non MBT node receiving this frame and that already previously sent out an MBT message knows it has to become an MBT node itself.

If after an "nwkMBTFormationTimeout" message a node has no MBT neighbors in its neighbor table, it should re-trigger "MBT formation" by broadcasting an "MBT formation" to its neighbor nodes in one-hop broadcast message, with its short address included in the NWK layer header source field. The 1-hop neighbors receiving this message should schedule re-broadcasting of original "MBT formation" packet according to the formula:

re-broadcast delay = LC * step + random jitter;

where LC is the link cost to the node from which it received the message; and

step is a chosen constant, e.g. 25 ms.

and the "preferred node" sub-field set accordingly.

Alternatively, the node with no MBT neighbors in its neighbor table could choose one neighbor device, based on the number of nodes included in the neighbors' Link Status messages, if used (and the acceptable link cost). This will allow choosing a MBT node, which has the potential of covering the most nodes in its neighborhood. The MBT-less node would then send a one-hop network-level broadcast, with its own short address in the NWK header source address field and the address of the chosen neighbor in the MAC header destination address field.

Subsequently, the process can continue, as described previously.

When any node in a system wants to broadcast a message (of any sort, except for RREQ message), it simply does broadcast it. The message will be re-broadcasted, using passive ACK or re-tries, as specified by the ZigBee standard, but ONLY by the MBT nodes. Non MBT-nodes will add the message to their broadcast transaction table (BTT) to avoid duplicates and process it accordingly to the message type, but not re- broadcast it. Thus, the broadcast message will propagate faster through the network and with less impact on the network performance.

There may be nodes not having any single MBT-node in their neighbor table, e.g. nodes joining the network after the MBT formation was performed or nodes which for whatever reason missed the MBT formation process completely, for instance due to sleep, interference, collision, mobility, etc.. They could automatically discover the MBT nodes, by observing them forwarding and not originating the broadcast messages. Alternatively, the new nodes could observe the nodes forwarding their own broadcast messages. If the joiner's broadcast wasn't re-broadcasted by any MBT-node within nwkPassiveAckTimeout, the j oiner could re-trigger "MBT formation" by sending one-hop broadcast "MBT formation" packet with its short address included in the NWK header source address field, as described in the step above. The PreferredNode subfield may be unset. Alternatively, the MBT nodes could observe a non-MBT nodes re- broadcasting (i.e. forwarding a broadcast which they have not originated). Thus, the corresponding MBT node could send a one-hop broadcast "MBT formation" message to inform the unnecessarily re-broadcasting node.

Alternatively, the MBT formation could be repeated periodically (e.g. once a day) by the NR, so the joiner would use a randomly selected neighbor (MAC layer unicast, NWK layer broadcast) to forward the broadcast for it, until the next "MBT formation".

In the simple network topology as depicted in Figure 5, the MBT will be built as depicted in Figure 6. Due to interference, node 34 cannot see transmissions by MBT-nodes 31 and 33; and it is too far-away to see transmission by MBT-node 35. Thus, it only sees the transmission by non-MBT node 32, so it doesn't have an MBT node among its neighbors. After a nwkMBTFormationTimeout expires on node 34, node 34 re-triggers MBT formation (by sending an "MBT formation" command as 1- hop broadcast with its own address set as a source address in the NWK header, and the "Preferred node" sub-field not set). This will trigger any node in the vicinity of node 34 AND with reasonable link cost to node 34 AND (preferably being MBT-node itself OR having at least one MBT-node in their neighbor table). In the example of Figure 5 those requirements are only fulfilled by node 32. They will schedule (with delay as described above) a "MBT formation" command transmission with PreferredNode bit set. On receipt of this command, node 34 immediately transmits a standard "MBT formation" command, all-broadcast-addressed and with PreferredNode bit cleared, as 1-hop broadcast, to clear the scheduled transmissions by other potential MBT-nodes in its vicinity. Thus node 32 becomes MBT node, to assure node 34 is reached by the broadcast messages sent using the minimum broadcast tree.

In the dense network depicted in Figure 7, where the arrow indicates range corresponding to a moderate link cost, only the black nodes need to re-broadcast any message, to be able to deliver this message to each and every node in this network.

In a variant, separate broadcast trees could be established for each of the specific broadcast addresses/broadcast groups. Currently, the following broadcast addresses are defined in ZigBee-2007 [rl7] specification:

• Oxffff: All devices in PAN

• Oxfffd: All devices with macRxOnWhenldle = TRUE • Oxfffc: All routers and coordinator

• Oxfffb: Low power routers only

This address should then be used in the NWK header source address field and NWK command payload destination address field.

The solution above requires pre-establishment of the MBT, which may be too -maintenance intensive for highly dynamic networks with mobile nodes. Thus, the current embodiment is proposed for broadcast forwarding via ad-hoc broadcast trees.

By assumption, each node participating in the broadcast transmission is assumed to know the incoming and outgoing link cost to its neighbors. This can be achieved e.g. by usage of Link Status messages.

When a node receives a packet from next higher layer to be sent in broadcast addressing mode, the node simply does transmit it in broadcast mode. Then, it listens for its neighbors to re-broadcast the packet by passive acknowledgement.

All nodes on a first reception of this broadcast packet add the received packet to their broadcast transaction table (BTT) to avoid duplicates; process the message accordingly to the message type, and schedule re-transmission of the packet according to the following formula:

re-broadcast delay = | 6 - LC | * 15ms + random jitter

where LC is the link cost between the receiver node and the transmitting node

whereby the nodes with link cost smaller than 6 drop the scheduled re- broadcast, if they see at least N other nodes re-broadcast it before its own re-broadcast is due (where N>1; preferably N=l).

In a variant, a node i with link cost of exactly 6 can also drop the scheduled re-broadcast, if node i sees at least M other nodes re-broadcast it during i's re- broadcast delay timeout (where M>1; preferably M = min (3; # of neighbors of node i)). In a further variant, the node i with link cost of exactly 6 can analyze i's link cost to the X nodes that re-broadcasted the message during i's re-broadcast delay timeout and drop i's scheduled re -broadcasting only if among the re-broadcasting nodes nl , n2, ... , nX observed by i there were at least P nodes (where P>1 ; and preferably P=2), to which i's link cost was at least 6.

The originator node keeps track of the nodes re-broadcasting (passive acknowledgement) and re-transmits the broadcast packet (according to passive acknowledgement mechanism's parameters) only if the expected nodes do not re- broadcast it within the predefined timeout.

In a simplest scenario, it will re-transmit the broadcast packet, if any of its neighbors with link cost of exactly 6 does not re-broadcast it. In a more advanced scenario, it will re-transmit the broadcast packet only if less than Z of its neighbors retransmit it (where Z>1; and preferably Z = min (8; # of neighbors of the node)). In a yet more advanced variant, the node will analyze the link cost between the re- broadcasting neighbors nl, n2, ..., nX and refrain from re-transmitting only if at least Y (where Y>1 ; and preferably Y = min (6; # of neighbors of the node)) with inter- neighbor link cost of at least 6 re-broadcasted the message.

So, the packet will quickly and efficiently propagate through the network, without the need of pre-established MBT

The method may be implemented by a computer program product that is able to implement any of the method steps as described above when loaded and run on computer means of a routing apparatus. The computer program may be stored/distributed on a suitable medium supplied together with or as a part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

An integrated circuit may be arranged to perform any of the method steps in accordance with the disclosed embodiments.

While the invention has been illustrated and described in details in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive; the invention is not limited to the disclosed embodiment.

Other variations to the disclosed embodiments can be understood and effected by those skilled on the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements and the indefinite article "a" or "an" does not exclude a plurality.

Claims

Method for defining broadcast routers in a wireless multihop mesh network of nodes, said network comprising a plurality of routing nodes potentially able to repeat a broadcast message, comprising:

• determining (11) for at least one first routing node of the plurality of routing nodes the number of neighboring routing nodes and the quality of each link between said first routing node and said neighboring routing nodes;

• selecting (13) a subset of said plurality of routing nodes comprising a reduced number of routing nodes so that only routing nodes belonging to said subset are allowed to perform selected operations.

Method according to claim 1, wherein said subset is selected so that said subset is able to broadcast a message reaching all nodes of said network, and the selected operations comprise the forwarding of broadcast communication other than the route discovery.

Method according to claim 1 , wherein said subset is selected so that said subset is able to broadcast a message reaching all nodes of said network, and the selected operations comprise the forwarding of all broadcast communication.

Method according to claim 1, wherein said subset is selected such that said subset is able to allow all nodes of said network to be connected to said network with acceptable quality, and the selected operations comprise accepting a child node, forwarding traffic on behalf of said child node, participating in route discovery, routing and forwarding broadcast communication.

Method according to claim 1, wherein the subset selection comprises:

• sending a broadcast message by a sending routing node;

• at each routing node receiving said broadcast message:

• computing a rebroadcast delay as a function increasing proportionally with the absolute value of the difference between the quality of the communication with the sending routing node and a predetermined optimal quality value; • setting a flag of member of the subset in the broadcast message if the quality of the communication with the sending routing node is equal to the predetermined optimal quality value;

• listening to the rebroadcast of the broadcast message by the neighboring routing nodes until the rebroadcast delay lapses;

• if no neighboring routing node has rebroadcasted the broadcast message during the rebroadcast delay, defining itself as a member of the subset and broadcasting the broadcast message at the end of the broadcast delay.

6. Method according to claim 1, wherein the subset selection comprises:

• select a first routing node;

• define all nodes in the range of the first routing node as connected;

• select a routing node defined as connected and define all nodes in the range of the selected routing node as connected;

· repeat the routing node selection until all nodes of the network are defined as connected;

• include in the subset the selected routing nodes.

7. Method according to claim 6, wherein the selected operations comprise all specific routing operations so that routing nodes of said subset operate in the role of routing devices, and the other routing nodes operate in the role of non-routing reduced-function devices.

8. Method according to claim 1, wherein the network being compliant to IEEE 802.15.4/ZigBee standard, wherein the subset selection is centralized to one node.

9. Method according to claim 8, wherein the network further comprises a network coordinator on which the subset selection is centralized, and the configuration of any routing node of the subset is done by the network coordinator through a message containing a capability field of the routing node's intended children.

10. Method according to claim 1, wherein the subset selection is decentralized to each routing node, each routing node deciding if it participates in the subset or if some of its neighboring routing nodes participate in the subset.

11. Method according to claim 10, wherein any routing node of the subset receiving a request to join from a routing node decides to accept the requesting routing node as a routing child and to include the requesting node into the subset when there are less than a predetermined number of routing nodes of the subset in the neighborhood and the quality of the connection is equal to a predetermined quality value.

12. Method according to claim 11, wherein any routing node of the subset stores the capability of the requesting routing node to be a member of the subset and is able, on predetermined conditions, to instruct the requesting node to rejoin the network as a member, or not, of the subset.

13. Method according to claim 12, wherein a routing node requesting to join the network collects, during the join process, responses from routing nodes of the subset and decides to not be member of the subset if the number of neighboring routing nodes of the subset is above a predetermined value or if the quality of the connections to these routing nodes is below average.

14. Method according to claim 12, wherein a routing node not member of the subset decides to join the subset when a device in its neighborhood tries to join the network without success.

15. A Wireless Multihop Mesh Network comprising a plurality of routing nodes potentially able to repeat a broadcast message, the routing nodes comprising means for defining broadcast routers, said means being arranged for:

• determining (1 1) for at least one first routing node of the plurality of routing nodes the number of neighboring routing nodes and the quality of each link between said first routing node and said neighboring routing nodes; and arranged for • selecting (13) a subset of said plurality of routing nodes comprising a reduced number of routing nodes so that only routing nodes belonging to said subset are allowed to perform selected operations.