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.

One of the main causes of signaling flooding is due to Route requests and discoveries. Many attempts have been carried out to limit the signaling overhead caused by route discovery. However, the attempts target the reduction of signaling during this process. As a consequence, there is no limitation of the number of route discoveries in a network, even if they are more efficient from the overhead point of view.

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 method which reduces the number of route discoveries necessary for the operating of a network.

In accordance with a first aspect of the invention, a method is proposed for operating a first node in a network comprising at least one second node, the method comprising the steps of

(a) the first node receiving a message including a second node network address and a second node complete address,

(b) the first node checking whether its storage means contains at least one entry linked to the second node,

(c) the first node tagging the entry linked to the second node temporarily as invalid upon detection of an address conflict for the second node.

In accordance with a second aspect of the invention, it is proposed a radio node comprising a receiver for receiving a message including a further node network address and a further node complete address, storage means containing at least one entry, control means for checking whether the storage means contains at least one entry linked to the further node, and for tagging the entry linked to the further node temporarily as invalid upon detection of an address conflict for the further node.

As a consequence, the system in accordance with the invention enables to avoid rediscovering a route because of a change of identity of a radio node. It is to be noted that this invention may work independently of the network topology, i.e. regardless the fact the network is segmented. Thanks to this method, a route discovery may be avoided if there is a conflict of address in connection with a node. The invalid entry (invalid because of the no more valid identity of a node) in the routing table is temporarily kept as invalid and may not be used until a valid ID is given to the node and transmitted to the device storing this routing table. In some embodiments, since any node could have a routing table, the method may apply to every type of node present in the network.

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. 2a-c is a representation of a routing table of a node during the operating phases of the network in accordance with an embodiment of the invention.

Figure 3 represents a state diagram in accordance with the operation of a node in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In a ZigBee network, like represented on Figure 1, or in a non segmented Zigbee network, stochastic addressing is used where each node gets a random address within the 16 bit wide address space. After a short check by a parent, whether the address is in conflict with other 16-bit addresses known to the parent (neighbours, bound and infrastructure devices), the node announces the usage of this address by means of a Device annce broadcast. If any device in the network notices a conflict, i.e. two nodes using the same address, it is reported via broadcast network status message, and subsequently both conflicting nodes get a new random address and broadcast it. In case of an address conflict, both conflicting nodes change their address. That means that all other information about these nodes identified by their (old) network address is no longer valid. This information includes neighbour tables and routing tables. Especially routing table information is precious because re-establishing routes can be a costly activity as it floods the network with broadcasts of route request.

The methods and the systems proposed in the following exemplary embodiments of the invention aim at keeping the information identified by the nodes network address even after address conflict (e.g. marked as obsolete) and update this information in a smart manner when new address information about the nodes that had to change address comes in. Special care is taken of the order in which information is updated: since the routing table and the route discovery table do not contain the 64-bit long (invariable) IEEE addresses.

In accordance with a first embodiment, the method is designed in such a way that it is interoperable with nodes that simply delete all obsolete entries. A node N that receives any of the following address conflict detection packets

Device announcement, Route request (RREQ), Network Status Command indicating an address conflict (OxOd), or address verification (OxOe) checks whether it has the IEEEaddr and/or the NWKaddr from the message stored in its NIB AddrMap.

The following cases can occur.

(1) If neither NWKaddr nor IEEEaddr occurs in AddrMap; no special handling is needed. The address pair could then be added to the AddrMap, if needed, e.g. if the device identified by the IEEEaddr is bound device of node N or if N establishes Routing Table/Route Discovery Table entry involving this device.

(2) If the IEEEaddr and NWKaddr occur in the NIB AddrMap only once and as pair, and this entry is valid, there is no conflict, so no special handling is needed.

(3) If a conflict is detected whereby the same NWKaddr is already in the AddrMap, but for another node (with a different IEEEaddr), this conflict will have to be resolved. I.e. both of the conflicting nodes will have to obtain a new NWKaddr, so the NWKaddr in the table will change sooner or later. The current mapping is therefore of no use anymore. Instead of simply deleting it, together with the neighbour table, routing table and route discovery table entries belonging to this node; its NWKAddr can be made temporarily invalid. First, node N invalidates the corresponding entry in the NIB AddrMap.

This could be accomplished by adding an entry for IEEEaddr in NIB AddrMap with NWKaddr 'unspecified' (OxFFFF). Thus in general two entries for IEEEaddr can exist and therefore when looking for a specific IEEEaddress the whole table shall be searched. Sorting the table may prevent the need for this. Alternatively, the AddrMap database could be extended with a 'valid' field (bit), but this may consume much more memory space.

Subsequently, N is to search its routing table (RT) for entries with this conflicting NWKaddress. The routes to this NWKaddress or using this NWKaddress as next hop, which have a status value other than 'discovery underway' shall get a status 'inactive'. (Alternatively, a completely new status could be introduced into the standard, but at the moment, the already defined status value 'inactive' does not seem to serve any purpose in the ZigBee specification [rl7]).

