RU2405282C2 - Route selection in wireless networks - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: method is proposed for detection of route between unit of source and unit of assignment in wireless network, which includes the following stages: establishment of intermediate flag of route request message reply by means of source unit, avalanche-like mailing of route request message into wireless network and reply to message of route request by message of route reply by means of the first intermediate unit and having actual route to assignment unit. Also method is proposed for detection of best route, which includes the following stages: selection of best route by assignment unit between itself and source unit on the basis of cumulative metrics received in messages of route request received by assignment unit, generation of additional message of route reply and peer-to-peer transfer of additional message of route reply to source unit.

EFFECT: provides for fast detection of best route between source unit and one or more assignment units.

42 cl, 6 dwg

Description

Technical field

The present invention relates to wireless networks and, in particular, to wireless mesh networks. More specifically, the present invention relates to the processing of route request messages in on-demand routing protocols.

State of the art

On-demand routing protocols, such as the self-organizing distance-on-demand vector (AODV) routing protocol defined by the MANET working group in the IETF, uses the route request and route response mechanism to establish routes between two nodes in wireless mesh / ad hoc networks . When the source node wants to send data packets / frames to the destination node, the source node detects the route to the destination by broadcasting an avalanche of route request message (RREQ) over the network if the source node does not have and requires a valid route to the destination node. A return route back to the source is created by nodes in the network as they receive and redirect RREQs. When a node receives an RREQ, the receiving node responds to this request by generating a route response message (RREP) if: (1) either the receiving node itself is the destination, (2) either the receiving node has a valid route to the destination node and the "destination node only" flag "(D) in RREQ is NOT set. The RREP is sent in unicast mode to the source node by means of the established return route, and thereby creates a direct route to the destination node in the intermediate nodes and ultimately in the source node. Established routes are terminated upon expiration if they are not used during a given lifetime of the route.

In AODV, the “destination node only” flag of the RREQ message is set by the source node and is not changed by intermediate nodes. If the "destination node only" flag is set in RREQ by the source node, the intermediate node does not respond to RREQ with a RREP message, even if the intermediate / receiving node has a valid route to the destination node. He redirects / floods the RREQ to his neighbors. Only the destination node responds to this RREQ. In this mode of operation, the route detection delay can be quite significant, although the optimal actual route between the source and destination nodes is eventually detected in the process. Low latency is very important for real-time applications such as voice and video.

If the “destination node only” flag is not set by the source node, then any intermediate node with the correct route to the destination node answers the RREQ with a RREP message. The RREP message is sent back to the source node in unicast mode and establishes a direct route to the destination node. If the “voluntary RREP” (G) flag is set to RREQ, then this intermediate node also transmits gratuitous RREP to the destination node in unicast mode so that the destination node recognizes the routes to the source node. However, in AODV, if the intermediate node generates RREP (because the intermediate node has a valid route to the destination node), then the intermediate node discards the RREQ. With this approach, the source node can detect the route to the destination node more quickly, since the source node does not have to wait for the response of the destination node. However, the optimal end-to-end route may not be detected, since the route quoted at the intermediate node may not be the route with the optimal metric to the destination node. Metrics may have changed due to the dynamics of wireless networks, making a quote route less desirable. Those. due to changes in network topology, routing metrics, etc. it is possible that a route quoted at an intermediate node may become worse, or that other routes with better end-to-end metrics may become available, making other routes more desirable.

A problem solved by the present invention is how to use the RREQ and RREP mechanism in order to quickly detect an optimal metric route between a source node and one or more destination nodes.

SUMMARY OF THE INVENTION

