EP2484152A1

EP2484152A1 - Method for establishing a bidirectional communication path in a wireless network

Info

Publication number: EP2484152A1
Application number: EP10742474A
Authority: EP
Inventors: Michael Bahr; Torsten Meyer; Norbert Vicari
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2009-09-29
Filing date: 2010-08-06
Publication date: 2012-08-08
Also published as: US20120182943A1; WO2011038963A1; CN102577518A; DE102009043403A1; DE102009043403B4

Abstract

The invention relates to a method for establishing a bidirectional communication path (PF) in a wireless network (NET), particularly in a wireless sensor network, wherein the network (NET) comprises nodes in the form of a sink node (SK) and a plurality of subscriber nodes (SE), and wherein the communication path (PF) for the bidirectional transmission of data packets is to be established between the sink node (SK) and at least one queried node (SO) of the subscriber nodes (SE). An uplink path from a particular subscriber node (SE) to the sink node (SK) is determined in that a periodic exchange of path messages takes place between adjacent nodes (SK, SE) of the network (NET), wherein a particular path message signals the respectively shortest distance to the sink node (SK), particularly in the form of a metric. Furthermore, each of the nodes (SE) administers the path thereof to the sink node (SK) by saving the address of the adjacent node (SE) having the best metric to the sink node (SK) for forwarding the data packets. A downlink path from the sink node (SK) to the at least one queried node (SO) is determined in that an address list is inserted into at least one of the path messages sent by the sink node (SK), which list comprises the address of a respectively queried node (SO). Each subscriber node (SE) that receives a path message having an address list inserts the address list to the path message it sends out, and the subscriber node(s) (SE) addressed in the address list change as queried nodes (SO) to a dedicated transmission state upon receiving the path message with the address list.

Description

description

Method for establishing a bidirectional communication path in a wireless network

The invention relates to a method for building a bidi ^{¬-directional} communication path in a wireless network, particularly a wireless sensor network, wherein the network node comprises in the form of a sink node and a plurality of subscriber nodes, between the sink node and at least one requested node of the subscriber node of the communication path is set up for bidirectional About Mitt ^¬ development of data packets. The invention further relates to a computer program product and a network, in particular a wireless sensor network.

Wireless networks are often implemented in the form of wireless sensor networks (also called sensor networks). A wireless sensor network is formed by a collection of sensors, the nodes or sensor nodes of the sensor network, with a radio interface. The respective sensors übertra ^¬ gene, for example, measured values and status information (general ^¬ my: data) to, at least, which is typically a sink node acts as a gateway. If the sensors are not in direct reach of the sink node, they also pass the data on to others of the sensors. Thus, a so-called multi-hop data transmission is established. For this purpose, the information about the respectively next node for forwarding to the sink node, ie via the path, is kept in the sensor node. This information is commonly referred to as a routing table entry.

The sensor nodes as well as the sink nodes are typically designed for extreme energy efficiency as well as low cost in implementation. This means that the nodes have very low resources, in particular a low computing power and a small main memory. The latter indicates that even the routing tables can only contain a few entries. In addition, only low data rates can be achieved via the radio interface, with the resource also having to be used as sparingly as possible, since the radio interface has a particularly high energy consumption relative to the other components, such as sensor or CPU.

Paths from a respective sensor to the sink node (gateway), ie in the so-called uplink direction, can be set up in a simple and resource-saving manner using so-called collection tree protocols. Such protocols are based on the periodi ^¬ rule exchange of packets between neighboring nodes, which indicate the respective shortest distance to the sink in the form of a metric. These packets are called beacons. Each node maintains a path to the Senkenkno ^¬ th by abspei ^¬ chert the neighboring node with the smallest distance to the sink for transmission of its data packets. However, occasionally messages, eg configuration packages, should be sent from the sink node to a selected node. For this, corresponding paths have to be set up in the opposite direction, ie the so-called downlink direction, which is not supported by the class of collection tree protocols. ^Therefore, additional mechanisms are required when using this protocol.

There is also the problem that in a large sensor network the structure of the paths must be particularly efficient, in particular because the available memory is not sufficient to maintain paths for all nodes in the sink or in the nodes close to the sink. As a result, the paths from the sink node to the selected node must be detected and rebuilt repeatedly because they can not be permanently maintained.

In the context of wireless sensor networks, two specifications are known which relate to the communication keep busy in multi-hop networks: ZigBee and WirelessHAR.

In addition to the cluster tree protocol, ZigBee supports a reactive AODV-based multi-hop protocol. The cluster tree protocol assigns addresses depending on the Topolo ^¬ gie, which efficiently solves the above problem, but in practice leads to significant limitations on the usability, because the entire application logic also mo with changes in the topology and related address changes ^¬ must be modified. Since this is not practical, ZigBee's Cluster Tree method is not used in current applications. Therefore, in recent ZigBee Pro Feature Set the cluster tree protocol is not supported and complemented the AODV based Proto col ^¬ by many-to-one and source routing. A com munication ^¬ from the sink node to individual nodes can be realized both by a targeted construction of routes with the reaction ven AODV mechanism and via the source-routing option. The reactive establishment of routes results in a network-wide broadcast. Due to the low Spei ^¬ cherkapazität the node with respect to the routing tables must be frequently repeated this process, which results in an increased consumption of resources, including energy.

Source routing requires the recording of all intermediate nodes in data packets that are transmitted from a node to the sink node. This list of intermediate nodes is then carried in the data packet which is transmitted from the sink node to one of the nodes (sensors). Disadvantages of this method are the reduction of the maximum size of the payload data of the packets (in the standard IEEE 802.15.4 maximum 128 bytes including the packet header) depending on the distance (counted in hops, ie the number of intermediate nodes) between node and sink nodes and the additional effort for the realization of a second class of routing protocols.

WirelessHART supports both table-based and source routing. At WirelessHART, routing is centrally controlled by a network manager who knows the topology. The table-based routing is gurationsprozess by the elaborate Confi- more for longer-term relationships Kommunikationsbezie ^¬ suitable. The resource constraint of the memory makes frequent reconfiguration of the routing tables inevitable, since not all communication relationships between the sink node and all nodes of the sensor network can be held in memory. Source routing solves the memory problem, but is limited to a total of four hops in WirelessHART. Also, the effort for the implementation of two routing protocols is not negligible.

In the world of wireless data communication, in particular the IEEE 802.11 Wi-Fi protocols Pfa ^¬ de are also known to build to the sink node. The current draft standard IEEE 802.11s D2.02 also includes the mesh routing protocol HWMP (published in [1]). In addition to the on-demand mode, it is also possible to construct a route tree, which may also be bidirectional, from a specific node, the so-called root MP. Typically, a root MP is a sink node or gateway. For this, two different methods are angege ^¬ ben: proactive PREQ mode and RANN mode. In proactive PREQ mode, a so-called path

