WO2011131688A1

WO2011131688A1 - A path selection method for a network

Info

Publication number: WO2011131688A1
Application number: PCT/EP2011/056265
Authority: WO
Inventors: Torsten Meyer; Michael Bahr
Original assignee: Siemens Aktiengesellschaft
Priority date: 2010-04-19
Filing date: 2011-04-19
Publication date: 2011-10-27

Abstract

The invention proposes an efficient solution for Quality of Service flow handling by using a combination of proactive tree-based and reactive mesh-based path selection protocols thereby benefitting of each mode to overcome the drawbacks of each path selection protocol. By applying the inventive method an initial latency is avoidable and a usage of optimal intra-mesh paths between mesh nodes is possible.

Description

A PATH SELECTION METHOD FOR A NETWORK The invention relates to a path selection method for networks, particularly wireless mesh networks.

Path selection protocols, also referred to as routing proto^¬ cols, are known in the art. A path selection protocol for wireless mesh networks named HWMP (»Hybrid Wireless Mesh Pro^¬ tocol^ is described in a draft amendment to standard IEEE 802.11: Mesh Networking, IEEE P802. lls/D3.05 Std., November 2009. The protocol HWMP provides separate mechanisms for a pro^¬ active tree-based path selection towards a gateway and a re^¬ active path selection between mesh nodes.

The reactive path selection is operated to find optimal paths with respect to delay or other Quality of Service (QoS) cri^¬ teria. However, this selection imposes an initial latency on the path discovery process. On the other hand, the proactive tree-based path selection provides a path even to the other mesh nodes without initial latency, but the data frames have to pass through the gateway, which is not efficient with re^¬ spect to delay and is very likely to lead to congestion around the gateway.

Earlier draft versions of the standard IEEE 802.11s, in par- ticular a draft amendment to standard IEEE 802.11: Mesh Net^¬ working, IEEE P802. lls/DO .01 Std., March 2006, clauses

11A.4.3.1.1/3/7, define a specific mode called »Hybrid Rout- ing« . In this approach of hybrid routing, a source mesh node forwards all data frames, for which no path to the destination is known by the source node, to the root of the proactive tree. The root mesh node is set as the mesh destination in the data frame and no intermediate mesh node, even if it has knowledge of a path to the destination, will forward the data frame to the final destination.

The root mesh node, that knows a path to the destination due to the proactive tree path selection, will than send the data frame to the destination. If the destination is inside the mesh, the destination mesh node will start a reactive path discovery towards the source mesh node, so that later on, an optimal path between source and destination exists.

Until then, all data frames are forwarded through the root mesh node. This approach is not able to consider Quality of Service requirements in the path discovery.

It is an object of the present invention is to provide a path selection method for a network, by which an initial latency in the forwarding of packets is avoidable.

According to the present invention there is provided a method for selecting a path in a network comprising a plurality of nodes, wherein the path to be selected is established between an originator node and a target node, wherein a proactively built tree path is established in the network by which a node is able to determine a consecutive node along the tree path, wherein a data packet exchanged by nodes include a destina^¬ tion address and a flow identification number, and, wherein a data packet arriving at a forwarding node and having a re- served flow identification number, particularly zero, is forwarded to the consecutive node along the tree path or to a next hop node assigned to the reserved flow identification number and an address of the destination node. The method in^¬ cludes the steps of:

a) determining a flow identification number by the source node, for the case that a lookup for a forwarding information assigned to said determined flow identification number is not successful, establishing a path discovery by the source node, and,

forwarding data packets featuring the flow identifica^¬ tion number determined by the source node along the pro- actively built tree path by altering the flow identifi^¬ cation number of the data packet to the reserved flow identification number and forwarding the packets along the tree-path as long as the lookup for the forwarding information assigned to said deter-mined flow identifi^¬ cation number is not successful.

The general idea of the present invention is to overcome the initial latency of a reactive path selection by a combination of a tree-based proactive path selection and mesh-based reac^¬ tive path selection including concepts of a flow based path selection . A basic concept according to the invention is the usage of a flow identification number evaluated to forward a data packet. Generally, a data packet having a reserved flow iden^¬ tification number is forwarded by a forwarding node to a consecutive node along a tree path. This tree path structure is proactively built in the network. Considering this tree path, a node is able to determine a consecutive node along the tree path in the direction to the destination.