The present invention discloses a method and system for processing / sending route request messages (RREQ) and generating route response messages (RREP) in on-demand routing protocols, an example of which is AODV, so that a route with an optimal metric can be detected without causing significant delay / route detection delays in wireless mesh / random networks. In particular, when a source node wants to find a route to a destination node, the source node floods the network in an avalanche RREQ message with a destination node specified in the destination list and a metric field initialized to 0. The RREQ message contains a new flag “intermediate response (IR) "for each destination node. The source node sets the flag corresponding to the destination node to RREQ when it initiates an RREQ flood to detect the route to the destination node (s). During RREQ floods, the first intermediate node with a valid route to the destination node responds with a RREP message to the RREQ. The RREP message is transmitted in unicast mode to the source node and thereby quickly establishes a temporary direct route to the destination. Thus, the source node can use this temporary direct route to transmit packets / frames of data with low delay / delay route detection. The first intermediate node resets / clears the IR flag in the RREQ message and sends the updated RREQ message further towards the destination node. Since the IR flag in RREQ is cleared, subsequent intermediate nodes should not respond to this RREQ and only propagate it even if subsequent intermediate nodes have a valid route to the destination node (s). RREQs eventually reach the destination node (s). Destination nodes (s) can choose a route / path with an optimal metric based on end-to-end metrics and send a new RREP back to the source node to establish a route with an optimal metric between the source node and this destination node. If the optimal path is different from the temporary direct path that is established by RREP from the intermediate node, the source node switches to the optimal path after the optimal path is established.

A system and method for detecting a route between a source node and a destination node in a wireless network are described, including setting an intermediate flag for a response to a route request message by a source node, flooding a route request message to a wireless network, and responding to a route request message with a route response message through the first intermediate a node that has a valid route to the destination node. The system and method then updates the route request message and re-floods the route request message to the wireless network. The response step, said response step thereby establishes a temporary direct route between the source node and the destination node of the wireless network. A system and method for detecting a route with optimal metrics are also described, wherein the route response message becomes the first route response message. The system and method for detecting a route with an optimal metric includes selecting a route node with an optimal metric between itself and the source node based on the total metrics received in the route request messages received by the destination node, creating an additional route response message and unicast sending an additional route response message to the source node. If the temporary direct route is a route with an optimal metric, then the additional route response message serves as confirmation, and if the temporary direct route is not a route with an optimal metric, an additional route response message is used to establish a route with an optimal metric when receiving an additional route response message source node.

Brief Description of the Drawings

The present invention is most understood from the following detailed description, illustrated by the accompanying drawings, in which the following is presented:

Figure 1 is an exemplary RREQ message format.

2 is a schematic representation of a wireless mesh network in accordance with the principles of the present invention.

Figure 3 is a schematic representation of a wireless mesh network in accordance with the principles of the present invention.

4 is a flowchart of an on-demand routing protocol method showing when the present invention is used.

5 is a flowchart of a method of the present invention.

6 is a block diagram of a node in accordance with the principles of the present invention.

Detailed Description of Preferred Embodiments

When a source node / grid point wants to transmit packets / data frames to some destination node, it checks its routing table for a route. If there is a valid route, it sends packets / frames to the next transit (relay) section specified in the routing table for this destination node. If there is no valid route, the source node initiates route detection by flooding the route request message (RREQ) over the wireless mesh / random network. Packets / data frames may originate from a node or from stations associated with the node if the node is a wireless access point. It is possible that the source node should detect routes / paths to multiple destination nodes. The source node can distribute RREQ for each destination or, to reduce the routing overhead, send a single RREQ message to the network, having a list of multiple addresses of destination nodes embedded in it.

Figure 1 is an exemplary RREQ message format, with other formats possible. The RREQ message contains, for example, the start / source node address, creator serial number, destination node address and destination serial number (or the number of destinations and a list of destination addresses and their sequence numbers), RREQ identifier, message identifier, message length, lifetime (TTL ), the number of transit sections, routing metrics, flags and other information. In addition to the “destination node only” (D) and “voluntary RREP” (G) flags, a new flag, called the “intermediate response” (IR) flag in this document, is contained in the RREQ message. Flags D and G are contained as inherited from traditional AODV. These two flags are not set / used by the source node and are ignored by intermediate nodes and destination nodes. One alternative implementation is that the RREQ message does not contain the D and G flags at all. If the RREQ message carries a list of destination addresses, then several intermediate response flags are included in the RREQ message, each of which corresponds to the destination address. When the source node wants to find a route to one or more destination addresses, it sets the "intermediate response" (IR) flag (s) corresponding to the destination address (s). It should be noted that the destination node address (s) may be Internet Protocol (IP) address (s) or Layer 2 address (s) (media access control, MAC). In order to adapt to changes in network conditions and maintain a route with optimal metrics between nodes, each active source node can optionally send a periodic RREQ message (serving RREQ) to the wireless mesh / random network for the destination address (s) with which he makes the connection. The IR flag in the serving RREQ is not set. The intermediate and destination nodes process the serving RREQ in accordance with the same rules as those used to process the non-serving RREQ in the discovery phase.