Request message (PREQ) sent with a broadcast address as ge ^¬ searched destination of the root MP in the network. As a result, a unidirectional path to the root MP is established in each node of the network. The result of this procedure corresponds to the collection tree routing in the considered sensor networks. However, the PREQ message is usually "flooded", ie it is sent by the node that receives the message received immediately with updated path metric per

Broadcast forwarded to all neighboring nodes.

The bidirectional paths in the root MP to each node can be generated in HWMP proactive PREQ mode using two different methods. With a set flag "proactive PREP", each node that has received the PREQ message to the broadcast address responds with a corresponding path reply message (PREP) .This method is not even in WLAN networks This means that N * L transmissions of PREP packets per transmitted PREQ message from the root MP are necessary, where N represents the number of nodes in the tree and L the mean tree depth The method is not energy efficient and generates overhead, and the root MP would have a path to all nodes in the network, which would lead to resource problems due to the size of the routing table.) If the flag is "proactive PREP "is not set, the node sends only one PREP alert when he needs ei ^¬ nen bidirectional path, ie a path from the root MP to the node. The initiator here is the node, whereby the sending of PREP messages is maintained as long as the node sends data to the root MP. With this method, the routing table in the root MP is smaller, but it would cover all sensor nodes in the sensor network and therefore be too large for a resource limited wireless network because each node sends data to the sink node. Another problem with this method is that the need for a bidirectional path is known only at the sink node / root MP, but the bidirectional path is initiated only from the node in the tree and there is no possibility in HWMP of this need for the node tree to convey. The RANN mode of HWMP differs only in the on ^¬ construction of the bidirectional routes. This is a so-called. Root Announcement message (RANN message) according to the above flooded in the network described proactive PREQ message. However, no entry is made in the routing table, only the best predecessor node to the root MP is determined. The information is not used for forwarding data packets, but merely for forwarding routing messages, in particular Path Request

(PREQ) messages. The paths between the node in the tree and the root MP are created via a unicast PREQ / PREP message exchange. This exchange of routing messages is also initiated by the node in the tree. It is also not possible to communicate the need for a bidirectional path present at the sink node / root MP to the nodes in the tree. Besides, one would have to

PREQ / PREP message exchanges are made for each node to achieve the functionality of a collection tree protocol.

In HWMP, when a data packet is sent on the path, the lifetime of the corresponding return path and its associated return path is reset to the maximum value. In the sensor networks described above, this would result in a once established bi-directional path always remaining bidirectional, because data packets were sent to the sink node again and again by the sensors, thereby also renewing the lifetime of the corresponding path from the sink node to the sensor node. The bidirectional path Wür ^¬ de thereby never called by a passage of life. Time-out will be deleted.

HWMP allows multiple destination addresses in the PREQ messages. By definition, either one or more destination addresses for individual nodes in reactive mode or only the broadcast address for the tree in PREQ may be used. This reduces energy-intensive request messages.

It is therefore an object of the present invention to specify a method with which a bidirectional communication path in a wireless network, in particular a wireless sensor network, can be established. In this case, the method should be suitable for being able to be executed efficiently in a wireless network with low resources. It is a further object of the present invention to provide a computer program product and a network in which a bidirectional data transmission with low resource consumption is possible. These objects are achieved by methods according to the features of claims 1 and 4, a Computerprogrammpro ^¬ product according to the features of claim 23, and a network according to the features of claim 24. Advantageous embodiments will become apparent from the dependent patent claims.

The invention provides a method for establishing a bidirectional communication path in a wireless network, in particular a wireless sensor network, wherein the network comprises nodes in the form of a sink node and a plurality of subscriber nodes, wherein the communication path between the sink node and at least one requested node of the subscriber node is set up for bidirectional About Mitt ^¬ development of data packets. In the method according to the invention, an uplink path from a respective subscriber node to the sink node is determined by a periodic exchange of path messages, that is to say messages with path information, between adjacent nodes of the network, wherein a respective path message to the respective shortest distance to the sink node, in particular in the form of a metric signals, and each of the nodes characterized manages a path to the sink node, that it the address of the neighboring node with the bes ^¬ th metric to the sink node for forwarding the Datenpa- kete stores. The path messages can be so-called beacons, as they are known from collection tree protocols. Using this procedure to determine the uplink path the shortest paths between the sink nodes and a respective subscriber node are determined. This approach is collectively known as Collection Tree Protocol, which has been described above. The exchanged messages are called beacons. For example, the best metric includes the least number of subscriber nodes located on the path.

In the inventive method, a downlink path to the at least determined by the sink node a requested node in that in at least one of, sent from the sink node path message is an address list is inserted, which includes the address of a respective one is in question ^¬ th node. Each participant node receives a path message with an address list, adds the Adresslis ^¬ a te of the light emitted by it Path message. In this case, the subscriber node addressed in the address list, upon receiving the path message with the address list, transitions into a dedicated send state as requested nodes.

The inventive method thus proposes to insert the address or addresses of the requested node (s) into a beacon in accordance with the collection tree protocol. By An ^¬ hang an address list of the requested node to the path message (Beacon), it is possible that the requested node Report explicitly at the sink node, without the latter having to flood the wireless network ^¬ factory energy-intensive with an additional request message , This will be the marginalized ^¬ energy resources in particular carried a wireless sensor network, billing in a wireless network.

Due to the restriction to a few requested sensor nodes, there is the additional positive effect that the routing table of the sink node contains only those subscriber nodes with which it actually communicates. This adds up to the very limited storage capacity of the sink node and the subscriber nodes that are intermediate nodes are taken into account.

By an advantageous configuration of maximum life time, path messages interval (beacon interval) and To ^¬ sammenstellung of lists of the requested sensor nodes, the invention can be used in many forms of wireless networks. According to an expedient embodiment, when a path message is received with the address list, a requested node removes its address from the address list before the requested node sends its path message with the address list to the nodes adjacent to it.

According to another embodiment, a subscriber node only considers path messages from such an adjacent node, which is selected as the next hop to the sink node due to the path message. As a result, the resources available in the nodes are used sparingly.

