Method for operating a wireless mesh data network with multiple nodes

[0001] The invention relates to a method of operating a MESH-type wireless data network with multiple network nodes in which data frames are transmitted from a source node through one or more intermediate nodes to a destination node, wherein the source node, one or more intermediate nodes, and the node the target are the network nodes of the data network.

[0002] Transmission of data frames between the source node and the destination node can take place in essentially different routes in MESH data networks. The term route is understood to mean a number of network nodes that are located in a neighboring manner and have a data connection to the source node and the destination node at their ends. In order not to leave the case of transmission of data frames from the source node to the destination node, the so-called route request message to all neighboring network nodes (so-called Broadcast) that forward the route request message on broadcast to neighboring network nodes until the route request message finally reaches the destination node. A destination reply message is initiated by the destination node. During the transmission of the route inquiry message and the deliberate return transmission of the route response message (so-called Unicast) to the source node, entries are created in so-called route selection tables (so-called routing tables) at each node of the network. This provides a defined path for transmitting data frames between the source node and the destination node.

[0003] In the context of the present invention, a data path or path is understood to mean the transmission of data frames by one or more specified intermediate nodes between the source node and the destination node. Data frames that are transmitted from the source node to the destination node along the data path are transmitted along the forward route. When data frames are transmitted from the destination node to the source node, this is referred to in the following description as the reverse route.

[0004] In such MESH wireless data networks, there is a problem that individual frames on the path between the source node and the destination node may be erroneously transmitted, thereby creating data loops or loops. This disturbs data communication between the source node and the destination node. Incorrect data frame transmission can occur in all known transmission protocols (so-called routing protocols). The formation of such undesired data loops can occur through faulty network nodes or accidentally or intentionally during the transmission of data frames to the network node that is on the path in the direction of transmission in front of the transmitting network node. When the loop forms, the data frame or frames are forwarded to the network node that is in the forward direction on the path closer to the source node. As a result, the bandwidth available to the network can be reduced.

[0005] To prevent the continuous transport of an erroneously oriented data frame, it is known to integrate life time information into a data frame. This is for example used for data packets according to the Internet Protocol (IP) and for data packets according to the IEEE 802.11s specification. Life time information

-4 is referred to as Time to Live (ttl). This is an integer value that is usually set by the sender of the data frame to 255. When the data frame is forwarded to the new network node, the value is reduced by 1. When the lifetime value is 0, the data frame is discarded and is no longer transported on the network data.

[0006] Another known security mechanism is the so-called "source routing". The recipient of the data frame can check if the sender (transmitter) of the data frame has the authority to forward this data frame to the recipient. The check is based on path information that is contained in the data frame.

[0007] Furthermore, it is known to use unique sequence numbers when transmitting data frames. Thanks to this, it can be verified whether data frames have already been forwarded. Based on the sequence numbers, it can thus be inferred whether the data frame will reach one network node to another network node or once again to a network node.

[0008] From the Ad-hoc On-demand Distance Vector Routing (AODV) algorithm, as described for IP MANET Routing in RFC 3561, it is known to use so-called list of precursors. Precursor lists are used for network node error notifications. A list of precursors is created for both the forward direction and the reverse direction of the data path. This occurs when processing the route response message that was sent by the destination node. The basis of this procedure is that both directions (forward direction and return direction) follow the same path. The precursor lists used in AODV cannot, however, prevent loops.

[0009] Document Garcia-Luna-Aceves JJ et al: "On-Demand Loop-Free Routing With Link Vectors", IEEE Journal On Selected Areas In Communications, IEEE Bd. 23, No. 3, pages 533-546, ISSN: 0733-8716, describes an On Demand Link Vector protocol, a routing protocol for ad hoc networks based on link state information that is free of routing loops and that supports destination-based packet forwarding.

[0010] Hence, the object of the invention is to provide a method by which data loops can be avoided when transmitting data frames in a MESH-type wireless data network.

[0011] Another object of the invention is to provide a method by which the transmission of data frames in a MESH-type wireless data network allows the most efficient use of resources made available by the data network.

[0012] These objects are achieved by a method with the features of claim 1. Preferred embodiments are set out in the dependent claims.