Thus, it can be seen that the distribution of non-serving and serving RREQ messages in a wireless mesh / arbitrarily organized network leads to the establishment / updating of the return route to the creator (source node) of RREQ in intermediate nodes and destination nodes. Distribution of non-serving RREQ messages also initiates RREP messages from destination nodes and possibly intermediate nodes. Distribution of RREQ service messages initiates RREP messages from destination nodes.

When an intermediate or destination node receives an RREQ message, it creates a return route to the source node or updates the current return route if the RREQ message transmitted via a route / path that suggested a better metric than the current return route to the source node. It should be noted that each node can receive several copies of the same RREQ message (starting from the same source node and having the same RREQ identifier), and each RREQ message travels a different path from the source node to the receiving node / intermediate node / destination node. If the return route is created or modified, or it is the “first copy” of the RREQ message, the RREQ message is sent (flooded). The “first copy” is used herein to indicate that this copy of the RREQ message is the first copy or time that this receiving node / intermediate node / destination node received or saw this particular RREQ message identified by the creator address and RREQ identifier. When an intermediate node sends an RREQ message, the metric field in the RREQ message is updated to reflect the total metric of the route to the RREQ source node from the intermediate node. In addition, if the IR flag for the destination node in the destination node list of the received RREQ message is set and the intermediate node has the correct route to the destination node, the intermediate node responds to the RREQ message with an RREP route response message. This route response message is transmitted to the source node in unicast mode and establishes a direct path to the destination node. The source node can then use this route to send frames / data packets to the destination node immediately. If the intermediate node replies to the RREQ message with the RREP message for the destination node in the list of RREQ destination nodes, it clears / clears the IR flag for this destination node in the RREQ message until the updated RREQ message is sent again to the network. The reason for resetting the IR flag after sending the RREP message is to suppress all RREP messages from subsequent intermediate nodes. Only the first intermediate node with a valid route to the destination node along the route traversed by the avalanche of the RREQ message responds with the RREP message for this destination node. If the IR flag for the destination is cleared / cleared in the RREQ message, the intermediate node should not respond with the RREP message, even if it has a valid route to the destination node.

After creating / establishing or updating the return route to the source node, the destination node sends the RREP message back to the source node in unicast mode. Intermediate nodes create direct routes to the destination node (s) when receiving the RREP message, and also send the RREP message to the source node. When the source node receives the RREP message, it creates a direct route to the destination node. If the destination node receives additional RREQ messages with better metrics, the destination node updates its route to the source node to the new route, and also sends a new RREP message back to the source node along the updated route. The new RREP message establishes a more optimal (updated) direct route from the source node to the destination node in the intermediate nodes and, as a result, in the source node. Once this more optimal direct route is established, the source node uses it to transmit data. As a result, a bidirectional end-to-end route with an optimal metric is established between the source node and the destination node. Using this approach, the source node can quickly obtain a route to the destination node, which is established using the RREP message to which the intermediate node responds with a valid route to the destination node. If this route is not an end-to-end route with an optimal metric between the source and destination nodes, the route is then updated to the route with the optimal metric.

Figure 2 illustrates an avalanche distribution to a wireless mesh / random network of a Route Request (RREQ) message and an intermediate node B with a valid route to a destination node E responding to a RREQ message with a RREP message. Consider an example in which the source node A tries to find the route to the destination node E. The source node A floods the route request message (RREQ) with the IR flag installed in the wireless mesh / random network. Assume that intermediate node B already has a valid BCDE route to destination node E. When intermediate node B receives RREQ, it creates a return route to the source node from which it receives RREQ as the next transit leg (source node A) of the return route / path . Intermediate Node B responds to RREQ RREP in unicast mode because it has a valid route to destination E, and the IR flag in RREQ is set.