Hereinafter the reserved flow identification number is as- sumed to have a value of zero without assuming any restric^¬ tion. Of course the value for the reserved flow identifica^¬ tion number can have any value as long as this value is used consistently in the sense of a reserved flow identification number .

Although this path in the direction to the destination along the tree path might not represent an optimal path, yet, it is a sub-optimal basis for a route which is able to be replaced by a later route determined by a discovery process, i.e. a reactive path selection. One particular advantage of the invention is an avoidance of initial latency. This is achieved by the inventive prerequi^¬ site that the forwarding of data packets, for which no for^¬ warding information assigned to a flow identification have been determined yet, is not stalled until the path discovery process has concluded. Instead, the flow identification of such packets is altered to zero, which has the consequence that these data packets when arriving at a forwarding node are immediately forwarded to the consecutive node along the tree path or to the next hop node for the flow identification zero and destination address. In other words, a tree-based proactive path selection for instantaneous forwarding is ap^¬ plied in the initial tree path usage phase to avoid the la^¬ tency time of reactive on-demand path selection protocol. As already mentioned the initial forwarding of data packets is not stalled until the path discovery process has con^¬ cluded. In particular, this means - with respect to the in^¬ vention as outlined in claim 1 - that the establishment of a path discovery by the source node according to step b) and the forwarding of data packets by altering the flow identifi^¬ cation number of the data packet to zero according to step c) are not to be understood as chronological consecutive steps. As a matter of fact, steps b) and c) substantially start in parallel .

Due to the difficulties of estimating and providing the right Quality of Service reservations for a flow identification number of zero on the tree path, the invention is especially useful for Quality of Service flows that tolerate a lower quality of service at the beginning of the flow. In any case, any flow, with or without Quality of Service requirements, will benefit from the invention due to an earlier transmis- sion of the first data packets. These flows have to suffice with whatever the path tree offers. This may be just best ef^¬ fort, some priority for the data packets, or some preassigned QoS reservation that is dimensioned in such a way, that it covers a significant subset of the flows using phase 1 (Ini^¬ tial Tree Path Usage) .

A further advantage of the invention arises from a usage of flow identification numbers which allows an implementation of a Quality of Service (QoS) concept. In particular, a path se^¬ lection based on flow identification numbers may be used in order to assign different paths to flows with different Qual^¬ ity of Service requirements. Advantageously, since the source node is the only node that is aware of the Quality of Service requirements without any additional signaling, QoS paths are established from the source node.

In this way, the invention extends the combination of a pro^¬ active tree-based path and a mesh-based reactive path selec- tion with procedures to flow based path selection which allow a Quality of Service path selection and setting up of

uni-directional paths.

Furthermore, the invention allows an establishment of indi- vidual Quality of Service paths for different flows, even be^¬ tween the same source and destination. The Quality of Service flow reservation is preferably unidirectional from the source to the destination node, which leads to saving of bandwidth compared to bidirectional Quality of Service reservation.

Preferred embodiments of the invention are set out in depend^¬ ent claims.

According to an embodiment of the invention, a storage of a transmitter address of a path request in the form of a pre^¬ cursor address is provided. This makes it possible to utilize the precursor address as next hop address in the propagation process of control messages such as path reply message and path error message to the originator without the need of set^¬ ting up a reverse path to the originator. According to a further embodiment of the invention a path is established by checking whether Quality of Service (Qos) re^¬ quirements are fulfilled along the path. Advantageously, QoS paths are unidirectionally established from the source node. This results in a saving of resources of bandwidth in the re- verse direction.

According to a further embodiment of the invention, subsequent to a conclusion of the process of path establishment, packets are immediately forwarded according to their specific flow identification along discovered paths in an optimal path usage phase.

According to a further embodiment of the invention, Quality of Service reservations are only allocated in the direction from the source to the destination node. This advantageously implies savings in terms of Quality of Service resources which otherwise had to be allocated along the reverse path towards the source node. These and other objects and advantages of the present inven^¬ tion will become more apparent and readily appreciated from the following description of the preferred embodiments, taken in conjunction with the accompanying drawing of which: Fig. 1 shows an exemplary embodiment of a network struc^¬ ture to illustrate an exemplary embodiment of the proposed method; and;

Fig. 2 shows the exemplary embodiment of the network

