WO2018077864A1

WO2018077864A1 - Method and apparatus for dynamic tree building in mesh networks

Info

Publication number: WO2018077864A1
Application number: PCT/EP2017/077139
Authority: WO
Inventors: Zhizhong Zhang; Bozena Erdmann; Armand Michel Marie Lelkens; Luca Zappaterra; Xiangyu Wang; Rong Fan; Peiliang DONG; Jun Yao
Original assignee: Philips Lighting Holding B.V.
Priority date: 2016-10-26
Filing date: 2017-10-24
Publication date: 2018-05-03

Abstract

Method and apparatus for dynamic tree building in mesh networks The present invention relates to a method and apparatus for controlling a broadcast, multicast or groupcast transmission in a mesh-type network by forming a tree network for all routers, in which leaf routers don't forward broadcast packets. By using reserved fields in a link status message, a tree network can be formed without any extra network communication added. With this approach, not all routers, only automatically- selected parent routers need to forward the messages of the broadcast, so that broadcast storm can be largely reduced. Furthermore, a fully automatic way of forming the tree network among all routers can be provided, if the root node of a tree is randomly automatically selected. Several trees could then be formed at a first stage and merged into one large tree in the end.

Description

METHOD AN D APPARATUS FOR DYNAMIC TREE BUILDING IN MESH NETWORKS

FIELD OF THE INVENTION

The invention relates to the field of broadcast, multicast or groupcast transmission in mesh networks, such as - but not limited to - ZigBee networks, for use in various different applications for home, office, retail, hospitality and industry.

BACKGROUND OF THE INVENTION

A mesh network is a network topology in which each node (such as a router or switch or the like) is capable of relaying data for the network. In the following, a mesh node is to be understood to include end devices, Green Power Devices, other reduced functionality devices or any other node (e.g. ZED or GPD in ZigBee networks) which is part of a mesh network but do not participate in meshing.

All mesh nodes cooperate in the distribution of data in the network. Mesh networks can relay messages using either a flooding technique or a routing technique. Mesh networks can be considered a type of an ad-hoc network. Thus, mesh networks are closely related to mobile ad hoc networks (MANETs), although MANETs also must deal with problems introduced by the mobility of the nodes.

ZigBee is an IEEE 802.15.4-based specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios. Major benefit of the ZigBee technology is its vertical integration, i.e. availability of a complete standardized protocol stack from IEEE 802.15.4 for the lower layers to network layer to application layer specification; as opposed to other wireless network technologies, such as Thread, Bluetooth or Wi-Fi. ZigBee networks are widely used in different applications, such as home, retail, and industry/office. Applications include wireless light switches, lamps, thermostats, various sensors, electrical meters with in-home- displays, traffic management systems, and other consumer and industrial equipment that requires short-range low-rate wireless data transfer. Its low power consumption limits transmission distances to 10-lOOm line-of-sight, depending on power output and environmental characteristics. ZigBee devices can transmit data over long distances by passing data through a mesh network of intermediate devices to reach more distant ones.

It is common that nodes in the mesh-type networks are interconnected for redundancy, i.e. the nodes have multiple communication links to other nodes within their radio range (neighbour nodes). When nodes are interconnected, the network will not fail completely and any part of the network will not get disconnected from the rest of the network even if one of the communication links fails. However, when nodes are interconnected for redundancy, a serious network problem can occur, which is known as broadcast storm. In ZigBee large-scale networks, especially dense networks, broadcast storm is one big issue that leads to reduced network performance. Data traffic on the second layer (Layer 2 or Data-Link layer in the Open Systems Interconnect (OSI) model for a set of telecommunication protocols) which handles the moving of data in and out across a physical link in the network, can be classified as unicast (one to one), multicast (one to many), and broadcast (one to all). Broadcasts and multicasts are required for normal operation of the network, for example to address all nodes in a network, e.g. performing network discovery or routing operation, or to address a group of devices, e.g. for synchronous control. A broadcast originating from a device connected to any node can cause circulation of broadcast messages around the network and can saturate the network consuming all available bandwidth. This network condition is known as a broadcast storm. Broadcast storm is a serious network problem and can shut down entire networks for seconds.

In a ZigBee network, all routers should forward a broadcast message when they receive the message, and may have to transmit the forwarded message multiple times (depending if a passive acknowledgement mechanism is used), to assure robust communication. In this case, in case of a large, dense network, too many broadcast messages are transmitted in the air, which is like a broadcast storm. It may last even 15-45 seconds and other messages may be blocked.

A conventional approach to reduce broadcast storm is the Trickle algorithm described in the IETF (Internet Engineering Task Force) specification RFC 6206 which can partly reduce the broadcast storm. The Trickle algorithm allows nodes to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. However, any router who receives a broadcast will still need to forward the message of the broadcast.