[0013] In the method of the invention for operating a MESH-type wireless data network with multiple network nodes in which data frames are transmitted from the source node through one or more intermediate nodes to the destination node, the source node, one or more intermediate nodes and the destination node are data network network nodes. During transmission, the data frame is checked by at least some of the network nodes that receive the data frame, based on the precursor list assigned to the destination node of the data frame, whether the network node sending the data frame is included in the precursor list. In a positive case, the data frame is transmitted to the next network node. In the negative case the data frame is discarded or the error recovery procedure is carried out.

[0014] Within the framework of the invention, it is proposed to use precursor lists to detect data frames that originate from network nodes that are not authorized or intended for transmission of a given data frame. The precursor lists are lists with information about direct neighboring network nodes. This prevents data loops in the MESH wireless data network. By preventing data loops, you can avoid wasting valuable bandwidth in your data network.

[0015] In order to reliably prevent queues, network nodes need to check that the network node sending the data frame is included in the precursor list. The check is intentionally carried out by all network nodes. Checking by the destination node is not absolutely necessary.

[0016] A variant is also possible in which checking is performed by all network nodes, except for the source node and the destination node and the intermediate node immediately before the destination node. Properly, the check would also not be done by the intermediate node immediately before the source node when the source node is the target of the message (so-called reverse path).

[0017] According to one embodiment, one route selection table (so-called routing table) is created for the source node, destination node and intermediate nodes, each of the route selection tables having at least one entry. For each entry in the route selection table, a precursor list is created that includes direct adjacent nodes that can transmit a data frame to the appropriate network node. It is thus determined for each of the network nodes from which neighboring network nodes within the data path can receive message frames.

[0018] The route selection table is created as part of the route inquiry message initiated by the source node and the route response message initiated by the destination node. The route inquiry message is also referred to as the route request message. Route response messages are also known to the skilled person as a route reply message. Route query messages are sent as a broadcast message by the source node. In contrast, the route response message initiated by the destination node appears as a unicast message. Entries for the forward direction of the data path as well as for the reverse direction of the data path are created in the route selection tables. The forward direction of the data path extends from the source node to the destination node. The reverse direction is appropriately directed from the destination node to the source node.

[0019] The creation and / or updating of the precursor list is according to another embodiment carried out as part of the route response message initiated by the destination node.

[0020] According to another embodiment, the data frame includes the source node address, destination node address, the sending network node address of this data frame, and the network node address receiving the data frame. The receiving network node checks whether the address assigned to it corresponds to the destination node's address in the data frame. If the check is positive, the data frame is fed to the next processing unit, in particular to the higher layer in the OSI reference model. This means that the data frame has reached the destination node.

[0021] According to another embodiment, the entry in the precursor list comprises a Media Access Control address (Media

-8Access Control = MAC) or IP address and entry lifetime. The precursor list is the same list of MAC or IP addresses. The elements of the precursor list are direct neighbors (network nodes) of the network node that can transmit a data frame to this network node. This is because the network node transmitting the data frame lies on the data path to the destination node. A list of precursors is created for each entry in the route selection table. In many routing protocols this is equivalent to one entry because there is only one entry in the routing table per destination node for each destination node. As a result, this means that the list of precursors for the target node may have n entries, with n G [1, N]. N is the number of sources that can have active data paths through this node (N> 1).

[0022] In addition to using precursor lists to detect misdirected data frames, the invention proposes a method of proceeding to create and maintain a list of precursors used for this purpose.

[0023] In the invention, MAC or IP address value pairs and lifetime pairs are recorded as entries in the precursor lists. The lifetime of the entry is comparable to the lifetime value in the AODV algorithm. The underlying principle is that the lifetime of the network node precursor list entry is reset to its initial value when that network node receives a data frame from the network node whose address corresponds to the MAC address in the entry. Life times are updated for entries in the forward direction and in the reverse direction, when the life times of entries in the routing table are updated in both the forward and reverse direction when the corresponding data frame is received. In addition, an entry in the precursor list is deleted when the life of the entry has expired. Thanks to this it can be provided

-9 be that the risk of data loops being minimized is minimized.