RREP establishes a direct route to destination E at source A. Once source A creates a route / path to destination E using RREP from intermediate B, source A can start sending packets / data frames to destination E via route ABCDE. Intermediate Node B clears the IR flag in the RREQ message and sends it further. The reason for resetting the IR flag is to limit the response to the RREQ floods only to the first intermediate node with a valid path to the destination node. Other intermediate nodes further, for example, C and D, should not respond to this RREQ with RREP, since the IR flag is not set. Assume that the intermediate nodes F, G, and H do not have valid routes to the destination node E. When the intermediate nodes F, G, and H receive an avalanche of RREQ messages, they create a return route to the source node A using the node from which each of the intermediate nodes nodes F, G and H accept RREQ as the next transit leg of the return route. Each of the intermediate nodes F, G, and H then sends RREQ messages further.

In this example, destination node E receives two copies of this RREQ, each of which travels a different path: A-B-C-D-E, A-F-G-H-E. Provided that the two RREQs have reached destination E in the following order: A-B-C-D-E and then A-F-G-H-E, destination E first creates a route to source A via intermediate D as soon as destination E receives RREQ along route / path A-B-C-D-E. At this point, the return route to source node A is located at intermediate nodes B, C and D. Destination node E sends an RREP along route E-D-C-B-A. RREP just updates the route A-B-C-D-E. If there is any other destination node (s) in the RREQ destination list, such as node I, destination node E removes itself from the destination list and then sends the RREQ further (for example, to node I). If there is no other destination node (s) in the RREQ destination list, then the RREQ is not sent.

Figure 3 illustrates a wireless local area network, showing that destination E responds to RREP (1) when receiving RREQ via A-B-C-D-E and transmits a new RREP, (2) to establish a more optimal direct route / path after receiving RREQ via A-F-G-H-E. When destination E receives a RREQ that went through A-F-G-H-E, destination E determines that this RREQ has traveled along a path with a better metric to A than temporarily sending route A / B-C-D-E. Therefore, the destination node E modifies / updates the next transit section from the intermediate node D to the intermediate node H and updates the metric. Thereafter, destination node E transmits the RREP in unicast mode back to source node A via an intermediate node H, and also updates and sends RREQ if there are one or more other destination nodes in the RREQ destination list. RREP sets the route to source node A through intermediate nodes H, G and F. When source A receives this RREP, it modifies / updates the next transit section for destination node E from intermediate node B to intermediate node F. The route to destination node E changes on AFGHE.

4 is a flowchart of an RREQ message processing. When the node receives the RREQ message, it first creates / sets or updates the return route to the previous transit section from which the node received the RREQ message, if necessary, at step 410. The intermediate / receiving node can then create or update the return route to the RREQ creator as follows . If the return route to the creator of the RREQ message is not in the routing table or is invalid at steps 415 and 420, it is created or updated. The next transit in the routing table for the return route for the RREQ creator becomes the previous transit section (the node from which the RREQ message is received). If a valid return route to the RREQ creator exists, the source sequence number in the RREQ message is compared with the sequence number of the route entry in the routing table in step 425 for the return route. If the sequence number in the RREQ message is older, it is discarded and additional processing is not performed at step 445. Otherwise, the current return route to the creator is modified if the new metric is more optimal than the metric of the current route to the creator in the routing table at step 430. New the metric is defined as the metric in the RREQ message plus the linking metric between the node from which it received the RREQ message and itself. If the new metric is not more optimal than the metric of the current return route in the routing table entry, but the source sequence number in RREQ is greater than (newer) the sequence number in the routing table for the return route in step 435, the intermediate node checks if optional processing functions are supported hysteresis and caching the candidate metric route using the mesh network, at 450. If these optional processing functions are not supported, the return route to the RREQ creator is updated. is processed at step 455. When the return route is created or modified, the sequence number in the routing table for the return route is set to the source number in the RREQ message, the next transit becomes the node from which the RREQ message is received, the metric is set to the new metric, and the number of transit sections set equal to one more than the number of transit sections in the RREQ message.

If the return route to the source node is created or modified, or the RREQ message was the first copy of a new RREQ message (the RREQ ID is not visible from the source earlier) at 420 and 440, the RREQ redirection and RREP generation procedure described in this document is executed on step 475. There may be other cases where the procedure for sending an RREQ and generating an RREP described herein is executed by a node. For example, in some method of caching a candidate route with an optimal metric, RREQ messages can be stored in a waiting queue with a timer during the caching of route options. When the wait queue timer expires, the procedure for sending the RREQ and generating the RREP is executed.