SUM MARY OF THE INVENTION

It is an object of the present invention to provide an improved approach to control broadcast or multicast transmission in order to reduce broadcast storm.

This object is achieved by an apparatus as claimed in claim 1, by a network as claimed in claim 13, by a method as claimed in claim 14, and by a computer program product as claimed in claim 15.

Accordingly, if the link quality of a transmission link between a network node and a neighbor node meets a predetermined quality requirement, the neighbor node is set to a parent node status for a broadcast tree structure of the mesh-type network and the network node is set to a leaf node status and controlled to suppress retransmission of received broadcast messages. Additionally, a parent node with equal or at least similar link quality that already is a parent to another node can be chosen, which will reduce the total number of parent nodes in the system. Hence, not all routers, but only automatically- selected parent routers need to forward the messages of the broadcast. Broadcast storm can thus be largely reduced for mesh-type networks by forming a tree network of routers, in which leaf routers don't forward broadcast packets.

It is noted that throughout the document a parent node is to be understood as a tree parent router used as broadcast and/or tree forwarder (node), wherein the broadcast tree is overlaid over the network mesh.

According to a first option, it may be determined at the network node whether a link quality of a transmission link to a neighbor node, from which a parent node status request message has been received, meets the predetermined quality requirement, and to enter the parent node status if the transmission link to the requesting neighbor node meets the predetermined quality requirement. It is thereby ensured that a parent-leaf relationship is only established if a sufficient link quality is given in both directions between the parent node and the leaf node.

According to a second option which can be combined with the first option, an information indicating the requesting neighbor node as a leaf node may be added to a maintained list of neighbor nodes if the transmission link to the requesting neighbor node meets the predetermined quality requirement. Thus, an information about all connected leaf nodes in the neighborhood is available at each parent node.

According to a third option which can be combined with the above first or second option, the parent node status may be requested by setting a predetermined information in a link status entry field of a link status message. This provides the advantage that reserved bit(s) or byte(s) in the link status message can be used to form a tree-type network without any extra network communication added.

According to a fourth option which can be combined with any one of the above first to third options, a successful parent node status may be signaled by setting a predetermined information in another link status entry field of a link status message. Similar to the third option, this measure provides the advantage that reserved bit(s) or byte(s) in the link status message can be used to form a tree-type network without any extra network communication added.

According to a fifth option which can be combined with any one of the above first to fourth options, a predetermined flag may be set in a link status command option field of a link status message if the network node is configured as a root node or parent node or leaf node of the tree structure of the mesh-type network and to reset the predetermined flag in the link status command option field of the link status message if the network node is configured as a rootless node of the tree structure. Besides the advantage that reserved bit(s) or byte(s) in the link status message can be used to form a tree-type network without any extra network communication added, the status of a node as part of the tree structure can be directly obtained from its link status message.

According to a sixth option which can be combined with the above second option, a leaf node information can be removed from the maintained list of neighbor nodes if the concerned network node which maintains the list of neighbor nodes does not receive a link status message from the corresponding leaf node within a predetermined period of time or upon reception of a leaving message from the neighbor node or a leaving instruction for the neighbor node. Thereby, the concerned network node can be made aware of all active leaf nodes and whether it still needs to retransmit broadcast messages.

According to a seventh option which can be combined with the above sixth option, the status of the network node may be changed to a leaf node status if the removed leaf node information was related to a last leaf node in the list of neighbor nodes. This measure serves to prevent useless retransmissions of broadcast messages if a parent node has no more connection to a subordinate leaf node of the tree structure. It may be achieved by maintaining a tree status for each neighbor, and specifically, by having parent nodes keep information on all of their leaf nodes. Moreover, leaf nodes may maintain information about their parent nodes (and may re-discover a parent node if required), and may clean stale parent nodes, so that the tree is re-formed every now and then, e.g. periodically or upon major network event (e.g. key update, layout change, etc.).

According to an eighth option which can be combined with any one of the above first to seventh options, a procedure for requesting a new parent node may be initiated if a network node detects the disappearance of the parent node, e.g. does not receive a link status message from a parent node of the network node within a

predetermined period of time or upon reception of a leaving message from the parent node or a leaving instruction for the parent node. Thereby, it can be ensured that a functional tree structure can be maintained even if a network links or a network node fails for whatever reason .

According to a ninth option which can be combined with the above eighth option, the status of the network node may be changed to a rootless node status upon detecting the disappearance of the parent node or if the procedure for requesting a new parent node fails. This measure provides the advantage that a network node that has lost its link to the tree structure starts retransmitting again, and can be used as a new root node of a further tree structure to ensure full coverage.

