WO2009036792A1 - Compressed source routing - Google Patents

Abstract

The present invention provides a method of routing communications in a wireless data communication system comprising a plurality of nodes organised into a multi-hop network of connection paths between said nodes, a connection path being provided between a node and a next hop neighbouring node. The method comprises, in a communication to be sent, encoding a compressed route in the form of non-null references to nodes, also called hop index, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses, and for each of said nodes, storing a table relating at least one reference to a next hop neighbouring node to that next hop neighbouring node's address. A corresponding wireless data communication system is also provided.

Description

Compressed source routing

Technical field of the invention

The present invention relates generally to the field of communication networks. More specifically, the present invention relates to the field of wireless networks for data communication, more particularly to wireless multi-hop networks forming ad hoc networks. Still more specifically, embodiments of the present invention relate to a data communication system comprising a plurality of nodes organised in a multi-hop network using a data communication protocol stack with low program and data memory footprint, and to a method of communication between nodes in a multi-hop network using such data communication protocol stack. The present invention is particularly useful for all kinds of wireless sensor applications.

Background of the invention

A wireless network is a flexible data communications system, which uses wireless media such as radio frequency technology to transmit and receive data over the air, minimizing the need for wired connections.

Wireless networks use electromagnetic waves such as e.g. radio signals or infrared signals, to communicate information from one point to another without relying on any physical connection. One type of electromagnetic waves, radio waves, is often referred to as radio carriers because they simply perform the function of delivering energy from a local transmitter to a remote receiver. The data being transmitted is superimposed on the electromagnetic wave, in the example given a radio carrier, so that it can be accurately extracted at the receiving end. Once data is superimposed (modulated) onto the radio carrier, the radio signal occupies more than a single frequency, since the frequency or bit rate of the modulating information adds to the carrier. Multiple radio carriers can exist in the same space at the same time without interfering with each other if the radio waves are transmitted on different radio frequencies. To extract data, a radio receiver tunes in one radio frequency while rejecting all other frequencies. The modulated signal thus received is then demodulated and the data is extracted from the signal. Wireless networks are highly desirable communication networks because they do not suffer from the cost and labour of installing cables

(eliminating the need to pull cables through ceilings and walls), and they permit greater flexibility in locating and optionally moving communication equipment (the network can be extended to places that cannot be wired).

One particular field for usage of wireless networks is sensor applications. The requirements of wireless sensor applications are straightforward: network coverage of the sensor environment must be absolute, the installation process should be plug-and-play and the reliability must be extremely high. The multi-hop network concept as shortly explained below, provides an answer to all three challenges.

Multi-hop networks comprise a plurality of nodes organised into a network of wireless connection paths between the nodes. Multi-hopping is a way of routing data, voice and/or instructions between the nodes in the network. It allows for continuous connections and reconfiguration around blocked paths by "hopping" from node to node until a connection can be established.

In a multi-hop network, there is typically one special node, called a network co-ordinator that starts the network. All other nodes connect to the network through this co-ordinator or through another node that was connected to the network before.

In multi-hop wireless networks intermediate nodes act as repeaters and/or routers for other nodes. Hence messages hop from one node to another, thereby bridging longer distances than could be spanned by a single wireless link between two nodes. In order for a first node to be able to repeat/route messages from a second node, the first node is first set in a receiving state. After reception of the message from the second node, the first node is set in a transmitting state, for repeating or routing the message further to a third node, which in turn is set in a receiving state. Multi-hop networking provides an answer to the challenge of network coverage put forward by wireless sensor applications: as nodes are dispersed over a limited location, e.g. a building, and every node is able to communicate to its neighbouring nodes that are within electromagnetic wave reception distance, the full environment is actually enveloped in a cloud of electromagnetic waves, e.g. radio waves. State of the art multi-hop network technology may be self-forming and self-healing. This means that the network will set itself up without manual intervention. New nodes will associate automatically to the network. When a node is removed or a link between any two nodes is disturbed, then the network automatically reconfigures on-the-fly to re-establish reliable communication (self-healing property). This means that the network can still operate even when a node breaks down or a connection goes bad. As a result, a very reliable network is formed. State of the art wireless sensor networks are often powered by a feature-rich multi-hop network communication stack, thus implementing the three main features:

• it is self-forming (for easy installation)

• it is self-healing (for robustness), and • it is multi-hop, meaning that the range of data transmission can be extended by using network nodes as relay stations, so that messages can be transported over larger distances.

To obtain these and other features, quite complex protocols, like the

ZigBee protocol, have been constructed. The ZigBee protocol is a standard for embedded application software that has been ratified in 2004 under IEEE

802.15.4 Wireless Networking Standards. It is an established set of specifications for wireless personal area networking (WPAN), e.g. digital radio connections between computers and related devices. The devices can include telephones, hand-held digital assistants, sensors and controls located within a few meters of each other.

When such complex protocols are implemented in embedded radio modules, they turn out to be demanding quite a lot of program and memory space. As flash ROM and memory is determining quite a large part of the price, price of radio modules running such a wireless communication stack is quite high. For some applications the price of such modules is too high.

Routing data through a network involves two basic activities: determining optimal routing paths and transporting information groups or messages through the network. Routing protocols evaluate what path will be the best for a message to travel through the network. When a message arrives at a node, a first check is performed as to whether the message's final destination is the node itself or not. If not, the node will determine to which next hop it has to send this message and transmit the message. The way to determine the next hop is different for different network protocols. In state of the art protocols, the address for the next hop can be retrieved from a routing table (also called routing cache) stored in the nodes, it can be retrieved from the message itself (this is called source routing), or it can be calculated from the address. When retrieved from the table, a node needs to build and maintain the routing table, which is an operation requiring both a lot of memory and routines to add, delete and lookup entries in the table. Route discovery is done by means of broadcast packets; this is a quite complex algorithm. A routing table is a database on a router, used to store that routers' information on the topology of the network. It is used to direct forwarding by matching destination addresses to the network paths used to reach them. In the simplest model, hop-by-hop routing, each routing table lists, for all reachable destinations, the address of the next device along the path to that destination; the next hop. Assuming that the routing tables are consistent, the simple algorithm of relaying packets to their destination's next hop thus suffices to deliver data anywhere in a network. In case of using a routing table, a message only contains the destination address, and the nodes at each junction in the network determine, based on their routing table, how best to forward the message. Source routing is a way of moving data through a network in which the path is predetermined by the source or some device that tells the source about the path. The path information is placed in the message. When the message arrives at a node, no forwarding decision is necessary. The node looks at the path information in the message to determine the port on which it should forward the message, if it is not itself the final destination. When using prior art source routing, no special routines or maintenance on the node are needed. However, the number of hops which can be involved is greatly limited by the packet length, as complete addresses of the hop nodes need to be included in the message frame, one for each hop. As an example, with a maximum packet length of 100 bytes, of which only 50 bytes can be used for source routing, and when applying 64 bit MAC addresses, the number of hops is limited to 6.