The invention provides a further method for establishing a bidirectional communication path in a wireless network, in particular a wireless sensor network, wherein the network comprises nodes in the form of a sink node and a plurality of subscriber nodes, wherein between the sink node and at least one requested node of the subscriber node, the communication path for bidirectional About ^¬ mediation is to build data packets. In this method, an uplink path from a respective one of the subscriber nodes to the sink node is determined by periodically exchanging path messages between adjacent nodes of the network, each path message being the shortest distance to the sink node, especially in the form of a metric, and each of the nodes manages its path to the sink node by assigning it the address of the neighboring node with the particular node. stored metric to the sink node for forwarding the data packets. A downlink path from the sink node to the at least one requested node according to the invention determined in that in addition to the periodically gesende- th path messages by the sink node comprising a request- message with an address list, the address of each ^¬ weiligen requested node , is sent out; the request message through each of these request message emp ^¬ scavenging node, is sent to the respective adjacent nodes continue; and pass the one or more addressable ^¬ th subscriber node in the address list upon receipt of the request message with the address list as requested node in a dedicated transmit state. The request message updates automatically in all Kno ^¬ th, which receive this request message, the Kommunikati ^¬ onspfad to sink node. This process principle is similar to the on-demand mode of HWMP sure to send a expli ^¬ deficits request message with multiple destination addresses. Such an explicit request message only needs to be distributed once in the wireless network, so that the number of additional routing packets can be kept small. This allows energy-efficient operation of the wireless network. Another advantage is that a combination of a request message with the path ^{¬ construction} to the sink node brings an additional update of the paths to the sink node with it. A request message initiated by the sink node automatically updates the path to the sink node in all nodes receiving this request message.

According to an expedient embodiment remove the subscriber nodes which are addressed in the address list, their ad ^¬ ress from the address list prior to forwarding to the respective adjacent nodes. Since nodes that receive a request message and their ad ^¬ ress is included in the list of destination addresses to delete their address before forwarding it from the list, it may happen that the list of destinations is empty, but not all participants have received the request message to Aktuali ^¬ Sieren the paths to the sink node. Although this does not lead to a malfunction of the network if these subscriber nodes do not receive the request message, the timeliness of the paths to the sink node can be increased by forwarding. For this, the subscriber node must be informed to also forward a request with an empty list of destination addresses. There are the following options:

In a first variant, the subscriber node, the one initiated by the sink node request message are received, ^¬ gen continue to lead, these adjacent to their nodes. This is preferably done regardless of whether destination addresses are present in the address list or not.

According to another variant direct the subscriber node, the further one-initiated by the sink node request message with ei ^¬ ner contained therein broadcast address as the destination address of the request message erhaltendie request message with lee ^¬ rer destination list to all participants nodes and interpret this Broadcast Address not as request. But as subscriber node with the contained destination addresses are also invited to mark their packets to the Senkenkno ^¬ th, the broadcast address then requires special treatment because not everyone, but only certain user nodes are to mark the data packets.

According to a further variant, an indicator is inserted in the request message, which signals to the request message receiving node that the request message is to forward even with an empty address list to the neighboring nodes. If the indicator is set, the query Message forwarded even if the destination address list is empty. If the indicator is not set, the request message will not be forwarded if the destination address list is empty. According to a further expedient embodiment, the requested node provides at least the next data packet to be sent to the sink node in a predefined manner with a marking which is interpreted by the subscriber nodes lying on the communication path to the sink node as an indicator for a forwarding message.

By integrating the functionality of response messages into regular data packets, there is a further saving on routing packets. The establishment of communication paths is thereby enabled in the wireless network without generating additional signaling traffic. As a result, virtually no additional energy is required: adding a few bytes to existing data packets requires significantly less energy than sending additional packets. A further advantage of the method according to the invention is that, by the construction of local routing tables, the method scales in comparison to the source routing methods known from the prior art.

According to a further expedient embodiment, the subscriber nodes, which lie on the path from a requested node to the sink node, as well as the sink node, the downlink path in their forwarding table when they receive a marked data packet from one of the requested nodes.

Expediently, at least ^¬ entered following information in the forwarding table: a destination address which is the address of the requested node, and corresponds to the source address of a labeled Since ^¬ tenpakets; an address of a neighboring peer node (night vi ^¬ most hop), which is the address of the next subscriber ^¬ node on the path to the destination address. This corresponds ^¬ what the sender address of the selected data packet; - one of a life of a communication path ent ^¬ speaking information, which specifies after how long the path cleared for the requested node from the Wei terleitungs table. It is further contemplated that the life of a path on the occurrence of the following events on their Maxi ^¬ malwert reset: when receiving or relaying a provided with a marking packet of data from the requested node, which is transmitted to the sink node, or

upon receipt or forwarding of a data packet sent from the sink node addressed to the requested node.

In particular, the subscriber node is informed of the lifetime of the communication path in a configuration. Just ^¬ so it is possible to insert this value in the marked data packets, so that then this value is used for the routing table.

The maximum value for the lifetime of the path from the sink node to the requested node should be chosen such that this path still exists when the next data packet is sent by the sink node on this path.

A path metric for the paths from the sink node to the requested sensor nodes can be dispensed with since the path from the sink node to the requested sensor node corresponds exactly to the already existing path from the requested sensor node to the sink node. A further expedient embodiment provides that a marked data packet is provided with a sequence number. If a tagged data packet contains a sequence number with which the order of the (marked) data packets can be determined unambiguously from one and the same requested sensor node, then it is useful to include this in the routing table entry, since the correct chronologi ^¬ processing is simplified in data transmission problems.

The association of a participant node with its predecessor in the tree structure may change to another parent node due to changing environmental conditions, which change the metric to the sink node. In the worst case, a break in a communication connection between two adjacent subscriber nodes, so that a transmission of data packets between the subscriber node and its predecessor node is no longer possible. Constellations in the topology are possible in which the sink node does not notice the interruption of the path to the subscriber node and therefore the packets from the sink node can not be transmitted to the subscriber node. For this reason, all paths outgoing from the sink node that have passed through this unused or even unavailable link must be updated in all intermediate nodes and in the sink node. This process is referred to below as path maintenance.

The uplink paths are automatically, e.g. via the received path messages (beacons), updated. So that the paths are also updated in the downlink direction, the data packets of the requested nodes must be marked as long as the corresponding downlink path should exist.

The necessity of path maintenance of a downlink path in the relevant requested node is expediently characterized by a flag, whereby in the case of mark flag the data packets at the sink nodes are marked with the marking.

There are two variants available for this purpose.

In order for a requested node to know whether there is a downlink path from the sink node to it that has to be serviced, according to an advantageous embodiment of the method, the lifetime of a downlink path is stored in the relevant requested node. Conveniently, a timer initialized with the maximum path lifetime is started when generating a downlink path. The generation of the path is the time when the first marked data packet is sent after a request from the requested node. In particular, the initial lifetime for the downlink path from the sink node to this subscriber node in that subscriber node corresponds to the lifetime set in the intermediate nodes for that downlink path. An embodiment of this first variant provides that the marker flag and a further flag characterizing a first data packet are set by a subscriber node as soon as it becomes a requested node, the further flag including the transmission of the first marker Data packets are deleted at the sink node. In particular, the at least one node is asked ^¬ no longer provides a transmitting to the sink node to data packet with the marker when the timer has expired and the further flag and the marker flag are not set. Alternatively, the additional flag with a non ^¬ negative mark resource is combined, taking into account the number of at least selected data packets according to each request by the sink node. According to a further expedient embodiment, a flag for the existence of a downlink path verwen ^¬ det, wherein the questioned node in question from him to Marks the data packets sent to sink nodes as long as the flag is set. The flag is set by