The source node may transmit periodic RREQ service messages to update its active forward and reverse routes. Each time a source transmits a RREQ serving message, a route update cycle is called. It is possible that nodes that already have a return route with the optimal metric to the source node receive a RREQ message with a newer sequence number, but a route with the worst metric to the source node before receiving the RREQ message through the current route with the optimal metric. Additionally, a copy of the RREQ message distributed along the current route with the optimal metric may be lost during the flood. These events can lead to a swing of the route. In order to reduce the swing of the route and choose the route with the optimal metric during each cycle of updating routes, some type of hysteresis mechanism and caching of candidate routes with the optimal metric can be used. If at step 450 it is determined that the hysteresis and caching of the optimal route options is implemented through the mesh network, the intermediate node updates the routing table and modifies the return route if the source sequence number in the RREQ message is greater than (newer) the sequence number in the routing table entry by a value exceeding threshold value. Otherwise, the return route may be cached as a potential alternative route at 465.

If the node subsequently finds out that the current return route has deteriorated and is getting worse than the return route option, it can change to the route option defined earlier in the same update cycle. The present invention describes a method and system for sending an RREQ message and generating an RREP message for route discovery with optimal metrics without causing a large delay / delay in route detection in wireless mesh networks. The method of the present invention works with or without hysteresis and caching of optimal options / alternative routes.

5 is a flowchart illustrating a method for sending an RREQ and generating an RREP of the present invention, in which the node determines whether it is a destination node, i.e. whether one or more node addresses (self_addr) matches the requested destination address in the destination list of the RREQ rreq.dest message, at step 505. It should be noted that the node itself can have several addresses or can act as a proxy (intermediary) for other nodes. For example, a node can be an access point and generate / manage routing messages on behalf of the outdated stations associated with it (proxy for stations). The functionality for this case is similar to the situation when a node has several addresses. The destination addresses of the associated stations can be considered as alias addresses for the access point. A node is a destination node if one or more of the addresses specified in the destination list of the RREQ message belongs to it or to one of the nodes using it as a proxy. When a node receives an RREQ message in which the destination node is the node using it as a proxy, it must process the RREQ message as if the address of the destination node was its address. Moreover, the node may be the destination node for the requested addresses in the RREQ message destination list, but an intermediate node for the other requested address in the RREQ message destination list.

If one or more node addresses matches the requested destination addresses in the destination list of the RREQ message, the node generates and transmits the RREP message in unicast mode to the creator of the RREQ message for these matching destination addresses in step 510. The destination node deletes its own / used proxy address (a) from the RREQ message destination list in step 515. After that, if there are no remaining requested addresses in the RREQ message destination list in step 520, the RREQ message is discarded in step 525. If the node is not a destination node The values for any requested address in the destination list of the RREQ message (505) or there are other requested addresses in the destination list of the RREQ message, in addition to the host addresses, i.e. if the node is an intermediate node for one or more addresses in the destination list of the RREQ message, the node checks the remaining addresses in the destination list of the RREQ message as follows. Assume that rreq.dest [i] represents the (i + 1) th address in the destination list of the RREQ message. The node initializes the index (for example, i) at step 545 and checks rreq.dest [i], i.e. the first address in the destination list of the RREQ message to determine if there is an active direct route to the destination node represented by rreq.dest [i] in step 550. If the intermediate node has an active route to the destination, the route to the destination node is valid ( 555), the sequence number is at least as large as that indicated in the original RREQ message (560), and the “intermediate response (IR)” flag is set (570), the intermediate node generates an RREP message for the requested destination address in step 575, and sends the generated RREP message in unicast mode, the creator of the RREQ message on the current return route. The IR flag for this requested assignment in the RREQ message is reset at step 580. The node increments the index (for example, by one) and checks to see if there are any additional addresses in the destination list of the RREQ message at step 590. If there are any additional addresses in the destination list of the RREQ message, then the above cycle is repeated starting from step 550. That is, the loop repeats if an RREP message should be sent for the next requested destination. The cycle repeats until all addresses in the destination list of the RREQ message are verified.

The initial incoming RREQ message is checked to determine if there is more than 1 lifetime value (TTL) in step 530. If the TTL value is greater than one, then the information in the initial RREQ message is updated, including decreasing the TTL value in the outgoing RREQ message, for example, per unit at step 535. The serial number, metric, and number of transit sections of the source are also set equal to the corresponding information in the updated route record for the source at step 535. The updated RREQ message is sent at step 540.