When using routing based on the address, as in the 'Cskip' algorithm in Zigbee, the network operation is bound to a strict network tree structure.

Based on the destination address a routing node can determine whether it has to forward the packet to its parent node, or to one of its children. In other words, a node can determine whether the destination sits in one of its own subtrees or not. The network tree structure cannot easily cope with changes in the medium. And this also needs a very strict association and address assignment procedure.

Summary of the invention

It is an object of the present invention to provide good apparatus or methods implementing data communication between nodes in a multi-hop network, the data communication making use of limited memory.

The above objective is accomplished by a method and device according to the present invention.

In a first aspect, the present invention provides a method of routing communications in a wireless data communication system comprising a plurality of nodes organised into a multi-hop network of connection paths between said nodes, a connection path being provided between a node and a next hop neighbouring node. The method comprises, in a communication to be sent, encoding a compressed route in the form of non-null references to nodes, also called hop index, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses, and for each of said nodes, storing a table relating at least one reference to a next hop neighbouring node to that next hop neighbouring node's address.

By using indices rather than full addresses, less space is needed in the communication data packets to store the route: an index can be represented with far less bits than the complete address, as the number of bits is determined by the amount of next hop neighbouring nodes, which is far less than the number of network nodes which need an address. The number of next hop neighbouring nodes does not need to correspond to the real number of neighbouring nodes, but can be a subset thereof, as a node does not necessarily need to be able to communicate which each neighbouring node, thus optionally reducing the number of bits necessary to represent the neighbouring nodes still further.

In a method according to embodiments of the present invention, the wireless data communication system may comprise a co-ordinator node and a plurality of network nodes, the co-ordinator node being for controlling the plurality of network nodes. In embodiments of the present invention it may be such that every message comes from or goes to the network co-ordinator node.

In a method according to embodiments of the present invention, where communications are routed in a downstream communication direction if they are routed from the coordinator node towards another network node, and communications are routed in an upstream communication direction if they are routed from a network node towards the coordinator node, the compressed route may comprise a communication direction of the message to be sent, and the table may relate at least an upstream communication direction to the physical address of an upstream next hop neighbouring node's address and/or a downstream communication direction to the physical address of a downstream next hop neighbouring node's address. In this case, a 1-bit index is sufficient for determining the route.

In a method according to embodiments of the present invention, a route may be determined by a processor associated with the coordinator node. In this case routes are determined centrally. This does not yield the most efficient or fastest communication, but the most memory efficient communication, with the least use of memory in each of the nodes, both for data storage and for program memory.

In a second aspect, the present invention provides a wireless data communication system comprising a plurality of nodes organised into a multi- hop network of connection paths between said nodes, a connection path being provided between a node and a next hop neighbouring node, each node comprising a memory. The memory stores a routing table relating at least one non-null reference to a next hop neighbouring node to that next neighbouring node's address, the reference having a number of bits smaller than the number of bits necessary to represent the node's address.

In a wireless data communication system according to embodiments of the present invention, one of the nodes may be a coordinator node controlling the plurality of nodes.

In a wireless data communication system according to embodiments of the present invention, a processor may be associated with the coordinator node. The processor may be incorporated into the coordinator node or may be a separate processor linked to the coordinator node. This way, processing power may be taken away from the coordinator node and included into e.g. a PC connected to the node. More processing power may be provided this way, and the node itself is less power consuming.

In embodiments of the present invention, the coordinator node may be adapted to receive information from the processor. The link between the processor and the coordinator node may be a wired link or a wireless link.

In embodiments of the present invention, the reference to a next hop neighbouring node may be one bit and may indicates an upstream or a downstream next hop neighbouring node, an upstream neighbouring node being a neighbouring node in a communication direction towards the coordinator node, and a downstream neighbouring node being a neighbouring node in a communication direction away from the coordinator node.

In embodiments of the present invention, each of the nodes may comprise a processor. In embodiments of the present invention, each of the nodes may comprise a communication interface for communication with the communication interface of another node.

In a wireless data communication system according to embodiments of the present invention, at least some of the nodes may comprise a first mesh networking protocol stack and a second mesh networking protocol stack. The first mesh networking protocol stack may be adapted for data communication with others nodes, and the second mesh networking protocol stack may be adapted for changing parameters in the non-volatile memory of the node. This may be used e.g. for updating the primary memory of the node, e.g. over the air update of program memory. Such over the air update of nodes can be performed on single nodes, without interrupting the overall operation of the main network. Alternatively, this could also be used during installation and commissioning of a network, to exchange e.g. encryption keys.

In embodiments of the present invention, the above double mesh networking protocol stack may be present in a node with or without means for using the compressed route sourcing of embodiments of the present invention. In a third aspect, the present invention provides the use of a wireless data communication system of embodiments of the present invention in sensor applications.

In a fourth aspect, the present invention provides the use of a method of embodiments of the present invention for a multi-hop over the air update of program memory of a node in a wireless communication system according to embodiments of the present invention.

In a fifth aspect, the present invention provides a controller for controlling operation of a node in a wireless multi-hop network. The controller comprises a data reception port for receiving a data packet, the data packet encoding a compressed route for the data packet to hop through the wireless multi-hop network, the compressed route being in the form of non-null references to nodes, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses, an evaluator for evaluating, based on the received data packet, whether the node is a final destination, a data communicator for handing over, if the node is a final destination, the received data packet to the next higher layer, e.g. the application layer, a data look-up means for fetching, if the node is not a final destination, a next hop neighbouring node's address corresponding to the reference to the next hop neighbouring node encoded in the received data packet, and message forwarding means to forward the data packet to a next hop neighbouring node as determined by the reference in the data packet. A controller in accordance with embodiments of the present invention may be an embedded controller which is embedded into the node.

In a further aspect, the present invention provides a computer program product enabling a processor to carry out a method in accordance with embodiments of the present invention. In yet another aspect, the present invention also provides a machine readable data storage device storing the computer program product embodiments of the present invention. In still a further aspect, the present invention provides transmission of the computer program product of embodiments of the present invention over a local or wide area telecommunications network.

In a further aspect, the present invention provides a data packet structure encoding a compressed route for the data packet to hop through a wireless multi-hop network, the compressed route being in the form of non-null references to nodes, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses. In the data packet structure according embodiments of the present invention, the compressed route may be a 1-bit index indicating an upstream or a downstream direction, the upstream direction being a communication direction towards a coordinator node in the wireless multi-hop network, and the downstream direction being a communication direction away from the coordinator node.

