WO2010131152A1

WO2010131152A1 - A method for communicating in a segmented network

Info

Publication number: WO2010131152A1
Application number: PCT/IB2010/051924
Authority: WO
Inventors: Xiaoniu Yang; Xiangyu Wang; Armand Lelkens
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2009-05-13
Filing date: 2010-05-03
Publication date: 2010-11-18

Abstract

The present invention relates to a method for communicating in a network, said network comprising a plurality of sub-networks interconnected by means of a backbone, each sub-network comprising a plurality of nodes and a control device coupling the sub-network to the backbone, the method comprising the steps of (a) a first node, which is connected to a first control device through at least one first parent node, monitoring its link with the first parent node, and (b) upon detection of a parent node change from the first parent node to a second parent node, transmitting to a control device linked to the second parent node an announcement message indicative of this change.

Description

A METHOD FOR COMMUNICATING IN A SEGMENTED NETWORK

FIELD OF THE INVENTION

The present invention relates to a method for communicating in a network, comprising a plurality of nodes, and such nodes. This invention is more especially related to ad hoc networks and that may comprise a plurality of sub-networks interconnected to each other by a backbone.

This invention is, for example, relevant for Zigbee networks.

BACKGROUND OF THE INVENTION

Ad hoc networks, like a ZigBee network, are often limited with large scale network deployment where hundreds and thousands of sensors and controllers in commercial buildings need to be fully connected. The root cause of the scalability problem in large-scale networks, like a large scale Zigbee network, is the so-called "broadcast storm" problem where ongoing broadcasting interferes with parallel unicast packet traversals. In order to reduce the consequence of a broadcast storm, instead of connecting all devices using one single ZigBee network, it is proposed to use a "Scalable Hybrid and Integrated Network" concept where a single logical ZigBee network is divided physically into a number of ZigBee segments that are connected by some high bandwidth backbone technologies, such as Ethernet or Wi-Fi. This is illustrated with Figure 1.

In the ZigBee bridging specification, a ZigBee Bridging Device (ZBDs) is an entity that connect physically separated ZigBee segments into one logical ZigBee networks transparently. To achieve transparency with regard to backbone technologies, a ZBD encapsulates every ZigBee packet it receives in an IP packet and tunnel it towards a destination ZBD where the encapsulated ZigBee packet is unpacked without modifications.

However, the ZigBee bridging devices do not provide full support for scalability. Indeed, in a bridged ZigBee network, logically all ZigBee network segments or sub-networks are considered as one ZigBee network where every node share the same ZigBee PAN network ID and share the same ZigBee network address space. This is achieved by transparent bridging done at ZBDs. Transparent bridging also implies that rebroadcasting will take place in every other segments for a broadcast originated from one segment. While this is necessary for data broadcasting that needs to reach every ZigBee devices on a network, this is unnecessary for some of the control packets. For example, when a routing discovery packet for a particular node is sent, only the segment that contains the particular node need to be flooded with the broadcasting of the packet. Broadcasting to other segments is unnecessary and will not yield any useful result.

In a large network, overhead in maintaining network connectivity is large. This leads to large number of control packets being transmitted in broadcast mode. These include among other things Device Announcement and Route Discovery commands. Therefore suppressing unnecessary flooding of control packets in every segment becomes necessary to reach full scalability.

SUMMARY OF THE INVENTION It is an object of the invention to propose a method for reducing the flooding subsequent to broadcast messages.

It is another object of the invention to propose a network where the bridging devices are able to decide on whether a message should be further broadcast.

As a consequence, in accordance with a first aspect of the invention, a method is proposed for communicating in a network, said network comprising a plurality of subnetworks interconnected by means of a backbone, each sub-network comprising a plurality of nodes and a control device coupling the sub-network to the backbone, the method comprising the steps of

(a) a first node, which is connected to a first control device through at least one first parent node, monitoring its link with the first parent node, and

(b) upon detection of a parent node change from the first parent node to a second parent node, transmitting to a control device linked to the second parent node an announcement message indicative of this change.