structure along with forwarding information recorded for some nodes of the network to further il- lustrate an exemplary embodiment of the proposed method .

The technical terms »frame« and »packet« as used herein are to be understood as substantially synonymous, both terms meaning a segmented organization of data substantially con^¬ sisting of a payload part and a header part. On a higher level of differentiation, the term »packet« may denote a unit of data passed across an interface between the internet layer and the link layer according to the OSI (Open Systems

Interconnection) layer model. Accordingly, the term »frame« may denote a unit of transmission in a link layer protocol, which consists of a link-layer header followed by a packet. However, this differentiation is not applied herein. Thus, each term »frame« or »packet« as used herein includes both, packets and frames.

In the following section some keywords hereinafter used are defined .

An originator is a node that initiates a path discovery. Note that an originator could also be the source or the destina^¬ tion of a data communication. A target is a node to which the originator attempts to estab^¬ lish a path. Note that a target could also be the source or the destination of a data communication.

An intermediate is a node that participates in the path se- lection and is neither path originator nor path target.

A flow is a directed stream of data packets from the source to the destination that belongs to a specific application. A flow uses an ordered accumulation of intermediate nodes de- scribing the path from the source (usually the originator) to the destination (usually the target) . A FlowID or flow identification is a network-wide unique identifier for a specific flow. It can be, for instance, a hash value which is calculated at the originator node. For instance, input values for the hash calculation can be source IP address, destination IP address, protocol, source port and destination port.

A precursor is a neighbor node which identifies a given node as the next hop for a specific FlowID.

Lifetime is the time during which forwarding information remains available.

The following section defines a message format explained by data structures. Data structures of path selection messages and tables have a format which hereinafter is described in an Extended Backus-Naur Form (EBNF) . The description of the data structures will be limited to information necessary to ex^¬ plain the invention and embodiments thereof. Additional in- formation might be contained in real-life implementations.

Data structure of Packets

In the data structure of packets, PREQ denotes a Path Request control packet and PREP denotes a Path Reply control packet.

Data structure of forwarding information <fw-information> ::= {fw-entry}

<fw-entry> ::= <flowID> <destAddr> <nextHopAddr> <precur- sorAddr> <lifetime> Reference will now be made in detail to the preferred embodi^¬ ments of the present invention, examples of which are illus^¬ trated in the accompanying drawing, wherein like reference signs refer to like elements throughout. Figure 1 shows a wireless mesh network NET. The wireless mesh network NET consists of nodes, particularly wireless mesh nodes, providing a distributed network NET. The particular wireless mesh nodes are represented by a circle with a nu^¬ meral of 0...10 inside the circle. The numeral corresponds to a simplified address of the respective node.

As part of the network NET a gateway GW is shown as a node having an address of 0 (zero) . Further, a source SRC is shown as a node having an address of 7 (seven) . Finally, a destina- tion DST is shown as a node having an address of 4 (four) .

All other nodes having an address 1...3, 5...6 and 8...10 act as intermediate nodes. In the following, these nodes 1...3, 5...6, 8...10 are referenced by their address.

The network structure is built by a proactively established tree in which the gateway GW acts as a root of the network NET and furthermore may possibly feature a transition point to other - not shown - networks. The branches or connec- tions of this tree are depicted by a respective dotted line interconnecting the nodes.

Additionally, each node in the network NET has knowledge about a »next hop« information of connected nodes in its lo- cal sub-tree. For instance, node 1 knows the tree-based next hop information for nodes 3, 4, 7, 8 and 9 addresses of the nodes of its local sub-tree. In this exemplary embodiment, node 7 is the originator and node 4 is the target in the path discovery phase. Therefore, a path from node 7 to node 4 should be found.

In known wireless mesh networks, most of the data traffic is passed towards the gateway, which is connected to external networks like the internet. In addition, data traffic between the mesh nodes of the mesh network is generated. Mesh nodes have to discover the best path to the destination node in or^¬ der to transmit data packets quickly and efficiently. This aspect becomes more important especially when data traffic has to satisfy specific Quality of Service requirements. In the following an exemplary embodiment of the invention is described whereby an exemplary process is consisting of four phases :

Phase 1: Initial Tree Path Usage, Instantaneous Data Com- munication

Phase 2: Path Discovery and Establishment