According to a tenth option which can be combined with any one of the above first to ninth options, the network node may be set into a default status of a rootless node, and an initial random procedure may be performed for randomly setting the network node to a root node status if it determines that all neighbor nodes are set to a rootless node status. According to an eleventh option which can be combined with the above tenth option, an address of a root node of the network node may be provided in a link status message, and a parent node status of a neighbor node may be requested if a link status message with a different root node address has been received from the neighbor node and a predetermined relation between the different root node address and the address of the root node of the network node is determined. Thereby, a network node can change to another tree structure, so that several trees formed at first stage can be merged into one large tree in the end. This measure provides a fully automatic way of forming the tree network among all the routers, in which the root node of the tree structure is randomly automatically selected.

It is noted that the above apparatus may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet.

It shall be understood that the apparatus of claim 1, the network of claim 13, the method of claim 14 and the computer program product of claim 15 may have similar and/or identical preferred embodiments, in particular, as defined in the dependent claims.

It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings:

Fig. 1 shows a schematic tree structure of a mesh-type network; Fig. 2 shows a format of a link status message and reserved fields for use in various embodiments;

Fig. 3 shows an example of a process for forming a tree structure according to a first embodiment;

Fig. 4 shows an example of a process for merging tree structures according to a second embodiment; Fig. 5 shows a schematic flow diagram of a control operation for a router in a mesh-type network according to the first embodiment;

Fig. 6 shows a schematic flow diagram of a startup control operation for a router in a mesh-type network according to the second embodiment; and

Fig. 7 shows a schematic flow diagram of a tree merge control operation for a router according to the second embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the present invention are now described based on a ZigBee network as an example of a mesh-type network where routers selectively forward broadcast messages in accordance with an established dynamic tree structure which is overlaid over the mesh structure. I.e., nodes may have a link between each other that are not parent-leaf links of the tree structure. The broadcast tree can be used for network management traffic (such as route discovery traffic) and/or for data traffic. In addition, separate trees can be used for different purposes. Fig. 1 shows a schematic architecture of a tree topology according to the embodiments, which can be established in a mesh-type ZigBee network. In the following, role and relationship of network nodes (e.g., routers in the ZigBee network) in the tree structure is explained with reference to Fig. 1.

At the top or root of the tree, a root node R_A forms the origin and is connected via a parent-leaf parent link p/lp to parent nodes P and via a parent-leaf link p/l to leaf nodes L. The root node R_A is configured to forward broadcast messages and to set a flag (e.g. tree flag) in its links status message to indicate that it is part of a tree. The network address of the root node R_A may be used as a tree identifier.

The parent nodes P are also configured to forward broadcast messages and to set the flag (e.g. tree flag) in their link status message to indicate that they are part of the tree. The link between two parent nodes P is a parent/leaf parent link p/lp.

The leaf nodes L at a leaf of the tree are configured to suppress forwarding of broadcast messages, i.e., they do not forward any received broadcast messages. Similar to the root node R_A and parent nodes P, the leaf nodes L are configured to set the flag (e.g. tree flag) in its links status message to indicate that they are part of the tree, so that they can be selected as parent nodes by further nodes. Finally, rootless nodes O are provided, which have no established link or connection to the tree. They have a similar function as the root node and are configured to forward received broadcast messages. However, they do not set the flag (i.e. the tree flag) in their link status messages, since they are not (yet) part of a tree. However, the rootless nodes are of course part of the network and capable of communicating. They just do not (yet) belong to the tree structure and therefore cannot re-broadcast in an efficient manner.

It is to be noted that Fig. 1 does not show non-routing mesh nodes, such as end devices, Green Power Devices, or other reduced functionality, since they do not participate in meshing and thus are typically not participating in re-broadcasting and their role may be reduced to retrieving, upon waking up, a buffered message from the parent (e.g. sleeping end devices) or may even not be able to receive broadcast communication (e.g. transmit-only Green Power Devices).

According to the following embodiments, broadcast storm in the ZigBee network (or other mesh-type networks) can be reduced by forming a broadcast tree network for routers and by configuring end routers so as to suppress forwarding broadcast messages or packets (e.g., the devices can be programmed such that when in a leaf role, they suppress forwarding broadcast or multicast messages). More specifically, preferably the tree network can be formed by using reserved bit(s) or byte(s) in a predetermined massage, e.g., the link status message, so that a tree-type network can be formed without any extra network communication added. Thus, not all routers, only automatically-selected parent routers need to forward the messages of the broadcast, so that broadcast storm can be largely reduced.

The proposed solution thus can advantageously coexist with legacy devices, reducing the network load also in partly-compliant networks, as it doesn't add any traffic of its own and does not rely on all nodes participating in the tree forming.

Fig. 2 shows a format of a known link status message and reserved fields which can be used for conveying information in the following embodiments.