a path message in which the subscriber node is included in the address list (i.e., requested) and / or

Data packets received from the node ^¬ lowering the requested node.

By combining these two conditions, a subscriber node need only once in the path messages for the duration of a downlink path be requested regardless because of ^¬, how many path messages intervals this path exists. This allows independent exist on the maximum permissible size of the path message as many downlink paths simultaneously solan ^¬ ge the sink node transmits on these downlink paths packets despite the limited number of requested user nodes in the path message. Also, the path message interval and the lifetime of the downlink path can be selected completely independently of each other.

The setting of the flag by data packets which the requested node receives from the sink node can also be omitted in principle. However, only a limited number of downlink paths can then exist at the same time, since the requested nodes must always be requested again with each path message and the space for the addresses of the subscriber nodes in the path messages is limited. In addition, it should be noted that the lifetime of the downlink path is greater than the path message interval if a continuous presence of the downlink path is desired.

According to a further expedient embodiment, the flag is reset when a predetermined number of data packets provided with a marker are sent to the sensor. node was sent from a respective requested node.

An alternative of the second variant provides that the flag is reset if the requested Kno ^¬ th is no longer included in the address list in a predetermined number of received path messages.

The invention further includes a computer program product that can be loaded directly into the internal memory of a digital computer and comprises software code sections are executed with de ^¬ NEN the steps of the inventive method when the product is run on the computer. The invention further provides a network, in particular a wireless sensor network, wherein the network has nodes in the form of a sink node and a plurality of subscriber nodes, between the sink node and at least one requested node of the subscriber node, the communication path for the bidirectional transmission of data ^¬ packets is buildable. In the network according to the invention, an uplink path from a respective subscriber node to the sink node can be determined by periodically exchanging path messages between adjacent nodes of the network, wherein a respective path message is the shortest distance to the sink node, in particular in the form of a metric, and each of the nodes manages its path to the sink node by storing the address of the neighboring node with the best metrics to the sink node for forwarding the data packets. A downlink path from the sink node to the ^to-¬ least a requested node is determined by the fact that in at least one of, sent from the sink node path message is an address list is inserted, which includes the address of a respective requested node; each subscriber node receiving a path message with an address list sends the address list to its inserted path message; and that the or addressed in the ad ^¬ ressliste subscriber node upon receipt of the path message having the address list of the requested node pass into a dedicated transmit state.

The network according to the invention has the same advantages as have been described in connection with the method according to the invention.

The invention will be explained in more detail by way of example embodiments in the drawing. 1 shows a schematic, exemplary sensor network with a plurality of nodes and a respective path of a subscriber node to a sink node;

2A, 2B show two possible implementations of path messages with requests to the sensor nodes of the sensor network according to FIG. 1, FIG.

3 shows a flow of communication according to the invention in the requested node J according to a first method for path maintenance, and

4 shows a flow of communication according to the invention in the requested node J according to a second method for path maintenance. Fig. 1 shows an exemplary sensor network NET, which comprises bone ^¬ th in the form of a sink node SK and a plurality of subscriber nodes SE. The subscriber nodes represent, for example, sensor nodes and have a unique address, which is identified in FIG. 1 by A, B, C, K, L. Between existing subscriber node SE existing communication links (so-called links) are shown in Fig. 1 with a thin dotted line. Grease lines between two nodes represent a communication path between the connected nodes. The paths between the individual subscriber nodes SE have been constructed in accordance with the collection tree protocol which has already been explained in the introduction. A detail later discussed communication path between the sink node SK and the subscriber node SE with the address "J" (abbreviated node J) is marked with PF to this communication path lying part ^¬ slave nodes B and E are referred to as intermediate nodes..

The paths of the subscriber node SE to the sink node SK are established by each of the subscriber nodes A to L communicating its shortest distance to the sink node SK in path messages designated with beacons. The sink node SK makes himself with beacons with distance "0" or a ande ^¬ ren initial start value, which is the smallest value in its environment known to himself. After adding the distance to the subscriber node from which another participant node Beacon has received, at the distance to the sink node communicated in the beacon, the subscriber node knows the corresponding distances to the sink node via its neighboring subscriber node A subscriber node SE sends data destined for the sink node SK to the adjacent subscriber node SE, via the It has the shortest distance to the sink node SK After finite time, the information about the distance to the sink node SK, starting from the sink node SK, has reached all the subscriber nodes SE in the network.

In the following description, it is assumed that the sink node SK wishes to send three data and control packets to the subscriber node with the address "J." For this purpose, a communication path from the sink node SK to the particular subscriber node must first be determined, with this subscriber node being requested Node SO is called. For this purpose, a list of addresses of the subscriber nodes to which the sink node SK wishes to send data is attached to the beacon emitted by the sink node SK for setting up respective paths to the sink node SK. In the present case, this is the subscriber node SE with the address "J". Each part ^¬ participants node that receives such a beacon, this address list adds in his next beacon with one. This addresses all subscriber nodes SE of the sensor network NET are reported. Receives a Subscriber node SE, which is contained in this address list (here: node "J") such a

Beacon, he removes his address from the address list be ^¬ before he forwards it in his next beacon to the subscriber node SE adjacent to him. In principle, it is sufficient that only those beacons to be ^¬ taken into account, which are received from a neighboring peer nodes SE which then due to this beacon as the next node (hop) is selected to sink node SK. In the embodiment according to Fig. 1 of the Senkenkno ^¬ th SK therefore carries the address of the subscriber node SE with the address "Y" as a node of requested in its beacon a After a finite time this request achieved in the beacon of one of its neighboring peer nodes (here the node. I, E, F or K) the node J. In the exemplary embodiment, only those beacons are considered which are received by an adjacent subscriber node SE, which is then selected as the next hop to the sink node SK, also repeatedly, on the basis of this beacon these are the beacons of node E.

FIG. 2A shows a possible realization of a beacon with a request to a specific subscriber node SE of the sensor network NET. With EF, existing fields are already marked in a conventional beacon. N indicates the number of requested subscriber nodes SE. IDl (SO), IDN (SO) are the identifiers (addresses) the requested subscriber node called. The address list can in principle, as shown in Fig. 2A, have a number N of requested nodes, wherein the number N> 0. Field N can also be omitted if the number and position of the requested subscriber nodes are unambiguous from the