In accordance with embodiments of the present invention, a new communication protocol stack has been conceived, with low program and data memory footprint, i.e. low program and data memory requirements. This communication protocol stack can be used on simple modules having small memory modules, but also as a second communication protocol stack which sits on the side in the bootloader section of the program flash memory of more complex systems, containing a primary more sophisticated, hence larger, memory. A multi-hop network of embodiments of the present invention shows one or more of the following characteristics:

- nodes do not keep routing tables, but use 'compressed' routing information in a message to relay to other nodes, - all distributed intelligence is pulled away from the network nodes to the central node, the network coordinator, the command set being limited to the absolute basics, and/or

- communication can be done over different basic network layers, e.g. physical layers (phy's), providing means for transmitting raw bits rather than data packets over a physical data link connecting network nodes; this makes it possible to also use other interface peripherals such as universal asynchronous receiver / transmitter (UART) or serial peripheral interface (SPI), as an alternative to the wireless (RF) receiver / transmitter, so that the intelligence of network set-up and maintenance can be done by a PC program.

Particular and preferred aspects of the invention are set out in the accompanying independent and dependent claims. Features from the dependent claims may be combined with features of the independent claims and with features of other dependent claims as appropriate and not merely as explicitly set out in the claims.

Although there has been constant improvement, change and evolution of devices in this field, the present concepts are believed to represent substantial new and novel improvements, including departures from prior practices, resulting in the provision of more efficient, stable, reliable and cheap devices of this nature.

The above and other characteristics, features and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the invention. This description is given for the sake of example only, without limiting the scope of the invention. The reference figures quoted below refer to the attached drawings.

Brief description of the drawings

Fig. 1A and Fig. 1 B illustrate two types of multi-hop networks. Fig. 2 illustrates a multi-hop network structure according to embodiments of the present invention, in which all nodes are simple radio nodes and the co-ordinator function is performed by a PC. Fig. 3 is a flow chart illustrating the relay procedure in each node, according to embodiments of the present invention.

Fig. 4a and Fig. 4b illustrate embodiments of a data packet structure in accordance with embodiments of the present invention. Fig. 5 illustrates a data packet structure for setting up the content of a destinations table in a node in accordance with embodiments of the present invention.

Fig. 6 is a flow chart illustrating network discovery by the co-ordinator according to embodiments of the present invention. Fig. 7 is a flowchart illustrating an active scan procedure according to embodiments of the present invention.

Fig. 8 is a flowchart illustrating a route establish procedure according to embodiments of the present invention.

Fig. 9 is a flowchart illustrating updating the firmware for a group of nodes according to embodiments of the present invention.

Description of illustrative embodiments

The present invention will be described with respect to particular embodiments and with reference to certain drawings but the invention is not limited thereto but only by the claims. The drawings described are only schematic and are non-limiting. In the drawings, the size of some of the elements may be exaggerated and not drawn on scale for illustrative purposes. The dimensions and the relative dimensions do not correspond to actual reductions to practice of the invention.

Furthermore, the terms first, second, third and the like in the description and in the claims, are used for distinguishing between similar elements and not necessarily for describing a sequence, either temporally, spatially, in ranking or in any other manner. It is to be understood that the terms so used are interchangeable under appropriate circumstances and that the embodiments of the invention described herein are capable of operation in other sequences than described or illustrated herein.

It is to be noticed that the term "comprising", used in the claims, should not be interpreted as being restricted to the means listed thereafter; it does not exclude other elements or steps. It is thus to be interpreted as specifying the presence of the stated features, integers, steps or components as referred to, but does not preclude the presence or addition of one or more other features, integers, steps or components, or groups thereof. Thus, the scope of the expression "a device comprising means A and B" should not be limited to devices consisting only of components A and B. It means that with respect to the present invention, the only relevant components of the device are A and B.

Similarly, it is to be noticed that the term "coupled", also used in the claims, should not be interpreted as being restricted to direct connections only. The terms "coupled" and "connected", along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression "a device A coupled to a device B" should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. "Coupled" may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other. Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

Similarly it should be appreciated that in the description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those in the art.

For example, in the following claims, any of the claimed embodiments can be used in any combination.

Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function.

Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

The following terms are provided solely to aid in the understanding of the invention.

The term "network co-ordinator" shall expressly include, but not be limited to, any communication device, which operates as a central controller in an ad-hoc communication network. The network co-ordinator may be a node in an ad-hoc communication network or a separate controller controlling a node in such network. The term "node" shall expressly include, but not be limited to, any communication device (such as for example a portable communication device or a fixed communicating device, e.g. switches, motion sensors, temperature sensors as employed in a wirelessly enabled sensor network), which participates in an ad-hoc communication network. The term "node" may include the network co-ordinator.

The following abbreviations are used in the description and/or the drawings: APS Application Support Layer CRC Cyclic Redundancy Check FCF Frame control field

FCS Frame check sequence

FFD Full Functionality Device

MAC Medium access control NWK Network

OSI Open Systems Interconnection Basic Reference Model

Phy Physical layer of the OSI model

RFD Reduced Functionality Device RF Radio frequency SPI Serial Peripheral Interface

UART Universal Asynchronous Receiver/Transmitter

The invention will now be described by a detailed description of several embodiments of the invention. It is clear that other embodiments of the invention can be configured according to the knowledge of persons skilled in the art without departing from the true spirit or technical teaching of the invention, the invention being limited only by the terms of the appended claims.

A multi-hop wireless network in accordance with embodiments of the present invention comprises a plurality of nodes organised into or organisable into a wireless network of interconnection paths. Such nodes may form an ad hoc wireless network or a peer-to-peer (P2P) wireless network. In a peer-to- peer wireless topology any device or node can communicate with any other device or node as long as they are in electromagnetic wave transmission range of one another, e.g. in a radio sphere of influence. A connection path is then provided between a node and a next hop neighbouring node within electromagnetic wave transmission range from that node.

Applications such as industrial control and monitoring, e.g. building automatisation, wireless sensor networks, asset, inventory and people tracking, intelligent agriculture, healthcare supervision, e.g. home care and elderly care networks, automotive and safety and security benefit from such a network topology. A peer-to-peer network can be any of ad-hoc, self- organising and self-healing or a combination of these. It may allow multiple hops to route messages from any node to any other node on the network. Nodes in a multi-hop network can be any of three types: a co-ordinator node, a router node or an end node.

- a co-ordinator node 11 , also indicated C in Fig. 1A and Fig. 1 B: This is the most capable device, and always is a full functionality node (FFD), meaning that it can communicate (talk) to other FFDs or to reduced functionality nodes (RFDs) which are resource-constrained. The co-ordinator node forms the root of the network and might bridge to other networks, if available (not illustrated in the drawings). There is exactly one co-ordinator node in each multi-hop network at any moment in time. However, two nodes in a multi-hop network could both be coordinator-capable, where the second node can be used as a backup if the first one fails. In that sense, over time, there may be more than 1 coordinator node. The co-ordinator node 11 is able to store information about the network. Usually the co-ordinator node 11 is powered from a stable power source such as mains power or a large re-chargeable battery, e.g. within an automobile. The co-ordinator node operates as a central controller in the ad- hoc communication network. The co-ordinator node may comprise an internal or an external controller, such as for example a computing device, e.g. PC₁ connected up to the co-ordinator node.

- a router node 12, indicated F in Fig. 1A and L in Fig. 1 B: Router nodes can act as an intermediate node, passing data from one node to another node. Router nodes in accordance with embodiments of the present invention can be RFDs or FFDs. An RFD may comprise just enough functionality to talk to its parent or child nodes. Router nodes F as in Fig. 1A are mains powered, while router nodes L (low-power router nodes) as in Fig. 1 B are usually battery powered.

- an end node 13, indicated R in Fig. 1A: Such end node contains just enough functionality to talk to its parent node (which is either the co-ordinator node C or a router node F which is within electromagnetic wave transmission range from the end node). It cannot relay data from another node to yet another node. It requires the least amount of memory, and therefore can be less expensive to manufacture than a co-ordinator node 11. In embodiments of the presnt invention an end node 13 is an RFD. Usually an end node 13 is battery powered. Embodiments of the present invention may be used for any type of multi-hop network connecting nodes to each other through a wireless network path, such as for example but not limited to radio frequency (RF), infrared wireless area networks, DECT (Digital Enhanced Cordless Telecommunications), WiFi (Wireless Fidelity), IrDA (infrared data communication) or Bluetooth. In particular it may be useful for a multi-hop network in accordance with the IEEE 802.15.4 Wireless Networking Standards. This standard provides specifications for devices that have low data rates, consume very low power and are thus characterised by long battery life.

In a multi-hop network according to embodiments of the present invention, all nodes may be simple radio nodes, as illustrated in Fig. 2. The coordinator function is performed by a controlling machine 20 having abundant resources with regard to memory and processing power, like for example a PC, which is linked, wired or wirelessly, to a root node 21 in the network. In the embodiment illustrated in Fig. 2, the controlling machine 20 is connected via a wired link to the root node 21. According to embodiments of the present invention, all nodes 21 , 22, 23 of the network may be organised in a dynamic tree topology. A dynamic tree organises information in a tree layout, wherein a central root node 21 (the top level of the hierarchy) is connected to one or more other nodes 22 that are one level lower in the hierarchy (i.e. the second level), with a point-to-point link between each of the second level nodes 22 and the top level central root node 21. The second level nodes 22 may be router nodes (as the right hand second level node in Fig. 2) or may be end nodes (as the left hand second level node in Fig. 2). Each of the second level nodes 22 that are connected to the top level central root node 21 may also have one or more other nodes 23 that are one level lower in the hierarchy (i.e. the third level) connected to it, also with point-to-point link. Again the third level nodes 23 may be router nodes or may be end nodes. The top level central root node 21 is the only node that has no other node above it in the hierarchy. The dynamic tree can contain any number of levels, and each level can contain any number of items. Dynamic tree means that the coordinator 20 can change the topology in a very simple way, by just changing routes between nodes.

The present invention is not limited to tree topology; however, in a sensor network, the dataflow automatically organises itself to a dynamic tree, as there is one collector in the system (coordinator node), to which all other nodes in the network send their data. Nevertheless, in accordance with embodiments of the present invention, other topologies such as for example mesh topology are also possible. Mesh topology is the type of network topology in which at least some of the nodes of the network are connected to more than one other node in the network with a point-to-point link. In most practical networks that are based upon the mesh topology, all of the data that is transmitted between nodes in the network takes the shortest path between nodes, except in the case of a failure or break in one of the links, in which case the data takes an alternate path to the destination. This implies that the nodes of the network, or in embodiments of the present invention at least the coordinator node, possess some type of logical 'routing' algorithm to determine the correct path to use at any particular time.

According to embodiments of the present invention, all communication goes from a node 21 , 22, 23 to the coordinator 20 and vice versa - normally no communication between nodes is done. Messages can, however, according to standard networking protocols, be relayed between nodes.

Communication between nodes may be by inband signalling, i.e. a same channel may be used for payload and for control signals, or communication may be by out of band signalling, i.e. a different channel may be used for payload and for control signals. In this latter case, a change channel operation is performed between sending control signals and sending real payload over the network. When a message arrives at a node 21 , 22, 23, a first check is performed as to whether the message's final destination is the node itself or not. If not, the node will determine to which next hop it has to send this message and the message will be transmitted. A multi-hop network in accordance with embodiments of the present invention uses a novel technique of so-called compressed source routing.

This technique comprises encoding, in a message to be sent, a compressed route in the form of non-null references to nodes, e.g. indices to nodes, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses, and for each of the nodes, storing a destination list relating the references of next hop neighbouring nodes to the next hop neighbouring node's addresses.

In this technique, for each node 21 , 22, 23, all possible next hop neighbouring nodes' addresses are abstracted to an index, which can be represented with a minimum number of bits. In its simplest form, a message can be transmitted either 'upstream' or 'downstream', which can be represented by a 1 bit number. Each node 21 , 22, 23 then only needs to store in memory a destination list comprising an indication relating to upstream or downstream data communication direction, and the corresponding full address of its upstream and downstream next hop neighbouring node. When more memory is available, a node can keep a table of 4, 8, ... neighbouring nodes.

One could see this destination list as a routing table, with two distinct exceptions:

- in a prior art routing table, each entry, corresponding to each possible destination which can be reached from a particular node, consists of two addresses: the final destination address and a corresponding next hop address, while in a destination list in accordance with embodiments of the present invention only an index to one or more next hop neighbouring nodes and the corresponding next hop addresses need to be stored, there thus being less entries in the destination list.

- when using a routing table, a search algorithm is needed to retrieve the next hop address, while in accordance with embodiments of the present invention, the index can be used to retrieve the address from the destination list immediately, which mostly is natively supported by most modern microprocessors.

These destination lists can be pre-configured, for a completely static network, or can be filled by the coordinator 20, as is implemented in accordance with embodiments of the present invention and described hereinbelow with regard to Fig. 6.

The general network packet structure encoding a compressed route in the form of non-null references to nodes, e.g. indices to nodes, in accordance with embodiments of the present invention, is given in Fig. 4 and Fig. 4b. In these figures, an example is given for two cases.

The first case is illustrated in Fig. 4a and is the simple case of a 1 bit route index stored in the data packet structure, for example stored in bit 0 of the network frame control field 41 (NWK FCF) of the network packet, together with a destination address being stored in the data packet structure, for example in the destination address field 42. This may be used in case each node in a tree only connects to one upstream node and to one downstream node, except for the root node 21 on level 1 which does not connect to a further upstream node but only connects to a single downstream node 22, and for the nodes 23 on the lowest level of a branch, which do not connect to further downstream nodes, but each connect to an upstream node 22. Each node 21 , 22, 23 just knows its downstream and upstream path relative to the network coordinator 20. In this case, the compressed route is in its most abstracted form, i.e. an indication of whether the route is an upstream or a downstream route. No explicit route is included in the package, i.e. no explicit references to nodes to be hopped through, has been included in the package as there is only 1 possibility.

In the second case represented in Fig. 4b, a 2-bit index is used, meaning that each node has the choice of 4 next hop destinations. The destination list stored in the nodes comprises the two-bit indices and the corresponding destination addresses. The relay procedure in each node 21 , 22, 23 may then be illustrated by a flow chart as in Fig. 3. When a node 21 , 22, 23 receives an incoming message, step 30, the node determines whether the received incoming message is a data packet or a network command (not illustrated in Fig. 3). This is determined from the frame type field 46 in the data packet structure, more particularly, e.g. from bits 1 and 2 thereof. If the received incoming message is a data packet, the node determines from the incoming message whether it is the final destination for that message, step 31. This can be determined from the destination address field 42. If so, the node hands over the data to the next higher layer of that node, step 32. The next higher layer for data packets is the application support layer (APS). The route handling is thus performed on the network layer. If the incoming message is a scan request or a route establish, the packet structure looks the same, except of the packet type, the type being stored in the frame type subfield 44 in the frame type field 46, the frame type then being a network command. In that case, the packet is not handed over to the next higher layer, but handled internally in the network layer. When a data packet message arrives in a node (in case this node is not the final destination) the node first retrieves the communication direction (not illustrated in Fig. 3), i.e. towards or away from the co-ordinator node 21. This communication direction can for example be determined from the direction field 43. If the communication direction is away from the co-ordinator node 21 , the route is included in compressed form in the data package, e.g. in the route field 48. The route is stored in compressed form in the data packet by storing for each hop, in the example given, a two-bit identifier indicating a link or directions to the next hop. By including the route in compressed form in the data packet, less bandwidth is required for sending the messages. The node 22 receiving the data packet retrieves the hop number (not illustrated in Fig. 3), e.g. 3. The determination of the hop number can be done from the hop count subfield 47 in the NWK FCF field. The node then increments the hop count by 1 , step 33, and then retrieves the index corresponding to the incremented hop number (in the particular example given Hoplndex(4)), step 34. The node 22 then retrieves the destination address corresponding to this incremented hop number Destination(Hoplndex(4)) stored in the node itself, step 35, and forwards the packet to the destination address, step 36. Compared to a standard routing table, the information to be stored in a node is much more limited: rather than storing a table for all reachable destinations, a limited table with only indexes to neighbouring nodes and corresponding addresses need to be stored.

According to embodiments of the present invention, in case the communication is towards the co-ordinator node 21 , as indicated by the direction field 43, no compressed route needs to be included in the route field 48. All nodes may store their first hop back towards the co-ordinator node 21. The direction bit 43 thus may act as a kind of shortcut bit, shortcutting the route stored in the route field 48, when communication is to be sent towards the co-ordinator node 21. In that case all traffic can be routed via the coordinator node 21 , so that the local devices 22, 23 do not need to store entire routes but only their path to the co-ordinator node 21.

The frame type 44 in the network frame control field 41 , as indicated above, indicates the purpose of the frame and hence the content of the payload 45. As an example only, the invention not being limited thereto, four frame types may be defined in accordance with embodiments of the present invention:

Data frames are meant to be used for the next higher layer. The two other types are for issuing network commands, dealt with by the network layer - this will be described hereinbelow.

The fields Phy header and MAC header can be anything, e.g. the headers as defined in the IEEE802.15.4 standard, to identify wireless messages intended for communication between nodes, and to distinguish them from other wireless messages which may be received by the nodes. The FCS (forward check sequence, also known as CRC) field is an optional field which may be used for detecting accidental alteration of data during transmission of the messages between nodes. It is worth noting that a destination address Destination(n) in the table relating the index to the next hop neighbouring node can be any unambiguous identification of a node, e.g. the MAC address of a neighboring node, or can indicate that the message needs to be sent to the UART (universal asynchronous receiver/transmitter) of the neighbouring node.

As an extension, if in the destinations table also the channel is stored, one can also select a different channel for each hop. This would be advantageous because it provides local interference avoidance. Instead of having global interference avoidance by setting one single channel for the entire network, this may be done locally, so that different interference source in different parts of the network can be avoided. Furthermore, bandwidth in the network is increased by letting different nodes in each other's neighbourhood operate on different channels without interference or in-the-air collisions of packets. As indicated above, in order to perform routing, each node's destination list needs to be filled. In its simplest from this could be pre-programmed in the node's memory, for example in a non-volatile memory.

To offer more flexibility, a network according to an embodiment of the present invention may implement a command that allows the central coordinator 20 to set up the content of the destination lists of all nodes 21 , 22, 23.

A coordinator 20 can fill an entry in a node's destination list, by sending an 'Establish Route' packet. The packet content is illustrated in Fig. 5. The fields are as also explained with regard to Fig. 4a and Fig. 4b. The packet comprises at least an index field 51 comprising the necessary bits for representing an index and a destination address field 52 comprising e.g. 8 bytes for representing a corresponding destination address. In case the 2-bit indices are used as indicated above, such message is sent four times to a same node, each time with a different value for the index (00, 01 , 10, 11 ) and with a different value for the corresponding destination address.

On receipt of such a packet, a node updates its destinations table with the content of the packet network payload, i.e. it stores the destination address contained in the data packet into the destination list so that it is related to the relevant index.

In order to establish routes in an automatic 'self-forming' way, the network co-ordinator 20 needs to be able to obtain information from the network, in particular, it needs to know a node's neighbours and the quality of the link with those neighbours.

In order to do this, each node 21 , 22, 23 can respond to a so-called 'NetworkDiscovery' request from the network co-ordinator 20. The procedure is similar to an Active Scan in an IEEE802.15.4 system. With this building block, the network co-ordinator 20 can establish a

'map' from the network, by performing a procedure 60 as illustrated by flow chart in Fig. 6. In this procedure, the co-ordinator 20 is assumed to be running on a PC, connected to the first network node 21 via the UART of that first node 21. When co-ordinator 20 starts full network discovery, it clears the 'node list' and adds a first node 21 , connected to its serial port, to a 'new nodes' list, step 61. It then moves the first element in the 'new nodes' list, i.e. first node 21 , to 'nodes' list, and copies it to 'current' list, step 62. A route to the node 21 present in the 'current' list is established, step 63, i.e. a route between the co- ordinator 20 and the first node 21. Then a network discovery to the node 21 in the 'current' list is issued, step 64, i.e. a check is made, step 65, whether further nodes can be reached from node 21. In case of the network illustrated in Fig. 2, two nodes 22 can communicate with node 21. These nodes 22 are both added to the 'new node' list, step 66. The first of nodes 22 is moved to the 'nodes' list and is copied to current, step 62. A route is established between node 21 and the first of nodes 22, step 63. A network discovery to the first of nodes 22 in the 'current' list is issued, step 64, i.e. a check is made, step 65, whether further nodes can be reached from the first of node 22. In the embodiment illustrated in Fig. 22, no further nodes can be reached from the left hand node 22. The second of nodes 22 is moved to the 'nodes' list and is copied to current, step 62. A route is established between node 21 and the second of nodes 22, step 63. A network discovery to the second of nodes 22 in the 'current' list is issued, step 64, i.e. a check is made, step 65, whether further nodes can be reached from the second of nodes 22. In the embodiment illustrated in Fig. 2, three nodes 23 can be reached from the second of nodes 22. The procedure continues as explained above and as illustrated in Fig. 6, up to the point where no nodes appear in the 'new nodes' list, and a full network discovery has been performed.

As a result of the above iterative procedure, the coordinator 20 can start establishing routes and communication. This fulfills the self-forming aspect.

By issuing regular scans on all nodes 21 , 22, 23, the network co-ordinator 20 can keep this information up to date. By establishing new routes from this information, the network co-ordinator 20 can make the network 'self-healing'.

From the command set described above, namely:

- a command for network discovery,

- a command for setting up routes in a node, and - the mechanism of relaying messages a self-forming self-healing multi-hop network can be set up, fitting in a very small program memory footprint. On a typical state of the art 8 bit processor, code size can be something in the area of 4 kbytes. Moreover, different phy layers can be used, depending on what interfaces are available (e.g. RF, UART₁ SPI, ...).

This communication protocol stack can be used for any application, but is mainly intended for a centrally administered application, where data goes either from a node 21 , 22, 23 to the central co-ordinator 20 or back

One particular application is to provide two communication protocol stacks, e.g. to have in a node, in particular in a plurality of nodes or in all the nodes, a low-footprint communication system on the side of a main communication system, in case the main communication system has to be taken off-line. This means that the amount of program memory needed is small, i.e. smaller than twice the amount of program memory needed for storing the information needed for running the node. One very useful example of this, is over-the-air update of a full-blown networking protocol, like for example Zigbee. Updating the embedded firmware of a node 21 , 22, 23 could be done by having at least twice the necessary program memory available, running from one embedded firmware version in the first half of the program memory, whilst updating the second half, and then jump over. However, this is very costly in memory space, and most microcontrollers do not have this facility. Advantageously, state of the art small microcontrollers allow the option of having a bootloader. This bootloader is a simple program that can be executed to update the rest of the program memory. As this bootloader is quite small, a communication protocol stack in accordance with embodiments of the present invention can be used. When two communication protocol stacks are provided according to embodiments of the present invention, the first communication protocol stack may be adapted for data communication with other nodes, i.e. provides the main communication system. The second communication protocol stack may be adapted for changing parameters in the memory, e.g. non-volatile memory, of the node, which memory is used for performing the main communication.

As an example, a bootloader application may be running on top of a communication protocol stack in accordance with embodiments of the present invention. In this application, the 'index' in the compressed source routing may be using only 1 bit, however, the invention is not limited thereto. In the following procedures the master is a computer application running on network co-ordinator 20 and is connected to a node 21 through a serial connection, without intending to limit the invention thereto. In alternative embodiments, in case of the over-the-air updates of network nodes, the coordinator for updating the program of the nodes does not need to be the same device as the network coordinator 21 , meaning that during the update, separate devices can be taken out of the network, while the rest just remains operational. The coordinator may be a 'Programming tool' on a PC.

In the beginning, the network co-ordinator 20 has no information about the nodes in the network. It only knows itself. It has to explore the network to know all the nodes 21 , 22, 23 and their radio area.

The network co-ordinator will start with an active scan to search for nodes in his area. It will broadcast a scan request on every available channel. The nodes 21 , 22, 23 that receive the scan message will respond to the network co-ordinator with a scan response. The scan requests on the different channels are not sent immediately after each other but with a pre-determined amount of time between them. This way, the nodes 21 , 22, 23 have time to respond to the scan message and the network co-ordinator 20 knows which node 21 , 22, 23 is listening on which channel.

In the case assumed here, the network co-ordinator 20 will only send a scan message on the serial connection and will get a response from the connected node 21.

The master will select one of the nodes (= the scan node 21 ) found, step 71 , and will set up a route to that node 21 , step 72. This is done by sending a route establish request to the node 21 , step 73. The network coordinator is the node's parent and there is no child. The child address is the broadcast address. The child channel is the channel on which the first active scan is sent. The scan node 21 will reply with a route establish response to confirm the route establish request, step 74.

The network co-ordinator 20 can now send an active scan request along the route, step 75. The scan node broadcasts the active scan on the channel configured with the route establish request. The nodes around the scan node that listen on that channel receive the message and respond with an active scan response to the master, step 76.

To send a scan request on another channel, the network co-ordinator 20 needs to change the channel, step 77, and to send a new route establish request to the scan node with the new channel as child channel, step 73. After the route establish response by the scan node, step 74, the network coordinator 20 can send a new active scan request, step 75, to discover the nodes that are listening on the new channel. This sequence is repeated for every channel.

If no route establish response by the scan node is received, step 78, a new try is performed. After a predetermined number of tries (in the example illustrated 3), an active scan failure message is generated. After performing the above active scan procedure, the network coordinator 20 knows all the nodes 22, 23 that can communicate with the scan node 21 and the channel they listen on.

The network co-ordinator 20 can now select a new scan node, step 71 , and perform an active scan on every channel through this node. This is repeated until every node has been a scan node and the network co-ordinator

20 has revealed the whole network. Fig. 7 displays the flowchart of the active scan procedure.

Fig. 8 displays the flowchart of an example of a route establish procedure. In a first step 801 , an end node 23 is selected. The best route to that selected end node 23 is calculated, step 802, and then this route is established. First the system is initialised, step 809: node is set to the first node in the root, parent is set to the master, child is set to the next node and retry is set to 3. A test is carried out, to see whether node is the broadcast address, step 110. If so, the route is established, step 808. If not, a test is performed to see whether node is the end node, step 811. If so, the route is set so that as child node the broadcast address is used, step 812. A route establish request is sent to the first node 21 , with as parent the network coordinator and as child node 22 (see Fig. 2), step 803. When a route establish response has been received from first node 21 , step 804, the part of the route between the network co-ordinator and the first node has been established, step 805. As the node is not the selected end-node, further parts of the route need to be established. A route establish request is sent to a next node, in particular for the embodiment illustrated in Fig. 2 node 22, with as parent node 21 and as child node 23, step 803. If no route establish response is received from the second node 22 after a pre-determined amount of time, step 805, the route establish request is again sent to node 22. If this has happened a predetermined amount of times, block 806, the link between the parent node and the node itself, in the example considered the link between node 21 and node 22 is removed, step 807, after which another best route to the end node is calculated 802, and the routes are re-established for this second best route. On the other hand, if a route can be established between nodes 21 and 22, step 804, and the node 22 is not the end node, the procedure continues. If tne node is the end node, the route is established, step 808. Other examples of the route establish procedure, slightly differing from the above example, may also be used.

As an alternative, when all the network information is already available from somewhere else, it is possible to feed this information to the network co-ordinator 20. In this case the exploring of the network procedure as illustrated by the flow chart of Fig. 8 can be skipped.

Fig. 9 shows a flowchart of an embodiment of a firmware update process for a group of nodes. The group of nodes 21 , 22, 23 of which the firmware is to be updated is first selected, step 900.

Before the network co-ordinator 20 can update the firmware of a node 21 , 22, 23, it has to establish a route to the nodes 21 , 22, 23, step 901. After exploring the network the network co-ordinator 20 can calculate the best route to a node 21 , 22, 23 and establish this route. Once this is done, the aliveness of the nodes 21 , 22, 23 may be queried, as indicated by block 990 in the flowchart. If aliveness is queried, the system is a guarded system, also called a watched system. Querying of aliveness may be done by means of a message which requires a mandatory response. Such message may be any signal which does not disturb the normal communication operation of the nodes in the network. It may be a signal sent on the communication channel of the normal network operation, or on another channel. Nodes which are not alive or do not respond to the message requiring a mandatory response are marked as bad and are removed from the group, step 925. One embodiment of such alive querying is illustrated in more detail in the flow chart of Fig. 9. This embodiment is for an implementation with firmware update on a channel different from the communication channel used for normal network operation. After establishing the route, the network coordinator 20, in this embodiment, sends a change channel request to a node (step 920). A channel change is not really necessary, but it is a nice feature so that the actual firmware update is done on a different channel than the normal network operation. This means that specific network nodes can be updated on a different channel, without disturbing the operation of the main communication protocol stack. If a change channel response is received from the node, step 921 , the same is done for the next node, up to when all nodes have been queried, block 922. If no change channel response is received after a predetermined time, block 923, a change channel request is again sent to the node, step 920. If no change channel response is received after a predetermined number of tries, block 924, in the example given 3 times, the route is marked as being bad, and the node is removed from the group, step 925. The change channel request is sent to each of the nodes.

After establishing the route, and optionally after aliveness querying, the nodes may be woken op to start the firmware broadcasting, see block 991 in the flow chart. The network co-ordinator 20 will send a start request to a node, step 902. The node prepares itself for receiving and flashing the firmware and sends a start response to the network co-ordinator 20, step 903. If the network co-ordinator 20 does not receive the start response from the node after a pre- determined amount of time, a new try is performed, block 930. After a predetermined amount or retries, block 931 , in the example given three retries, when still no start response is received, the route is marked as bad and the node is removed from the group, step 932. The start request is sent to each of the nodes, step 931. The network co-ordinator 20 divides the firmware in different parts and sends them to the nodes 21 , 22, 23, step 904. The nodes 21 , 22, 23 receive the parts and flash them to the right place in the flash memory.

The firmware data messages are sent with some time between them because the receiving node 21 , 22, 23 needs some time to store the data of a message in flash memory.

When the last part is sent, a validation determination procedure may be started, block 992. One example of such validation determination procedure is illustrated in Fig. 9 and described hereinafter. The network co-ordinator 20 sends a stop request to a node, step 905. If no stop response from the node is received within a pre-determined amount of time, block 940, a new stop request is sent to the node, step 905. If a new stop request has been sent a pre-determined amount of times, block 941 , and still no stop request response has been received by the co-ordinator 20, the route is marked as bad, and the node is removed from the group, step 942. But if all communication runs good, then upon reception of the stop response message, the node checks the validity of the code and sends a stop response with the result of the check, step 906. If the code is not valid, step 907, the firmware update for this node failed, step 908, and the network co-ordinator 20 keeps track of this fact, for example by noting it in a list. Thereafter, the procedure may be performed for a next node, step 910. If the code is valid, step 907, the firmware update for this node succeeded, step 909, and the procedure may be performed for a next node, step 910, up till the procedure has been performed for all nodes, step 911. Once the procedure has been performed for all nodes, step 911 , a check is performed, step 913, whether the firmware update for all nodes has been successful. If so, the procedure is terminated, step 912. If not, at least all failed nodes, and optionally all nodes, need to be flashed again, step 904, after which the validation determination procedure 992 is started all over again.

When a group of nodes needs the same firmware update and can be reached from another node, they can be updated together by sending a same data packet to all those nodes from the single node. In this case, the network co-ordinator 20 sets up a route to a node which reaches the other nodes. Then the network co-ordinator 20 sends change channel requests for every node of the group so that they are on the same channel.

It is to be noted that there is no route establish to any nodes of the group. The change channel request for a specific node is sent along the route and is broadcast by the last node in the route. Every node nearby receives this message, but only the node that is specified as end point in the change channel request will act on the request by changing its channel and responding with a change channel respond.

The next step is sending the start request to every node of the group. This will happen in the same way as the change channel request. The nodes of the group will respond with a start response message.

Now the nodes are ready to receive the new firmware. The network co-ordinator 20 will send the firmware with the firmware data messages. The messages contain the broadcast address as network endpoint and are broadcasted by the last node of the route. The messages are received by all the nodes nearby the broadcasting node, but will only be used by the nodes that have received the start request.

After all the firmware parts are sent, the network co-ordinator 20 will send a stop request to each node of the group. The nodes will respond with a stop response which finishes the update process.

If the update procedure of a node fails, then the node may be flashed together with another group.

Optionally, an optimization may be provided by adding an additional message that will give the command to a node to broadcast its own firmware to another node. This is advantageous for speed of transmission: [o]in this case, the new firmware only needs to be transmitted to a single node in a group of nodes in a multi-hop way; all the other nodes in the neighbourhood of that single node get their firmware not only in single hop, but also all at the same time, rather than 'unicast' to these nodes one by one.

Other embodiments and implementations of the above algorithms can be envisaged under the present invention, as defined by the claims.

When all updates are done, all the nodes have to switch to the main application. Switching the nodes will happen from the outside of the network to the inside.

First a route to the outside of the network is created. This route is used to send the switch application request to the nodes nearby the last node of the route. The nodes respond with the application switch response and start the main application. The start of the main application is performed by clearing the stay in bootloader bit and resetting the node with a watchdog. The bootloader startup part will then start the main application.

When the firmware of a node is not valid, the node does not switch to the application and reports this with an application switch response. The master will update the firmware of the node so that its firmware will be valid and the node can be switched to the main application.

Now another route can be made to switch another group at the outside of the network. This is repeated until all nodes are switched. When a node is switched tot the main application, the network co-ordinator 20 needs to be sure that by doing this, no other node gets isolated.

It is to be understood that although preferred embodiments, specific constructions and configurations, have been discussed herein for devices according to the present invention, various changes or modifications in form and detail may be made without departing from the scope of this invention as defined by the appended claims. For example, functionality may be added or deleted from the flow charts and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

Claims

1.- A method of routing communications in a wireless data communication system comprising a plurality of nodes organised into a multi-hop network of connection paths between said nodes, a connection path being provided between a node and a next hop neighbouring node, the method comprising: in a communication to be sent, encoding a compressed route in the form of non-null references to nodes, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses, and for each of said nodes, storing a table relating at least one reference to a next hop neighbouring node to that next hop neighbouring node's address.

2.- A method according to claim 1 , the wireless data communication system comprising a coordinator node and a plurality of network nodes, the coordinator node controlling the plurality of network nodes.

3.- A method according to claim 2, communications being routed in a downstream communication direction if they are routed from the coordinator node towards another network node, and communications being routed in an upstream communication direction if they are routed from a network node towards the coordinator node, wherein the compressed route comprises a communication direction of the message to be sent, the table relating at least an upstream communication direction to the physical address of an upstream next hop neighbouring node's address or a downstream communication direction to the physical address of a downstream next hop neighbouring node's address.

4.- A method according to any of claims 2 or 3, wherein a route is determined by a processor associated with the coordinator node.

5.- A wireless data communication system comprising a plurality of nodes organised into a multi-hop network of connection paths between said nodes, a connection path being provided between a node and a next hop neighbouring node, each node comprising a memory, wherein said memory stores a routing table relating at least one non-null reference to a next hop neighbouring node to that next neighbouring node's address, the reference having a number of bits smaller than the number of bits necessary to represent the node's address.

6.- A wireless data communication system according to claim 5, wherein one of the nodes is a coordinator node controlling the plurality of nodes.

7.- A wireless data communication system according to claim 6, wherein a processor is associated with the coordinator node.

8.- A wireless data communication system according to claim 7, wherein the processor is incorporated into the coordinator node.

9.- A wireless data communication system according to claim 7, wherein the processor is a separate processor linked to the coordinator node.

10.- A wireless data communication system according to claim 9, wherein the coordinator node is adapted to receive information from the processor.

11.- A wireless data communication system according to any of claims 9 or 10, wherein the link between the processor and the coordinator node is a wired link.

12.- A wireless data communication system according to any of claims 9 or 10, wherein the link between the processor and the coordinator node is a wireless link.

13.- A wireless data communication system according to any of claims 6 to 12, wherein the reference to a next hop neighbouring node is one bit and indicates an upstream or a downstream next hop neighbouring node, an upstream neighbouring node being a neighbouring node in a communication direction towards the coordinator node, and a downstream neighbouring node being a neighbouring node in a communication direction away from the coordinator node.

14.- A wireless data communication system according to any of claims 5 to 13, wherein each of the nodes comprises a processor.

15.- A wireless data communication system according to any of claims 5 to 14, wherein each of the nodes comprises a communication interface for communication with the communication interface of another node.

16.- A wireless data communication system according to any of claims 5 to

15, wherein at least some of the nodes comprise a first mesh networking protocol stack and a second mesh networking protocol stack, the first mesh networking protocol stack being adapted for data communication with others nodes, and the second mesh networking protocol stack being adapted for changing parameters in the memory of the node.

17.- Use of a wireless data communication system as in any of claims 5 to 16 in sensor applications.

18.- Use of a method as in any of claims 1 to 4 for a multi-hop over the air update of program memory of a node in a wireless communication system as in any of claims 5 to 16.

19.- A controller for controlling operation of a node in a wireless multi-hop network, the controller comprising: a data reception port for receiving a data packet, the data packet encoding a compressed route for the data packet to hop through the wireless multi-hop network, the compressed route being in the form of non-null references to nodes, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses, an evaluator for evaluating, based on the received data packet, whether the node is a final destination, a data communicator for handing over, if the node is a final destination, the received data packet to the next higher layer a data look-up means for fetching, if the node is not a final destination, a next hop neighbouring node's address corresponding to the reference to the next hop neighbouring node encoded in the received data packet, and message forwarding means to forward the data packet to a next hop neighbouring node as determined by the reference in the data packet.

20.- A controller in accordance with claim 19, wherein the controller is an embedded controller which is embedded into the node.

21.- A computer program product enabling a processor to carry out a method as described in any of claims 1 to 4.

22.- A machine readable data storage device storing the computer program product of claim 21.

23.- Transmission of the computer program product of claim 21 over a local or wide area telecommunications network.

24.- Data packet structure encoding a compressed route for the data packet to hop through a wireless multi-hop network, the compressed route being in the form of non-null references to nodes, the references having a number of bits smaller than the number of bits necessary to represent the nodes' addresses.

25.- Data packet structure according to claim 24, wherein the compressed route is a 1-bit index indicating an upstream or a downstream direction, the upstream direction being a communication direction towards a coordinator node in the wireless multi-hop network, and the downstream direction being a communication direction away from the coordinator node.