The link status message as defined by ZigBee [ZigBee Core specification, ZigBee document 05-3474r21, Figure 3.22] comprises a header portion (H) and a payload portion (PL) which both consist of a variable number of octets (bytes). The header portion (H) comprises of a frame control field (FC) with a length of two octets and routing fields (RF) of variable length Vh. The payload portion (PL) comprises a command identifier field (CI) with a length of one octet and a command payload of variable length Vp. The two lengths Vh and Vp are independent and most likely different. The command payload (CP) comprises a link status command options field (CO) with a length of one octet and a link status list (LSL) of variable length V.

The first five bits (bit No. 0 to bit No. 4) of the links status command options field are used for an entry count. Bit No. 5 is used as a flag to indicate a first frame of the sender's link status and bit No. 6 is used as a flag to indicate a last frame of the sender's link status. Finally, bit No. 7 of the link status command options field is reserved (R) for other purposes.

Furthermore, the link status list comprises a plurality of link status entries

(LSEs) for neighbor nodes, each entry comprising a neighbor network address (NN-ADR) of a length of two octets and a link status field (LS) of a length of one octet. The first three bits (bit No. 0 to bit No. 2) of the link status field are used to indicate an incoming cost (IC) of the related neighbor node and the fifth to seventh bits (bit No. 4 to bit No. 6) are used to indicated an outgoing cost (OC) of the related neighbor node. Finally, bits No. 3 and 7 of the link status field are reserved (R) for other purposes.

According to the following embodiments, bit No. 7 (bit7) of the command options field is used for controlling the formation of a tree structure.

Furthermore, in the following embodiments the normal link status schedule (e.g., as a default e.g. every 15s) is used to communicate tree-related information. As an alternative, it may be possible for a node to send the link status message ahead of schedule, so that the tree-related changes are communicated quicker.

In the following first embodiment, a half automatic formation of a tree structure is provided, because the root nodes need to be manually selected. More specifically, the formation of the tree structure in the ZigBee network is achieved by controlling all root routers or parent routers to send their link status message with a flag, i.e., bit7 = 1, in link status command option field, to thereby announce that the sending router is part of the tree structure and can be selected as parent router. Those neighboring routers in the ZigBee network which are rootless nodes will listen to the link status message from the root/parent router and choose one as its parent based, e.g. on the quality of the transmission, e.g., link signal strength, bit or packet error rate, number of retransmissions, number of neighbor nodes of the candidate parent, total amount of packets sent to/received from that candidate parent, any information related specifically to the quality of the broadcast communication received previously from the candidate parent, the fact of the candidate already being a (tree) parent router, etc. or other criteria, e.g. group membership of the candidate parent, network protocol version of the candidate patent, location of the candidate parent; this information may be derivable from the link status messages sent by the candidate parent or from other communication with the candidate parent, or may require dedicated exchange.

To communicate this choice, the neighboring routers set bit No. 3 (bit3) of the link status field of the selected parent router to a predetermined binary state, e.g. "1" (bit3 =1) to thereby issue a parent request. The selected parent router can acknowledge the parent request by setting bit No. 7 (bit7) of the link status field of the link status entry corresponding to the requesting node in the link status message to a predetermined binary state, e.g. "1" (bit7 =1) to thereby issue a parent response, which is an optional step depending on the measured link quality. In this way, a rootless node can join the tree structure and become a leaf router which will send a link status message where the flag in command option field of the link status message is set (i.e. bit7 = 1), announcing that it is part of the tree structure and could be a parent router. The above steps can be continued until all routers are part of the tree network.

As an alternative, a parent node could actually set the parent response flag in link status entries for all its neighbors (maybe except its own parent). This way - and if the exact tracking of leaf nodes is not required or when dedicated messages are used for tree establishment - the yet rootless nodes can attach themselves to a tree quicker, and the link status processing is simplified since rootless nodes only need to analyze link status entries for their own address.

In case of a link failure between a parent router and a leaf router, which is caused by failure of the leaf router, so that the parent router does not hear the link status message for a predetermined time period (e.g., three times the interval of the link status message), the parent router may remove the leaf router from its neighbor table and from the link status list. This parent router will then become an end router if the removed leaf router was the last leaf router in its neighbor list and stop rebroadcasting. If the leaf router sees its address removed from the link status list of the parent, it makes itself a rootless node (setting bit 7 of the command options field of the link status message to "ObO") and chooses a parent. Upon adding the former leaf back to the neighbor table, the former parent does not automatically indicate its leaf status, it will happen upon the parent request.