Note that the destination node can have / use one or more addresses as a proxy, and the intermediate node can have valid route (s) to one or more destination addresses. The RREQ message may carry one or more destination addresses in the destination address list. The processing node / intermediate node / destination node can satisfy the above conditions and send an RREP message for several requested addresses in the destination list of the RREQ message. If a node sends an RREP message for multiple destinations, it can send multiple RREP messages, one for each destination, or it can send one aggregated RREP message with multiple destination addresses in the address list.

6 is a block diagram illustrating the details of a node 600 of the present invention. The assembly includes a communication link quality and load measurement module 605, a routing metrics calculation module 610, a route selection module 615, and a communication module 620. The link quality and load measurement module 605 measures the quality and load of the link / channel with each of its neighbors. It provides measurement results to routing metric calculation module 610 so that routing metric calculation module 610 can determine the link cost / metric for each of its neighbors. Note that a node can have several neighbors, several radio interfaces, and several physical / logical channels / communication lines. All of them must be measured. Each node's routing metrics calculation module 610 uses measurements made by the link quality and load measurement module, along with other information, to calculate the routing metrics for each node it communicates with. The routing metric is updated periodically. The route selection module 615 determines / selects the route / path to send / transmit data to the destination node based on the calculated routing metrics. Route selection module 615 exchanges routing control messages and data with other nodes in the mesh network via communication module 620. It should be noted that the node may have one or more radio interfaces and other communication interfaces. It should be understood that the route selection module may actually be composed of several smaller blocks or combined with other modules described herein. Additionally, it should be understood that the processes described herein (especially with respect to FIGS. 3 and 4) may be software, hardware, firmware, or any combination of the above, executed in or through a route selection module.

It should be understood that the present invention can be implemented in various forms of hardware, software, firmware, special-purpose processors, or a combination of the above, for example, in a mobile terminal, access point or cellular network. Preferably, the present invention is implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program materially implemented on a program storage device. An application program can be uploaded or executed by a machine containing any appropriate architecture. Preferably, the machine is implemented on a computing platform having hardware such as one or more central processing units (CPUs), random access memory (RAM), and input-output interfaces. The computing platform also includes the operating system and micro-command code. The various processes and functions described in this document can be either part of the micro-command code, or part of an application program (or a combination of the above), which is executed by the operating system. In addition, various other peripheral devices can be connected to a computing platform, such as an additional data storage device and a printing device.

Additionally, it should be understood that since some of the constituent system components and process steps depicted in the accompanying drawings are preferably implemented in software, the actual relationships between system components (or process steps) may differ depending on the method by which the present invention is programmed. Given the methods proposed herein, those skilled in the art will be able to take into account these and similar implementations or configurations of the present invention.

Claims (42)

