A method and apparatus for calculating a routing metric for a wireless network including retrieving configured system parameters, selecting a form of a first weight factor based on channel load/utilization and parameters of the first weight factor, selecting a form of a second weight factor based on frame/packet error rate and parameters of the second weight factor, retrieving estimated link bit rate, measuring a channel/link busy time, estimating a channel/link load, estimating a packet/frame error rate of the link and calculating the metric are described. A method and system for determining a route/path between two nodes of a wireless network including calculating a weighted radio and load aware metric by each node in the wireless network, storing the metric and using the metric to select the route/path for communication between two nodes of the wireless network based on a sum of the metrics calculated by each node of the wireless network are also described.
|
1. A method for calculating a routing metric for a wireless network comprising a plurality of nodes, said method comprising:
at a node of said plurality of nodes, retrieving parameters of said wireless network, wherein said parameters include protocol overhead and a test packet size;
selecting a form of a first weight factor based on channel load and selecting a parameter of said first weight factor;
selecting a form of a second weight factor based on packet error rate and selecting a parameter of said second weight factor;
retrieving estimated channel bit rate;
measuring a channel busy time, wherein said channel busy time is any time when any other node of said plurality of nodes within an interference range performs transmission, said transmission being detected by physical carrier sensing or virtual carrier sensing;
estimating said channel load, wherein said estimated channel load is said channel busy time divided by a measurement period;
estimating said packet error rate of the channel; and
calculating said routing metric based on said wireless network parameters, said first weight factor, said second weight factor, said estimated channel bit rate, said estimated channel load and said estimated packet error rate, wherein said routing metric is calculated by each node of said plurality of nodes in said wireless network, wherein said wireless network is a wireless mesh routing network.
14. A node for calculating a routing metric in a wireless network comprising a plurality of nodes, said node comprising:
at least one central processing unit;
a random access memory;
one or more input/output interfaces; and further comprising:
means for retrieving parameters of said wireless network, wherein said parameters include protocol overhead and a test packet size;
means for selecting a form of a first weight factor based on channel load and selecting a parameter of said first weight factor;
means for selecting a form of a second weight factor based on packet error rate and selecting a parameter of said second weight factor;
means for retrieving estimated channel bit rate;
means for measuring a channel busy time, wherein said channel busy time is any time when any other node of said plurality of nodes within an interference range performs transmission, said transmission being detected by physical carrier sensing or virtual carrier sensing;
means for estimating a channel load, wherein said channel load is said channel busy time divided by a measurement period;
means for estimating said packet error rate of said channel; and
means for calculating said routing metric based on said wireless network parameters, said first weight factor, said second weight factor, said estimated channel bit rate, said estimated channel load and said estimated packet error rate, wherein said routing metric is calculated by each node of said plurality of nodes in said wireless network, wherein said wireless network is a wireless mesh routing network.
2. The method according to
3. The method according to
4. The method according to
5. The method according to
6. The method according to
7. The method according to
8. The method according to
9. The method according to
11. The method according to
determining if a quantized form of said routing metric is to be used;
retrieving a configured number of quantization levels and a quantization factor, if the quantized form of said routing metric is to be used; and
calculating a quantized routing metric if said quantized form of said routing metric is to be used.
13. The method according to
15. The node according to
16. The node according to
17. The node according to
18. The node according to
19. The node according to
20. The node according to
21. The node according to
22. The node according to
23. The node according to
24. The node according to
means for determining if a quantized form of said routing metric is to be used;
means for retrieving a configured number of quantization levels and a quantization factor, if the quantized form of said routing metric is to be used; and
means for calculating a quantized routing metric if said quantized form of said routing metric is to be used.
26. The node according to
|
This application claims the benefit, under 35 U.S.C. §365 of International Application PCT/US2005/039597, filed Nov. 2, 2005, which was published in accordance with PCT Article 21(2) on May 10, 2007 in English.
The present invention relates to wireless networks and, in particular, to wireless mesh networks. Very specifically the present invention relates to a radio and traffic load aware routing metric for selecting a communications path in wireless mesh networks.
In wireless mesh networks, a single-hop or multi-hop path needs to be selected to forward data frames/packets from a source node/mesh point to a destination node/mesh point. The path selection is based on a metric. Such a routing metric is important for optimizing the design of routing and forwarding mechanisms in mesh networks. Routing metrics for wired or optical networks do not account for the fact that nodes share the communications medium in wireless networks. Metrics that do exist for wireless mesh networks do not consider factors such as traffic load and error rate on the radio link.
Most of the current mesh routing protocols use the minimum hop count as the metric to make the path selection decision. With this approach, the quality of the radio link and the traffic load on the link is not considered. The path with the minimum number of hops is selected to forward the data frames. However, minimal hop count paths can have poor performance because they tend to include radio links between distant nodes and the quality of links along the path may not be good, let alone optimal. The radio links with a long physical span can be lossy, incurring a number of retransmissions and a low physical layer data rate. Many radio transmission systems, for example IEEE 802.11 radios, adapt the physical layer data rate depending on the link quality. This actually results in poor throughput and reduces the efficiency of network utilization compared to selecting a path with more hops but better link quality.
A prior art metric called “expected transmission count” (EXT) has been used as a routing metric. This metric estimates the number of retransmissions needed to successfully send a unicast packet by measuring the loss rate of broadcast packets between pairs of neighboring nodes. The routing protocol selects the path with the smallest total sum of the expected number of retransmissions. EXT takes the link loss rate, i.e. the number of needed retransmissions, into consideration but it does not take the link data rate and link load into account. Two links with different data rates may have the same loss rate. A heavily loaded link may incur a low loss rate and may be selected to include in the path so that this link becomes more loaded and congestion occurs.
Another known metric called “per-hop round trip time” (RTT) has been proposed as the routing metric. This metric estimates the round trip delay of unicast probing packets between neighboring nodes. The routing protocol selects the path with the lowest total sum of RTTs. The RTT metric implicitly accounts for the link quality and traffic load to avoid heavily loaded or lossy links. However, one problem with this metric is that it requires that every node in the mesh network to send probe packets to each of its neighbors, which introduces network overhead. Furthermore, this metric does not explicitly take the link data rate into account.
In radio/wireless networks, both the link/channel quality and load varies so the value of link metric changes frequently. This may cause the path to change frequently, leading to route instability. All the above measures do not consider how to maintain the route stability while achieving quick response to the link state and network topology changes. Clearly, a metric is needed for improved routing and forwarding mechanisms for wireless mesh networks that accounts for radio link quality and traffic load as well as route stability even in the face of rapidly changing link/channel quality and load variations.
The present invention is for a radio and traffic load aware metric that can be used by routing protocols/algorithms to select a communications path in a wireless mesh network. Furthermore, the present invention is a method to achieve quick responses to link state and network topology changes while maintaining the route stability by quantizing the routing metric.
A method and apparatus for calculating a routing metric for a wireless network including retrieving configured system parameters, selecting a form of a first weight factor based on channel load/utilization and parameters of the first weight factor, selecting a form of a second weight factor based on frame/packet error rate and parameters of the second weight factor, retrieving estimated link bit rate, measuring a channel/link busy time, estimating a channel/link load, estimating a packet/frame error rate of the link and calculating the metric are described. A method and system for determining a route/path between two nodes of a wireless network including calculating a weighted radio and load aware metric by each node in the wireless network, storing the metric and using the metric to select the route/path for communication between two nodes of the wireless network based on a sum of the metrics calculated by each node of the wireless network are also described.
The present invention is best understood from the following detailed description when read in conjunction with the accompanying drawings. The drawings include the following figures briefly described below:
Let Toh denote the protocol overhead at the medium access control and physical layers, and L the test frame/packet size. Given a radio transmission system, Toh is a constant. For example, for IEEE 802.11a radio, Toh, can be set to be 185 μs. The size of test frame/packet L can be a pre-configured constant, for example, 8224 bits. L can also be, for example, an average frame/packet size or a maximum frame/packet size. Toh and L are configured in advance by a designer/administrator and stored in a configuration file in a memory/storage device/unit. Alternatively L and Toh can be configured via a local configuration mechanism or through a network management system during system installation or initialization. Furthermore, let R denote the link bit rate at which the node transmits a frame/packet of the standard size L under current channel conditions. The link bit rate depends on the local implementation of the link rate adaptation. Let Er denote the frame/packet error rate if the node transmits frames/packets of the standard size L at the transmission bit rate R. Er can be measured and/or estimated by a node in the mesh network locally. Let ρ denote the load/utilization of the channel/link. The routing metric of the present invention is a Weighted Radio and Load Aware (WRALA) link cost function. The WRALA cost function for each radio link can be calculated as
where W1(ρ) and W2(Er) are two weight functions/factors, depending on ρ and Er, respectively. Some possible forms of W1(ρ) are
W1(ρ)=1
In this case, all links are weighted equally.
In this case, links with channel load/utilization less than ρ0 are weighted equally. Links with channel load/utilization between ρ0 and ρmax are weighted with an integer K1. Links with channel load/utilization greater than ρmax are not considered in the path selection because their cost is infinite.
In this case, links with channel load/utilization less than ρ0, are weighted equally. Links with channel load/utilization between ρ0 and ρmax are given weights increasing with their channel load/utilization. Links with channel utilization greater than ρmax are not considered in the path selection because their cost is infinite. Note that form/equation (3) includes form/equation (2) implicitly as a special case, with α1=0 and A1=K1. Generally, the system designer/administrator can select suitable values of α1, A1, ρmax and ρ0 depending on targeted network revenue and application requirements.
Similarly, some possible forms of W2(Er) are:
W2(Er)=1 (1)
In this case, all links are weighted equally.
In this case, links with packet/frame error rate less than E0 are weighted equally. Links with packet/frame error rate between E0 and Emax are weighted with an integer K2. Links with packet/frame error rate greater than Emax are not considered in the path selection because their cost is infinite.
In this case, links with packet/frame error rate less than E0 are weighted equally. Links with packet/frame error rate between E0 and Emax are given weights increasing with their channel load/utilization. Links with packet/frame error rate greater than Emax are not considered in the path selection because their cost is infinite. Note that once again form/equation (3) includes form/equation (2) implicitly as a special case, with α2=0 and A2=K2. Generally, the system designer/administrator can select suitable values of α2, A2, E0 and Emax depending on targeted network revenue and application requirements.
Note that the weight functions W1(ρ) and W2(Er) are not limited to the above forms. The weight functions may take other forms.
The WRALA link cost function of the present invention represents a composite routing metric, which takes the radio resources consumed by sending a packet/frame over a particular link and the load on the link into account.
Both the link/channel quality and load varies so the value of WRALA changes frequently. If WRALA is used directly as the routing metric, the path may change frequently, leading to route instability. Therefore, in cases where the link/channel quality varies frequently such that the path may also change frequently, the present invention includes a further metric to not only achieve quick response to the link state and network topology changes but also to maintain the route stability. A quantized version of WRALA is used as the link cost function. The quantized WRALA (QWRALA) can be in the form of
QWRALA=Ceiling(M×WRALA/Q)
or
where M is the number of quantization levels and Q is the quantization factor. Generally, the system designer can choose a suitable Q depending on some targeted tradeoff of route stability and network response time to link state and topology changes. M and Q are configured in advance by a designer/administrator and stored in a configuration file in a memory/storage device/unit. Alternatively M and Q can be configured via a local configuration mechanism or through a network management system during system installation or initialization. In order to use a limited number of bits (a fixed size field) to represent the value of QWRALA, the value of QWRALA can be truncated to M+1 if it is larger than M+1.
A node can estimate the load/utilization of the channel/link to each of its neighbors. One possible method to estimate the channel load/utilization is to use the channel busy time. Due to the shared nature of wireless channels, the channel busy time is defined as any time when any node within the interference range performs transmission. When a node uses the channel to transmit a frame/packet, this channel is busy and other nodes within the interference range cannot simultaneously transmit using the same frequency. If another node attempts to transmit during this busy time, a collision occurs and the transmitted frames/packets of both nodes suffer errors. If the estimated channel busy time is Tbusy during a measurement period Tp, the channel load is ρ=Tbusy/Tp. Channel busy time is the time during which either the physical carrier sense or network allocation vector (NAV) indicates channel busy.
The WRALA/QWRALA link cost metrics of the present invention can be applied to select the path in mesh networks. It can be incorporated into the design of routing protocols/algorithms, including on-demand, proactive, and hybrid routing protocols to select the path with the lowest total sum of the WRALAs/QWRALAs between nodes of potential paths.
For example, if the WRALA/QWRALA link metric is incorporated into a proactive link state routing protocol such as OLSR and OSPF, the WRALA/QWRALA link cost for each pair of links in the mesh network needs to be estimated. A node in the mesh network locally estimates the WRALA/QWRALA link costs to each of its neighbors and announces those link costs to other nodes of the network as part of the link state information in the routing control messages. Each node maintains a routing/forwarding table that allows it to forward data frames/packets destined for other nodes in the network. The routing/forwarding table is determined based on the cached link state information generated by each node. Using the WRALA/QWRALA link cost functions as the metric, a node determines the route to a destination with the lowest total sum of WRALA/QWRALA link costs. As an example as shown in
Another example is incorporating the WRALA/QWRALA metric into an on-demand routing protocol such as AODV that uses a Route Request (RREQ) and Route Reply (RREP) mechanism to establish routes between two nodes. The path with the lowest total sum of WRALA/QWRALA link costs is discovered, created and maintained when a source node wants to send data frames/packets to some destination node. It is assumed that each node has some mechanism to determine the WRALA/QWRALA link cost to each of its neighbors. In addition to other information, the destination address and the routing metric field are contained in the RREQ and RREP messages to propagate the metric information between nodes. When a source node wants to send data to some destination node and does not have a valid route to this destination, the source node initiates route discovery by flooding a Route Request (RREQ) message to all the nodes in the network, in which the destination address is specified and the metric field is initialized to zero. It should be noted that each intermediate or destination node may receive multiple copies of the same RREQ that originates at the source node. Each of these RREQs traverses a unique path from the source node to the processing node. A processing node is any node that processes RREQs including intermediate nodes and destination nodes. When a node receives a RREQ it updates the metric field by adding the link cost between the node from which it received RREQ message and itself (called updated metric). The node then establishes/creates a reverse route to the source node or updates its current reverse route if the RREQ passed through a route with a metric better than the current reverse route to the source. The intermediate node forwards (re-floods) the RREQ if a reverse route is established/modified or the RREQ is the first copy/instance of an RREQ. When a RREQ is forwarded, the metric field in the RREQ has the updated metric that reflects the cumulative metric of the route to the RREQ's source from the forwarding/intermediate node.
After creating or updating a reverse route to the source node, the destination node or the intermediate nodes with a valid route to the destination sends a unicast Route Reply (RREP) message back to the source node. In addition to other information, the RREP message contains a metric field to propagate the metric information. The RREP establishes a forward route to the destination in the intermediate nodes and eventually in the source node. When an intermediate node receives the RREP message, it updates the metric by adding the link cost between the node from which it received the RREP message and itself. It then establishes/creates a route to the destination node or updates its current route to the destination. The intermediate node forwards the RREP in unicast to the upstream node towards the source node based on the established reverse route. The metric field in the RREP is the updated metric, which reflects the cumulative metric of the route to the destination from the forwarding/intermediate node. When the source node receives the RREP, it creates/establishes a route to the destination. After a RREP has been sent, if the destination node receives further RREQs with better metrics, the destination node updates its route to the source node and also sends a fresh RREP to the source node along the updated route. Thus, a bidirectional, optimal end-to-end metric with the lowest cumulative value of WRALA/QWRALA link costs is established between the source node and the destination node.
Referring now to
In proactive routing protocols, to maintain the route stability while achieving a reasonably quick response to the link state and topology changes, a node immediately announces the state change for one of its links to the other nodes in the network by flooding the routing control messages if and only if the changes in the WRALA/QWRALA metric for this link are greater than a threshold, compared with the value in its last announcement. The node immediately floods routing messages to announce the change in the link state if (and only if) (WRALA(current)−WRALA(last))/WRALA(last)×100%>X %,
It is to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof, for example, within a mobile terminal, access point, or a 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 tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform as shown in
It is to be further understood that, because some of the constituent system components and method steps depicted in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.
Patent | Priority | Assignee | Title |
10015720, | Mar 14 2014 | goTenna, Inc.; GOTENNA INC | System and method for digital communication between computing devices |
10050865, | Feb 28 2014 | Tyco Fire & Security GmbH | Maintaining routing information |
10230430, | Aug 21 2013 | NTT DoCoMo, Inc | Mobile station and mobile communication system |
10602424, | Mar 14 2014 | goTenna Inc. | System and method for digital communication between computing devices |
10944669, | Feb 09 2018 | goTenna, Inc. | System and method for efficient network-wide broadcast in a multi-hop wireless network using packet echos |
11082344, | Mar 08 2019 | goTenna, Inc.; GOTENNA,INC | Method for utilization-based traffic throttling in a wireless mesh network |
11108637, | Nov 08 2019 | T-MOBILE INNOVATIONS LLC | Wireless relay consensus for mesh network architectures |
11558299, | Mar 08 2019 | goTenna, Inc. | Method for utilization-based traffic throttling in a wireless mesh network |
11747430, | Feb 28 2014 | Tyco Fire & Security GmbH | Correlation of sensory inputs to identify unauthorized persons |
11750505, | Feb 09 2018 | goTenna Inc. | System and method for efficient network-wide broadcast in a multi-hop wireless network using packet echos |
11811642, | Jul 27 2018 | goTenna, Inc. | Vineā¢: zero-control routing using data packet inspection for wireless mesh networks |
8625485, | Apr 30 2009 | Hewlett Packard Enterprise Development LP | Data flow routing in a multi-hop wireless network |
8861390, | Jul 27 2011 | Cisco Technology, Inc. | Estimated transmission overhead (ETO) metrics for variable data rate communication links |
9602379, | Jul 21 2014 | Cisco Technology, Inc. | Real-time route selection based-on estimated transmission overhead |
9603079, | Dec 30 2011 | Intel Corporation | Routing for mobile nodes |
9756549, | Mar 14 2014 | goTenna Inc.; GOTENNA INC | System and method for digital communication between computing devices |
9992021, | Mar 14 2013 | goTenna, Inc. | System and method for private and point-to-point communication between computing devices |
Patent | Priority | Assignee | Title |
6229807, | Feb 04 1998 | IBM Corporation | Process of monitoring the activity status of terminals in a digital communication system |
6684247, | Apr 04 2000 | Intellectual Ventures II LLC | Method and system for identifying congestion and anomalies in a network |
6873600, | Feb 04 2000 | AT&T Corp | Consistent sampling for network traffic measurement |
20030202469, | |||
20030204616, | |||
20040093426, | |||
20060153081, | |||
20070036096, | |||
20110080853, | |||
WO40032, | |||
WO2005096566, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Nov 02 2005 | Thomson Licensing | (assignment on the face of the patent) | / | |||
Nov 18 2005 | LIU, HANG | Thomson Licensing | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 020925 | /0864 |
Date | Maintenance Fee Events |
May 11 2016 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jun 15 2020 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Aug 05 2024 | REM: Maintenance Fee Reminder Mailed. |
Date | Maintenance Schedule |
Dec 18 2015 | 4 years fee payment window open |
Jun 18 2016 | 6 months grace period start (w surcharge) |
Dec 18 2016 | patent expiry (for year 4) |
Dec 18 2018 | 2 years to revive unintentionally abandoned end. (for year 4) |
Dec 18 2019 | 8 years fee payment window open |
Jun 18 2020 | 6 months grace period start (w surcharge) |
Dec 18 2020 | patent expiry (for year 8) |
Dec 18 2022 | 2 years to revive unintentionally abandoned end. (for year 8) |
Dec 18 2023 | 12 years fee payment window open |
Jun 18 2024 | 6 months grace period start (w surcharge) |
Dec 18 2024 | patent expiry (for year 12) |
Dec 18 2026 | 2 years to revive unintentionally abandoned end. (for year 12) |