In case of a link failure between a parent router and a leaf router, which is caused by failure of the parent router, the leaf router may reconnect to the tree based on the link status messages it receives. Before reconnecting to the tree, it (and its child routers if any) will become a rootless router which forwards broadcast messages again. Thus, losing one neighbor router, even the original joining parent, doesn't disconnect a router from the network. It can stay operational and keeps its own subsidiary nodes (i.e., child nodes), etc. though it may need to re-establish the routes and also the connection(s) to the broadcast tree.

Preferably, the parent router always sets the bit 7 of the link status field of the link status command. This way, the child can recover this information after brief power down.

The rootless node may collect a number of link status messages, e.g. during one default link status cycle (15s), to increase the chances for selecting a good parent router. Alternatively, the rootless node may select as parent the first router fulfilling the criteria. In yet another embodiment, the rootless node may select a new parent based at least in part on the information in its neighbor table. In that case, the node may track the tree bit of the link status messages of its neighbors and update it accordingly.

Fig. 3 shows an example of a process for forming a tree structure according to the first embodiment. In Fig. 3, solid arrows indicate different messages and dotted/dashed arrows indicate changes of a functionality of the concerned node. The different fillings of the circles for nodes B and C indicate that they have changed their function or role within the tree in steps 4, 7 and 9, respectively. In this example, the formation of the tree structure starts with a root node R_A and two rootless nodes B and C. In step 1, the root node R_A sends a link status message with flag (i.e., bit7=l in command options field of the link status message). Rootless node B sends a parent request (i.e., bit3=l in link status field of root node address) to root node R_A in step 2. Then, in step 3, root node R_A responds to rootless node with a parent response (i.e., bit7=l in link status field of root node address). Thus, rootless node B upgrades to an end router status in step 4 and sends a link status message with flag (i.e., bit7=l in command options field of the link status message) in step 5. Then, in step 6, rootless node C sends a parent request (i.e., bit3=l in link status field of B's address) to end router B. In response thereto, end router B upgrades to a parent router in step 7 and sends a parent response (i.e., bit7=l in link status field of C's address) to rootless node C in step 8. In response thereto, rootless node C upgrades to an end router in step 9 and sends a link status message with flag (i.e., bit7=l in command options field of the link status message).

In a second embodiment, a fully automatic way of forming the tree structure among all the routers is provided, wherein a root node of the tree is randomly automatically selected, and wherein several trees could be formed at a first stage and merged into one large tree in the end.

More specifically, all routers are rootless routers when the process starts, e.g. upon joining the network or rejoining it after power outage. The rootless routers will randomly rise to the root routers if all of their neighbor routers are rootless routers, e.g. they may generate a random number between 0 and 1 and if the number is larger 0.5, then they become a root router. Root routers, end routers and parent router send the link status message with the flag (i.e., bit7 = 1 in link status command option field), announcing that they can be root or parent rooters, and add their root address in the link status message, as additional last link status entry the address of the root router in the neighbor network address field with zero incoming cost and zero outgoing cost (zero today being an invalid value). The subsequent formation of the tree corresponds to the first embodiment with the difference that every router in the tree will provide the address of the root of the tree in its link status message and that a rootless node may see multiple candidates which may use different trees.

Fig. 4 shows an example of a process for merging tree structures according to a second embodiment, where criteria for merging the tree could be preset like, e.g., choose the root with highest value of network address as final root node. In Fig. 4, solid arrows indicate different messages and dashed/dotted arrows indicate changes of a functionality of the concerned node.

When any of the nodes of a first tree with first root router R_A, e.g. an end router A22 receives in step 1 a link status message from its neighbor router Bll which indicates a root address B of a second root router R_B of a second tree, this router A22 will send in step 2 a parent request (i.e., link status message with bit3=l in the link status field of Bll's address) to its neighbor router Bll if the root address A is lower than the root address B (Aaddr<Baddr). In response thereto, the neighbor router Bll will send in step 3 a parent response (i.e., link status message with bit7=l in the link status field of A22's address) to end router A22. As indicated before, this is an optional confirmation. In step 4, end router A22 leaves tree A and joins tree B. Then, in step 5, end router A22 will send its link status message with bit7 = 1 in the link status command option field and root address B of root router R_B in the respective link status entry. In the following, more detailed control operation procedures for controlling routers of the above first and second embodiments in a ZigBee network or any other mesh-type networks are described with reference to Figs. 5 to 7.

Fig. 5 shows a schematic flow diagram of an exemplary control operation for a router in a ZigBee network according to the first embodiment. The control operation may be continuously or intermittently executed in each router by a processor under control of a corresponding software program or routine. It is however pointed out the present invention is in no way restricted to this detailed processing and various modification can be applied.

At Startup, in step 500, root routers are manually set and in step 501 it is determined whether the concerned router is a root router, an end router or a parent router. If not, it is determined in step 501 that the concerned router is a rootless router which does not yet belong to a tree, and the router sends a link status message without flag (i.e., bit7 = 0 in command option field of the link status command) in step 502. If the concerned router is a root router, an end router or a parent router, the procedure branches to step 510 and the router sends a link status message with the flag (bit7 = 1 in link status command option field) indicating that it is part of a tree and can be selected as parent router.