Phase 3: Optimal Path Usage, Efficient Data Communication Phase 4 : Path Maintenance The proposed process starts with a first phase. In this phase, a method according to the invention is used which im^¬ plies an instantaneous data communication along with a usage of an initial tree path. According to the invention, a specific flow identification number, hereinafter referred to as »FlowID«, is calculated at the source node which uniquely identifies the data communica^¬ tion between source node and destination node. Data packets which belong to this specific flow are recognized by the same FlowID. In general, if a node receives a data packet then it makes a lookup for the incoming FlowID in its forwarding in^¬ formation to determine how to forward this data packet. However, at the time of the very first data packet of a flow, the lookup in the forwarding information of the source node is not successful because currently no forwarding information for this specific FlowID is available. Consequently, the source node triggers a path discovery for the destination node with this specific FlowID. This path discovery process is further described in the consecutive second phase. As long as the source node has not discovered an appropriate path for this specific FlowID, data packets are forwarded through a proactively built tree, for instance, built with the Proactive PREQ mode with Proactive PREP of HWMP described in draft amendment to standard IEEE 802.11: Mesh Networking, IEEE P802. lls/D3.05 Std., November 2009. Each node in the tree knows all its child nodes of its sub-tree with the cor^¬ responding next hop information.

In general, data packets, which are forwarded through the tree, have a reserved FlowID. Hereinafter this reserved flow identification number is assumed to have a value of zero without assuming any restriction. Hence, the source node changes the specific FlowID of the arriving data packets to FlowID 0 if it recognizes that currently no forwarding infor- mation for this specific FlowID is available. The combination of FlowID 0 and the destination address makes it possible that the data communication immediately starts without any considerable latency from the source to the destination node using the proactively built tree rooted at the root mesh node.

Within phase 1, the tree paths with FlowID 0 will be used by many paths with different Quality of Service requirements. The root node of the path tree, however, does not have any knowledge of the Quality of Service requirements of the flows that will use the path tree during phase 1 (Initial Tree Path Usage) . These flows have to suffice with whatever the path tree offers. This may be just best effort;

- some priority for the data packets; or;

some pre-assigned Quality of Service reservation that is dimensioned in such a way, that it covers a significant subset of the flows using phase 1 (Initial Tree Path Us^¬ age) .

This may result in the situation that the transport of data packets cannot accomplish the required Quality of Service during this phase 1. However, this is an acceptable compro^¬ mise for the immediate transmission of the data packets in order to avoid the initial latency that comes with the reac^¬ tive path discovery of the optimal path.

According to the proposed process a second phase is subse^¬ quently scheduled which optionally runs in parallel to the first phase. In this phase according to a further exemplary embodiment of the invention, a method is used which implies a path discovery and a path establishment.

The path discovery phase is performed in a similar way as al- ready known from reactive ad hoc path selection protocols like HWMP, see Draft amendment to standard IEEE 802.11: Mesh Networking, IEEE P802. lls/D3.05 Std., November 2009.

The path discovery starts from the originator, which wants to find and setup a unidirectional path to the target fulfilling certain Quality of Service requirements that are known at the originator. The originator broadcasts a Path Request (PREQ) control packet. The PREQ contains - among other fields - the FlowID for which a path from the originator to the target should be established and the Quality of Service require^¬ ments . The neighbors of the originator receive this PREQ and check if they are the requested target. If a current PREQ receiver node is not the target - which means this current receiver node is an intermediate node - and the Quality of Service requirements are fulfilled, this current receiver node adds the following records to the forwarding information for the target : the FlowID »flowID« of the PREQ as Flow ID »flowID«

- the Target »targetAddr« as Destination »destAddr«

the transmitter of the PREQ as the precursor address »precursorAddr«

Note that said FlowID, target address and/or precursor ad- dress can either be recorded in the actual forwarding information or in a separate data structure. In any case, it must not be forgotten that this forwarding information is still incomplete because the next hop to the destination is still missing .

After that, the intermediate node rebroadcasts the PREQ to its neighbors. In this way, the PREQ is rebroadcast until it reaches the target. If the receiver of the PREQ is the target, it sends a Path Reply (PREP) message including the FlowID as a unicast mes^¬ sage back to the originator using the transmitter of the received PREQ as the next hop. This node receives the PREP and checks if it is the desired destination (in this case the originator) . If the PREP receiver is an intermediate node, this intermediate node updates the entry in its forwarding information for the FlowID »flowID« and the destination »tar- getAddr« received in the PREP. The transmitter of the PREP is recorded as the next hop »nextHopAddr« .