In accordance with a second aspect of the invention, it is proposed a node connected to a first control device through at least one first parent node in a first sub-network, the node comprising monitoring means for monitoring its link with the first parent node, and transmitting means for transmitting, upon detection of a parent node change from the first parent node to a second parent node, to a control device linked to the second parent node an announcement message indicative of this change. An idea for achieving intelligent suppressing of unnecessary broadcasting is a segment node list that is present and maintained in every bridging device (in an embodiment, Zigbee Bridging Devices or ZBDs). A bridging device is a device which is connected on one side with a subnetwork, like a Zigbee subnetwork, and on the other side to a backbone, like a WLAN or wired Internet. This bridging device is a gateway ensuring the communications between the subnetwork and the backbone. The bridging device will base its decision whether to forward a broadcast message to its segment on their segment node list.

When a new node has just joined a network, it usually starts with sending a Device

Announcement command in broadcast mode. Its bridging device may insert the new node to its node list, which contains all nodes in its serving segment. The maintenance of a node list may not be always straightforward. This is especially true when nodes physically move around or when environment changes that forces nodes to leave one segment and to associate with another. The node list at a bridging device may not always reflect what is in the reality in its segment. This inconsistency will naturally lead to wrong decisions when it comes to intelligent broadcast suppressing.

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

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will now be described in more detail, by way of example, with reference to the accompanying drawings, wherein:

Fig. 1 already described is a block diagram of a segmented network.

Fig. 2 is a block diagram of a network in accordance with an embodiment of the invention. - Fig. 3 is an example of the operation of the method in accordance with an embodiment of the invention.

Fig. 4 is another example of the operation of the method in accordance with another embodiment of the invention.

Fig. 5 is still another example of the operation of the method in accordance with another embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention may be implemented in a network being segmented like illustrated on

Figure 1. Such a network, in exemplary embodiment, is a Zigbee network comprising a plurality of sub-networks or segments being interconnected by means of at least one backbone. To ensure communication from a segment to the backbone, a bridging device or segment control device is provided in each segment.

To reach scalability in such network, it is proposed three main intelligent functionalities that can be introduced to the bridging devices or segment control device. Such bridging devices may comprise each a segment node list including the list of the nodes belonging to the segment to which the bridging device is dedicated. This node list should be continuously updated and contains all the nodes the considered segment contains. Based on the node list, intelligent suppressing of broadcast traffic can be performed. Indeed, the control device may check whether a message needs to be forwarded to the segments or not. For example, a route request addressed to a node which is not present in a segment is of no use for the nodes of this segment and must thus not be broadcast in this segment. Second, bridging devices will help in detecting potential overlapping in ZigBee segments. Overlapping may arise due to addition of new nodes that connect previously separated segments or due to environment changes that previously separated segments suddenly get connected. Overlapping is harmful as broadcast domain will not be restricted to small ZigBee segments and will be able to propagate to more nodes. This functionality is dealt with in the embodiments of this invention. Third, once overlapping of segments is detected, the bridging devices will help in switch segments onto different channels to resume non-overlapping again.

The methods and the systems proposed in the following exemplary embodiments of the invention aim to achieve scalable ZigBee networks without any modifications to the ZigBee stack on ZigBee nodes, e.g. light sensors and light switches.

In the embodiments described in connections with this invention, it is dealt with an error situation when a node list is no longer consistent with reality. Such an error situation may arise when a node moves together with its parent node from one segment to another. A parent node is a node through which a child node is connected to the bridging device. A child node may have a plurality of subsequent parent node (e.g. a parent node of the parent node of the child node). When the parent node is being updated in the node list, the node itself may not be updated in the node list as the node has not changed its parent and its network address and it is not aware of the movement together with its parent.

Thus, it is required for the node list to take into account this change of situation. A first embodiment including a first method for the problem involves active reporting by the parent device to the grandparent device recursively about members in the association tree. A second embodiment including a second method involves recursive searching for child nodes in attempt to update the node list timely. A third embodiment including a third method involves active global searching after route discovery failure to the moved node.