In step 503, the rootless router checks based on received link status messages whether one of his neighbor routers is a root router, an end router or a parent router and if the link quality of this neighbor router meets at least one predetermined criterion, e.g., whether the link quality exceeds a predetermined threshold and is the best link quality in its neighbor list. If so, the rootless router sends in step 504 a link status message with a parent request (i.e., bit3 =1 in the link status field of the related neighbor router) to the selected router. It is however noted that the or rootless phan router may only know the difference if (i) the parent router always includes the parent flag (i.e., bit 7 of link status) and (ii) the rootless router analyzes the complete link status list of the neighbor router. Otherwise, esp. if (i) is not true, it may only see current snapshot (exchange).

In step 511, the router is in the root, parent or end router state and checks whether it has received a links status message with a parent request (i.e., bit3 =1 in its link status field) from one of its neighbor routers. If not, the procedure branches to step 517. If so, the router will check in step 512 if the link quality of this neighbor router meets at least one predetermined criterion, e.g., whether the link quality exceeds a predetermined threshold. If not, the selected router will only update the link quality of this neighbor in step 513. If yes, the selected router will add the neighbor router which has sent the parent request as its leaf in its neighbor table in step 514. Then, in step 515, the selected router will become a parent router if it was an end router. Thereafter, it will send in step 516 a link status message with parent response (i.e., with bit7 =1 in the link status field of the related neighbor).

In step 505 the router is in the rootless router state and checks whether within a given period of time (e.g. 1 cycle of the link status message) it has received a links status message with a parent response (i.e., bit7 =1 in its link status field) from one of its neighbor routers. If not, the procedure may move to step 517. If yes, it will check in step 506 if he has sent a parent request to this neighbor router before. If not, it will only update the link quality of the concerned neighbor router in step 507. If yes, it will update the link quality and become the end router in step 508. Then, it sends a link status message with a flag (i.e., bit7 = 1 in the command option of the link status command field and bit7 = 0 in the link status fields of all the link status entries) in step 509 to thereby indicate that it is now part of a tree and can be selected as parent router.

In step 517, the router checks (e.g., based on a counter or timer or watchdog operation) whether it has received a link status message from each parent or leaf node of its neighbor list within a predetermined time period (e.g., three intervals of the link status message). If so, the procedure jumps back to step 501 where the current status of the router is checked. If not, and the router is part of a tree as root, parent, or leaf router, a link failure between a parent router and a leaf router is determined, since the router did not receive the link status message during the predetermined period of the link expired.

It is noted that step 517 may be used for link failure of the broadcast tree only. Rootless routers may jump straight to step 501 or 502. The checking in step 517 may also include checking if a leaving message has been received from a leaf node or if a leaving instruction for a leaf node has been received. If such a leaving message or instruction has been received, the procedure moves forward to step 518. This is used for link failure of the broadcast tree. The rootless node could jump straight to 501 or 502.

Then, in step 518, it is checked whether the router is a parent router of the node with the failed link or a node that has left the network. If so, it will remove the leaf router with the link failure from its neighbor table in step 519. Then, it is checked in step 520 whether the removed leaf router was the last leaf router in the neighbor table. If so, the router will change its state in step 521 from a parent router to an end router. If not, the procedure jumps back to step 501.

Otherwise, if it is determined in step 518 that the router is not a parent router of the node with the failed link, the procedure branches to step 522, where it is checked whether the router is a leaf router of the node with the failed link. If not, the procedure jumps back to step 501. If yes, the leaf router will start in step 523 a process of adding a new parent router within a predetermined time period Tl according to its neighbor table. As an example, the predetermined time period Tl may be set to 10s as a default value. It is however noted that exceptions for a failing root may be provided. Then, it is checked in step 524 if the parent adding process has failed. If not, the procedure jumps back to step 501. If yes, the leaf router will change its state, becomes a rootless router and sends a link status message without flag (i.e., with bit7 = 0 in command option field of the link status command) to indicate that it is not part of a tree and cannot be selected as a parent router. Finally, the procedure jumps back to step 501.

Thus, by controlling every router of a mesh network in accordance with the control procedure of Fig. 5, the mesh network will automatically form a tree structure and end routers do not need to forward any broadcast, so that broadcast storm can be reduced.

Fig. 6 shows a schematic flow diagram of a startup control operation for a router for fully automated tree formation in a ZigBee network according to the second embodiment.

