Using Asymmetric Links to Improve SSR’s RoutingPerformance

Pascal BirnstillDepartment of Computer Science

Technical University Munich, Germany

Email: birnstill@so.in.tum.de

Pengfei DiDepartment of Computer Science

Technical University Munich, Germany

Email: di@so.in.tum.de

Thomas FuhrmannDepartment of Computer Science

Technical University Munich, Germany

Email: fuhrmann@so.in.tum.de

Abstract—Empirical evidence shows that asymmetric links oc-cur frequently in wireless networks. Still, most routing protocolsassume symmetric links. Thus, they cannot exploit the additionalconnectivity and bandwidth that asymmetric links provide.

In this paper, we propose an extension of the scalable sourcerouting protocol (SSR) that enables SSR to use asymmetric links.It enhances SSR’s hello messages with a limited amount of localtopology information, which allows the nodes to discover directedcycles in the network. Such cycles provide a return path in caseswhere the forward path contains asymmetric links. With ourproposed extension, SSR can thus use asymmetric links and stillguarantee bidirectional connectivity.

We evaluate our proposals with extensive simulations. Apractical test in a 150 node test bed is ongoing work.

I. INTRODUCTION

Most routing protocols assume links to be symmetric: WhenI can hear you, you can hear me! The Ad hoc On demandDistance Vector (AODV) [1], for example, sets up routing

information along the path that a route requests travels through

the network. If one of the links was asymmetric, messages

could not travel back along the so recorded routing informa-

tion. Hence, AODV must not consider asymmetric links for its

routing at all. Other protocols suffer from similar restrictions

that make it impossible for them to benefit from asymmetric

links.

On the other hand, asymmetric links are very common

in wireless networks1. Depending on the respective setting,

several authors report between 10% and 30% links with highly

asymmetric delivery rates. Such links are not suitable for

bidirectional usage. Most routing protocols, however, implic-

itly assume paths to be completely bidirectional. Thus, these

protocols even have to ignore the reliable and potentially high-

throughput direction of asymmetric links and thus waste a

great deal of bandwidth and connectivity opportunities.

Assume for example a routing protocol running on top of

an IEEE 802.11-based [2] MAC layer. If we used a link

with highly asymmetric delivery ratio, it would be unlikely

to successfully transmit a (unicast) packet as well as the

corresponding ACK. Hence we would prefer to only use the

direction with high delivery ratio for routing (which implies

that we have to send the message per broadcast and that the

1Note that when using the term asymmetric links in this work, we alwaysrefer to links with highly asymmetric delivery rates, which are only suitablefor unidirectional usage.

network layer needs to deal with packet loss). In order to avoid

the direction with low delivery ratio, we need to establish a

more convenient reverse path.

In this paper, we study an enhancement of the scalable

source routing (SSR) protocol [3]. SSR is a DHT-inspired

routing approach. It is especially suitable for large networks

that cannot be structured hierarchically, for example large ad-

hoc and mesh networks. Our enhancement allows SSR to also

use asymmetric links. Thereby, it increases SSR’s performance

and reliability.

From a node’s point of view, we have to distinguish between

inbound and outbound asymmetric links. Inbound asymmetric

links are easy to discover by employing a common periodic

hello protocol. If a node receives a hello message, there is at

least an inbound link. With the usual requirement that a node’s

hello messages contain a list of its 1-hop neighbors, the node

can also determine if the link is in fact bidirectional. Receiving

a hello message that does not contain the own address implies

that the link is inbound asymmetric. Obviously, a node cannot

use such a link when forwarding outbound traffic.

The network can only benefit from an inbound asymmetric

link, when the information about that link propagates from the

link’s sink to its source, i. e. when the source node learns about

an outbound asymmetric link. Obviously, a node can use such

a link for forwarding.

Approaches for discovering outbound asymmetric links are

mostly based on the idea of detecting directed cycles within

the network topology graph. Formally spoken, in any directedgraph a bidirectional flow between two nodes is possible if

and only if there exists a directed cycle containing both of