After that, the intermediate node sends the PREP as a unicast message to its recorded transmitter of the former received PREQ for this specific FlowID which is the precursor on the path for the FlowID and the target and is contained in the field »precursorAddr« of the entry in the forwarding information. In this way, the PREP is forwarded until it reaches the originator. If the receiver of the PREP is the originator, said originator extracts the FlowID and updates its forward^¬ ing information using the transmitter of the PREP as the next hop in the same way as the intermediate nodes. At this point, the path for this specific FlowID is established from the originator to the target.

Note that this procedure sets up a uni-directional path only whereby the path is set up from the originator to the desti^¬ nation, because the PREQs do not create any forwarding infor- mation towards the originator. Instead, incomplete forwarding information to the target is stored which contains the neces^¬ sary information, namely precursor address, for propagating the PREP packet back to the originator. Note that unanswered and incomplete forwarding information for a specific FlowID at nodes is deleted after its lifetime has expired.

According to an alternative embodiment it is also possible to discover bi-directional paths that are flow-based and fulfill the given Quality of Service requirements. According to this embodiment, the PREQs set up the reverse path from the target to the originator. The reverse path is than used to forward the PREPs to the originator. The following details have to be considered if the process is used for setting up

bi-directional flow-based Quality of Service paths:

The flowIDs for the forward path (originator to target) and the reverse path (target to originator) have to be different, because network wide unique flow IDs are as^¬ sumed . The PREP will be only propagated by intermediate nodes, if the path fulfills the Quality of Service requirements. The already setup reverse path will time out after the life^¬ time of its entry in the forwarding information expired.

In an alternative embodiment the Quality of Service require^¬ ments are empty, which means there are no such Quality of Service requirements. Further on, Quality of Service require^¬ ments can be equally established for all directions or dif- ferently established for each direction.

As to the former case in which Quality of Service require^¬ ments are equally established for all directions, the Quality of Service requirements specifically are established for the forward path from originator to target in the case that a uni-directional path is to be set up, or, for both the for^¬ ward and the reverse path if a bi-directional path is to be set up. As to the latter case in which Quality of Service require^¬ ments are differently established for each direction, the es^¬ tablishment of Quality of Service requirements is only possi^¬ ble if a bi-directional path is to be set up. If no Quality of Service requirements have to be fulfilled, any other (non-QoS) path selection metric will be used for the path selection decision. A simple example for such a metric is the hop count metric. According to a further embodiment of the invention, control packets, in particular path request packet and path reply packets, are extended by a flag if both, uni-directional and bi-directional, paths have to be used concurrently. This flag indicates whether a uni-directional or a bi-directional path to a target has to be discovered. In the proposed process a third phase is scheduled which fol^¬ lows the second phase. In this phase, a method according to an advantageous further embodiment of the invention is used which implies a usage of information gained by the preceding phase for the forwarding of data packets. This phase is dedi^¬ cated to an optimal path usage.

In this phase all nodes along the discovered path from the originator to the target have forwarding information for the specific FlowID assigned to this path. Therefore, if a node receives a data packet containing this specific FlowID then the lookup in its forwarding information is successful and the node is able to forward the received data packet accord^¬ ingly. In this way, the packets for a data communication be- tween source and destination node are forwarded based on the specific FlowID.

Furthermore, each discovered path for a specific FlowID pos^¬ sesses a lifetime, which is related to the last usage of this path. The lifetime for a specific FlowID is always updated to its maximum if data packets with the specific FlowID are for^¬ warded on this path. On the other hand, this means that the lifetime for a path for a specific FlowID is reduced if the path is not used. Therefore, a path for a specific FlowID is subject to aging. In consequence, it is removed from the for^¬ warding information of a mesh node if no data packets were forwarded for the duration of the given lifetime.

In the proposed process a fourth phase is scheduled which follows the third phase. In this phase, a method according to an advantageous further embodiment of the invention is used which implies a path maintenance and error handling of the established paths for specific FlowIDs. If a node detects a link failure a Path Error (PERR) message is generated by the node for each specific FlowID which uses this link to reach its next hop. The PERR is sent as a uni- cast message along the path in reverse direction by using the stored precursor address of this affected FlowID from the forwarding information. The PERR can alternatively be sent by broadcast .