Initially, at start-up in step 601, all routers of the mesh network are set to a rootless router state and may thus provide the root of a tree. Then, in step 602, it is checked whether all neighbor routers in the neighbor list are rootless routers. If so, the controlled router will randomly rise to the root router state in step 603, e.g. based on random control procedure which generate a random number and checks if the random number meets a predetermined criterion, e.g., it generates a fractional number between 0 and 1 and if the number is larger than a default value (e.g. 0.5), the rootless router becomes a root router; more intelligent choices may be possible, e.g. placing a root in a gateway and/or concentrator and/or controller, having one root per floor and/or area and/or group, etc.

Then, the procedure may continue at step 501 of Fig. 5, so that routers in the root, leaf or parent router state send a link status message with a flag (i.e., bit7 = 1 in link status command option field) in step 510. However, in the second embodiment, steps 509 and 510 of Fig. 5 are modified in that an additional last link status entry is added, where the address of the root router is entered as neighbor node address in the link status entry and the incoming and outgoing costs of the link status field are set to zero. Similarly, the parent request or parent response fields may be set to zero.

Fig. 7 shows a schematic flow diagram of a tree merge control operation for a router according to the second embodiment, which may be inserted into the "yes"-branch after step 517 in Fig. 5.

When a router in a root, parent or leaf router state with root address A in its link status entry determines in step 517 of Fig. 5 that it has received from one of its neighbor routers a link status message, it determines in step 701 the root address B in the received link status message. Then, it checks in step 702 if the received root address B differs from the own root address A. If not, the procedure jumps back to step 501 of Fig. 5. Otherwise, if it is determined in step 702 that a different root address B has been received, it is checked in step 703 if a predetermined relation between the received root address B and the own root address A is fulfilled (e.g., own root address A higher than received root address B or own root address A lower than received root address B, or other relations). If not, the procedure jumps back to step 501 of Fig. 5. Otherwise, if it is determined in step 703 that the relation is fulfilled, the router is controlled in step 704 to send a link status message with parent request to its neighbor router from which he has received the root address B.

Alternatively, the nodes may be allowed to ask another node to arbitrate, e.g. a gateway, commissioning tool, etc. It is noted that a router in a rootless state may have the routers from multiple trees to choose from and could try to pick the lowest root first, if it meets the link quality criteria. Or, it may join any tree via the best parent, and eventually move with that parent to the final tree. Optionally, the tree behavior may be selectively enabled/disabled on the nodes, e.g. via some user interface (Ul) (e.g. dip switches) or OTA command setting, e.g. network control command, middleware command or application layer command. This way, in the same network, areas of less intense broadcast traffic (e.g. in very dense network parts, e.g., open office areas with generic and task lighting) and more intense broadcast traffic (e.g. in sparsely-populated network parts, e.g. staircases, corridors) can be defined separately.

As another option, the decision to use the tree-based broadcast suppression can be taken by the device itself, e.g. based on the number of neighbor nodes, number of broadcast messages observed per time unit, etc.

Consequently, the neighbor router will be controlled by its own control procedure in accordance with steps 511 to 516 of Fig. 5 to send an optional parent response to the requesting router. The desired broadcast may be triggered by an originator device unicasting to the parent or the originator device may directly broadcast the message.

Furthermore, broadcast retry parameters (number of retries, time between retries, passive acknowledgement threshold, etc.) could differ for the parent and the rootless node, e.g. assuring more robust transmission for the parent nodes. Then, the requesting router having changed the tree and root address will send a link message with a flag (bit7 = 1) in the link status command option field and the new root address B in the link status entry in accordance with steps 505 to 509 of Fig. 5.

As an option to assure robust reception, each broadcast tree node may be required to have at least N parent routers among its neighbor routers, where N>=1 and can be configurable. This way, the broadcast can be made more robust against node failure and temporary propagation problems.

Furthermore, a device can be a member of multiple trees and include information on multiple roots in its link status message.

As another option, a parent node A can track the tree status of its leaf nodes as to whether they are itself leaf nodes (e.g. B and C), not required to rebroadcast or whether they (e.g. E and F) are parent nodes to further nodes. This information can be used for further controlling the rebroadcasting, e.g. adapting the passive acknowledgement mechanism (e.g., the parent A may skip retries of re-broadcasting if both nodes E and F did forward the message already).

To summarize, a method and apparatus for controlling a broadcast, multicast or groupcast transmission in a mesh-type network by forming a tree network for all routers has been described, where leaf routers don't forward broadcast packets. By using reserved fields in a link status message, a tree network can be formed without any extra network communication added. With this approach, not all routers, only automatically-selected parent routers need to forward the messages of the broadcast, so that broadcast storm can be largely reduced. Furthermore, a fully automatic way of forming the tree network among all routers can be provided, if the root node of a tree is randomly automatically selected. Several trees could then be formed at a first stage and merged into one large tree in the end.