the given nodes. Nodes can use the remainder of the cycle

as a reverse path around the asymmetric link. Thus, such

a cycle is not only a necessary condition to discover an

outbound asymmetric link, it is also a sufficient condition for

bidirectional communication that can exploit asymmetric links.

In this paper, we propose an algorithm that allows SSR to

exchange (partial) topology information. To discover directed

cycles it uses so-called sink trees [4] as an extension of

SSR’s hello protocol. Upon initialization, nodes assume all

links to be unidirectional. Then the nodes gradually discover

outbound asymmetric links as they identify directed cycles in

the network topology graph. They do so by evaluating received

sink trees of their 1-hop neighbors.

978-1-4244-8435-5/10/$26.00 ©2010 IEEE

Exchanging exhaustive topology information does not scale

with regard to bandwidth consumption and local storage

requirements. Thus, we employ a strategy that prioritizes and

selects appropriate topology information for inclusion into the

periodic hello messages.

We have implemented our proposed algorithm in SSR and

evaluated it in simulations with OMNeT++ [5]. Our results

show that asymmetric links indeed improve the routing per-

formance of SSR. Moreover, we found that our extension of

the hello messages incurs only a small overhead.

This paper is structured as follows. In section II we outline

related work that addresses the problem of discovering and

resolving asymmetric links. Furthermore, we refer to empirical

studies that investigate how widespread asymmetric links are

in real-life wireless networks. In section III we introduce our

optimized sink tree-based algorithm. In section IV we describe

our simulation environment and present our evaluation results.

Finally, section IV concludes our paper with an outlook to

ongoing measurements in a 150 node test bed.

II. RELATED WORK

Real world studies of wireless ad-hoc networks indicate that

asymmetric links make up a significant fraction of all links

in the network. Ganesan et al. [6] study a test bed of 150

randomly distributed nodes. They observe that at least 15% of

the links are asymmetric – even when each node transmits with

the same transmission power and in the absence of additional

radio sources. De Couto et al. [7] investigate multiple indoor

deployments of wireless ad hoc networks. They report that

up to 30% of all occurring links show highly asymmetric

delivery rates. Zhao et al. [8] analyze multiple deployments

of up to 60 Mica motes. They also conclude that asymmetric

links occur frequently. Their measurements show that 10% of

the links deviate by more than 50% in the delivery rates of

the two directions. In practice, such links can only be used for

unidirectional communication.

Several authors address the problem of detecting and using

asymmetric links in routing protocols.

Dynamic Source Routing (DSR) [9] is a fully reactive ad hoc

routing protocol, i. e. DSR’s source routes are only established

on demand. A node initiates a so-called route discovery by

flooding the whole network with a route request (RREQ)message. Each intermediate node forwards the RREQ message

after appending its own address to the source route carried

in the message. When the RREQ reaches its destination, the

nodes have established a unidirectional source route, i. e. a

route from the source to the destination of the route request.

As DSR does not assume source routes to be bidirectional,

the destination has to trigger another route discovery for the

reverse direction. By this means DSR provides support for

asymmetric links natively, but at the cost of flooding the whole

network twice. SSR and our extension entirely avoid flooding.

SSR can thus operate in much larger networks.

Marina et al. [10] proposed an extension to support asym-

metric links in AODV. Similar to the DSR protocol AODV

establishes paths on demand by flooding the network with

route request messages. While DSR assembles a source route

along the path from the source to the destination within the

RREQ message, AODV builds up state on the nodes along

the path. In regular AODV, the destination as well as each

intermediate node only handle the first copy of a RREQ

message. Marina et al. suggest to handle each copy of a RREQ

message at each intermediate node. Thereby, the protocol

ensures connectivity when there is at least one bidirectional

path between source and destination. Unlike our proposal,

Marina et al. only circumvent asymmetric links. They cannot

exploit asymmetric links. Moreover, flooding all copies of the

RREQ messages incurs a significant overhead.

Nesargi et al. [11] propose to tunnel control messages of

both, link layer and routing layer around asymmetric links.