1. A method for determining the location of a route between a source node and a destination node in a wireless network, wherein said method comprises the steps of: sending a route request message via the aforementioned source node to the said wireless network; and receiving a route response message to said route request message from a first intermediate node having a valid route to said destination node, wherein said first intermediate node responds to said route request message based on a flag condition in said route request message. 2. The method according to claim 1, wherein said response step establishes a time route between said source node and said destination node of said wireless network. 3. The method according to claim 1, wherein said wireless network is a wireless mesh network. 4. The method according to claim 1, wherein said route response message of said reception step is transmitted in unicast mode to said source node. 5. The method according to claim 1, wherein the address of said destination node is one of an Internet Protocol address and an access control address for a transmission medium. 6. The method of claim 1, wherein said destination node includes destination nodes that are associated with one of the proxy and the access point. 7. The method according to claim 1, further comprising the step of sending a service request message of a route request to the wireless network in order to maintain a route with optimal metrics between nodes and adapt to changes in network status. 8. The method according to claim 7, further comprising receiving a response to said serving route request message, as if it is said route request message. 9. The method according to claim 2, in which said temporary route is available for data transmission after receiving said route response message by said source node. 10. The method according to claim 1, further comprising the step of unicasting receiving an additional route response message from said destination node, said additional route response message including an optimal metric route selected by said destination node based on summary metrics received in route request messages received by said destination node. 11. The method of claim 10, wherein if said time route is said route with an optimal metric, then said additional route response message serves as confirmation, and if said time route is not said route with an optimal metric, then said additional response message of the route serves to establish said route with an optimal metric after receiving said additional route response message by said source node. 12. A device for determining the location of a route between a source node and a destination node in a wireless network, comprising: means for an avalanche-like distribution to said wireless network of a route request message by said source node; and means for responding to said route request message with a route response message via a first intermediate node having a valid route to said destination node, said intermediate node responding to said route request message based on a flag condition in said route request message. 13. The device according to item 12, in which said means for responding establishes a temporary route between said source node and said destination node of said wireless network. 14. The device according to item 12, in which said wireless network is a wireless mesh network. 15. The device according to item 12, wherein said route response message of said receiving means is transmitted in unicast mode to said source node. 16. The device according to item 12, in which the address of the destination node is one of the addresses of the Internet Protocol and the address of the access control to the transmission medium. 17. The device according to item 12, in which said destination node includes destination nodes that are associated with one of the proxy and access point. 18. The device according to item 12, further comprising means for an avalanche-like distribution to the wireless network of a serving route request message in order to maintain a route with optimal metrics between nodes and adapt to changes in network status. 19. The apparatus of claim 18, further comprising means for receiving a response to said serving route request message, as if it is said route request message. 20. The device according to clause 15, in which said temporary route is available for data transmission after receiving said route response message by said source node. 21. The device according to item 12, further comprising a means for receiving in a unicast mode an additional route response message from said destination node, said additional route response message based on the total metrics received in the route request messages received by said destination node. 22. The device according to item 21, in which if said temporary route is said route with an optimal metric, then said additional route response message serves as confirmation, and if said temporary route is not said route with an optimal metric, then said additional response message of the route serves to establish said route with an optimal metric after receiving said additional route response message by said source node. 23. A method for determining the location of a route between a source node and a destination node in a wireless network, the method comprising the steps of: receiving a route request message from said source node; and responding to said route request message with a route response message via a first intermediate node having a valid route to said destination node, said intermediate node responding to said route request message based on a flag condition in said route request message. 24. The method of claim 23, further comprising the steps of: updating said route request message; and, the above-mentioned route request message is sent in an avalanche manner to the wireless network. 25. The method of claim 23, wherein said response step establishes a time route between said source node and said destination node of said wireless network. 26. The method of claim 24, wherein said updating step further comprises resetting said flag and updating a metric in said route request message using a total metric of said route between said source node and said intermediate node. 27. The method according to item 23, in which the aforementioned wireless network is a wireless mesh network. 28. The method of claim 23, wherein said route response message of said response step is transmitted in unicast mode to said source node. 29. The method of claim 23, wherein the address of said destination node is one of an Internet Protocol address and a medium access control address. 30. The method of claim 23, wherein said destination node includes destination nodes that are associated with one of the proxy and the access point. 31. The method of claim 23, further comprising responding to the serving route request message, as if it is said route request message. 32. The method according A.25, in which the aforementioned time route is available for data transmission after receiving the said route response message by said source node. 33. A device for determining the location of a route between a source node and a destination node in a wireless network, said device comprising: means for receiving a route request message from said source node; and means for responding to said route request message with a route response message by a first intermediate node having a valid route to said destination node, said intermediate node responding to said route request message based on a flag condition in said route request message. 34. The device according to p. 33, further comprising: means for updating said route request message; and means for flooding into said wireless network of said route request message. 35. The device according to p. 33, in which the said means for responding establishes a temporary route between said source node and said destination node of said wireless network. 36. The apparatus of claim 33, wherein said updating means further comprises means for resetting said flag and means for updating a metric in said route request message with a total metric of said route between said source node and said intermediate node. 37. The device according to p, in which said wireless network is a wireless mesh network. 38. The apparatus of claim 33, wherein said route response message of said response means is transmitted in unicast mode to said source node. 39. The device according to p, in which the address of the destination node is one of the addresses of the Internet Protocol and the address of the access control to the transmission medium. 40. The device according to p, in which said destination node includes destination nodes that are associated with one of the proxy and access point. 41. The apparatus of claim 33, further comprising means for responding to said serving route request message, as if it is said route request message. 42. The device according to clause 35, wherein said temporary direct route is available for transmitting data frames after receiving said route response message by said source node.

Images