In a bridged ZigBee network, shown in Figure 2, there is a node list which indicates which node is in the segment of which ZBD(s). This node list is used for routing of packets within the logical network that comprises all ZigBee network segments. Moreover, it is also the basis for intelligent suppressing of unnecessary broadcasting. The node list may be kept in a central location, or it may be distributed to all ZBD2. Essentially, the node list should comprise which node is in the segment of which ZBD(s). This is illustrated in figure 2. The node list can help in achieving intelligent route discovery.

When a new node joins the network, it will send out Device Announcement or Route Discovery broadcast message. At least one of the Bridging Device can intercept the message and update the node list accordingly.

There exist a plurality of situations leading to an error: - Error Situation 1 : when an existing node leaves its segment and associates at another segment, if it still keeps the same network address, it may not send out Device Announcement message. The bridging devices for both the previous segment and the new segment will not be aware of the change. And the node list contains inconsistency.

Error Situation 2: when a child node together with its parent node moves from their segment to another segment, the parent may get a new network address, send out

Device Announcement and get itself updated in the node list. However, since the child node has not changed its parent and its address, it may not send out Device Announcement. In this case, there is inconsistency about the child node in the node list. The error situation is illustrated on figure 3. The similarity between the above error scenarios is that a device may keep the same network address when it changes its segment physically. And in fact, a device should always try to keep its short network address whenever possible. Accordingly, it does not need to send out Device Announcement like a new node does. Without a Device Announcement message, the bridging devices have no way to know the change. In accordance with the first embodiment, whenever a device gets associated with a new parent, but still keeps the same network address, it is required to send out a Device Announcement or a Route Discovery broadcast message if it has immediately a packet to send. Bridging devices upon interception of this message can update the node list accordingly. This is required to address for instance Error Situation 1. The second embodiment also takes care of Error Situation 2. In this case, the parent node gets itself updated in the node list by the method in the first embodiment. The new bridging device where the parent node moves to, will use recursive inquiries to find out all the child nodes upon intercepting either Device Announcement or Route Discovery message, from the parent node. In performing recursive inquiries, the new bridging device should send out an IEEE addr req unicast message with RequestType being "Extended response" to the parent node. The parent node will send an IEEE addr rsp back to the Zigbee Bridging Device, which contains a list of its child device and their network addresses. The ZBD then use the same procedure of sending IEEE addr req and receiving IEEE addr rsp to inquiry recursively whether child and grandchild nodes have moved together with the parent. If yes, the ZBD updates the node list; if not, the ZBD stops the recursive inquiry for the node. This process is illustrated in figure 4.

On Figure, it is shown the method of operation in accordance with this example of embodiment. First, step 1 , the Parent node sends Device Announcement and gets the node list updated. Then, in step 2, the control device ZBD2 sends to the Parent node an IEEE addr req asking for a children list. As a consequence, at step 3, the Parent node replies back an IEEE addr rsp containing its children list. Then, in order to check that no more nodes are connected to the children nodes, at step 4, ZBD2 sends to the Child node an IEEE addr asking for grandchildren if any. The third embodiment, illustrated on figure 5, also deals with Error Situation 2 with an alternative method. When the parent get its information updated in the node list after its moving, no further action is required for ZBDs. The inconsistency between the node list and the moving child nodes will not incur any problem until there is a need to communicate to them. When a Source Node needs to communicate to a child node, the communication will fail as routing of messages to the node will follow the incorrect node list. The source node will start to do routing discovery for the node, and it will also fail as the incorrectness in the node list will route the Routing Discovery message wrongly. ZBDs will monitor how many Routing Discovery the Source Node sends out to find a route to the Child Node, if more than one Routing Discovery message is being sent out after a nwkcRouteDiscoveryTime, ZBDs will start a global search for the Child Node in all segments. The result would be that the moved Child Node is found in its new segment and the node list is updated with this information.

In accordance with the operation described on Figure 5, at step 1, node p sends a device announcement and updates the node list for instance on ZBD2. Then, at step 2, a node h transmits a message to node c. However, because of the apparition of node p, node c route is no more correct (node c being moved from the first segment to the second segment) and the message delivery fails. Then, at step 3, node h sends out a route discovery for c and its routed only to ZBDl, and again at step 4. This avoids the transmission to all segments of the route discovery request. Eventually, at step 5, ZBDl realizes that node c is no longer in the first segment and inform the other ZBD (ZBD2, and ZBD3) to perform a global search for c.