They use a hello protocol to detect incoming asymmetric links.

Regular network layer messages then encapsulate the control

messages, for example, the link layer acknowledgments. The

actual set-up of the tunnel is left to the respective routing

protocol. In AODV, for example, the sink of an asymmetric

link would need to trigger an additional route discovery to

establish a reverse path to the asymmetric link’s source. This

again incurs a large overhead that we avoid by our integrated

approach.

Ravi Prakash [12] introduced an asymmetric link extension

for common distance vector routing algorithms. It is based

on exchanging full-fledged topology information among the

nodes in the network. This results in exchanging matrices of

size O(n2), where n is the number of nodes. Clearly, this

approach does not scale to large wireless networks, even when

sparse matrix compression schemes are applied.

Wang et al. propose A4LP [13], a location- and power-

aware routing protocol for heterogeneous ad hoc networks with

asymmetric links. In their proposal, each node holds a set of

backward and a set of forward neighbors. A node learns about

its backward neighbors by means of a common hello protocol.

Unlike our proposal, the technique of Wang et al. for resolving

forward neighbors behind asymmetric links is limited to so-

called 3-party proxy sets, i. e. sets of three neighboring nodes

that contain at least one symmetric link and that are circularly

connected among each other. Paths to destinations beyond a

node’s neighbor sets require flooding techniques and some

kind of location information like network coordinates.

Sinha et al. [14] describe an extension of their zone routingprotocol (ZRP), which supports the use of asymmetric links.

The zone of a given node is defined as the set of all nodes

in the current node’s environment that are reachable within

a certain hop radius. Unlike the common hello protocols

that exchange beacons between 1-hop neighbors only, the

ZRP extension requires each node to broadcast a list of the

backward neighbors within its zone. Based on this backward

neighbor information, a node can calculate the shortest path

to each node in its zone. Obviously, the detection and use

of asymmetric links is limited to the predefined zone radius.

Cycles that exceed the zone radius are not detected.

Ramasubramanian et al. [15] propose the bidirectional rout-

ing abstraction (BRA) for asymmetric mobile ad hoc networks.

BRA introduces a sub-routing layer, i. e. it is independent of

the actual routing protocol. BRA employs a modified Bellman-Ford algorithm to discover reverse paths around asymmetric

links within a node’s so-called locality. A locality is defined by

a given number of hops. The algorithm periodically exchanges

a reversed distance-vector reporting the distances from each

other node within the sender’s locality to the sender of a given

distance-vector message.

Jorge A. Cobb [4] introduces an algorithm, which is based

on the idea of periodically exchanging so-called sink treesbetween 1-hop neighbors. A sink tree is a data structure storing

a node’s inbound paths. It is similar to SSR’s route cache that

stores a node’s outbound paths. Cobb shows that the problem

of detecting and resolving asymmetric links is equivalent to

discovering loops in a node’s sink tree. To the best of our

knowledge, this approach incurs the lowest control overhead

of all asymmetric routing proposals so far.

In our work, we extend Cobb’s works. We propose a more

scalable variant of the sink tree-based algorithm, which only

exchanges partial sink trees according to a prioritization of a

node’s local topology information.

III. DETECTING DIRECTED CYCLES IN SINK TREES

In the subsequent sections we describe our approach for

discovering and resolving asymmetric links in detail.

A. Assumptions and Simplifications

We assume that for each pair of nodes (p, q) in a given

network topology graph, there exists a path in the direction

from node p to node q as well as in the reverse direction

from node q to node p. Formally expressed, we assume a

directed graph that is strongly connected. A directed graph

G = (V, E) is strongly connected if and only if for

each directed edge (p, q) exists at least one directed cyclecontaining the edge. This common assumption is necessary

to exclude, e. g. nodes with only inbound or only outbound

links.

Moreover, we apply the asymmetry assumption, i. e. each

link is assumed to be unidirectional until it has been proven

to be bidirectional.

B. Basic Algorithm

Sink trees as introduced by Cobb [4] contain inbound paths,

i. e. a node is the sink of all paths stored in its sink tree. 1-