Structure of the beacon result. This is the case when the ad ^¬ ests of the requested subscriber node SE follow immediately after EF as the last data fields. Fig. 2B shows a preferred embodiment according to which

Beacon additionally has a request flag SOF, with the beacon receiving subscriber node SE is signaled that subscriber nodes for a bidirectional communication ^¬ connection between the sink node and them are queried and these requested subscriber nodes are included in the inserted address list. Only if the request flag SOF is set are the additional fields (number N of the requested nodes and the identifiers (addresses) of the requested nodes) appended to the beacon. Again, the field N could be omitted if the end of the address list without the field N is clearly recognizable (eg by the end of the message).

After receiving a beacon by the requested node contained in the address list of the beacon, the requested node SO (here node J) marks its next data packet by an appropriate mechanism, such as a flag, for processing in the routing algorithm. If a subscriber node SE has been requested, it must provide at least the next data packet to the sink node SK with this marking. However, since the timings for sending data packets are dependent upon receipt of a beacon with a request, it ^¬ it laubt the set on the requested nodes marking (eg in the form of a marking flags or similar data structure) to determine whether the data packets Invention ^¬ according must be marked. If the flag is set accordingly, then all data packets of the requested node are SO marked. If the requested node SO is requested in a beacon, the requested node SO sets the marking. The way in which the mark can be reset is described below.

The intermediate nodes on the path to the sink node SK (here the nodes E and B) and the sink node SK itself treat a marked data packet similar to a response message and enter the corresponding route to the requested node SO (node J) in its routing table. At least the following information must be entered in the entry in the routing table:

Destination: This is the address of the requested bone ^¬ least SO (here: node J), ie the source address of the MAR-labeled data packet.

Next hop to the destination node: The address of the next sensor node en route to the requested sensor node, i. the sender address of the marked data packet.

A lifetime of the path: The length of time after which the path to the requested node SO is deleted from the routing table.

Various mechanisms put the life back into her Ma ^¬ ximalwert described below. In any case, this is done upon receipt of a data packet marked according to the invention from the requested sensor node SO (destination address) and upon receipt of data packets from the sink node SK, which are addressed to the requested sensor node SO. The maximum value of the lifetime can be communicated to the intermediate node by configuration. It is also possible to insert this value in the marked data packets so that this value is taken for the routing table.

The maximum value for the lifetime of the path from the sink node SK to the requested node SO (so-called downlink path) should be selected so that it still exists on the path when the next data packet is sent by the sink node SK. advantage. A path metric is not needed, since the path from the sink node SK to the requested node SO corresponds exactly to the already existing path from the requested sensor node to the sink node.

Alternatively, an explicit request message with multiple destination addresses can, similar to the on-demand mode of HWMP be ge ^¬ sends. Although this requires additional routing packets, but together with the other mechanisms of the method, such an explicit request message need only be distributed once in the sensor network so that the number of additional routing packets is small. Not all nodes of the sensor network need to receive the request message. In meshed networks, however, the request message is usually forwarded to all nodes. Therefore, a combination of a request message with the path structure to the sink node SK brings an additional update of the paths to the sink node SK. A request message, which was initiated by the sink node SK, automatically updated in all participating nodes that contain this request message, the path to the sink node ^¬.

Since nodes that receive such a request message and de ^¬ ren address is included in the list of destination delete their address before forwarding it from the list, it may happen that the list of destinations is empty, but not all subscriber node SE received the request message to update the paths to the sink node SK. However, it does not lead to a malfunction of the network NET if these subscriber nodes SE do not receive the request message.

However, the timeliness of the paths to the sink node SK can be increased by forwarding. For this purpose, the subscriber node SE is informed to also forward a request with an empty list of destination addresses. There are several ways to do this: There are generally all request messages that were initiated by lowering accounts SK forwarded, inde ^¬ pendent of whether a destination address in the inquiry

Message is included or not.

The broadcast address is specified as the destination address.

Since, however, the sensor nodes with the contained sensor nodes are actually requested to send a response message to the sink node, the broadcast address requires a special treatment, since not every sensor node, but only certain sensor nodes require a response.

To send message.

A flag is used in the request message. When the flag is set, the request message is forwarded even when lee ^¬ rer destination list. If the flag is not set, the request message is not weitergelei ^¬ tet, if the destination address list is empty.

The requested nodes SO respond to receiving a request message as when receiving a beacon in which they are listed in the list of destination addresses, i. with the marking of their data packets to the sink node SK.

The lifetime of the path PF is reset to the initial value by forwarding data packets on this path with each data packet. Usually a Datenpa ^¬ ket renews the life of both directions of a path PF. For the inventive process it is necessary that Datenpake ^¬ te, which are not marked in the manner described, refresh the life time only for the direction of the path, in which they are forwarded. This means that the path PF is updated from the sink node SK to the requested node SO (downlink path) by packets which the sink node SK transmits to a subscriber node SO, but not by unmarked data packets which the subscriber node SO sends to the sink node SK in the context of its normal function. Otherwise, this would cause a once attached, bidirectional path permanently remains bidirectional.

An exception to this is the data packets of the requested node SO marked in the manner described, which are transmitted to the sink node SK. By communicated with their marking routing functionality they put the Le ^¬ benszeit the downlink path from the sink node SK to the node is in question ^¬ th SO again to the initial value.

The method also takes into account the maintenance of a once constructed bidirectional path between the sink node SK and a requested node SO when the topology changes.

The association of a subscriber node SE to its repeat procedure ^¬ ger in the tree structure of the network may change due to fluctuating ambient conditions to another parent node, thus increasing the metric changes to the sink node. In the worst case, a link break occurs, so that a transmission of data packets between the subscriber node and its predecessor node is no longer possible. Constellations in the network topology are possible in which the sink node does not notice the interruption of the path to the subscriber node and therefore the data packets from the sink node SK can not be transmitted to a subscriber node SE or the requested node SO located on the path. For this reason, all paths originating from the sink node SK that pass through this unused or unavailable link must be updated in all intermediate nodes and in the sink node SK.

The paths in the uplink direction, ie from a subscriber node SE or the requested node SO in the direction of the sink node SK, are automatically updated via the beacons obtained. Thus the downlink paths in reverse Rich ^¬ tung from the sink node SK to the queried node SO updated Siert, the data packets of the requested node SO must be marked in the manner described as long as the corresponding path from the sink node SK to the requested node SO should exist.

Method A