[0024] The lifetime of the entry in the precursor list is maximally as long as the path lifetime value from the source node to the destination node, the path lifetime value being included as information in the routing table entry.

[0025] According to one embodiment, updating the lifetime of an entry in the precursor list and path lifetime values ​​in a given routing table entry occurs simultaneously. The update of the lifetime can also take place, for example, via a route reply message. It is not anticipated, however, that the route request message will update the precursor lists.

[0026] The reason for this is as follows: precursor lists are created during so-called route discovery by which the data path between the source node and the destination node is to be determined. The basic mechanisms in this case come from the original AODV specification. The publication on this subject can be found in [1]. The prior art procedure is supplemented in this case by adding lifetimes to the entries of the precursor list. The route inquiry message sent by the source node to all network nodes of the data network generates return directions from all network nodes to the source node. Then, when these return paths are created from the end, i.e. from the destination node, the previous network nodes are still unknown, so that nothing can be entered from the precursor list for the entry in the source node's route selection table. Route response message that is transmitted from the destination node to the source node using

The unicast mechanism, in turn, leads to entries on the precursor lists, both for the forward path and for the return path. The "destination node" and "source_node" information is taken from the corresponding fields of the route response message.

[0027] The following steps are performed to fill the routing table:

routingtable (destination_node) .create;

routingtable (desitnation_node) .lifetime.update (RREP.

lifetime);

routingtable (destination_node) .precursor_list.add (routingtable (source_node) next_hop, RREP.lifetime);

routingtable (source_node) .precursor_list.add (wegantwortnachricht.transmitter, routingtable (source_node) .lifetime).

[0028] Creating a list of precursors for a given entry in the routing table is not necessary in such an intermediate node when next to the source node the data frame route between the destination node and the source node, or if next to the source node and the destination node at the path of the transmission of data frames it is adjacent to the destination node. However, creating a list of precursors also simplifies and speeds up the methods in these cases. [0029] Both AODV and HWMP (Hybrid Wireless Mesh Protocol) allow intermediate nodes to respond to a route inquiry message with a route response message when they know the valid route to the destination node. In this case, the following updates must be made to the route selection tables of the intermediate node that generates the route inquiry message. "Destination_node" fields and

-11 "source_node" are taken from the corresponding fields of the route inquiry message:

- routingtable (destination_node) .precursor_list.add (routingtable (source_node) .next_hop, routingtable (destinati on_node) .lifetime)

- routingtable (source_node) .precursor_list.add (routingtable (destination_node) .next_hop, routingtable (source node) .lifetime) [0030] When another network node that is not a source node, a destination node or one of the intermediate nodes on the data path between the source node and the destination node, after receiving the source node route inquiry message (but not the route response message) transmits a data frame to the source node through another intermediate node, which subsequent intermediate node is the next intermediate node on the return path to the source node that does not contain the next network node in the entry precursor list in the routing table for the source node, according to one embodiment, the next intermediate node discards the data frame received from the next network node.

[0031] The data path created between the next network node and the source node is marked as non-binding according to the next embodiment on the next network node. To prevent unnecessary sending of data frames from the next network node to the source node, this path is marked so that the next network node can perform route discovery to the source node. This is instead of using a return path that was created as part of the route discovery between the source node and the next network node.

[0032] In an alternative embodiment, the precursor lists for the path between the next network node and the source node are filled before the data frame is transmitted from the next network node to the source node. This can be done, for example, by sending a route response message from the next network node to the source node.

[0033] In another alternative embodiment, when receiving the route inquiry message, the addresses of all network nodes adjacent to the network node together with the expiration value when receiving the route inquiry message are entered as temporary entries in the precursor list of that network node.

[0034] According to another embodiment, the network node is adjacent to the network node that has sent the route inquiry message, in this case it is not included in the precursor list of this network node.

[0035] Another embodiment provides that a temporary entry in the precursor list is provided with an expiration value (e.g., TTL (time to live value) in the Internet Protocol Header, e.g. IPV4), which has the same value as the return path, which was created by a route inquiry message.

[0036] In another optional embodiment, transient entries may be removed from the precursor list when an entry in the precursor list is created as part of a route response message initiated by the destination node.