hop neighbors exchange their sink trees piggy-backed onto the

hello messages that they periodically broadcast. Upon joining

the network, a node’s initial sink tree only contains the sink

node itself. It represents level 0 of the sink tree.

Let us denote the considered node as p, whose sink tree

contains only p itself at level 0. Assume that p disseminates

its sink tree within the subsequent hello message. A 1-hop

neighbor q receiving p’s hello message inserts p at level 1 of

its local sink tree. Afterwards q’s sink tree (at least) contains

the (single-hop) path q ← p. Hence, level 1 of a node’s sink

tree contains the 1-hop neighbors whose hello messages the

Fig. 1. Identifying a symmetric link to a 1-hop neighbor

node has recently received. We call this procedure the mergingof sink trees.

Now, let us assume that a 1-hop neighbor r receives a hellomessage from node q. After merging sink trees, q’s local sink

tree contains the path r ← q ← p. We hence say that the

local sink tree of node q now at least comprises three levels (0,

1 and 2). Note that a node’s level in the sink tree is equivalent

to its distance to the sink measured in hops. By this means,

the nodes’ sink trees gradually grow in breadth and - which

is more important to our purpose - in depth.

As mentioned above, we apply the assumption of asymme-

try (cf. III-A). Consequently we initially assume each particu-

lar link stored in a node’s sink tree to be unidirectional. In the

following we describe an algorithm that aims at discovering

outbound paths solely based on inbound paths stored in a

node’s sink tree. Such outbound paths potentially could either

contain an outbound asymmetric link or a reverse path, i. e. a

path to a backward neighbor behind an inbound asymmetric

link that has not been reachable so far. We will also refer to

the latter case as resolving an inbound asymmetric link.

The algorithm is based on the following elementary obser-

vation: If we discover a cycle within a node’s sink tree, i. e. if

the given sink node occurs again at a deeper level of the sink

tree, we thereby implicitly discover an outbound path.

First of all, we will concentrate on discovering a cycle

within one dedicated inbound path stored in a given node’s

local sink tree. We denote the considered sink node as s and

start with the elementary case of discovering a 2-hop cycle.

Let ni be an arbitrary 1-hop neighbor of s. Then our cycle

is given as s ← ni ← s. Obviously, we can resolve the

supposed inbound asymmetric link s ← ni with the outbound

link s → ni, i. e. by this means we identify a symmetric link

s ↔ ni.

In figure 1 we illustrate the described procedure with a

simple setting of three nodes A, B and C. Node A identifies

the symmetric link to node B upon merging the sink tree

received from node B into its own sink tree. The discovered

link is also entered into node A’s route cache. (We denote

route caches as source trees in order to emphasize the analogy

between a sink tree and a route cache.) In the final step, we

remove the duplicate entry for node A in order to not consider

Fig. 2. Resolving an inbound asymmetric link (i)

the same cycle once again.

Let us now consider cycles of k hops length with k > 2.

We express such paths formally as s ← n1 ←n2 ← . . . ← nk−1 ← s. Starting with the tail,

the second appearance of s, this inbound path delivers an

outbound path s → nk−1 → . . . → n2 → n1 to

the 1-hop neighbor n1. As mentioned above, there are two

ways to benefit from learning this outbound path. Assuming

that the path s → nk−1 → . . . → n2 → n1

contains an asymmetric link, node s learns about an outbound

asymmetric link that can be used for routing. On the other

hand, if there was an inbound asymmetric link s ← n1, the

learned outbound path would enable s to communicate with

this backward neighbor n1.

Revisiting our example (cf. fig. 2), we now consider node

A discovering the cycle A ← C ← B ← A. This cycle

delivers the outbound path A → B → C, which resolves

the inbound asymmetric link A ← C and is thus entered into

A’s source tree.

Upon detecting a cycle s ← n1 ← n2

← . . . ← nk−1 ← s spanning k > 2 hops, there is

another potential for resolving an inbound asymmetric link.

Obviously, such a cycle at least delivers a single outbound