If an intermediate node receives a PERR control packet it makes a lookup for this specific FlowID in its forwarding in^¬ formation to extract the precursor address. After that the PERR is forwarded as a unicast message with the extracted precursor address as the next hop address. The forwarding in^¬ formation for this specific FlowID is invalidated. By this way, the PERR is forwarded hop-by-hop to the originator of the path. After the originator receives the PERR for this specific FlowID, it forwards the data packets for this spe- cific FlowID according to phase 1 (Initial Tree Path Usage) and triggers a new path discovery as described in phase 2 (Path Discovery) . After phase 2 (Path Discovery) has finished, the data packets of this specific FlowID are for^¬ warded, again, according to phase 3 (Optimal Path Usage) .

In order to explain the proposed process by way of example, the process steps are described step by step according to Figure 2, which shows an exemplary process of path selection and forwarding by means of the network structure known from Figure 1.

In Figure 2, a table close to a respective node represents the forwarding information of the respective node. The format of the exchanged path selection messages refer to the message format which was introduced above. For instance, the message

PREQ <flowID:5> <targetAddr : 4> <originatorAddr : 7> means that a path request message for a specific FlowID 5 is sent to target node 4 in which node 7 is the originator node, whereas the message

PREP <flowID:5> <targetAddr : 4> <originatorAddr : 7> is interpreted as a path reply message for the specific

FlowID 5 which is sent to the originator node 7. A data packet is exemplarily presented as

DATA <flowID:5> <destAddr:4> <data-payload> .

In Figure 2, the following abbreviations are used: t: virtual time. This »virtual« timestamp is only used as a reference for the description without any tech^¬ nical implementation;

FID: FlowID;

Dst: Destination Address;

NH: Next Hop Address; Pre: Precursor Address; and; tlife: lifetime of the forwarding information entry.

The process begins with phase one. Starting at the virtual time tO, node 7 calculates the specific FlowID 5 for the data communication between itself and the destination node 4. Currently, no forwarding information entry for FlowID 5 is known. Consequently, node 7 triggers a path discovery for the destination node 4 with FlowID 5 as described in Phase 2.

Until node 7 has discovered an appropriate path for FlowID 5, node 7 changes the FlowID 5 of the incoming data packets to FlowID 0 in order to forward them by using the path tree. For the combination FlowID 0 and destination address 4, no forwarding information is stored. Therefore, node 7 forwards the data packet towards the root of the tree (node 0) to node 3 by using the forwarding information entry for the gateway, node 0.

When node 3 receives the data packet, it makes a lookup for the combination FlowID 0 and destination address 4 in its forwarding information. Based on that, node 3 also forwards the data packet towards the root of the tree (node 0) to node 1 by using the forwarding information entry for the gateway, node 0. After node 1 receives the data packet, it determines node 4 as the next hop for the FlowID 0 and the destination address 4. Therefore, node 1 forwards the data packet to node 4. Fi^¬ nally, the data packet is received from the destination node 4.

Phase two is performed in parallel to this process. Starting at the virtual time tl, the originator of the path discovery node 7 broadcasts the PREQ message PREQ <flowID:5> <targetAddr : 4> <originatorAddr : 7> .

The neighbors of node 7, node 3 and node 8, receive this PREQ and check if they are the requested target. Node 3 and 8 rec^¬ ognize themselves as intermediate nodes and record the FlowID 5 and node 7 as the precursor address in its forwarding in^¬ formation. After that, node 3 and 8 rebroadcast the PREQ to its neighbors.

In this way, the PREQ is rebroadcast until it reaches the target node 4. Node 4 receives the PREQ from node 8, it re^¬ cords the FlowID 5 and the related precursor address of node 8 in its forwarding information. Afterwards (at t2) the target node 4 sends a PREP message

PREP <flowID:5> <targetAddr : 4> <originatorAddr : 7> as a unicast message back to the originator node 7 using the precursor node 8 as the next hop.

Node 8 receives the PREP and recognizes itself as an interme- diate node. Then it updates the forwarding information for FlowID 5 using node 4 as the next hop.