[0037] The same problem also exists with proactive route inquiry messages in a proactive extension for so-called tree routing in HWMP. One-way tree from the root tree

-13 is started by a route inquiry message, wherein the route inquiry message is transmitted to all network nodes connected to the output node. This procedure creates a return path to the outgoing network node, however a precursor list cannot be created. HWMP uses a similar solution as proposed in the invention. When the proactive route response message flag is set, a route response message is sent in response to the route inquiry message. As a result, the list of precursors can be filled as usual. When the proactive route response message flag is not set, a route response message may be sent before the data frame, so that the precursor list is created "just in time".

[0038] The invention provides a simple mechanism for detecting misdirected data frames to prevent data loops due to intentional or erroneous forwarding. This is done by using precursor lists to detect misdirected data frames. In this case, the sender of the data frame is compared with the allowed predecessors on the list of precursors (= senders or transmitters). The invention in this case extends to the mechanism of precursor lists as it is specified for AODV. The entry is assigned a lifetime in the precursor list, so that the contents of the precursor list now corresponds to active data paths in the MESH wireless data network.

The invention is explained below with reference to the Figures. The figures show in turn:

-14Fig. 1

Fig. 2 shows the MESH data network with network nodes, on the basis of which is the method underlying the invention, with many explanations it is illustrated with the definitions of terms used in the description,

Figs. 3-8 respectively show the routing tables for the network nodes in Fig. 1, wherein the filling of the routing tables and the precursor lists contained therein is explained when creating the data path between two of the network nodes of the data network of Fig. 1, and

Fig. 9 shows the legend for the markings used in Figs. 3 to 8.

[0040] Fig. 1 is an example of a MESH data network with multiple MN network nodes. MN network nodes are partly connected to each other via KS communication links for data exchange. KS communication links are shaped as wireless. Each of the MN network nodes is assigned a unique address on the basis of which it is possible to transmit data frames from the source node to the destination node. In Fig. 1 MN node addresses of the network are marked with reference symbols S, B, A, C, D, F and G. The transmission of the data frame from one MN network node to the neighboring MN network node via the KS communication link is indicated by an arrow. Transmission of data frames from the source node of the data network to the destination node of the data network through one or more intermediate nodes in which the source nodes, destination nodes and intermediate nodes are formed by the network nodes

-15 data, followed by hop-by-hop, so from the network node to the network node.

[0041] When, for example, data frames are to be transmitted from the source node S to the destination node D of the data network of Fig. 1, then the data path must first be determined in which the intermediate nodes lying between the source node S and the destination node D ( in the embodiment, nodes B, A and C of the network), where route selection tables are assigned to the given network node. In the following description, route selection tables are referred to as routing tables. They are marked in Fig. 1 with the RT reference symbol. In the embodiment shown, the entry in the RT routing table contains three values. The first value gives the destination node address. The second value is a path metric, which is the same as the number of hops to the destination node to be reached. The third value is the address of the network node to which the data frame is to be transmitted in the next order. Also referred to as lane as "next hop".

[0042] The determination of the data path occurs by means of so-called "route discovery", which are sufficiently known for the operation of the MESH wireless data network. To this end, a route inquiry message is created by the source node S and is transmitted to all network nodes connected to the source node. This method of transmission referred to as broadcast is also carried out by intermediate nodes that have received such route inquiry message, hereinafter referred to as route request or route request message. When destination node D receives such a route request message, it corresponds to a route response message, hereinafter referred to as route reply or route reply message. Unlike the route reply message, however, it is

-Broadcasted to the source node S. This is also referred to as unicast.

[0043] As part of route discovery, routing tables of respective intermediate nodes in the data path can be created and filled.