link s → nk−1, i. e. s can directly reach its 1-hop neighbor

nk−1. Let us assume that the sink tree of s also provides a

disjoint path from the 1-hop neighbor nk−1 to s, i. e. a path of

the form s ← nn ← . . . ← nk ← nk−1. Concatenating

this path with the outbound link s → nk−1, we obtain the

cycle s ← nn ← . . . ← nk ← nk−1 ← s.

This cycle implicitly delivers the outbound path

s → nk−1 → nk → . . . → nn. If s ← nn

is an inbound asymmetric link, s can resolve this asymmetric

link with the discovered outbound path.

Figure 3 shows an example where node A applies the above

procedure for resolving the inbound asymmetric link A ← D.

After merging the sink tree received from node B into its local

sink tree, node A discovers the cycle A ← B ← C ← A.

As already depicted in the previous example (cf. figure 2)

this cycle delivers the outbound path A → C → B.

In this example, we only consider the first hop of this new

Fig. 3. Resolving an inbound asymmetric link (ii)

outbound path A → C. The sink tree of node A also contains

a disjoint inbound path A ← D ← C. Thus, we can

concatenate A → C and A ← D ← C to the cycle

A ← D ← C ← A. This cycle delivers the new outbound

path A → C → D, which resolves the inbound asymmetric

link A ← D.

C. Scalability Issues and Enhancements

If we implemented sink trees as described above, each

node’s sink tree would grow until it contained all links of

the given network. Thus the storage complexity for a sink

tree is in O(n), where n is the number of directed edges

in the network topology graph. Even if we assumed nodes

with sufficient storage capacity, it would not be practical to

periodically exchange sink trees of this size among 1-hop

neighbors.

Technically, the primary constraint that we have to meet is

the maximum transfer unit (MTU) of the underlying link layer

protocol. In practice, however, even hello messages completely

filling out the MTU can be to large. For instance, the higher

propagation delay of large messages implies an increasing

collision probability at media access.

In the following, we introduce a prioritization policy that

determines which sink tree information should be included

into the hello messages. This information replaces the list of

a node’s 1-hop neighbors that the regular SSR hello messages

contain. Obviously, this list corresponds to level 1 of the node’s

sink tree. Note that it is mandatory to completely include this

level of the sink tree in each hello message, because otherwise

the nodes could not discover their 1-hop neighborhood. Fur-

thermore, a policy to select sink tree information should only

dismiss information that exceeds a predefined boundary. Till

then we can include a node’s entire sink tree into the hello

messages.

We studied a prioritization policy that we call unresolvedlinks first. It selects paths or links of a node’s local sink tree

according to the following order of conditions:

local unresolved links � remote unresolved links� local resolved links � remote resolved links

Thus, as soon as a node’s local sink tree exceeds the

capacity of the hello message, we first of all prefer to include

paths containing unresolved inbound links, i. e. backward 1-

hop neighbors to whom we do not know a reverse path. If

there is further free capacity available in the hello message,

we also include paths that contain remote unresolved links.

After that we also include paths containing links that have

already been resolved, because these paths could be beneficial

for other nodes.

A node cannot know if a path that only contains resolved

links might be valuable for another node, i. e. if it might help

that node to resolve an inbound asymmetric link. Thus it might

be beneficial to exchange as much information as possible.

We studied two flavors of our unresolved links first policy

to decide if such an altruistic policy pays off. Both flavors

differ in the way how we apply our policy. We can either

apply it to each hello message individually or we apply it to

the entire sink tree. In the latter case, we divide the complete

local sink tree according to our policy and exchange it using

several subsequent hello messages.

Our simulations showed that the second flavor is neither

efficient at resolving local asymmetric links nor is it scalable

to larger networks. Hence, in the following, we always assume

that we apply our policy to each particular hello message.

Obviously, the introduced unresolved links first policy aims

at preferably resolving asymmetric links within a node’s

vicinity. Over time, the considered radius gradually increases

when local asymmetric links have been resolved already. As

long as asymmetric links are rare and cycles that resolve them