After that, the intermediate node 8 sends the PREP as a uni^¬ cast message to its precursor node 7 for the FlowID 5. In this way, the PREP is forwarded until it reaches the origina^¬ tor node 7. If node 7 receives the PREP then it extracts the FlowID 5 and updates its forwarding information using node 8 as the next hop. At this point, the path for the specific FlowID 5 is estab^¬ lished from the originator node 7 to the target node 4. The unanswered and incomplete forwarding information for FlowID 5 at nodes 3 and 1 is deleted after the lifetime expires. The process is followed by phase three which is started at the virtual time t3. If node 7 receives a data packet con^¬ taining the FlowID 5 then the lookup in its forwarding information results that node 8 is the next hop. Node 7 forwards the data packet with FlowID 5 to its next hop node 8.

Accordingly, node 8 forwards the data packet with FlowID 5 to its next hop node 4. Finally, node 4 receives the data packet and recognizes itself as the destination node. Furthermore, the lifetime for FlowID 5 is always updated to its maximum if data packets are forwarded for this FlowID. The forwarding information entry for FlowID 5 is removed from the forwarding information of the nodes if no data packets were forwarded for the whole lifetime.

The process is followed by phase four and the path mainte- nance and error handling of the established path for FlowID 5 is described.

Assumed that node 8 detects a link failure while forwarding data packets to node 4, said node 8 makes a lookup for all FlowIDs using this broken link.

In this case, it generates a Path Error message

PERR <flowID:5> <targetAddr : 4> <originatorAddr : 7> for FlowID 5.

Node 8 sends the PERR as a unicast message to the precursor node 7 of the FlowID 5. By this way, the PERR finally arrives at the originator node 7. As a consequence, node 7 triggers a new path discovery for FlowID 5.

During this path discovery, data packets for FlowID 5 are forwarded according to phase one. Until node 7 has discovered a new appropriate path for FlowID 5, node 7 changes the

FlowID 5 of the incoming data packets to FlowID 0 in order to forward them by using the path tree.

According to an alternative embodiment bi-directional paths are established. These bi-directional paths are accordingly established flow-based and fulfill the given Quality of Ser^¬ vice requirements. According to this embodiment, the path re^¬ quest messages set up the reverse path from the target to the originator. The reverse path is then used to forward the path reply messages to the originator. The following details have to be considered if the process is used for setting up bi-directional flow-based Quality of Service paths: The flowIDs for the forward path (originator to target) and the reverse path (target to originator) have to be different, because network wide unique flow IDs are as- sumed .

The PREP will be only propagated by intermediate nodes, if the path fulfills the Quality of Service requirements. The already setup reverse path will time out after the life- time of its entry in the forwarding information expired.

According to a further embodiment of the invention, control packets, in particular control packets implementing path request messages or path reply messages, are extended by a flag if both, uni-directional and bi-directional, paths have to be used concurrently. This flag indicates whether a uni^¬ directional or a bi-directional path to a target has to be discovered . According to an alternative embodiment of the invention a handling of multiple target addresses and/or multiple flow identification numbers in the control packets is provided in order to setup multiple flow-based paths at the same time. The invention proposes an efficient solution for Quality of Service flow handling by using a combination of proactive tree-based and reactive mesh-based path selection protocols thereby benefitting of each mode to overcome the drawbacks of each path selection protocol. By applying the inventive method an initial latency is avoidable and a usage of optimal intra-mesh paths between mesh nodes is possible.

Claims

Claims 1. Method for selecting a path in a network, particularly a wireless mesh network, the network comprising a plurality of nodes ( 0 , 1 , 2 , ...10 ) ,

wherein the path to be selected is established between an originator node and a target node,

- wherein a proactively built tree path is established in the network by which each node is able to determine a con^¬ secutive node along the tree path,

wherein a source node is a source of a data packet and a destination node is a destination of a data packet,

- wherein data packets exchanged by nodes include a destina^¬ tion address and a flow identification number, and, wherein a data packet arriving at a forwarding node and having a reserved flow identification number, particularly zero, is forwarded to the consecutive node along the tree path or to a next hop node assigned to the reserved flow identification number and an address of the destination node,

the method including the steps of:

a) determining a flow identification number by the source node,

b) for the case that a lookup for a forwarding information assigned to said determined flow identification number is not successful, establishing a path discovery by the source node, and,