[0044] Fig. 2 shows a typical convention in the description of the MESH data network. For simplicity, it is assumed that the SN source node is only through one intermediate IN node connected to the destination DN. A KS wireless communication link is created between the SN source node and the intermediate node IN or between the intermediate node IN and the destination DN. The SN, IN and DN network nodes lie on the DP data path through which the data frames are transmitted. The DP data path was determined by the route discovery method described above. Data frames that are transmitted from the SN source node to the DN destination node are transmitted in the forward direction or FR forward route. Data frames that are transmitted from the destination DN to the SN source node are transmitted in the reverse direction or on the RR return route. Reference will be made to this convention below. [0045] In the following brief description of the problem posed, Fig. 1 assumes that the data path between network node S as the source node and network node D as the destination node looks as follows: S-BA-CD. Another data path is to be created between network node G as the source node and network node D as the destination node. The corresponding data path looks like this: GFBACD.

[0046] Network node B, which is an intermediate node, has an entry in the routing table that includes network node D as the destination node. Three hops are necessary before the network node D is reached, but obtained by B

The data frame must be transmitted to network node A (also intermediate node). Correspondingly, network node A has an entry in the routing table in which network node D is included as the destination node. Two hops are necessary before the destination node D is reached, whereby the data frame received by A must be transmitted to network node C (intermediate node). Correspondingly, network node C has an entry in the routing table in which network node D is included as the destination node. One hop is required before the destination node D is reached, whereby the data frame received by C must be transmitted to network node D (destination node) When the network node F (also the intermediate node) receives the data frame for destination node D, it receives information about an entry in the routing table that four hops should be made to the destination node. The received data frames via network node F must be further transmitted to network node B.

[0047] In the event of a malfunction of the network node A, which may be intentional or related to failure, it is possible that the data frames will not be transmitted to network node C, but to network node F. This may for example be supported by information from the route inquiry message received by network node A from network node F. This results in the dashed data loop in Fig. 1. Namely, the network node F will, because of the entry in the routing table, forward the data frame to B, which for its part will forward the data frame to A.

[0048] Because loop formation costs valuable bandwidth in a MESH-type wireless data network, the invention provides entries in the routing table that are supplemented with precursor lists. By providing lists

18 precursors can be specified network frame nodes of the data that they cannot send to the network node receiving the data frame. This prevents data loops.

[0049] Each precursor list that is created for each entry in the routing table is a list of Media Access Control (MAC) addresses. The elements of the precursor list are direct adjacent network nodes of a network node having a list of precursors, which, according to the routes specified by the routing protocol, transmit data frames to this network node. The list of entry precursors in the routing table of a network node may thus have n G [1, N] entries, where N is the number of source nodes that have the active data path through the node.

[0050] The IEEE 802.11s (WLAN Mesh Networking) standard defines a format for data frames that contains six addresses. The data frame defined there contains, among others address of the network node that transmits the data frame (transmitter address). This network node is the previous network node (hop) on the data path. So in other words, it's a predecessor or precursor. This address, i.e. the transmitter address is compared to the address that is placed on the precursor list on the path to the desired destination node. When the recipient node is the destination node, the comparison does not need to be performed anymore because the transmission of the data frame to the destination node will not lead to a data loop.

[0051] Three addresses are needed to implement the method. The destination node address, the address of the network node that transmits the data frame, and the address of the network node that receives the data frame. As explained above, there is a comparison whether the destination address matches the address of the network node receiving the data frame. When he has it

-19 place, the received data frame is fed to a higher processing layer. When the destination address does not match the address of the network node receiving the data frame, it is checked that the address of the sending network node (transmitter) is included in the entry precursor list in the routing table for the destination node. When this happens, the data frame has been transmitted correctly. The receiving data frame, the network node then transmits it to the network node, which is contained in the corresponding entry in the routing table as next hop. In the case of a negative check result, the data frame is perceived as misdirected because the transmitter is not the previous network node on the data path and therefore was not allowed to transmit the data frame to that neighbor. The data frame is therefore either discarded or fed to a debugging procedure.

[0052] Entries on the precursor lists are also supplemented with life time values. The entry in the precursor list thus contains a pair of values ​​{MAC address, lifetime}. Complementing the lifetime value enables the precursor lists to correspond to active data paths in the data network. In other words, it is thus ensured that entries in the precursor lists are only intended for active data paths.

[0053] When the lifetime of the entry in the precursor list has elapsed, the corresponding entry is removed from the precursor list. A check or update of the lifetime value always occurs when a data frame is received by the network node and the corresponding entry in the precursor list is present. The lifetime of the precursor list entries can be updated in both directions, i.e. forward and backward in the data path.