So that a requested node SO also knows whether there is a path from the sink node SK to it, which must be serviced, the lifetime of the downlink path from the sink node SK to the requested node SO (abbreviated SK -> SO) is also carried in the requested node SO , It is therefor a timer vorgese ^¬ hen that is initialized with the maximum lifetime of the path and in generating the path from the sink node SK for turning requested node SO (sensor node) is started. This is the time at which the first highlighted data packet after ei ^¬ ner such a request from the requested node SO is sent. In particular, the initial lifetime for the path from the sink node SK to the requested node SO in this sensor node corresponds to the lifetime set in the intermediate nodes for that path.

The lifetime for the downlink path SK -> SO in the queried node SO with each received from the sink node SK package to the specified output value, ie the maximum life ^¬ time reset. Data packets, that is also tagged data ^¬ packets, sends the requested node SO as originator to the sink node SK, do not alter the timer of the requested node as a rule. An exception is the first marked data packet after receiving a beacon in which the

Node SO was requested. The marked data packet sets the timer to the start value and can be recognized by means of another flag, the so-called first data packet flag EDPF. If the first data packet flag EDPF is set, when sending a marked data packet, the timer is set to the initial value and the first data packet flag EDPF is deleted. The first- Data packet flag EDPF is set upon receipt of a beacon with Anfra ^¬ ge for the requested node SO.

If the timer expires and at this time the first data packet flag EDPF is not set, the flag MF is reset, so that subsequent data packets are no longer marked by the requested node SO.

The first data packet flag EDPF may also be combined with the flag MF in a non-negative integer tag resource MR. In this alternative, the following rules apply:

Initialization MR: = 0

Receiving a beacon with MR: = MR + n

Request SO n> 1

Send a data packet MR: = 0

at MR = 0 data packet unmarked

Send a data packet MR: = 1

at MR = 1 and Timer> 0 data packet is highlighted

Timer unchanged

Send a data packet MR: = 1

at MR = 1 and Timer = 0 data packet is marked

Timer will ge ^¬ set to start value

Sending a data packet MR: = MR - 1

at MR> 1 data packet is marked

Timer will ge ^¬ set to start value

Timer expires MR: = MR - 1

Receipt of a data packet MR: = 1

from the sink node SK at timer is set to starting ge ^¬ MR = 0 sets

Receipt of a data packet MR: = MR

from sink node SK at timer is set to starting value ge ^¬ MR> 0 sets The addend n here corresponds to the number of at least marked data packets after each beacon with a request. It is sufficient if n = 1. The above behavior when resetting the lifetime to the maximum value is slightly different in the requested sensor node SO than in the intermediate node and the sink node SK. As a result, the timer in the requested sensor node SO can run earlier than the timers for the lifetime of the downlink path SK -> SO in the intermediate node and in the sink node SK. This leads to no misconduct, because the crucial timer for the final transmission of data packets to the requested node is located in the intermediate node, which is the direct predecessor of the requested sensor node SO. The faster time-out on the requested node SO is intended, because in fact this timer corresponds to the time or the statement that the downlink path SK -> SO is to be maintained, ie the data packets from the requested node SO to the sink node SK be marked. If the timer expires on the requested node SO, the lifetime of the downlink path SK -> SO is no longer renewed by the data packets that are no longer marked and is deleted after the timers have expired in the intermediate nodes and in the sink node SK. If during this period (ie the timer expires, the queried node SO, the downlink path SK -> SO still exists per ^¬ but) the requested node SO receive a data packet from the sink node SK, he again sets the marker flag MF initialized its timer with the maximum value for the lifetime and marks again as long as his data packets ^{¬ he} invention, as the timer is active. This is shown by way of example in FIG. 3.

Fig. 3 processes according to the invention in angefrag- th node N at the address "J" shows not just be in accordance with the method described ^¬ A, wherein the marker flag MF and the first data packet flag EDPF be used. A The set flag is marked with "ns", a set flag is marked with "s". On the right side, the (Rx) or transmitted (Tx) data packets received by the requested node SO with the address J are shown. The data packets are read as follows: "B (E), (J)" means that a beacon of the subscriber node is received with the address E (originator of the beacon), the beacon a request for the node with the address J "D (J) _^ SK" means that a data packet is transmitted / sent from the node with the address J to the sink node SK. A data packet directed to the sink node SK and marked is marked D (J) -> SK (m). The chronological sequence is shown in the figure from top to bottom. First, both the first data packet flag EDPF and the flag flag are not set. At the time ti, the requested node SO with the address J (in short: node J) receives a beacon from the subscriber node E in which node J is requested (B (E), (J)). Thereafter, both the first data packet flag EDPF and the flag MF are set (ie, the flags change from "ns" to "s", respectively). Between time ti and t ₂ , node J receives further beacons from nodes F and I in which node J is requested. At the time t ₂ , node J sends a marked data packet to the sink node SK (D (J) -> SK (m)). Thereafter, the timer T is set to its start value SW. Also, the first data packet flag EDPF is changed to "not set-ns." The flag MF remains set "s". The timer T decrements as time progresses. At time t3, node J receives a data packet from sink node SK

(D (SK) -> J), whereupon the timer T is reset to its start value SW to ^¬ . The same happens at time t ₄ . At time t ₅ , node J receives a beacon from node E in which node J is requested (B (E), (J)), whereupon the first data packet flag EDPF changes its status to "set-s". Between t ₅ and te, the timer T has dropped from its start value SW to the value 0. The flag MF remains set "s" because the first data packet flag EDPF is set to "s". The timer T remains at 0 until the time te, at which it is set to its start value SW, since node J transmits a mar ^¬ kiertes data packet to the sink node SK

(D (J) -> SK (m)). At the same time, the first data packet flag EDPF is changed in its status to "not set-ns." At time t ₇ , the timer has fallen to its value 0, whereupon the flag MF also changes its status to "not set-ns". because the first data packet flag EDPF is also "not set-ns"

Node J sends a data packet from the sink node SK (D (SK) _^ J), whereupon the flag changes its status to "set-s" and the timer is set to its start value SW Between node ts and tg, node J receives a beacon B (E) in which no node is requested, therefore the states of the first

Data packet flags EDPF and the flag MF not ver ^¬ changes. Also, the timer T reaches the value 0, and the flag MF is set to "not set-ns." At the time tg at which the node J sends a data packet to the sink node SK, the timer T already has a value from 0 to, the flag is now "not set-ns". A data packet sent from node J to sink node SK is therefore not marked (D (J) -> SK). Method B

An alternative and on the requested node SO timerless method includes a corresponding flag MF (B.l) or

MF (B.2) for the existence of the downlink path SK - SO. The requested node SO marks its data packets as long as the flag MF is set. Bl or B.2 characterize here ^¬ two different methods, which will be explained in more detail below. The flag MF is set

- by beacons in which the node in the list of