c) forwarding data packets featuring the flow identification number determined by the source node along the proactively built tree path by altering the flow identification number of the data packet to the reserved flow identification number and forwarding the packets along the tree-path as long as the lookup for the forwarding information assigned to said determined flow identification number is not successful.

2. Method according to claim 1,

including the steps of:

broadcasting a path request message by the originator node, the path request message including the flow identi^¬ fication number determined in step a) and a target ad^¬ dress;

receiving the path request message by at least one receiv^¬ ing node neighbored to the originator node;

comparing by the receiving node its assigned address with the destination address included in the path request mes^¬ sage thereby determining whether the receiving node is the target node or an intermediate node.

3. Method according to claim 2,

whereby for the case that the receiving node is an intermedi^¬ ate node the following steps are applied:

updating a record of the flow identification number included within the forwarding information of the receiving node by a record of the flow identification number included within the path request message;

updating a record of a destination address included within the forwarding information of the receiving node by a record of the target address included within the path re^¬ quest message, the record of the destination address being assigned to a flow identification number being equal to the flow identification number included within the path request message;

updating a record of a precursor address included within the forwarding information of the receiving node by a record of the address of the node transmitting the path re^¬ quest message, the record of the precursor address being assigned to a flow identification number being equal to the flow identification number included within the path request message;

forwarding the path request message as a broadcast message by the receiving node.

4. Method according to claim 3,

including the step of checking whether Quality of Service re^¬ quirements are fulfilled.

5. Method according to one of claims 3 and 4,

whereby for the case that the receiving node is the target node the following steps are applied:

sending a path reply message by the target node whereby the destination address of the path reply message is set to the address of the originator node, by using the pre^¬ cursor address recorded in the forwarding information of the target node or the address of the node transmitting the path request message as a next hop node;

receiving the path reply message by the receiving node, comparing by the receiving node its assigned address with the destination address in the path reply message thereby determining whether the receiving node is the originator node or an intermediate node.

6. Method according to claim 5,

updating a record of a next hop address included within the forwarding information of the receiving node by a record of the address of the node transmitting the path re^¬ ply message, the record of the next hop address being as^¬ signed to a flow identification number being equal to the flow identification number included within the path reply message ;

sending a path reply message to the precursor address re^¬ corded in the forwarding information of the receiving node and being assigned to a flow identification number being equal to the flow identification number included within the path reply message by the receiving node, whereby the destination address of the path reply message is set to the address of the originator node;

7. Method according to claim 6,

whereby for the case that the receiving node is the origina^¬ tor node the following step is applied:

updating a record of a next hop address included within the forwarding information of the originator node by a record of the address of the node transmitting the path re^¬ quest message, the record of the next hop address being assigned to a flow identification number being equal to the flow identification number included within the path reply message;

8. Method according to one of the claims 5 to 7,

the path request message and the path reply message including a flag indicating that an additional reverse path from the target node to the originator node has to be established.

9. Method according to claim 8,

including the step of checking whether Quality of Service re^¬ quirements are fulfilled in the additional reverse path.

10. Method according to one of the preceding claims,

whereby a plurality of forwarding information records is maintained within a node, each record referenced by its flow identification number.

11. Method according to claim 10,

whereby a lifetime is assigned to each record of forwarding information and whereby a record is deleted in case that its lifetime has expired.

12. Method according to one of the preceding claims,

whereby for the case that a lookup for a forwarding informa^¬ tion assigned to said determined flow identification number is successful, forwarding data packets according to said for- warding information assigned to said flow identification number .

13. Method according to one of the preceding claims,

whereby for the case that a node detects failure on a link connecting two nodes, a path error message is generated and transmitted to at least one further node in the network.

14. Method according to claim 13,

whereby the path error message is generated for each flow identification number which forwarding information includes the link.

15. Method according to claim 14,

whereby the path error message is forwarded by each interme^¬ diate node receiving the path error message.

16. Method according to claim 15,

whereby the precursor address in the forwarding information is entered as the next hop address of the path error message.

17. Method according to one of claims 15 and 16,

whereby the forwarding information assigned to the flow identification number is invalidated by each node forwarding or receiving the path error message.

18. A node in a wireless mesh network comprising means for carrying out a method defined according to one of claims 1 to 17.

19. Computer program product, which contains a program code stored on a computer-readable medium and which, when executed on a processor of a node in a wireless mesh network, carries out a method according to one of claims 1 to 17.