are typically short, asymmetric links can be resolved within

few hello message intervals.

IV. EVALUATION

We have implemented our proposed approach as part of

our Scalable Source Routing library, which runs in the net-

work simulator OMNeT++ [5]. Since, for the time being,

we wanted to investigate the practicability and scalability of

our algorithm, we employed a simplified radio and link layer

protocol only. It assumes that packets are received when the

receiving node is in the transmission range of the sending

node. Otherwise the packets are lost.

The simulated network topologies are constructed as fol-

lows. We generate a uniformly random node distribution in

a square area with up to 100 nodes that have an equal

transmission range. This results in a unit disk graph topology.

Then we select a certain percentage of the nodes at random

and equip these nodes with a larger transmission range. By

this means we induce asymmetric links. At the same time,

TABLE IAVG. FRACTION OF ACTUAL ASYMMETRIC LINKS IN OUR SCENARIOS

Fraction of wide range nodes: 10% 20%Fraction of asymmetric links: ≤ 7% ≤ 13%

0

2

4

6

8

10

12

14

16

18

0 20 40 60 80 100

#hop

s

#nodes

Plain SSR, 10% / 20% wide range nodesSSR with sink trees, 10% wide range nodesSSR with sink trees, 20% wide range nodes

Fig. 4. Average path length per payload message

we can guarantee that the network topology graph remains

strongly connected. Compared to only using symmetric links,

these asymmetric links introduce shortcuts. In our scenarios

these shortcuts bridge at least two and at most three of the

symmetric links.

We equip our scenarios with 10% and 20% of these large

transmission range nodes. Table I shows the average fraction

of asymmetric links that correspond to these values. Note that

we cannot completely avoid to introduce symmetric shortcut

links. This is the case if and only if we happen to choose a pair

of nodes as large transmission range nodes whose Euclidean

distance is smaller than the extended transmission range. As

we need to exclude the benefit introduced by these symmetric

shortcut links from our consideration, we use exactly the same

scenarios when simulating plain SSR.

Our simulations run for 120 seconds. The interval between

subsequent hello messages is set to 2 seconds and we provide

100 bytes for the sink tree information in the hello messages.

We generate random network traffic by having each node

create a payload message to an arbitrary destination every

second. We simulate 10 runs per configuration and network

size, i. e. each configuration is simulated with 10 different

topologies of the same number of nodes.

We measured the achieved routing performance based on

the average path length of all generated payload messages.

Figure 4 shows the benefit of our proposal in comparison to

plain SSR. Obviously, we achieve the shortest paths in the

scenarios with the highest fraction of asymmetric links. Hence,

we conclude that our protocol can actually benefit from the

asymmetric links.

In figure 5 we furthermore show the relative reduction of the

path lengths in scenarios with 20% large transmission range

nodes. SSR with sink trees produces paths that are on average

8

10

12

14

16

18

20

22

24

26

28

30

0 20 40 60 80 100

Rel

ativ

e re

duct

ion

of a

vera

ge p

ath

leng

th [%

]

#nodes

Fig. 5. Relative reduction of average path lengths in scenarios with 20% ofwide range nodes

about 20% shorter than the paths of the plain SSR protocol in

the same scenarios. Again we conclude that exchanging partial

sink trees according to our prioritization policy allows SSR to

effectively exploit asymmetric links for routing.

V. CONCLUSION

In this paper, we have proposed a scalable approach for

discovering and resolving asymmetric links in wireless ad hoc

networks. Our proposal is based on the exchange of partial

sink trees among 1-hop neighbors. Our protocol efficiently

piggy-backs this information onto the underlying protocol’s

regular hello messages. A prioritization policy selects the most

useful information. This policy aims at resolving local inbound

asymmetric links first.

To evaluate our proposal, we have implemented it into the

scalable source routing (SSR) protocol. Our simulations show

that our proposed protocol can reduce the average path length

in sample networks with asymmetric links by up to 20%.

Currently, we are about to explore the potential of our

proposed approach in more realistic scenarios. At first we will