Thus, in accordance with these embodiments, each node monitors the link to its parent node. This can be done actively by the parent regularly transmitting to its child nodes a message indicative of its presence. This could also be done in reply to a request, like a regular request of the child node to its parents.

However, this could also be done passively, i.e. upon reception of data packets from the parent nodes, like broadcast messages (new address announcement, address conflict announcement or likewise) or transmission of user data packets from a source node. In each message, the transmitting node, here the parent node may be indicated and thus, it gives to the child node the identity of the parent node and information on the link with this parent node.

The invention and its embodiments are related to Scalable Hybrid and Integrated Networks for Lighting Control. Lighting control is active in controls in large commercial building. Currently, control networks are wired. Lighting control intends to ship wireless control products in the near future because of the no-wire advantages of wireless networks. ZigBee is the choice for wireless connectivity; however, ZigBee has been reported of limited support for large-scale networks.

Application of the embodiments of the invention can go maturely beyond lighting control to areas/products where large scale wireless sensor networks are desired.

In the present specification and claims the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Further, the word "comprising" does not exclude the presence of other elements or steps than those listed.

The inclusion of reference signs in parentheses in the claims is intended to aid understanding and is not intended to be limiting.

From reading the present disclosure, other modifications will be apparent to persons skilled in the art. Such modifications may involve other features which are already known in the art of radio communication.

Claims

1. A method for communicating in a network, said network comprising a plurality of sub-networks interconnected by means of a backbone, each sub-network comprising a plurality of nodes and a control device coupling the sub-network to the backbone, the method comprising the steps of

2. The method of claim 1, wherein at step (b), the transmission of the announcement message to the control device linked to the second parent node comprises broadcasting the announcement message to neighboring nodes of the first node.

3. The method of claim 1 or 2, wherein each control device of a sub-network comprises a sub-network node list of nodes belonging to this sub-network, and wherein the method comprises step (c) of the control device linked to the second parent node receiving the announcement message and updating its sub-network node list on the basis of the announcement message.

4. The method of claim 3, wherein step (c) is carried out if the control device linked to the second parent node does not belong to the first sub-network but to a second sub-network, and wherein the method further comprises step (d) of the control device of the second sub-network transmitting an update message at least to the first control device, said update message being indicative that the first node has migrated from the first sub-network to the second sub-network.

5. The method of any of the preceding claims, further comprising the steps of

(e) the control device linked to the second parent node inquiring to find out all the child nodes connected to the first node, and

(f) the control device linked to the second parent node updating its a sub-network node list of nodes.

6. The method of claim 5, wherein step (e) comprises transmission to the first node of an IEEE addr req message with extended request type, so that the first node transmits the list of all nodes having the first node as a parent node.

7. The method of claim 5 or 6, wherein step (e) and (f) are repeated recursively with each child node of the first node.

8. The method of claims 1 to 4, further comprising step (g) the first control device inquiring to find out a route to a first child node connected to the first node after having detected misrouted messages.

9. The method of claim 8 wherein step (g) comprises

(gl) inquiring to find out a route to the first child node in the first subnetwork, and (g2) upon failing to find a route in the first sub-network, inquiring to find out a route to the first child node through the backbone by requesting the control devices of other subnetworks.

10. The method of claim 9, further comprising the step of (g3) the first control device updating the first sub-network node list.

11. A node connected to a first control device through at least one first parent node in a first sub-network, the node comprising monitoring means for monitoring its link with the first parent node, and transmitting means for transmitting, upon detection of a parent node change from the first parent node to a second parent node, to a control device linked to the second parent node an announcement message indicative of this change.

12. A control device of a sub-network comprising means for implementing the method of any of claims 1 to 10.

13. A sub-network comprising at least one node as claimed in claim 11 and at least one control device as claimed in claim 12.

14. A network comprising a plurality of sub-networks as claimed in claim 13, interconnected by means of a backbone.