While the invention has been illustrated and described in detail 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 embodiments. The proposed broadcast control processing can be applied to and possibly standardized in other types of networks and with other types of messages and control fields. The tree-related communication may use dedicated messages instead of using (all) reserved bits of the link status messages, since the bits may be used for another purposes. Using other messages than link status messages, the link status messages being only exchanged by routing nodes, may further allow, if required, to involve other nodes, e.g. non-sleeping end devices, in the broadcast forwarding process, e.g. as root nodes or parent nodes. Furthermore, the invention is not restricted to broadcast transmission and could be applied to multicast and groupcast transmission (i.e. broadcast with higher layer grouplD- based filtering).

Other variations to the disclosed embodiments can be understood and effected by those skilled in 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 or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated.

A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

The described operations like those indicated in Figs. 5 to 7 can be implemented as program code means of a computer program and/or as dedicated hardware. The computer program may be stored and/or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

CLAIMS:

1. An apparatus in a network node for controlling transmission of the network node in a mesh-type network comprising a plurality of network nodes, the apparatus being adapted:

- to determine (503) whether a link quality of a transmission link between the network node and a neighbor node meets a predetermined quality requirement;

- to request (504) a parent node status of the neighbor node for a broadcast, multicast or groupcast tree structure of the mesh-type network by setting a predetermined information in a link status entry field of a link status message if the link quality meets the predetermined quality requirement; and

- to control the network node to enter (508) a leaf node status for the broadcast, multicast or groupcast tree structure and suppress retransmission of received broadcast messages if the requested parent node status is granted.

2. The apparatus of claim 1, wherein the apparatus is adapted to determine (511) whether a link quality of a transmission link to a neighbor node, from which a parent node status request information has been received, meets the predetermined quality requirement, and to enter (515) the parent node status if the transmission link to the requesting neighbor node meets the predetermined quality requirement.

3. The apparatus of claim 1, wherein the apparatus is adapted to add (514) to a maintained list of neighbor nodes an information indicating the requesting neighbor node as a leaf node if the transmission link to the requesting neighbor node meets the predetermined quality requirement.

4. The apparatus of claim 1, wherein the apparatus is adapted to signal a successful parent node status by setting (516) a predetermined information in a second link status entry field of a link status message.

5. The apparatus of claim 1, wherein the apparatus is adapted to set (510) a predetermined flag in a link status command option field of a link status message if the network node is configured as a root node (R_A, R_B) or parent node (P) or leaf node (E) of the tree structure of the mesh-type network and to reset (502) the predetermined flag in the link status command option field of the link status message if the network node is configured as a rootless node (O) of the tree structure.

6. The apparatus of claim 3, wherein the apparatus is adapted to remove (519) a leaf node information from the maintained list of neighbor nodes if it does not receive a link status message from the corresponding leaf node within a predetermined period of time, or if it has received a leaving message from a neighbor node, or if it has received a leaving instruction for a neighbor node.

7. The apparatus of claim 6, wherein the apparatus is adapted to change (521) the status of the network node to a leaf node status if the removed leaf node information was related to a last leaf node in the list of neighbor nodes.

8. The apparatus of claim 1, wherein the apparatus is adapted to initiate (523) a procedure for requesting a new parent node if it does not receive a link status message from a parent node of the network node within a predetermined period of time.

9. The apparatus of claim 8, wherein the apparatus is adapted to change (525) the status of the network node to a rootless node status if the procedure for requesting a new parent node fails.

10. The apparatus of claim 1, wherein the apparatus is adapted to set (601) the network node into a status of a rootless node as a default mode, and to perform (603) an initial random procedure for randomly setting the network node to a root node status if it determines (602) that all neighbor nodes are set to the rootless node status.

11. The apparatus of claim 10, wherein the apparatus is adapted to provide an address of a root node of the network node in a link status message, and to request (704) a parent node status of a neighbor node if a link status message with a different root node address has been received from the neighbor node and the different root node address fulfils the criteria of final root node selection.

12. A mesh-type network comprising a plurality of router devices comprising an apparatus of claim 1.

13. A method of controlling broadcast transmission in a mesh-type network comprising a plurality of network nodes, the method comprising the steps of:

- determining (503) at a network node whether a link quality of a transmission link between the network node and a neighbor node meets a predetermined quality requirement;

- requesting (504) a parent node status of the neighbor node for a broadcast, multicast or groupcast tree structure of the mesh-type network by setting a predetermined information in a link status entry field of a link status message if the link quality meets the predetermined quality requirement; and

- controlling the network node to enter (508) a leaf node status for the tree structure and suppress retransmission of received broadcast messages if the requested parent node status is granted.

14. A computer program product comprising code means for producing the steps of claim 13 when run on a computer device.