-20 Corresponds to the procedure described in

AODV / HWMP.

[0054] The new value of the lifetime entry is the maximum possible value for the lifetime. Intentionally, no lifetime value of a precursor list entry is greater than the corresponding lifetime of the data path. In general, the update of the lifetime value on the precursor list occurs together with the update of the lifetime value of the entry in the routing table. The lifetime values ​​of the precursor list entries are also updated when route reply messages pass through the network node. In turn, route request messages do not update the precursor list lifetime entry.

[0055] Listed precursor lists for entries in the routing table are also generated as part of route discovery. In this case, a special case may occur during the route discovery process. When the source node S wants to communicate with the destination node D, route discovery is initiated by the source node S, which sends a route request message to all network nodes in the data network. The route request message creates return paths from all network nodes to the source node S. However, as explained at the beginning, only one data path is created between the source node S and the target node D, on which the destination node D sends back route reply . This route reply message results in precursor lists being created on network nodes, but only on network nodes that lie on the data path between S and D. The data path is, as explained at the beginning, SBA-CD. In other network nodes, in the embodiment in F and G network nodes, however, no such precursor lists are created in the associated entries in the table

-21routingu. Nevertheless, the return path from network node G to source node S is indeed valid.

[0056] When the network node G transmits the data frame to the source node S on this return path, it sends the data frame to the next network node, which in the embodiment is the network node F. The network node F, which is adjacent to the network node G, does not however, it has entries in the precursor list for network node G. Hence, the data frames transmitted by G are discarded at network node F, even though they were transmitted on the binding path.

[0057] Three options are available to solve this problem.

1. The return path created between G and S is seen as a non-binding path. To prevent unnecessary sending of data frames, this path must be marked accordingly so that the network node G can initiate route discovery to network node S, instead of using the return path to S that was initiated by route discovery initiated by S.

2. List of precursors can be generated in that a route reply message to S is transmitted before the correct data frames are transmitted from G to

S.

3. Alternatively, the addresses of all neighboring network nodes may be entered in the precursor list for the return path. This is not necessary for the network node that sent

-22 route request message. For network node F, these would be adjacent network nodes A and G. The adjacent network node B does not need to be admitted to the precursor list, because it sent a route request message. These entries are provided with a time out that has the same value as the return path that was created by the route request message. This simple solution, however, has the disadvantage that during route discovery a short time is given during which protection against the formation of a data loop is not given.

[0058] Subsequent Figures 3 to 8 now explain how entries in the routing table are created with the associated precursor lists, which is in relation to the data network shown in Fig. 1. Fig. 9 shows the legend for better understanding for selected markings in Figs. 3 to 8.