The Route Discovery Table (RDT) and the Neighbour table (NT) do not need updating.

If this conflict detection was not the result of receiving a Network Status (OxOd), N reports the conflict with broadcast Network Status Command (OxOd), as defined by ZigBee specification.

If the conflicting NWKadd belongs to one of N's children, N should proceed with new address assignment, as defined by ZigBee specification.

Then, it waits for the Device annc command, announcing the new NWKaddr for that IEEEaddr.

In extension, if no Device annc appears within Addresslnvalidation seconds (e.g. 2 hours) after invalidating the NIB AddrMap and/or the Routing Table entry, those entries can be removed.

(4) Another type of conflict occurs when the same IEEEaddr is in the AddrMap, but with a different NWKaddr or NWKaddress unspecified. This means that the node has changed its NWKaddress. If the NWKaddress in the AddrMap was not set to unspecified the node N apparently did not see the previous conflict. Node N still has the old NWKaddress in its AddrMap and other tables.

On receipt of a message with both IEEEAddr and a non-conflicting NWKaddr for an entry present in N's NIB AddrMap, the node N:

• Shall wait for the BTT entry for this Device annc packet to expire, to increase the probability that the address is unique network-wide , thus stable, and no further conflict for this address would be detected. • first gets the old NWKaddress from the AddrMap (based on the IEEEaddress)

• and then updates the RT entry by replacing all occurrences of oldNWKaddress in destination and next-hop fields with newNWKaddress. For entries that do not have status discovery underway the status is set to active.

• In the RDT, in all entries the fields SrcAddr and SenderAddr shall be updated with the newNWKaddress.

• After that, the NT and AddrMap shall be updated with the newNWKaddress. As illustrated on Figure 2a to 2c, the table stored in a node implementing the solution proposed in one of these embodiments is changed. As illustrated on Figure 2a, the memory of the node N contains a table comprising a plurality of entries. In this example, each entry contains information linked to a node, here a route description to a node. This route includes the destination node complete address (here IEEE ID 1) and the destination node network address (here network ID 1). Moreover, the route also comprises information about the next hop, i.e. the next node to which the message must be transmitted to follow the path to the destination node. The next node may be identified by the pair of its network address (Network ID _next ) and its complete address (IEEE ID _next ).

Upon detection of an address conflict regarding the destination node, as depicted on Figure 2b, the node N tags the entry as unvalid by changing one of the network address or the complete address into a special address. In this example network ID 1 has been changed since the address conflict was related to the destination node. However, the change would have been applied to Network ID _nex t if the address conflict was related to the next hop node.

If a message needs to be transmitted in the meantime, an error message may be returned to the source node and the message may not be transmitted further.

When the address conflict is solved, the new address of the destination node is used to amend the unvalid entry as illustrated on Figure 2c. Thus, there is no use of requesting a new route discovery for this destination node. It enables to avoid an important signalling cost for such a task.

This example was illustrated on the routing table for the sake of illustration clarity, however, this could be done on a mapping table, which registers all the nodes known to the node N. Thus, only one entry is needed to be amended, the other tables referring to the mapping table.

Figure 3 represents a state diagram for entries in the AddrMap containing tuples (In ₅ Nm) of an IEEEaddress I _n that uses Networkaddress N _m . The changes occur on the receipt of different messages indicating that some node with IEEEaddress I is (now) using NWKaddress N, or that NWKaddress N shall no longer be used because a conflict occurred somewhere else. This figure reflects the choice where invalidation of an entry for some IEEEaddr is implemented by means of an extra tuple with 'unspecified' NWKaddr OxFFFF

It is to be noted that conflicts may happen repetitively, i.e. the second Device annc message can also create a conflict (e.g. with a different node). In this case, the node N should not update any of its tables (RT, NT, RDT, NIB AddrMap). Thus, the tables only any external node N are only updated after a new, non-conflicting address is found.

The only exception is the parent of the End Device (ZED) node with address conflict, as it is the parent that chooses the new address for the ZED child.

To enable the parent to keep the old NWKAddr of the ZED child until it's confirmed to be unique, it could use two entries: create a temporary NIB AddrMap (as invalid) entry, with the IEEEAddr and only NWKaddr of the ZED child and cache the new NWKAddr (to be tested on uniqueness) in the NIB. Then, if no address conflict is detected X seconds later, it updates all the RT entries (if any) and removes the NIB AddressMap entry.

In extension, this mechanism could temporarily be used for routing by the parent/intermediate nodes, in case any packets should arrive between conflict detection and resolution, e.g. from nodes that missed the conflict detection.

Similarly, the conflicting device itself could temporarily keep two entries in its (NIB nwkNetworkAddress and/or PIB macShortAddress), in order to be able to receive packets addressed to both its old and new address in the time between conflict discovery and resolution

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.

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.