Destination address is included, so is requested, and / or by the data packets of the requested node SO receives Sen ^¬ kenknoten SK.

By combining these two conditions, a node only needs to be requested once in the beacons for the duration of a downlink path SK -> SO, regardless of how many beacon intervals that path exists. As a result, any number of downlink paths SK -> SO can exist simultaneously in the beacon, regardless of the maximum permissible size of the path message, despite the limited number of requested nodes SO, as long as the sink node SK sends data packets on these paths. This also allows the beacon interval and the lifetime of the path to be selected completely ^{independent of} one another.

The flag MF is reset

after sending n (where n> 1) marked data packets to the sink node SK. In particular, when n> 1, it is advantageous if the counter of the marked data packets still to be sent is set to n again after receiving a beacon in which a node was requested, and / or receiving a data packet from the sink node SK. This approach corresponds to the Ver ^¬ go Bl

by the nth (where n> 1) beacon, in which the sensor node receiving the beacon is not included in the list of destination addresses, that is to say it is not requested (method B.2). In method B.l, the existence of the downlink path SK -> depends

SO strongly from the traffic offer between the sink node SK and the requested node SO, ie the number and times of the data packets. Therefore, it is expedient to choose the lifetime of the downlink path SK -> SO so large that, in as many cases as possible, the path still exists if the sink node SK wishes to send the data packet to the requested node SO. The lifetime should be greater than that Period between the sending of the marked data packet and the next data packet from the sink node SK to the requested node SO. If the downlink path SK -> SO has already been deleted, the sink node SK must explicitly restart the path by entering the requested node SO into the list of destination addresses in the next beacon.

In method B. 2, a conflict with the method described above for deleting addresses from the destination address list may arise: A requested node SO removes its own address from the list of destination addresses in the beacon before it sends it out. If he receives this beacon again later, he would stop marking his data packets. Maybe he did not even send a tagged data packet. This situation can be considered as follows:

At least one data packet at the sink node SK after receiving the beacon in which a subscriber node has been requested is marked and the lifetime of the downlink path SK -> SO is chosen to be so large that at least the transmission of the next beacon round in the

Lifetime falls. The life time is thus greater than the beacon interval and the life time is greater than (n * beacon interval), if (n - 1) beacon failures to ^¬ are lerierbar.

- Requested nodes SO do not delete themselves from the list of the destination address in the beacon during forwarding.

The list of destination addresses is only checked if the sequence number of the beacon is greater than the sequence number of the beacon, through which the current path to the sink node SK has been entered or if the distance to the sink node SK is better for the same sequence number.

4 shows the chronological sequences in the requested node SO with the address "J" (in short: node J) in accordance with the methods B1 and B.2 In both variants B1 and B.2, n = 1. The lifetime of the path is slightly longer than three times the interval for sending data through node J.

At the time ti, the node J sends a data packet to the sink node SK (D (J) -SK). At this time, in both methods B.l and B.2, the flag flags MF (B.l) and

MF (B.2) "not set-ns" At time t ₂ , node J receives a beacon of the neighboring node E in which node J is requested (B (E), (J)), whereupon the marker flags MF (Bl) or MF (B.2) their status is set to "s" än ^¬ countries. Between time t ₂ and t _3, the node J receives beacons from other nodes F and I, in which it is requested in each case, but this leads to no change in the Markie ^¬ approximately flags. Only at the time t ₃ with the sending of a marked data packet from the node J to the sink node SK (D (J) -SK (m)) does the flag MF (Bl) change its status to "not set-ns" according to method Bl while the flag MF (B.2) of the method B.2 maintains its status "set-s". With the reception of a data packet from the sink node SK (D (SK) -J) at the time t _4, the Markie ^¬ approximately flag MF (Bl) changes according to the method Bl its status and is again "set-s". The transmission of a labeled Data packets at time t ₅ to the sink node SK

Turn (D (J) -SK (m)) changes the status of the marker flag MF (Bl), while the marker flag of the procedure B.2 un ^¬ changed "set-s" remains. The method described is to time t ₂ maintained. at time t _3, the node J receives a beacon of the node e (B (e)), in which the node J is not requested, whereupon the marker flag Mäss overall the procedure B.2 MF (B .2) changes its status to "not set-ns". A time t _i4 emitted ^¬ data packet of the node J to the sink node SK is accordingly in both methods Bl and B.2 not highlighted (D (J) -SK). Since after the time t _i4 by the node J beacon is no longer received in which this is requested, the flag flags remain unchanged to "not set-ns". The tagged data packets from J require the following entries in the routing tables of the corresponding sensor nodes. The routing table below applies to all procedures A, Bl and B.2 .:

If the path J -> SK changes when forwarding the beacons, then the next data packet marked according to the invention is placed by J in the path SK -> J onto this new path.

In the presented methods A, Bl and B.2, the persistence of the downlink path SK -> SO depends on whether data packets are sent on this path. If the path also vorgehal ^¬ th, when no data packets are sent from the sink node to the queried node SO, the sink node SK must be timely that the requested sensor node SO to include in the list of destination addresses in the beacon so that the timer for the marking of data packets is again set to the maximum value in the requested node SO. Alternatively, it is also possible to send empty data packets.

Furthermore, general traffic sent from the sensor nodes to the sink node must not generate new path entries in the sink node. This is only possible with specially marked data packets as described above. This reduces the number of path entries on the sink node SK. Only the nodes to which the sink node wants to send are entered. bibliography

[1] IEEE 802.1ls / D2.02 Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 10: Mesh Networking, Chapter 11 B.9.

Claims

claims

Method for establishing a bidirectional communication path (PF) in a wireless network (NET), in particular a wireless sensor network, wherein the network (NET) has nodes in the form of a sink node (SK) and a plurality of subscriber nodes (SE), wherein between the sink node (SK) and at least one requested node (SO) of the subscriber node (SE) the communication path (PF) is to be set up for the bidirectional transmission of data packets, in which:

an uplink path of a respective one of Teilnehmerkno ^¬ th (SE) to the sink node (SK) is determined in that

a periodic exchange of path messages

between adjacent nodes (SK, SE) of the network (NET), whereby a respective path message signals the respectively shortest distance to the sink node (SK), in particular in the form of a metric, and

each of the nodes (SE) manages its path to the sink node (SK) by storing the address of the neighboring node (SE) with the best metric to the sink node (SK) for forwarding the data packets;

a downlink path from the sink node (SK) to the at least one requested node (SO) is determined by

an address list is inserted in at least one of the, by the sink node (SK) transmitted path messages comprising the addresses of the respective been ^¬ requested node (SO);

each subscriber node (SE) receiving a path message with an address list sends the address list to the path

