U.S. patent application number 13/042080 was filed with the patent office on 2011-06-30 for wireless routing selection system and method.
This patent application is currently assigned to TRAPEZE NETWORKS, INC.. Invention is credited to Gary Morain, James Murphy.
Application Number | 20110158122 13/042080 |
Document ID | / |
Family ID | 39416825 |
Filed Date | 2011-06-30 |
United States Patent
Application |
20110158122 |
Kind Code |
A1 |
Murphy; James ; et
al. |
June 30, 2011 |
WIRELESS ROUTING SELECTION SYSTEM AND METHOD
Abstract
A technique involves untethered access points (UAPs) that can
broadcast estimated transmission time (ETT) that represents an
estimated time it would take for a packet to be transmitted from
the first UAP to an AP that is wire coupled to a network. The
proposed system can offer, among other advantages, accurate ETT
values for use by UAPs of a wireless network.
Inventors: |
Murphy; James; (Pleasanton,
CA) ; Morain; Gary; (San Jose, CA) |
Assignee: |
TRAPEZE NETWORKS, INC.
Pleasanton
CA
|
Family ID: |
39416825 |
Appl. No.: |
13/042080 |
Filed: |
March 7, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11604075 |
Nov 22, 2006 |
7912982 |
|
|
13042080 |
|
|
|
|
60812403 |
Jun 9, 2006 |
|
|
|
Current U.S.
Class: |
370/252 ;
370/328 |
Current CPC
Class: |
H04W 40/14 20130101;
H04L 45/121 20130101 |
Class at
Publication: |
370/252 ;
370/328 |
International
Class: |
H04W 40/04 20090101
H04W040/04; H04L 12/26 20060101 H04L012/26 |
Claims
1. A method comprising: receiving, at a first wireless node, an
estimated transmission time (ETT) from each wireless node from a
plurality of wireless nodes that are within a range of the first
wireless node, the ETT for each wireless node from the plurality of
wireless nodes is a next-hop-to-destination-path ETT (ETTp)
associated with one remaining wireless node from the plurality of
wireless nodes; at the first wireless node, adding for each
wireless node from the plurality of wireless nodes a link ETT
(ETT1) to a corresponding ETTp to determine a node-specific path
metric for that wireless node; and at the first wireless node,
selecting a next hop based on the determined node-specific path
metrics.
2. The method of claim 1, wherein each ETTp is a function of an
ETT1, another ETTp, and a node transmission time of a second
wireless node from the plurality of wireless nodes.
3. The method of claim 1, further including, at the first wireless
node, calculating an advertised ETTp for the first wireless node,
the advertised ETTp based on at least one ETT1, the ETTp of the
first wireless node, and a node transmission time of the first
wireless node.
4. The method of claim 1, further including broadcasting an
advertised ETTp from the first wireless node to a second wireless
node from the plurality of wireless nodes.
5. The method of claim 1, further including measuring an ETT1 from
the first wireless node to each wireless node from the plurality of
wireless nodes.
6. The method of claim 1, further including: placing a packet on an
egress queue of the first wireless node at a first time; receiving
an acknowledgement that the packet was received by a second
wireless node from the plurality of wireless nodes at a second
time; and measuring an ETT1 between the first wireless node and the
second wireless node based on the first time and the second
time.
7. The method of claim 1, further including: receiving a packet on
an ingress interface of a wireless node from the plurality of
wireless nodes at a first time; placing the packet on an egress
interface of that wireless node at a second time; and calculating
the ETTp of that wireless node based on the first time and the
second time.
8. An apparatus comprising: a first access point configured to be
wirelessly coupled to a second access point; the first access point
is configured to broadcast an estimated transmission time (ETT) for
a packet to be transmitted from the first access point to the
second access point, the ETT including an estimated node transition
time (NTT) at the first access point and an ETT over a link to the
next hop that is based on current load.
9. The apparatus of claim 8, the first access point configured to
transmit the packet to a network via a station.
10. The apparatus of claim 8, the first access point is configured
to compare a next-hop-to-destination-path ETT (ETTp) of the second
access point to an ETTp advertised by a third access point, and to
send the first packet to the third access point when the advertised
ETTp of the third access point is lower than the ETT of the second
access point.
11. The apparatus of claim 8, the first access point is configured
to calculate an ETT between the first access point and the second
access point by queuing the first packet to be sent to the second
access point and by measuring the amount of time the first packet
is queued.
12. The apparatus of claims 8, the first access point is configured
to calculate the ETT between the first access point and the second
access point by sending the first packet to the second access
point, receiving an acknowledgment of receipt from the second
access point, and measuring the amount of time between sending the
packet and receiving the acknowledgment.
13. The apparatus of claim 8, wherein the first access point is
untethered.
14. The apparatus of claim 8, wherein the first access point is
untethered and the second access point is tethered.
15. An apparatus, comprising: an estimated transmission time (ETT)
engine configured to receive an estimated path transmission time
(ETTp) advertised for each wireless node from a plurality of
wireless nodes linked to an access point (AP), the ETTp for each
wireless node from the plurality of wireless nodes being a function
of a link ETT (ETT1), the ETTp for a remaining wireless node from
the plurality of wireless nodes, and a node transition time (NTT)
of that wireless node; the ETT engine configured to measure, for
each wireless node from the plurality of wireless nodes, the ETT1
between the AP and that wireless node; and the ETT engine
configured to determine a node-specific path metric for each
wireless node from the plurality of wireless nodes, based on the
measured ETT1 and the ETTp for that wireless node; and a next hop
selector coupled to the ETT engine and configured to select a
transmission path for a message received at the AP, based on the
node-specific path metrics.
16. The apparatus of claim 15, wherein the ETT engine is configured
to calculate an advertised ETTp for the AP, based on the measured
ETT1s and the received advertised ETTps.
17. The apparatus of claim 15, wherein the ETT engine is configured
toe to calculate the advertised ETTp for the AP as a function of
one of (1) the measured ETT1's, (2) a received advertised ETTps or
(3) a computed NTT of the AP.
18. The apparatus of claim 15, wherein the AP computes an NTT as a
function of an amount of time to be enqueue the message within the
AP for transmission to another node.
19. The apparatus of claim 15, wherein the ETT engine is configured
to calculate each ETT1 as an indication of an amount of time
between a packet being enqueued at an egress interface of the AP
and an acknowledgement of the packet being received by the AP.
20. The apparatus of claim 15, further including: an ETTp broadcast
engine coupled to the ETT engine and configured to broadcast the
advertised ETTp for the access point, from the access point to a
wireless node from the plurality of wireless nodes.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. application Ser.
No. 11/604,075, entitled "Wireless Routing Selection System And
Method," filed Nov. 22, 2006, which claims priority to and the
benefit of Provisional Patent Application Ser. No. 60/812,403
entitled "Wireless Routing Selection System And Method," filed Jun.
9, 2006, both of which are incorporated herein by reference in
their entireties.
BACKGROUND
[0002] Next hop selection in a wireless protocol is made by
selecting a least cost hop. Historically, cost has been determined
by hop count, signal strength, error rate, utilization, and other
factors. One technique for wireless routing selection involves
defining cost based on expected transmission time (ETT) for some
link (ETT1).
[0003] For example, link cost may be determined by measuring the
transmission time to send a 1 Mbps stream of packets across the
link and measuring its transmission time for some number of bytes.
An algorithm may measure for each available bandwidth across the
link, and the transmission time is defined as the time from when
the packet is scheduled (specifically, sent to the radio) and the
time that an acknowledgement is received.
[0004] The improvement of algorithms for next hop selection are the
subject of research. Any improvements may have significant
repercussions on the relevant technologies. Accordingly, any
improvement in next hop selection would be advantageous.
[0005] These are but a subset of the problems and issues associated
with wireless routing selection, and are intended to characterize
weaknesses in the prior art by way of example. The foregoing
examples of the related art and limitations related therewith are
intended to be illustrative and not exclusive. Other limitations of
the related art will become apparent to those of skill in the art
upon a reading of the specification and a study of the
drawings.
SUMMARY
[0006] The following embodiments and aspects thereof are described
and illustrated in conjunction with systems, tools, and methods
that are meant to be exemplary and illustrative, not limiting in
scope. In various embodiments, one or more of the above-described
problems have been reduced or eliminated, while other embodiments
are directed to other improvements.
[0007] A wireless network system is typically coupled to a wired
network at some point. Such a point is sometimes referred to as an
access point (AP). A plurality of untethered APs (UAPs) may be
coupled to one another, and eventually to the AP, to allow a
wireless network to grow to practically any size. However, as the
network grows in size using UAPs, it becomes more difficult to
figure out a best path from a mobile station, through the UAPs to
the AP in an optimal fashion.
[0008] Advantageously, UAPs can broadcast estimated transmission
time (ETT) that represents an estimated time it would take for a
packet to be transmitted from the first UAP to the AP. Thus, a UAP
that is right next to the AP should be able to give a low ETT to
the AP. As the advertised ETTs percolate through the wireless
network, UAPs can eventually settle on optimal paths to the AP. The
better the estimate, the more likely the optimally chosen paths are
actually optimal.
[0009] The proposed system can offer, among other advantages,
accurate ETT values for use by UAPs of a wireless network. This and
other advantages of the techniques described herein will become
apparent to those skilled in the art upon a reading of the
following descriptions and a study of the several figures of the
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Embodiments of the invention are illustrated in the figures.
However, the embodiments and figures are illustrative rather than
limiting; they provide examples of the invention.
[0011] FIG. 1 depicts an example of a rate aware wireless
system.
[0012] FIG. 2 depicts an example of a weighted graph of source,
next hop, and destination nodes.
[0013] FIG. 3 depicts an example of a system in which an ETTp
calculation includes time spent on an output queue.
[0014] FIG. 4 depicts a graph that provides a conceptual depiction
of queue latency.
[0015] FIG. 5 depicts an example of a wireless network system that
includes a plurality of untethered APs (UAPs).
[0016] FIG. 6 depicts a flowchart of an example of a method for
selecting a next hop.
[0017] FIG. 7 depicts a flowchart of an example of a method for
measuring ETT1 to a node.
[0018] FIG. 8 depicts a flowchart of an example of a method for
advertising an ETTp.
[0019] FIG. 9 depicts a flowchart of an example of a method for
calculating NTT.
DETAILED DESCRIPTION
[0020] In the following description, several specific details are
presented to provide a thorough understanding of embodiments of the
invention. One skilled in the relevant art will recognize, however,
that the invention can be practiced without one or more of the
specific details, or in combination with other components, etc. In
other instances, well-known implementations or operations are not
shown or described in detail to avoid obscuring aspects of various
embodiments, of the invention.
[0021] FIG. 1 depicts an example of a rate aware wireless system
100. In the example of FIG. 1, the system 100 includes a node 110,
a node 120, and a node 130. For illustrative purposes, the node 110
and the node 130 are currently linked via active link 112, while
the node 120 and the node 130 are not currently linked, as
represented by the candidate link 122. In an embodiment, the
candidate link 122 is periodically measured to determine if it is a
better route than the active link 112. Optionally, if the node 130
is a next hop from a source node to a destination node, the node
130 may be linked to another node (not shown) through a next hop
link 132.
[0022] In the example of FIG. 1, the node 110 advertises an
estimated transmission time (ETT) for the path (ETTp) to a
destination. ETTp 114 is the sum of ETT for each link (ETT1) from
the source (e.g., the node 110) to the destination (not shown).
ETTp 124 is the sum of ETT1 from the source (e.g., the node 120) to
the destination (not shown). Optionally, the node 130 advertises an
ETTp 134 that is the ETTp from the node 130 to the destination
(passing through either the node 110 or the node 120). ETTp 134 is
optional because it will only exist if the node 130 is a next hop
node.
[0023] FIG. 2 depicts an example of a weighted graph 200 of source,
next hop, and destination nodes. The weights of the edges in the
graph 200 are ETT1 between two nodes of the graph 200. ETTp is the
sum of ETT1 from a source node 202 to a destination node 206.
Typically, there are multiple next hop nodes 204-1 to 204-N
(referred to collectively as nodes 204) between the source node 202
and the destination node 206, though it is possible to have none.
As is shown in FIG. 2, the ETT1 from the source node 202 to the
node 204-1 has an ETT1.sub.0. In general each of the nodes 204 has
an ETT1x to the next hop, where x=the ordinal position of the
current node. For example, the ETT1.sub.1 is the ETT1 from the node
204-1 to the node 204-2. As another example, the ETT1.sub.N is the
ETT1 from the node 204-N to the destination node 206.
[0024] In some embodiments, the ETTp calculation is for the time a
packet is sent from a radio until the time an acknowledgement is
received. This, however, does not include time spent on a queue
waiting for the radio to become available. Advantageously, by
including the time spent on the queue, the ETTp calculation can
take into consideration the real time it takes to transmit a packet
based on load and utilization.
[0025] FIG. 3 depicts an example of a system 300 in which an ETTp
calculation includes time spent on an output queue. In the example
of FIG. 3, the system 300 includes a wireless device 302, an access
point (AP) 304, and an AP 306, a wireless switch 308, and a wired
network 310. It may be noted that the AP 304 is depicted as an
untethered AP. In an embodiment, any number of untethered APs could
be coupled together to reach the tethered AP 306.
[0026] In the example of FIG. 3, the wireless device 302 includes a
queue 312, with packets 314-1 to 314-N enqueued thereon. The packet
314-1 is presumably a first packet of a stream of packets than the
wireless device 302 is trying to send to the AP 304. However, the
AP 304 may not be available, which results in the packet being
enqueued in the queue 312, as shown. The packet 314-N is the last
packet to be enqueued prior to the packet 314-1 finally being sent
to the AP 304. Thus, the example of FIG. 3 illustrates the queue
312 just before the packet 314-1 is sent to the AP 304 (and
dequeued). The time spent waiting may be referred to as radio
availability latency because it measures the time it takes for a
radio (at the AP 304, in this case) to become available.
[0027] The AP 304 has a comparable queue 316, which is coupled to
an ETT engine 318. The wireless device 302 may or may not have an
ETT engine to determine how long a packet is enqueued on the queue
312, but in the example of FIG. 1, no such engine is present at the
wireless device 302. The queue 316 functions in a manner quite
similar to that described with reference to the queue 312. At the
AP 304, however, the ETT engine 318 actually measures the amount of
time a packet is enqueued. This radio availability latency can be
added to an advertised ETTp, as described later with reference to
FIG. 1, to give a more accurate measure of ETT for a packet.
[0028] Advantageously, ETT can be used by a next hop selector to
decide upon an optimal next hop. In an embodiment, each AP includes
a next hop selector.
[0029] FIG. 4 depicts a graph 400 that provides a conceptual
depiction of queue latency. In the example of FIG. 4, the graph 400
includes (for illustrative purposes) a flat, or static, link rate
402 and a data rate 404 that increases over time. Where the link
rate 402 is greater than the data rate 404, the link is
under-utilized, as shown by the shaded link underutilization
portion 406 of the graph 400. The link saturation point 408 is at a
time where the link rate 402 and the data rate 404 are the same. At
the link saturation point 408, the link is fully utilized. Where
the link rate 402 is less than the data rate 404, the link is
congested, as shown by the shaded link congestion portion 410 of
the graph 410. When the link is congested, packets will arrive at
an output queue, such as the queue 316 (FIG. 3) at a rate that is
greater than the rate at which the packets are dequeued (and
transmitted). Thus, the time spent waiting on the queue will grow
as the link grows more congested. Advantageously, an ETT engine,
such as the ETT engine 318 (FIG. 3) can measure this time spent
waiting and incorporate the measurement into an ETT
calculation.
[0030] From "A Radio Aware Routing Protocol for Wireless Mesh
Networks" by Kulkarni et al. defines cost based on ETT1, and how
ETT1 can be aggregated to determine ETTp. However, the algorithm
used by Kulkarni et al. can be improved in some specific cases. For
example, the choice of 1 Mbps load rate for link cost calculation
is arbitrary and may be significantly off. In an embodiment,
expected load rate (ELR) is used instead. ELR is the load that a
link would be subject to if it was selected as a next-hop.
[0031] Referring once again to the example of FIG. 1, an ELR 10-30
136 and an ELR 30-10 138 are associated with the active link 112.
The ELR 10-30 136 is intended to illustrate ELR from the node 110
to the node 130 and the ELR 30-10 138 is intended to illustrate ELR
from the node 130 to the node 110. In an embodiment, the ETT of a
link will vary greatly depending on how much traffic is inserted
into it. The more traffic you insert into a link, the higher the
probability for collisions on the link. Accordingly, the ELR 10-30
136 is calculated dynamically based on current load conditions of
the active link 112 from the node 110 to the node 130, and the ELR
30-10 138 is calculated dynamically based on current load
conditions of the active link 112 from the node 130 to the node
110. The calculated ELR may be averaged in an exponentially
decaying fashion to allow route selection stabilization.
[0032] In the example of FIG. 1, conceptually, the node 130 is
trying to select the least cost link to some destination reachable
through both the node 110 and the node 120. As shown in the system
100, the active link 112 has an ELR 10-30 136 and an ELR 30-10 138.
The ELR 10-30 136 and the ELR 30-10 138 can be used to respectively
calculate an effective data rate (EDR) 10-30 116 and an EDR 30-10
118.
[0033] EDR is the rate determined by a rate selection algorithm. In
general, the rate selection algorithm should meet the following
goals: 1) To the extent possible, the selected rate should produce
optimal throughput of packets transmitted to a client. This is not
necessarily the same thing as minimizing retries. For instance,
retransmitting one time a large packet at 54 Mbps may result in
better throughput than transmitting the same large packet at a 1
Mbps with no retries. 2) To the extent possible, the algorithm
should be computationally light. That is, it should not consume a
lot of CPU time to determine a rate to use.
[0034] An example of a rate selection algorithm is as follows
(though any applicable known or convenient rate selection algorithm
could be used): The rate selection algorithm seeks to minimize
retransmissions. For each client it maintains a `best rate` value.
The rate selection algorithm is a control system that lowers the
best rate when the rate of retransmissions exceeds 50% and raises
the best rate when the rate of retransmissions is less than 50%.
For each transmitted packet, there are one of three possible
outcomes. 1) The packet is successfully transmitted with no
retransmissions, 2) the packet is successfully transmitted with one
or more retransmissions, 3) the packet transmission is unsuccessful
after all retransmission attempts.
[0035] For each client, a counter is maintained. When a packet is
successfully transmitted with no retransmissions, this counter is
incremented by 3. When a packet is successfully transmitted but
with retransmissions, the counter is decremented by 6. When a
packet is not successfully transmitted, the counter is not changed.
When the counter reached a value of -50, then the next lower rate
is made the best rate. When the counter reaches a value of 100, the
next higher rate is used as the best rate; however, the best rate
is not increased if it has been increased in the past 60 seconds.
This prevents the best rate from increasing too fast.
[0036] For each packet, transmissions are attempted using up to
four rates. [0037] The best rate is tried 1 time. This is the
initial transmission attempt, not a retransmission. [0038] The next
best rate is tried for configured number of retransmissions minus
2. For example, the default value for the retry count is 5, and so
by default the next best rate is tried 3 times. [0039] The next
lower rate is tried 1 time. [0040] The lowest rate supported by the
radio is tried 1 time.
[0041] This rate fall back schedule has the following properties.
1) If the best rate is successful, then there are no retries and
the client's counter is increased. 2) If the best rate fails, then
the next lower rate is used multiple times. The range of the next
best rate is better than the best rate, and so the next best rate
has a higher probability of success. The client's counter will be
decremented in this case to reflect that the best rate was
unsuccessful. 3) The radio's lowest rate has the best range, and so
if it fails, then the client is not reachable or the failure is due
to factors not related to distance. In this case, the client's
counter is unchanged because the failure is not related to
rate.
[0042] If the EDR is actually determined ELR, the algorithm further
reduces the bandwidth required to compute ETT1, since the EDR need
not be calculated through synthesized load. Notably, as shown in
FIG. 1, the EDR 20-30 126 uses the ELR 10-30 136, and the EDR 30-20
128 uses the ELR 30-10 138. Accordingly, for the candidate link 122
as well, a synthesized load is not used. Advantageously, in both
cases, ELR is calculated based on existing traffic.
[0043] It should be noted that sensing all data rates is less
efficient than using the techniques described herein.
Advantageously, by using EDR, all possible rates need not be
tested, making this technique more efficient. Moreover, selected
rates may not be the rate actually selected by a radio transmission
module. For example, if data rate selection does not yield an
answer that matches an algorithm such as Kulkarni's, the actual
ETT1 will be different than the expected ETT1 and the algorithm
will make suboptimal decisions. So using EDR can lead to
performance improvements as well.
[0044] In an embodiment, the ETTp calculation can be improved by
considering the amount of time a packet spends being processed in
intermediate nodes. This is the time it takes to receive a packet
on some interface and queue it on its egress interface. This time
is referred to as node transit time (NTT). Therefore, in a
non-limiting embodiment, ETTp=ETT1+ETTp_nh+NTT, where ETT1 is the
link between a node and a next hop node, ETTp_nh is the ETTp
advertised by the next hop node (e.g., the best advertised ETTp of
potential next hop nodes), and NTT is the time a packet spends
transiting a node. As was previously described, the ETT
calculations include the time a packet spends in a queue waiting
for a radio to become available. Conceptually, the NTT is the time
a packet spends in a node waiting to be enqueued.
[0045] The techniques described herein work best when there are
relatively few interesting destinations. Advantageously, this is
exactly the case in most IP network environments. Most hosts are
trying to communicate to their next hop IP router, which is
typically eventually accessed over a wired network. Hence, the
techniques described herein help answer the question "how do I get
to the wired network?" Only a single destination need be evaluated
and only a single value to ELR needs to be maintained.
[0046] FIG. 5 depicts an example of a wireless network system 500
that includes a plurality of untethered APs (UAPs). In the example
of FIG. 5, the system 500 includes a UAP 502, a UAP 504, a
plurality of UAPs 506-1 to 506-N (referred to collectively as UAPs
506), and an AP 508. For illustrative purposes only, a path for
wireless traffic from a station 510 to the AP 508 is depicted as a
dashed line. Potential paths for wireless traffic from the station
510 to the AP 508 are depicted as dotted lines.
[0047] In the example of FIG. 5, wireless traffic from the station
510 is directed to an AP with which the station 510 has associated.
Typically, though not always, the AP with which the station
associates is the one that is closest to the station 510 (or the
one that detects the highest RSSI from the station 510). In the
example of FIG. 5, the closest station is presumed to be the UAP
502.
[0048] In the example of FIG. 5, presumably, at some stage it was
determined that the best path from the station 510 to the AP 508
was from the USP 502 to the UAP 504 and finally to the AP 508.
However, the system 500 continuously or occasionally measures ETT
for various nodes, as was described above. Thus, it may be
determined that a different path (through one of the UAPs 506) is
better. It should be noted that, depending upon the implementation
and/or embodiment, a tethered AP could be rejected as a next hop in
favor of a UAP, followed by an eventual hop to some other AP. This
would be the case if ETTp from the UAP was better than the ETTp
directly to the tethered AP. Presumably, this would be unusual, but
not impossible.
[0049] At the UAP 502, the goal is to send traffic to the least
expensive AP that is wired to a network. By least expensive, what
is intended is that a weighted graph with edges that are ETT
between nodes, would yield the smallest result possible (or
practical). This AP may or may not be the AP closest to the UAP
502. The UAP 502, for illustrative purposes, is illustrated as a
large circle with various components. However, the UAP 504, the
UAPs 506, and/or the AP 508 may have similar components (not
shown).
[0050] In the example of FIG. 5, the UAP 502 includes an ingress
interface 512, an ETTp engine 514, a next hop selector 516, and an
egress interface 518. The ETTp engine 514 includes an ETTp_nh
module 520, an NTT module 522, and an ETT1 module 524. In
operation, in a non-limiting embodiment, the UAP 504 and the UAPs
506 have broadcast advertised ETTp values that are associated with
the path from the respective nodes to a destination, such as the
wired network. The ETTp_nh module 520 receives each of the
advertised ETTps.
[0051] Some time later (or concurrently) the station 510 sends
packets to the UAP 502, which are received at the ingress interface
512. The NTT module 522 receives an indication, such as a first
timestamp, that a first packet has been received. As much as is
practical, it would probably be valuable to have the timestamp
represent the exact time the first packet was received at the
ingress queue 512, though an estimate may be used. At this point,
the ETTp engine 514 knows only ETTp values for the UAP 504 and UAPs
506, but has no link information. It should be noted that in
practice there will typically be link information as described
later. Nevertheless, assuming for a moment that no link information
is available, the ETTp engine 514 can provide the advertised ETTp
values to the next hop selector 516, which picks an appropriate
optimal path to the destination based on the advertised ETTp
values. Specifically, the next hop selector 516 chooses the
shortest (e.g., lowest weight) path to the destination.
[0052] The first packet is enqueued at the egress interface 518, as
appropriate. It may be noted that the first packet may or may not
need to be enqueued in a case where the relevant link is
underutilized (or saturated but not congested). In any case, when
the first packet is received at the egress interface 518, the NTT
module 522 receives an indication, such as a second timestamp, that
the first packet has been received at the egress interface 518. At
this point, the NTT module 522, by comparing, for example, a first
timestamp and a second timestamp, can calculate the amount of time
that the first packet spent at the UAP 502. This information is
useful for purposes that are described below.
[0053] The first packet is sent from the egress interface 518 to
the UAP 504. For illustrative purposes, it is assumed that the UAP
504 is the next hop in an optimal path. In a non-limiting
embodiment, the UAP 504 sends an acknowledgement, as soon as the
first packet is received, that the first packet was received. The
acknowledgement is received at an acknowledgement interface 526. It
should be noted that the acknowledgement interface 526 may be part
of a radio interface that includes the ingress interface 512 (or
even the egress interface 518). In any case, the acknowledgement
interface 526 provides the ETT1 module 524 with an indication, such
as a timestamp, that an acknowledgement was received from the next
hop node. The ETT1 module 524 uses the indication (e.g., second
timestamp) that was generated when the first packet was enqueued on
the egress interface 518 and the indication (e.g., third timestamp)
that was generated upon receipt of the acknowledgement to provide
an ETT1 value.
[0054] At this point, the ETTp engine 514 has enough information to
know ETTp from the UAP 502 to the destination. Specifically,
ETT1+NTT+ETTp_nh=ETTp from the UAP 502 to the destination. This
ETTp value can be provided to an ETTp broadcast engine 528. In the
example of FIG. 5, the broadcast engine 528 is not providing any
value to the station 510 (unless the station 510 includes a means
for making use of the broadcast ETTp). However, the UAP 504, for
example, may have a broadcast engine that functions similarly. Such
an engine could be used to provide the advertised ETTp to the
ETTp_nh module 520, as described previously.
[0055] FIG. 6 depicts a flowchart 600 of an example of a method for
selecting a next hop. In the example of FIG. 6, the flowchart 600
starts at module 602 where ETTp is received from nodes that are
within range. In an embodiment, the node at which a next hop is
being selected listens for any node within range. In an
alternative, the potential next hop nodes may be restricted in some
manner.
[0056] In the example of FIG. 6, the flowchart 600 continues to
module 604 where ETT1 is measured to each node within range. Since
the ETT1 is an actual measurement (rather than a guess), the ETT1
is a relatively accurate representation of actual link
characteristics. Any applicable known or convenient technique may
be used to measure ETT1. An example of a method for measuring ETT1
to a node is described later with reference to FIG. 7.
[0057] In the example of FIG. 6, the flowchart 600 continues to
module 606 where ETT1 is added to ETTp from each node to arrive at
a node-specific path metric, and to module 608 where a next hop is
selected that is associated with a minimum of the node-specific
path metrics. Notably, the lowest ETTp plus a corresponding ETT1 is
not necessarily lower than some other ETTp plus a corresponding
ETT1.
[0058] FIG. 7 depicts a flowchart 700 of an example of a method for
measuring ETT1 to a node. In the example of FIG. 7, the flowchart
700 starts at module 702 where a packet is placed on an egress
queue. Packets are placed on egress queues when they are ready to
be transmitted to a next hop or destination.
[0059] In the example of FIG. 7, the flowchart 700 continues to
modules 704 where a first timestamp is taken. The first timestamp
represents the approximate time at which the packet was placed on
the egress queue. The packets may be left on an egress queue for a
relatively long time if they are enqueued at a faster rate than
they are dequeued (and transmitted). Typically, if a packet remains
in the egress queue for a relatively long period of time, a link
between the current queue and the next hop or destination is
congested.
[0060] In the example of FIG. 7, the flowchart 700 continues to
module 706 where an acknowledgement is received that the packet was
transmitted. The acknowledgement may be in the form of, by way of
example but not limitation, an 802.11 ack. Other protocols may have
other techniques or terminologies, but any applicable known or
convenient means for acknowledging that the packet was received may
be used, depending upon the implementation and/or embodiment.
[0061] In the example of FIG. 7, the flowchart 700 continues to
module 708 where a second timestamp is taken. The second timestamp
represents the approximate time at which the packet that was placed
on the egress queue, plus the time to reach the next hop, plus the
time to receive the acknowledgement (which is normally sent
immediately upon receipt of the packet). Alternatively, the second
timestamp could be placed in the acknowledgement such that the time
to receive the acknowledgement is omitted.
[0062] In the example of FIG. 7, the flowchart 700 continues to
module 710 where a difference between the first timestamp and the
second timestamp is found. In a non-limiting embodiment, this
entails calculating an exponentially decaying average of the
difference. In any case, the value found may be used as an
ETT1.
[0063] FIG. 8 depicts a flowchart 800 of an example of a method for
advertising an ETTp. In the example of FIG. 8, the flowchart 800
starts at module 802 where an advertised ETTp is calculated. ETTp
is calculated by selecting an advertised ETTp from some other node
and adding local NTT. NTT may be, by way of example but not
limitation, an exponentially weighted average of the time it takes
to transmit a packet from an ingress to an egress queue in a node.
An example of a method for calculating NTT is described later with
reference to FIG. 9.
[0064] In the example of FIG. 8, the flowchart 800 continues to
module 804 where the advertised ETTp is broadcast. In an
alternative embodiment, the ETTp may be multicast to a subset of
nodes within broadcast range. Any nodes within range may use the
advertised ETTp when selecting a next hop, if applicable.
[0065] FIG. 9 depicts a flowchart 900 of an example of a method for
calculating NTT. In the example of FIG. 9, the flowchart 900 starts
at module 902 with receiving a packet on an ingress interface. The
packet may be received from a wireless station, such as a mobile
device or UAP.
[0066] In the example of FIG. 9, the flowchart 900 continues to
module 904 where a first timestamp is taken. The first timestamp
represents the point in time when the packet is first received at
the node.
[0067] In the example of FIG. 9, the flowchart 900 continues to
module 906 where the packet is forwarded to an appropriate egress
interface. Techniques for forwarding packets to egress interfaces
are well known in the relevant art, and are not described herein.
It is assumed that some applicable known or convenient technique is
used.
[0068] In the example of FIG. 9, the flowchart 900 continues to
module 908 where a second timestamp is taken. The second timestamp
represents the point in time when the packet has been enqueued for
sending to a next hop or destination.
[0069] In the example of FIG. 9, the flowchart 900 continues to
module 910 where a difference between the first timestamp and the
second timestamp is found. In a non-limiting embodiment, an
exponentially decaying average is used. In an y case, the derived
value may be used as the local NTT.
[0070] As used herein, access point (AP) refers to receiving points
for any known or convenient wireless access technology.
Specifically, the term AP is not intended to be limited to 802.11
APs.
[0071] Some portions of the detailed description are presented in
terms of algorithms and symbolic representations of operations on
data bits within a computer memory. These algorithmic descriptions
and representations are the means used by those skilled in the data
processing arts to most effectively convey the substance of their
work to others skilled in the art. An algorithm is here, and
generally, conceived to be a self-consistent sequence of operations
leading to a desired result. The operations are those requiring
physical manipulations of physical quantities. Usually, though not
necessarily, these quantities take the form of electrical or
magnetic signals capable of being stored, transferred, combined,
compared, and otherwise manipulated. It has proven convenient at
times, principally for reasons of common usage, to refer to these
signals as bits, values, elements, symbols, characters, terms,
numbers, or the like.
[0072] It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate physical
quantities and are merely convenient labels applied to these
quantities. Unless specifically stated otherwise as apparent from
the following discussion, it is appreciated that throughout the
description, discussions utilizing terms such as "processing" or
"computing" or "calculating" or "determining" or "displaying" or
the like, refer to the action and processes of a computer system,
or similar electronic computing device, that manipulates and
transforms data represented as physical (electronic) quantities
within the computer system's registers and memories into other data
similarly represented as physical quantities within the computer
system memories or registers or other such information storage,
transmission or display devices.
[0073] The algorithms and techniques described herein also relate
to apparatus for pertaining the algorithms and techniques. This
apparatus may be specially constructed for the required purposes,
or it may comprise a general purpose computer selectively activated
or reconfigured by a computer program stored in the computer. Such
a computer program may be stored in a computer readable storage
medium, such as, but is not limited to, read-only memories (ROMs),
random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical
cards, any type of disk including floppy disks, optical disks,
CD-ROMs, and magnetic-optical disks, or any type of media suitable
for storing electronic instructions, and each coupled to a computer
system bus.
[0074] As used herein, the term "embodiment" means an embodiment
that serves to illustrate by way of example but not limitation.
[0075] It will be appreciated to those skilled in the art that the
preceding examples and embodiments are exemplary and not limiting
to the scope of the present invention. It is intended that all
permutations, enhancements, equivalents, and improvements thereto
that are apparent to those skilled in the art upon a reading of the
specification and a study of the drawings are included within the
true spirit and scope of the present invention. It is therefore
intended that the following appended claims include all such
modifications, permutations and equivalents as fall within the true
spirit and scope of the present invention.
* * * * *