study the performance in simulations with a more realistic

radio model. Additionally, we will conduct real-world mea-

surements with 150 mesh nodes in the BOWL network [16].

REFERENCES

[1] C. E. Perkins and E. M. Royer, “Ad hoc On-Demand Distance VectorRouting,” in Proc. 2nd IEEE Workshop on Mobile Computing Systemsand Applications, New Orleans, LA, USA, Feb. 1999, pp. 90–100.

[2] IEEE 802.11 Working Group, “IEEE Std. 802.11-1999: Wireless LANMedium Access Control (MAC) and Physical Layer (PHY) Specifica-tions.” 1999.

[3] T. Fuhrmann, “Scalable routing for networked sensors and actuators,” inProc. 2nd Annual IEEE Communications Society Conference on Sensorand Ad Hoc Communications and Networks, Sep. 2005.

[4] J. A. Cobb, “Forward-only uni-directional routing,” in Eleventh In-ternational Conference on Computer Communications and Networks,,October 2002, pp. 370– 375.

[5] A. Varga, “The OMNeT++ discrete event simulation system,” in Pro-ceedings of the European Simulation Multiconference (ESM’01), Prague,Czech Republic, 2001.

[6] D. Ganesan, B. Krishnamachari, A. Woo, D. Culler, D. Estrin, andS. Wicker, “An empirical study of epidemic algorithms in large scalemultihop wireless networks,” Intel Research, Tech. Rep., 2002.

[7] D. S. J. De Couto, D. Aguayo, B. A. Chambers, and R. Morris, “Per-formance of multihop wireless networks: shortest path is not enough,”SIGCOMM Comput. Commun. Rev., vol. 33, no. 1, pp. 83–88, 2003.

[8] J. Zhao and R. Govindan, “Understanding packet delivery performancein dense wireless sensor networks,” in Proc. Conf. Embedded NetworkedSensor Systems (SenSys), Los Angeles, CA, 2003.

[9] D. B. Johnson and D. A. Maltz, “Dynamic Source Routing in Ad HocWireless Networks,” Mobile Computing, vol. 353, pp. 153–181, Feb.1996.

[10] M. K. Marina and S. R. Das, “Routing performance in the presence ofunidirectional links in multihop wireless networks,” in Proceedings ofthe 3rd ACM international symposium on Mobile ad hoc networking &computing, Lausanne, Switzerland, 2002, pp. 12–23.

[11] S. Nesargi and R. Prakash, “A tunneling approach to routing withunidirectional links in mobilead-hoc networks,” in Proceedings. NinthInternational Conference on Computer Communications and Networks,Las Vegas, NV, USA, 2000, pp. 522–527.

[12] R. Prakash, “A routing algorithm for wireless ad hoc networks with uni-directional links,” Wireless Networks, vol. 7, pp. 617 – 625, November2001.

[13] G. Wang, Y. Ji, D. C. Marinescu, and D. Turgut, “A routing protocolfor power constrained networks with asymmetric links,” in Proceedingsof the 1st ACM international workshop on Performance evaluation ofwireless ad hoc, sensor, and ubiquitous networks, Venezia, Italy, 2004,pp. 69–76.

[14] P. Sinha, S. V. Krishnamurthy, and S. Dao, “Scalable unidirectionalrouting with zone routing protocol (zrp) extensions for mobile ad-hocnetworks,” in Wireless Communications and Networking Conference(WCNC), vol. 3, Chicago, IL, USA, 2000, pp. 1329–1339.

[15] V. Ramasubramanian and D. Mosse, “Bra: a bidirectional routingabstraction for asymmetric mobile ad hoc networks,” IEEE/ACM Trans.Netw., vol. 16, no. 1, pp. 116–129, 2008.

[16] M. Al-Bado, A. Feldmann, T. Fischer, T. Hhn, R. Merz, H. Schiberg,J. Schulz-Zander, C. Sengul, and B. Vahl, “Automated online recon-figurations in an outdoor live wireless mesh network,” Demo at ACMSIGCOMM ’09, August 2009.