[0059] The RT routing table has five entries: destination node address ("destination"), number of intermediate nodes lying on the destination path ("distance (hops)"), next network node address ("next hop"), lifetime value for the entry in the routing table ("time" out (life time) ") and a precursor list, wherein the entry in the precursor list includes the network node address and the life time entry (" precursor list (node, life time) "). [0060] Two types of NT messages are used in the description. RREQ specifies the route request message or route inquiry message. RREP specifies a route reply or route response message. Both routing RN messages contain the following values: moment ("time / at"), address of the sending network node ("transmitter"), node address

-23 source ("source"), destination node address ("destination"), number of network nodes to the destination node ("hop count"), life time ("life time").

[0061] In Fig. 3, the steps S1 to S6 show the creation of a data path between network node G as the source node and network node D as the destination node. This shows, in particular, how routing tables of each of the network nodes S, B, A, C, D, F and G are created after the route request message is sent by the G source node. The highlighted fields in the individual tables show the sender of the route request message and those fields in the routing table that resulted in a change due to the processing of the route request message.

[0062] In step S1, a route request RREQ message is sent by the network node G. The network node G is thus the message transmitter. At the same time, G is the source node of the data network, so that G is also entered in the "source" field. As a destination, the route request message receives the network node D (destination). Because the sender and message source are identical, enter 0 for the hop count value. Any value for 8 is chosen as the lifetime value. The associated G and F network node routing tables show that G is the sender of the message. The routing table of the network node F, which receives the route request RREQ message from G, stores information about the return route. The destination of the G network node is registered as the destination from here, because it is the source node of the route request message. The distance from him is one hop. To get to the destination of the return path, source G must be reached as the next node (next hop). As a lifetime for the entry in the routing table for the return path to the source node

-24G is selected from the route request message 8 time units.

[0063] In step S2, a route request RREQ message is sent to the network nodes connected to the network node F via KS communication links. In the embodiment according to Fig. 1, these are network nodes B, A and G. The route request message contains the following information: the sender, i.e. the transmitter, where the message is a network node F. The route request RREQ message has been initiated by the source node G, yes that it is entered in the source field. The destination is still the destination node D, so it is entered in the destination field. Network nodes F and G are spaced one hop count apart. The lifetime remains at the set value of 8. In each of the network nodes B, A and G that receive the route request message from F, entries are created in the routing table: in network nodes B and A both for the network node F of the transmitter as and for the source node G, in the network node G only for the network node F of the transmitter. The distance to the destination of the return path (source) is set to 2.

[0064] In this way, the route request RREQ message is transported further until it finally reaches the destination node D in step S6. Network node D has two entries in the routing table, one of which contains information for network node C as destination and one contains information for network node G as the destination.

[0065] In Figs. 4, in steps S7 to S11, route reply messages are shown which are sent by destination node D. Source node G is in this case the recipient of the route reply message. It should be inferred from the corresponding routing table that for some entries in the routing table there is a list of precursors,

-25 containing the address of the previous network node in the data path and the lifetime value.

[0066] The route reply message is sent via network node D. The route reply message is transmitted to the neighboring network node C. In the "source" field, there is still the source node G which initiated the route request message. The destination node is still the network node D to which the source node would like to establish a data path. Hop counts are calculated from the sender's perspective of the route reply message, hence the value is 0. The lifetime is set according to the lifetime from the route request message to 8, but can generally be chosen freely. Network node C that receives the route reply message from network node D can now create a new entry in the routing table on the one hand for network node D. On the other hand, for entries in the routing table to network nodes G and D (in each case destination) an entry in the precursor list can be created. When the message is to be sent by network node C to network node G as the destination, network node D is the predecessor on the data path. In turn, when a data frame is to be sent by network node C to network node D as the recipient, network node A is the predecessor on the data path. This information can be deduced from the routing table entry to the network node G as the recipient, because A here is included as next hop.

[0067] The route reply message is transported in a suitable way from network node C to network node A and from it to network node B, finally to network node F and then to node from network node G. They are in the described method, completed entries in the routing table, and corresponding precursor lists are generated.

[0068] The procedure corresponding to Figs. 3 and 4 is described in Fig. 5 in conjunction with Fig. 6 and Fig. 7. However, a route request message has been sent from the network node S as the source node, the node network D is specified as the destination node. As is apparent from, for example, Fig. 5, step S13, the moment in which the lifetime of the generated and updated entries in the routing table is different (moment 11 instead of moment 8). When considering stages S18 to S21, it can also be concluded that for some entries in the routing table (see e.g. step S20, entry in the routing table for network node D), the list of precursors is supplemented with another entry. Step S21 in Fig. 7 shows the final routing tables of all network nodes of the exemplary data network Fig. 1. Now, as described, in connection with Fig. 1, network node A will mistakenly send data that is destined for network node D to network node F instead of network node C, these data frames are discarded, so that a data loop will be prevented.

[0069] The consequences of the method according to the invention will become clearer once more on the basis of the following embodiment. The following abbreviations are used:

RA The address of the receiving network node ("receiver address"),

TA Address of the network node sending the data frame ("transmitter address"),

DA Address of the destination node ("destination address"),

SA The address from which the data frame was originally sent ("source address").

-27 Observation of network node A:

[0070]

Step 1: Network node A receives a data frame from RA = A,

TA = B, DA = D, SA = G or S;

Step 2: Network node A is not a destination for the data frame (A Ψ D), i.e. the destination node address does not match the address of the network node,

Step 3: The data frame was received correctly because the sending network node B is on the list of entry precursors in the routing table for destination node D ([D-2-C-11- (B, 11)]).

[0071] It is further assumed that network node A is to forward the frame to C (the entry in the routing table for network node D is: [D-2-C-11- (B, 11)]. In fact, it is assumed that network node A forwards the data frame by mistake to network node F.

Observation of network node F:

[0072]

<td>Stage</td><td> 1:</td><td>Hose from</td><td>network F receives the frame</td><td>data from:</td>

<td></td><td></td><td>RA = F,</td><td>TA = A, DA = D, SA = G or S,</td><td></td>

<td>Stage</td><td> 2:</td><td>Hose from</td><td>network F is not</td><td>place</td>

<td></td><td></td><td colspan="2">destination for data frame (F Ψ D)</td><td>^,</td>

<td>Stage</td><td> 3:</td><td>Frame</td><td>data was mistakenly</td><td>received,</td>

because sender B is not on the list of precursors of the entry in the routing table for

-28 network node D ([D-4-B-8- (G, 8)). This results in the data frame being discarded.

[0073] The invention thus prevents the formation of a data loop when the erroneous network node transmits the data frame back to the network node from which it is obtained.

It is assumed that network node B in Fig. 1 sends data frames that are destined for network node D, back to network node S or F. Both S and F have valid paths to destination node D, with the network node B is the nearest destination node i.e. next hop.

Observation of network node B:

[0074]

<td>Stage</td><td> 1:</td><td colspan="3">Network node B receives the data frame TA = S or F, DA = D, SA = S or G,</td><td>with RA = B,</td>

<td>Stage</td><td> 2:</td><td>Node</td><td>network B</td><td>does not constitute</td><td>place</td>

<td></td><td></td><td colspan="2">destination for the frame</td><td>data (BAD)</td><td>^,</td>

<td>Stage</td><td> 3:</td><td>Frame</td><td>data was left</td><td colspan="2">received correctly,</td>

because sender S or F is on the list of entry precursors in the routing table for network node D: ([D-3-A-11- (F, 8) (S, 11)]).

[0075] Network node B would be configured to transmit a data frame to network node A. This is due to an entry in the routing table for the network node: [D-3-A-11 (F, 8) (5, 11)]. In the embodiment, it is assumed that the data frame is transmitted by mistake to the network node F or S.

-29Section of the N network node:

[0076]

Step 1: Network node S receives a data frame from RA = S,

TA = B, DA = D, SA = S or G,

Step 2: The network node S is not a destination for the data frame (S Ψ D),

Step 3: The data frame was received by mistake because sender B is not on the list of entry precursors in the routing table for network node D: ([D-4-B-11- ()]). This results in the data frame being discarded.

Observation of network node F:

[0077]

Step 1: Network node F receives a data frame from RA = F,

TA = B, DA = D, SA = S or G,

Step 2: Network node F is not a destination for the data frame (F Ψ D),

Step 3: The data frame was received by mistake because sender B is not on the list of entry precursors in the routing table for network node D: ([D-4-B-8- (G, 8)]) [0078] Because of this, data frame discarded.

[0079] In addition, Fig. 8 shows the continuous updating of precursor lists of overlapping data paths. For example, it can be deduced from the routing tables of the S, B, A, C, D, F and G nodes that due to the lifetime of entries in the routing table are deleted

-30 related entries on the precursor list. This is represented by highlighted, blank entries in the table. At the end of the lifetime of the entry in the routing table, both the entry in the routing table and the entry in the precursor list itself are deleted. In the embodiment, it is assumed that the data path between network nodes G and D has expired. However, the data path to the destination node D in network nodes B, A and C does not expire because there is still an active data path between network nodes S and D. The precursor shows network node B for its data path to D, namely for data path between G and D and for the data path between S and D. In this case only the first one expires and is removed from the list of precursors.

Literature list:

[1] CE Perkins, EM Belding-Royer, SR Das: Ad hoc Ondemand Distance Vector (AODV) Routing, IETF Experimental RFC 3561, July 2003.

53 / 57P29104PL00