Insert message, and the one or more addressed in the address list subscriber node (SE) on receipt of the path message with the address list as queried nodes (SO) in a dedicated send state.

2. The method of claim 1, wherein a requested node (SO) on receipt of a path message with the address list removes its address from the address list, before the ^¬ asked node its path message with the address list to the neighboring nodes to it sending out.

A method according to claim 1 or 2, wherein a subscriber node (SE) considers path messages only from such an adjacent node selected as the next hop to the sink node (SK) due to the path message.

4. A method for establishing a bidirectional communication path (PF) in a wireless network (NET), in particular a wireless sensor network, wherein the network (NET) node in the form of a sink node (SK) and a plurality of subscriber node (SE), wherein between the sink node (SK) and at least one requested node (SO) of the subscriber node (SE) the communication path (PF) is to be set up for the bidirectional transmission of data packets, in which:

a periodic exchange of path messages between adjacent nodes (SK, SE) of the network

(NET), with a respective path message the shortest distance to the sink node

(SK), in particular in the form of a metric signaled, and

each of the nodes (SE) manages its path to the sink node (SK) by providing it with the address of the neighboring node (SE) with the best metric to the sink node (SK) stores for forwarding the data packets;

in addition to the periodically transmitted Path message by the sink node (SK) a request message to an address list that summarizes the Ad ^¬ ress of each requested node (SO) environmentally, is emitted,

the request message is forwarded by each of these received ^¬ the node to the respective adjacent nodes, and

the subscriber node (s) addressed in the address list upon receipt of the request

Transfer message with the address list as requested nodes (SO) in a dedicated send state.

5. The method of claim 4, wherein the subscriber node (SE), which are addressed in the address list, remove their address from the address list before forwarding to each ^¬ neighboring nodes.

The method of claim 5, wherein the subscriber nodes (SE) receiving a request message initiated by the sink node forward them to their neighboring nodes.

7. The method of claim 5, wherein the subscriber node (SE), which receive a request initiated by the sink node request message with a broadcast address as the destination address of the request message, this broadcast address is not interpreted as a request and the request - Forward message to its neighboring nodes.

8. The method of claim 5, wherein in the request message, an indicator (flag) is inserted, which the the request message receiving node signals that the request message is to be forwarded even with an empty address list to the ^¬ neighboring nodes.

9. The method according to any one of the preceding claims, wherein the at least one requested node (SO) at least the next ^¬ th, to the sink node (SK) to be sent data packet in a predetermined manner with a marker, which of the on the communication path (PF ) to the sink node (SK) lying subscriber node (SE) is interpreted as an indicator for a response message.

10. Method according to one of the preceding claims, in which the subscriber nodes (SE) lying on the path from a requested node (SO) to the sink node (SK) as well as the sink node (SK) the downlink path in their further routing table register when they receive a selected data packet from a ^¬ of the requested node (SO).

11. The method according to claim 10, wherein at least the following information is entered in the forwarding table:

a destination address, which is the address of the requested node (SO), and the source address of a marked data packet;

an address of an adjacent subscriber node (SE) which is the address of the next subscriber node (SE) on the path to the destination address;

one of a life of a communication path (PF) corresponding information, which indicates to wel ^¬ cher duration of the path to the node requested (SO) is deleted from the forwarding table.

The method of claim 11, wherein the lifetime of a path from the sink node (SK) to the requested node (SO) is reset to its maximum value when one of the following events occurs: upon receipt or forwarding of a tagged data packet from the requested node (SO) transmitted to the sink node (SK), or upon receipt or forwarding of a data packet sent from the sink node (SK) sent to the requested node (SO ) is addressed.

13. The method according to any one of the preceding claims, in which a marked data packet is provided with a sequence number.

14. The method according to any one of claims 9 to 13, wherein a need for path maintenance of a downlink path in the respective requested node (SO) is characterized by a flag (MF), wherein when set flag (MF ) the data packets at the sink node (SK) are marked with the marking.

15. The method of claim 14, wherein a timer initialized with the maximum path lifetime when generating a

Downlink path is started.

16. The method of claim 15, wherein the mark flag MF and another flag (EDPF) is set by a subscriber node (SE), as soon as this becomes a requested node (SO), wherein the further flag (EDPF) with the Übertra ^¬ supply of the first, labeled with a label data packet to the sink node (SK) is deleted.

17. The method of claim 16, wherein the at least one requested node (SO) no longer provides a data packet to be sent to the sink node (SK) with the marking when the timer has expired and the further flag (EDPF) and the marking flag Flag (MF) are not set.

18. The method of claim 16, wherein the flag (EDPF) is combined with a non-negative marking resource, which takes into account the number of at least marked data packets after each request by the sink node (SK).

19. The method according to any one of claims 1 to 13, wherein a mark flag (MF) is used for the existence of a downlink path, wherein the respective requested node (SO) with it the data sent to the sink node (SK) data packets with the flag provides as long as the flag (MF) flag is set.

A method according to claim 19, wherein the flag (MF) is reset when a predetermined number of tagged data packets have been sent to the sink node (SK) from a respective requested node (SO).

21. The method of claim 19, wherein the flag (MF) is reset if the requested node (SO) is no longer included in the address list in a predetermined number of received path messages.

22. The method according to any one of claims 14 to 21, wherein the flag (MF) is set by:

a path message in which the subscriber node (SE) is included in the address list, and / or

Data packets that the requested node (SO) from the Sen ^¬ kenknoten (SK) receives.

23. A computer program product that can be loaded directly into the internal storage rather a digital computer and comprises software code sections with which the steps according ei ^¬ nem of the preceding claims are performed when the product runs on the computer.

24. Network (NET), in particular a wireless sensor network, wherein the network (NET) has nodes in the form of a sink node (SK) and a plurality of subscriber nodes (SE), wherein between the sink node (SK) and at least one of the requested node (SO) of the subscriber node (SE) of the communication path (PF) can be built up for the bidirectional transmission of Da ^¬ tenpaketen, wherein:

- An uplink path from a respective one of the Teilnehmerkno ^¬ th (SE) to the sink node (SK) can be determined that

a periodic exchange of path messages between adjacent nodes (SK, SE) of the network (NET), wherein a respective path message the shortest distance to the sink node (SK), in particular in the form of a metric signals, and

a downlink path from the sink node (SK) to the at least one requested node (SO) can be determined by

in at least one of the path messages sent by the sink node (SK) an address list is inserted, which comprises the address of a respective requested node (SO);

each subscriber node (SE), which receives a path message with an address list, inserts the ad ^¬ ressliste to the transmitted by him path message; and

- The one or more addressed in the address list subscriber node (SE) on receipt of the path message with the address list as requested nodes (SO) in a dedicated send state.