Printer Friendly

Efficient peer-to-peer lookup in multi-hop wireless networks.

1. Introduction

Multi-hop wireless network can provide a flexible network service to wireless nodes spread over a certain area. Through a series of direct connections, distant nodes can indirectly communicate when they are beyond their radio coverage. Mesh-like connections between neighboring nodes enables multiple choices in choosing paths to the destination for data packets. Among applications of multi-hop wireless networks are wireless mesh networks, sensor networks, and vehicular ad-hoc networks. However, the lack of a centralized controller in those networks often makes it difficult to design a reliable service. Design of packet routing, for instance, has been a major challenge in multi-hop wireless networks for a couple of decades. Recently, data discovery in multi-hop wireless network has received attention as an application in multi-hop wireless networks [1][2][3][4][5]. In particular, one interesting question is whether it is possible to build a reliable peer-to-peer (P2P) file-sharing system in a wireless domain, likely suggested by the past success of Internet P2P file-sharing [5]. For distributed file sharing, a peer-to-peer lookup service is crucial. Using a P2P-lookup service, each node (or a peer) can request a target object that is stored within some other node (also a peer); each node can act as both a client (requesting data) and a server (serving data), even simultaneously if needed. This paper attempts to take an early step toward the design of a reliable wireless P2P-lookup service.

For the design of a wireless P2P-lookup, it is natural to apply the many existing P2P-lookup solutions originally intended for wired networks. The distributed hash table (DHT) [6][7][8][9][10] is regarded as an efficient and reliable P2P-lookup technology because of its highly structured design. Although DHTs may seem applicable at first, their topology-independent design makes DHTs inappropriate for multi-hop wireless networks. Because of radio interference and limited bandwidth, a multi-hop wireless network is more likely to delay or even fail packet delivery, as data travels more wireless links [11][12][13][14][15][16]. As DHTs disregard the underlying physical topology, they tend to suffer from a long search delay and a low search success rate. This is because a query message that only travels a few links in the DHT structure can travel multiple wireless links in the underlying wireless network. Although many topology-aware DHT schemes exist [17][18][19][20][21][22], DHTs are not primarily concerned with physical locality in their structure.

Other kinds of existing P2P-lookup are loosely-structured and unstructured approaches. Unlike DHTs, these do not build a global search structure. Instead, they guide the query message to the destination with local hints (loosely-structured) [23][24][25] or with blind attempts (unstructured) [26][27]. While the unstructured approach works poorly for multi-hop wireless networks due to link vulnerability, the loosely-structured approach is more adaptable. However, the analytic claims on unstructured and loosely-structured solutions [23][24][26][27] often make topological assumptions that are incompatible with multi-hop wireless networks; small world [28], power law [29], Gnutella network, or random graph models are assumed, while a multi-hop wireless network is best characterized by a random geometric graph [30]. For example, the mixing time analysis of a random walk found in [31][32][24] does not apply to random geometric graphs.

Some past work has explored the wireless P2P-lookup problem. Most works, however, proposed flooding-based solutions [33][34][35][36]. However, flooding scales poorly in multi-hop wireless networks. Many non-flooding solutions assume that nodes are aware of their locations and use geographic routing [1][2]. Other schemes build on tree structures, either by combining an existing DHT with an existing routing algorithm [3][4], or by designing their own structure [5]. Tree-based routing, however, has a tendency to forward query traffic to the links close to the root of the tree, and cause congestion on those links. Aly and Elnahas [37] proposed a hybrid method; their approach is closer to hierarchical approach than peer-to-peer approach (similar to the first generation P2P services, e.g., Napster).

In this paper, we focus on the wireless P2P-lookup problem; given a multi-hop wireless network and a set of objects, we assign each object to a node (or multiple nodes if desired) such that any node can find the object with the following properties:

* Decentralization: every node acts as both data requester and data provider,

* Load balance: each node can store an object with similar probability.

* Efficiency: every node can find (a copy of) an object as close as possible,

* Scalability: the scheme scales well with higher query rates.

In this work, instead of small ad-hoc networks with high mobility, we focus on relatively stable but large scale multi-hop wireless networks (such as a wireless mesh network in an urban area consisting of more than one hundred nodes). Large-scale is more challenging for P2P lookup services because flooding- or randomwalk-based schemes hardly work and search-optimization is critical because of large network diameter and inherently high query rates. Therefore, we assume the network has little mobility but query load is high.

We propose two wireless P2P-lookup schemes: a DHT scheme Ring Interval Graph Search (RIGS) and a loosely-structured scheme ValleyWalk. The RIGS builds a topology-dependent DHT structure such that one-hop neighbors in the structure are also one-hop neighbors in the underlying physical topology. Using the same design principle, ValleyWalk uses a simple heuristic to forward the query message to a neighbor node that is closer to the destination. Unlike RIGS, ValleyWalk is loosely-structured, and a simple hint about the destination guides the message to its destination. Both schemes use only local information and a global parameter.

We evaluate our scheme via packet-level simulations (using ns2 [38]) and make a comparison with the optimal solution and existing schemes. The results show that RIGS always guarantees successful search through near-shortest paths. ValleyWalk also finds the target through near-shortest paths when there are a moderate number of object copies in the network (i.e., 5% object replication). We also provide a mathematical analysis for finding upper-bounds on the search length of ValleyWalk. Our bound is significantly tighter than existing analysis given by Morselli et al. [24]. Our schemes, however, focus on static networks where the topology of the network does not dynamically change over time.

In the next section, we discuss existing P2P-lookup schemes that are not discussed in this section. In the following two sections, we describe RIGS (Section 3) and ValleyWalk (Section 4) in more detail. In Section 5 we present simulation results and in Section 6 we analyze the performance of ValleyWalk. We conclude in Section 7.

2. Related Work

In this section, we discuss existing distributed P2P lookup schemes not discussed in the previous section.

Breadth first search (BFS). Breadth first search requires no structure or topology control; the querying node floods the network within a certain hop distance hoping to hit the target [39]. Although flooding is simple and may find the closest copy of the target, the broadcast query messages can overload the network links. We can limit the flooding area, but finding the optimal flooding radius is not trivial [27]. Iterative deepening [40], Directed BFS, and Local indices are suggested to reduce the message overhead. The BFS method, however, is undesirable for multi-hop wireless networks, because of the limited bandwidth and interference.

Depth first search (DFS). The requesting node sends a single query message to one of its neighbors and each neighbor in turn forwards the query to one of its neighbors, until we hit a copy of the target object. Random-walk is a well-known DFS scheme where each node uniformly chooses a neighbor at random. Although the message overhead is minimal, the response time is high. The k-random-walk improves the response time by starting k independent random-walks simultaneously, but it can be costly to stop other random-walks when a random-walk finds a target. DFS is also undesirable in multi-hop wireless networks, because of its high response time.

Loosely-structured search. Loosely structured search leaves hints of the target locations throughout the network and uses those hints for searching the object. For example, FreeNet [23] uses history-based hints, Yappers [25] uses partition-based hints, and LMS [24] uses the node-to-object distance in the hash-space. Loosely-structured searching has little or no control over the topology, and thus can work in multi-hop wireless networks without significant modification. Our ValleyWalk uses a similar approach with LMS, but our searching algorithm significantly improved the search performance in multi-hop wireless networks.

Distributed hash table (DHT). The DHT-based scheme adds a significant amount of structure by closely coupling its overlay network topology and the placement of objects. DHTs such as CAN [8], Pastry [9], Chord [7], Tapestry [10], and Kademlia [6] can provide theoretical bounds on the worst-case performance and can guarantee successful search.

3. RIGS: Ring Interval Graph Search

RIGS is fully structured and carefully designed to find the closest target object. RIGS uses a novel search structure Ring Interval Graph with Shortest Interval Searching algorithm. The structure is built by a distributed algorithm during the initialization phase. Each node is only required to know the local information in order to forward search queries to destinations. RIGS is designed for stable multi-hop wireless networks (i.e., less mobility).

3.1 Hash space

RIGS uses the circular hash space used by Chord [7]. We simplify the original system using the assumption of continuity for the hash space; the hash-space is a continuous real interval [0,1) instead of a discrete set {0, 1, ... , [2.sup.m]}. As in Chord, we visualize the hash space as a unit-length circle where 0 and 1 meet at the same point and the values increase in the clockwise direction.

Each object is hashed to the hash space [0,1) and the hashed value is called a key. Each node is assigned a node-id in [0,1) by the RIGS algorithm. Each key is assigned to the node, viz., key-holder, for which the node-ID is equal to or greater than the key value in the hash space. Unlike other consistent-hashing systems that assign node-IDs at random, RIGS carefully chooses the node-ID such that the assignment generates a Ring Interval Graph.

3.2 Ring Interval Graph

In order to assign node-IDs, RIGS builds a distributed data structure called Ring Interval Graph. Let us first define ring interval and then define Ring Interval Graph. In this paper, [v.sub.i] denotes both the node itself and the assigned node-ID.

A ring interval (a, b] is a segment of the hash ring starting at a (excluding a) and ending at b (including b) in the clockwise direction. If a ring interval (a, b] contains zero, the interval is the union of two real intervals (a,1) and [0,b]. For example, if [v.sub.8] > [v.sub.0]> 0, then ([v.sub.8], [v.sub.0]] = {x | [v.sub.8] < x < 1 or 0 = x = [v.sub.0]}. For brevity, we write x[right arrow]y if there is no node-ID assgined in (x, y). A node-set {[v.sub.i], [v.sub.i+1], ..., [v.sub.i+k]} induces the ring interval ([v.sub.i-1], [v.sub.i+k]] if [v.sub.i-1][right arrow][v.sub.i] [right arrow][v.sub.i+1] [right arrow] ... [right arrow][v.sub.i+k] where [v.sub.i-1] is the preceding node of [v.sub.i]. In Fig. 1, {[v.sub.8], [v.sub.9], [v.sub.10], [v.sub.11], [v.sub.0]} induces the ring interval ([v.sub.7], [v.sub.0]]. Note that one node {[v.sub.i]} induces the ring interval ([v.sub.i-1], [v.sub.i]].

[FIGURE 1 OMITTED]

Definition 3.1 Given a network graph G = (V, E), a Ring Interval Graph (RIG) is an acyclic undirected subgraph [G.sub.RIG] = (V, [E.sub.RIG]) where [E.sub.RIG][??]E and each node is assigned a node-ID such that any one-cut (removal of one edge) of [G.sub.RIG] partitions the graph into two subgraphs [G.sub.1] = ([V.sub.1], [E.sub.1]) and [G.sub.2] = ([V.sub.2], [E.sub.2]), such that [V.sub.1] induces [R.sub.1], [V.sub.2] induces [R.sub.2], and [R.sub.1] and [R.sub.2] partition the hash space (i.e., [R.sub.1] [intersection] [R.sub.2] = [Empty set] and [R.sub.1] [union] [R.sub.2] = (0,1]).

Fig. 1-(center) shows a Ring Interval Graph of a 12-node graph. Their node-IDs are placed in the hash space at the corners of the figure. Without loss of generality, we assume that the nodes are placed in the order of the node index, in the clockwise direction. In Fig. 1-(top left corner), the removal of the edge ([v.sub.0], [v.sub.1]) partitions the ring into two subgraphs with node-set {[v.sub.8], ... , [v.sub.11], [v.sub.0]} and {[v.sub.1], ... , [v.sub.7]}. The hash space is partitioned into their induced ring intervals [[v.sub.7], [v.sub.0]) and [[v.sub.0], [v.sub.7]), respectively. Likewise, the figure illustrates the partition of the graph when edge ([v.sub.1], [v.sub.2]) or ([v.sub.1], [v.sub.4]) are removed. As Fig. 1-(bottom right coner) concisely illustrates, node [v.sub.1] can decide to which neighbor it should forward the query, by checking which interval the target key belongs to. We build a routing table based on the ring interval information. Interval table. Given the aforementioned partition information, we build a routing structure as follows. Let Nb(v) denote the neighbor set of node v and [Nb.sup.+](v) = Nb(v)[union]{v} be the expanded neighbor set. Suppose u[member of]Nb(v). Then, edge (v, u) partitions the hash-space into two ring intervals, one of which includes v and the other which includes u. Let [I.sup.u.sub.v] be one of the ring intervals that includes node u. For example, in Figure 1, [I.sup.[v.sub.4].sub.[v.sub.1]] = ([v.sub.3], [v.sub.7]], [I.sup.[v.sub.0].sub.[v.sub.1]] = ([v.sub.7], [v.sub.0]], and, [I.sup.[v.sub.2].sub.[v.sub.1]] = [v.sub.1], [v.sub.3]]. Let us also define [I.sup.v.sub.v] = ([v.sub.p], v] where [v.sub.p] is the preceding node of v in the hash space. For example, [I.sup.[v.sub.1].sub.[v.sub.1]] = ([v.sub.0], [v.sub.1]]. Note that if l [member of] [I.sup.[v.sub.1].sub.[v.sub.1]], then node [v.sub.1] has the key and the search terminates. Then, the interval-table or i-table of node v is i-table(v) = {[I.sup.u.sub.v]|u [member of] [Nb.sup.+] (v)}.

For example, in Fig. 1, i-table ([v.sub.1]) = {[I.sup.[v.sub.0].sub.[v.sub.1]], [I.sup.[v.sub.1].sub.[v.sub.1]], [I.sup.[v.sub.2].sub.[v.sub.1]], [I.sup.[v.sub.4].sub.[v.sub.1]]} = {([v.sub.7], [v.sub.0]], ([v.sub.0], [v.sub.1]], ([v.sub.0], [v.sub.1]], ([v.sub.1], [v.sub.3]], ([v.sub.3], [v.sub.7]]}. In practice, each node builds a list of <val, node> sorted according to val, where val is the ending value of each interval and node is the neighbor node associated with that interval. In Fig. 1, i-table ([v.sub.1]) = (<[v.sub.0], [v.sub.0]>, <[v.sub.1], [v.sub.1]>, <[v.sub.3], [v.sub.2]>, <[v.sub.7], [v.sub.4]>).

Basic routing. Given the i-table, each node can forward queries to a neighbor who is closer to the destniation on the Ring Interval Graph. Suppose we are given a query for key k. The node first finds an interval that contains the key. For example, node [v.sub.1] finds that k [member of] ([v.sub.3], [v.sub.7]] = [I.sup.[v.sub.4].sub.[v.sub.1]]. Then, the node forwards the query to the neighbor node associated with that interval. In our example, [v.sub.1] forwards to node [v.sub.4].

Basic routing, however, limits the traffic on the Ring Interval Graph, which is a spanning subgraph of the original graph. Subgraph routing, however, causes traffic congestion along the subgraph edges, while edges outside the subgraph remain idle. Subgraph routing also fails to find the shortest path and often causes a detour. In Fig. 1, the basic routing algorithm will deliver the query of k [member of] ([v.sub.3], [v.sub.7]] through the path ([v.sub.1], [v.sub.4], [v.sub.5], [v.sub.6]). However, it is likely that node [v.sub.1] and [v.sub.6] are one-hop neighbors in the original graph, and thus the query can be delivered in one-hop path ([v.sub.1], [v.sub.6]). In the following section, we describe how RIGS can use the Ring Interval Graph to overcome the drawbacks of basic routing, and achieve near-shortest path routing.

3.3 Shortest Interval Search

Although basic routing with i-table can route queries to destinations, the message path is limited to the spanning subgraph, which wastes edges outside the subgraph. Shortest interval search enables RIGS to use all the edges in the network and, more importantly, achieve near-shortest routing.

In brief, each node collects i-tables of neighbor nodes and for routing, the node selects the shortest ring interval containing the key in those i-tables, and forwards the query to the neighbor associated with the interval. Formally, let us define i *-table of node v as the set of all intervals collected from neighbors' i-tables, which is expressed as:

i *-table(v) = {[I.sup.w.sub.u]|u [member of] Nb(v), w [member of] [Nb.sup.+] (u)\{v}}

Given a key k, node v forwards the query to node u * such that:

u * = arg min {|[I.sup.w.sub.u]|: [I.sup.w.sub.u] [member of] i * -table, k [member of] [I.sup.w.sub.u]}.

Fig. 2 illustrates an example of Shortest Interval Search. Suppose we are given a network of 12 nodes {[v.sub.0], [v.sub.1], ... , [v.sub.11]}. The node-ID assignment is shown in the graph and their values are places in the hash space. In the graph, the solid edges represent the Ring Interval Graph, while the dotted lines are the rest of the edges in the network. Suppose node [v.sub.6] has collected the i-tables of neighbor nodes [v.sub.1], [v.sub.4], and [v.sub.5]. When [v.sub.6] receives a query for k such that k[right arrow][v.sub.3], node [v.sub.6] checks all the intervals in its i*-table and compares the length of the intervals that contain k: [I.sup.[v.sub.1]] = ([v.sub.1], [v.sub.3]], [I.sup.[v.sub.4]] = ([v.sub.7], [v.sub.3]], and [I.sup.[v.sub.5]] = ([v.sub.6], [v.sub.4]]. Since [I.sup.[v.sub.1]] has the shortest interval size (see Fig. 2-(bottom left corner)), node [v.sub.6] forwards the query message to node [v.sub.1]. Using the same algorithm, node [v.sub.1] forwards the query to [v.sub.3], which is the destination.

[FIGURE 2 OMITTED]

The following describes the Shortest Interval Search algorithm, which is executed when node v does not have the key.

1. min := 1 2. for all u [member of] Nb(v) do 3. for all [I.sup.w.sub.u] [member of] i *-table(v) do 4. if k [member of] [I.sup.w.sub.u] and |[I.sup.w.sub.u]| < min do 5. next-node := u 6. min := |[I.sup.w.sub.u]| 7. end if 8. end for 9. end for 10. v sends the query to next-node

Before we explain the rationale behind the algorithm, we first claim that following a shorter ring interval leads to a shorter path on the Ring Interval Graph than longer intervals.

Theorem 3.1 Given a key k and two nodes v and v', let [I.sup.u.sub.v] [member of] i-table(v) and [I.sup.u'.sub.v'] [member of] i-table(v') such that k [member of] [I.sup.u.sub.v] and k [member of] [I.sup.u'.sub.v']. Then,

If [I.sup.u'.sub.v'] [subset] [I.sup.u.sub.v] and [I.sup.u'.sub.v'] [not equal to] [I.sup.u.sub.v], then distance(v', holder(k)) < distance(v, holder(k))

where distance (*) is the hop count between two nodes on the Ring Interval Graph, and holder(k) is the node that possesses key k.

Proof of Theorem 3.1. Suppose v [member of] [I.sup.u.sub.v] (equivalently, v = u). Then [I.sup.u'.sub.v'] = [I.sup.u.sub.v], a contradiction. Therefore, v [??] [I.sup.u.sub.v] v [??] u. Then, the edge (v, u) partitions the network into two node-sets; the nodes whose node-IDs are in [I.sup.u.sub.v] and the nodes whose node-IDs are in R\[I.sup.u.sub.v] where R = [0, 1). Any node from one partition cannot go to the other partition without passing the edge (v, u).

Suppose v' [member of] R\[I.sup.u.sub.v]. Then, every path from v' to the key-holder of k, which is in the other partition, should pass the node v, i.e., v [member of] path(v', holder(k)). Since k [member of] [I.sup.u'.sub.v'], the key-holder of k belongs to [I.sup.u'.sub.v'], and the path from v' to holder(k) is contained in [I.sup.u'.sub.v']. Therefore, v [member of] [I.sup.u'.sub.v']. Since [I.sup.u'.sub.v'] [subset] [I.sup.u.sub.v], we get v [member of] [I.sup.u.sub.v], a contradiction. Therefore, v' [member of] [I.sup.u.sub.v].

Here we claim that v' is on the path from v to k, i.e., v' [member of] path(v, holder(k)). Suppose that this is not the case; v' is not in path(v, holder(k)). Let w ([not equal to] v') be a common node of the paths from v to holder(k) and from v' to holder(k), i.e., w [member of] path(v, holder(k)) [intersection] path(v', holder(k)). Since w [member of] [I.sup.u.sub.v], and v' is not in the path from v to w, v cannot be in R\[I.sup.u'.sub.v'], thus v [member of] [I.sup.u'.sub.v']. Since [I.sup.u'.sub.v'] [subset] [I.sup.u.sub.v], we get v [member of] [I.sup.u.sub.v], a contradiction. Therefore, v' is on the path from v to holder(k).

Based on Theorem 3.1, the Shortest Interval Search algorithm always chooses a neighbor that has the shortest ring interval containing the key. Although this choice only guarantees progression towards the destination on the Ring Interval Graph, the use of all available intervals in the vicinity finds short-cut paths beyond the Ring Interval Graph and avoids detours. Experimental results show that such a heuristic can achieve near-shortest paths in various settings.

3.4 Construction

Here we explain how we can construct a Ring Interval Graph of the given network topology. The construction requires a spanning tree of the original graph. We can construct a spanning tree via a depth-first or breadth-first graph traversal. We can also use one of the available distributed spanning-tree algorithms [41][42][43].

Given a spanning tree, we assign each node a node-ID in an increasing order along the depth-first traversal on the spanning tree. We assume that each node v knows the area of the hash space to which it was assigned, denoted by [L.sub.v], and [[summation].sub.v] [L.sub.v] = 1. For ease of explanation, we assume that the hash space is expanded to [0,n) where n is the number of nodes, and nodes are assigned a uniform unit length interval, that is, [L.sub.v] = 1. Since the assignment requires a depth-first traversal of the graph, we can build a depth-first spanning tree simultaneously if desired. However, in the algorithm description, we assume that a spanning tree is already given.

[FIGURE 3 OMITTED]

Fig. 3 shows an example construction of Ring Interval Graph. Suppose we are given a network graph, as shown in Fig. 3-(a), where the node-IDs have not yet been assigned. The construction algorithm starts with a randomly-chosen node and assigns zero as its node-ID, then performs a depth-first traversal, as shown in Fig. 3-(b). In the figure, the number in parenthesis denotes the order of visit. At the first visit of each node, the algorithm assigns a node-ID, which increases by one at each assignment. The resulting tree becomes a Min-Heap tree structure; all node-IDs of any subtree are greater than the node-ID of the root of the subtree. This property enables the partitioning property of Ring Interval Graph described in Definition 3.1. After assignment, only the edges of the depth-first traversal remain for the Ring Interval Graph. Fig. 3-(c) shows the Ring Interval Graph that corresponds to the DFS. The following construction algorithm is executed by v when it is the root node or when it receives message x from node p

1. if v is a root node then 2. y := 0 3. else 4. y := x + [L.sub.v] 5. i-table.add(<x, p>) 6. end if 7. node-id(v) := y 8. i-table.add(<y, v>) 9. for all u [member of] Nb(v) -{p} and u remains unvisited do 10. v sends u : "y" 11. wait v receives from u : "z" 12. i-table.add(<z, u>) 13. y := z 14. end for 15. if v is a not root node then 16. v sends p : "z" 17. end if

When node v receives x, which is the last assigned node-ID, it assigns itself a node-ID by increasing x by its assigned area [L.sub.v]. After adding i-table entries for p and v, it sends the last assigned value y to each neighbor and waits until the neighbor finishes assignment of all its descendent nodes. The returning value z is the last assigned value in the subtree of u. The node v repeats this for unvisited neighbors. After assigning all nodes in its subtree, v sends z to the parent node p. The construction ends when the root node receives reply messages from all unvisited child nodes, and it finishes the algorithm without executing line 11.

4. ValleyWalk

ValleyWalk uses a simple forwarding algorithm with a lightweight local structure; "each node forwards the query to the neighbor node that is the closest to the target object in the hash-space". Because of its minimal structure, ValleyWalk assumes that a moderate number of object copies are available in the network. After describing the algorithm, we discuss the difference between ValleyWalk and LMS [24].

4.1 Hash Space and Definitions

ValleyWalk uses the same hash-space as Chord, and we use the same notation used in Section 3. Unlike RIGS, we hash both objects and nodes to the hash-space, obtaining keys and node-IDs, respectively. Let us define metrics to represent the relationship between nodes and a key. Given a key k, we define key-hop-count of node v with respect to k, denoted by [hop.sub.k](v), as the number of nodes in the ring interval (k, v]. We also define key-distance of node v with respect to k, denoted by [dist.sub.k](v), as the length of the ring interval (k, v], that is, the distance from k to v in the clockwise direction. Fig. 4-(a) illustrates the definitions of [hop.sub.k](v) and [dist.sub.k](v). We state that node v is closer to k than node u if [dist.sub.k](v) < [dist.sub.k](u). As in Chord, key k is stored in the closest node v, that is, [hop.sub.k](v) = 1 or, equivalently, [dist.sub.k](v) < [dist.sub.k](u) [1] for all nodes u. In Fig. 4-(a), holder([k.sub.1]) = [v.sub.2], holder([k.sub.2]) = [v.sub.5], and holder([k.sub.3]) = [v.sub.7].

Given a key k, a node v is a local minimum with respect to k if v is the closest to the key among its neighbors, that is, [dist.sub.k](v) < [dist.sub.k](u) for all u . Nb(v). Fig. 4-(b) shows a network with two local minima, node 0 and node 2, and arrows indicating the closest nodes to the key among neighbor nodes. In LMS, keys are stored in local minima and each node forwards the query to the neighbor who is the closest to the key among neighbors. In the figure, queries are routed in the direction of the arrows. When we reach a local minimum but no key is found, a random walk is performed to restart another local-minima search. In the following, we explain ValleyWalk, which modifies LMS to achieve better performance.

[FIGURE 4 OMITTED]

4.2 ValleyWalk

ValleyWalk performs a simple deterministic walk to search or store keys in the nodes. Each node that receives a query for key k forwards the query to one of its unvisited neighbor nodes that is closest to k. Formally, node v forwards the query for k to an unvisited node u* if

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII]

In order to avoid loops, each node stores recent queries in its cache or records visited nodes within the query. When a node finds that the query has already visited all its neighbor nodes, it forwards the query to a randomly chosen neighbor. Fig. 5 illustrates the ValleyWalk. On the left are the node-IDs placed on the hash space. Suppose node [v.sub.8] receives a query for key [k.sub.1]. According to the values of node-IDs, [v.sub.0], [v.sub.1], and [v.sub.4] are local minima but only [v.sub.0] holds [k.sub.1]. Choosing the closest neighbor to k1 at each step, the query message reaches the destination through path ([v.sub.8] , [v.sub.1], [v.sub.3], [v.sub.0]). Note that unlike LMS, ValleyWalk continues with its deterministic walk when it reaches an empty (i.e., no key) local minimum.

As an analogy, we can compare ValleyWalk to a hiking strategy in a mountain where the hiker always chooses the direction towards the lowest area around the current position. The hiking path can be either downhill or uphill (if the hiker has reached the bottom of a basin), and, as a result, the hiker is likely to travel along the valleys between peaks.

Node v executes the following algorithm when it receives the query message for key k.

1. if v = holder(k) then 2. exit 3. end if 4. mindist := 1 5. next := [perpendicular to] 6. for all u [member of] Nb(v) s.t. u remains unvisited do 7. if [dist.sub.k](u) < mindist then 8. next-node := u 9. mindist := [dist.sub.k](u) 10. end if 11. end for 12. if next-node = [perpendicular to] then 13. pick a random u [member of] Nb(v) 14. end if 15. send the query to next-node

[FIGURE 5 OMITTED]

4.3 Key Assignment

Suppose we want to store r copies of each key in the network. Since ValleyWalk always forwards the query to a node with a smaller key distance, ValleyWalk is inclined to move towards local minima. Therefore, it is most efficient to store keys in local minima (as in LMS). However, the number of local minima for a given key depends on the topology and node-IDs. Let [LM.sub.k] be the set of local minima and |[LM.sub.k]| be the number of local minima in the network. Since the probability is 1/([d.sub.v]+1) that node v is a local minimum, where [d.sub.v] is the degree of node v, the expected number of local minima is:

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII]

where V is the total node-set. Since the number of local minima may not equal the replication number r, we store r copies of each key as follows.

We start with a ValleyWalk and whenever we reach a local minimum we store a copy of the key in that node. If we can find r local minima, we stop. If we can no longer find a local minimum (after a certain number of trials) and we still have copies of the key to store, then we store the remaining copies in randomly chosen nodes with a series of random-walks. As a result, it is possible to have both a local minimum node without a key and a key holder that is not a local minimum.

The discrepancy between the local minima set and the key-holder set can cause overhead of the search algorithm. In particular, a false positive, which involves hitting an empty local minimum, is more harmful than a false negative, which involves hitting a non-local-minimum and unexpectedly finding the key. In order to minimize the false positives, we can intentionally decrease the number of local minima such that |[LM.sub.k]| < r. Since E[|{LM.sub.k]|][less than or equal to] |V|/[delta]+1 where [delta] is the minimum degree in the network, we can artificially decrease the expected number of local minima by increasing the minimum node degree. Given a target minimum degree [delta] *, nodes that have fewer degrees than [delta] * can expand their neighbor sets by adding virtual links with ([delta] * - [d.sub.v]) 2-hop neighbor nodes. Adding a virtual link means that the node creates imaginary edges to the 2-hop neighbors and asks them to send their node-IDs. The expansion of the neighbor set creates an asymmetric relationship between neighbors; node v considers node u as a neighbor, while node u does not consider v as a neighbor. This asymmetry does not affect the correctness of the ValleyWalk. We do not expand the neighbor-set beyond 2-hop neighbors, to avoid creating a local overlay-network and increasing the search length.

4.4 ValleyWalk and LMS

LMS uses both the deterministic walk and random walk. The deterministic walk of LMS forwards the query towards the neighbor with the smallest key distance among neighbors and the current node (whereas ValleyWalk does not compare with the current node). Consequently, LMS stops its search at any local minimum node (whereas ValleyWalk continues the search). When LMS reaches an empty local minimum, LMS performs a random-walk, followed by another deterministic walk, and it repeats this until it hits a target. In order to avoid continuous arrival at the same local minimum (like a black hole), LMS doubles the length of the random-walk each time. The characteristics of a random walk differ between a wired network and a multi-hop wireless network. For instance, the analysis of the mixing time of the random-walk presented in [24] assumes a random graph, which is not the case in multi-hop wireless networks. Our simulation results show that by removing this random-walk from LMS and by replacing the deterministic walk with ValleyWalk, we can achieve a significant performance improvement in wireless P2P-lookup.

4.5 Analysis of ValleyWalk

In this section, we provide an analytic upper-bound of the search length of ValleyWalk. For simplicity, we assume that |[LM.sub.k]| [less than or equal to] r, that is, every local minimum has a key. When |[LM.sub.k]| > r, the additional search length when hitting empty local minima should be considered, and our analysis does not cover that case.

We model ValleyWalk as a time series - a series of independent random variables on [0, 1). Given a key k, let ([v.sub.0], [v.sub.1], [v.sub.2], ...) be a search path and ([X.sub.0], [X.sub.1], [X.sub.2], ...) be random variables for the key distance of the nodes in the path, that is, [X.sub.i]=[dist.sub.k](vi). By definition, [X.sub.i+1] is the smallest key distance among vi's neighbors, and the search stops at vi if [X.sub.i] < [X.sub.i+1], otherwise it continues. Therefore, if the search stops at [v.sub.l], then [X.sub.0] > [X.sub.1] > ... > [X.sub.l-1] > [X.sub.l] < [X.sub.l+1]. Since the first node is the distance between two random values, [X.sub.0] follows a uniform distribution on [0, 1). Suppose we have followed a path ([v.sub.0], [v.sub.1], [v.sub.2], ... , [v.sub.l]) so far, and none of them was a local minimum. Let revealed set [R.sub.l] denote the nodes either on the path or in the neighbor set of the path. That is, [R.sub.l] = {v|v [member of] [[union].sup.l.sub.i=0] [Nb.sup.+] (v.sub.1]}. Since ist.sub.k]([v.sub.0])>[dist.sub.k] ([v.sub.1])> ... >[dist.sub.k]([v.sub.l-1])>[dist.sub.k]([v.sub.l]) and [dist.sub.k]([v.sub.i]) < [dist.sub.k]([v.sub.j]) for all [v.sub.j] [member of] Nb([v.sub.i-1]), the node [v.sub.l] has the smallest key distance among all other nodes in [Rl.sub.-1], that is, [dist.sub.k]([v.sub.l]) < [dist.sub.k]([v.sub.j]) for all [v.sub.j] [member of] [Rl.sub.-1]. Since we want to find the next node [v.sub.l+1] [[member of] Nb([v.sub.l]) such that [dist.sub.k]([v.sub.l+1]) < [dist.sub.k]([v.sub.l]), we only need to check the nodes in Nb([v.sub.l])\[R.sub.l-1]. We call this set candidate set at step l+1, denoted by [C.sub.l+1]. Therefore, [X.sub.i+1] is the closest key distance of the nodes in [C.sub.i+1]. Since all candidate sets are disjoint, [X.sub.i]'s are independent. Fig. 6-(a) shows the topology, and each node is labeled according to its key-distance. The search follows the path ([v.sub.0], [v.sub.1], [v.sub.2]). The path selection is explained by Fig. 6-(b); at each step, we chose the smallest key distance (gray circles) among the candidate set (white or gray circles). The empty circles are revealed nodes in previous steps, so they are excluded in the candidate set. In the figure, [R.sub.2] = {9,6,11,0,3,5,7} and Nb([v.sub.2])={1,4,5,6,7}, so [C.sub.3] = Nb([v.sub.2])\[R.sub.2]={1,4}. Similarly, [C.sub.0]={9}, [C.sub.1] ={6,11}, and [C.sub.2] = {0,3,5,7}. Therefore, by choosing nodes with the smallest key-distance in candidate sets, we chose [v.sub.0] ([dist.sub.k]([v.sub.0])=9), [v.sub.1] ([dist.sub.k]([v.sub.1])=6), [v.sub.2] ([dist.sub.k]([v.sub.2])=0), and [v.sub.3] ([dist.sub.k]([v.sub.3])=1). Since [dist.sub.k]([v.sub.3])>[dist.sub.k]([v.sub.2]), we stop at [v.sub.2].

Consider the following thought experiment. Let [Delta] be the largest node degree in the network. Then, the candidate set cannot be larger than [Delta]. Imagine the case (viz., [Delta]-case) when each candidate set is as large as [Delta] (|[C.sub.i]|= [Delta]). Since a node is less likely to have the smallest key distance among a larger set of nodes then among smaller sets, the expected length of the search increases as the candidate-set expands. Therefore, the expected search length of the original case is no longer than the [Delta]-case, thus the [Delta]-case provides an upper-bound of the search length.

[FIGURE 6 OMITTED]

Theorem 4.1 (Tail-bound of ValleyWalk) Given k>0, the tail-bound of search length L of ValleyWalk is:

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII]

Proof of Theorem 4.1. Let [L.sub.[Delta]] be a random variable for the search length in [Delta]-case and [Y.sub.0], [Y.sub.1], [Y.sub.2], ... be the random variables for key distances along the search path in [Delta]-case. Let [??]([y.sub.0], [y.sub.1], ... , [Y.sub.k]) be the joint pdf of [Y.sub.0], [Y.sub.1], ... , [Y.sub.k]. Then,

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII]

Since [Y.sub.i]'s are independent, [??]([y.sub.0], [y.sub.1], ... , [Y.sub.k]) = [f.sub.0]]([y.sub.0]) [f.sub.1]]([y.sub.1]) ... [f.sub.k]]([y.sub.k]) where [f.sub.i]([y.sub.i]) is the pdf (probability density function) of [Y.sub.i]. Because [Y.sub.0] follows the uniform distribution on [0, 1), [f.sub.0]]([y.sub.0]) = 1. Since the key-distance of each node also follows the uniform distribution on [0,1) and [Y.sub.i] (i > 0) is the smallest key-distance among [Delta] nodes, pdf of [Y.sub.i] is [F.sub.i]]([Y.sub.i]) = f([y.sub.i]) = [Delta][(1- [y.sub.i]).sup.[Delta]-1] for i>0 and the cdf (cumulative distribution function) of [Y.sub.i] is [F.sub.i]]([Y.sub.i]) = F ([Y.sub.i]) = 1 -[(1 - y).sup.[Delta]].

Since [MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII], it follows

that: [MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII]

If we integrate the Binomial expansion [MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII] follows that: [MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII]

We can simplify the formula by using the finite difference technique. Let Df(x) = f(x + 1) f(x). Then, by equating [D.sup.k]f(x) and [D.sup.k] (1/x) and replacing x with 1/[Delta], it follows that:

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII]

Morselli et. al [24] showed a tail bound of [Delta]/[2.sup.k-1] for the same problem, and our bound is significantly tighter. Fig. 7 compares our analysis with Morselli's analysis and packet-level simulation results. The simulation parameters are the same as those in Section 5. The topology had an average degree of 6.5 and a maximum degree of 11 (thus [Delta] = 11). The variance of the node degree caused the gap between the simulation and analytic bound, and the gap becomes negligible when the variance of the degree becomes small. The average search length of the simulations was 1.49, and the average of our analysis was 1.54.

[FIGURE 7 OMITTED]

5. Performance Evaluation

By packet-level simulations, we evaluate the performance of RIGS and VALLEYWALK. We compare our algorithms with the optimal solution and other existing solutions.

5.1 Methodology

We used ns2 [38] for our simulations. We uniformly placed 100 nodes at random in a 1,000 by 1,000 [m.sup.2] rectangular area (denoted by density 1.0 in the figures). The wireless communication range was set to 250m. After an initialization period for gathering neighbor information (30 seconds), each node generates a series of queries with random keys, following a Poisson distribution of a fixed rate. We varied the total query rate from 20 to 100 queries per second. We also varied the replication number from 1 to 30 nodes. We repeated the simulations with 20 different random seeds and averaged the results.

5.2 Algorithm

We compared the following algorithms.

1. RIGS: Ring Interval Graph Search proposed in Section 3. We used BFS spanning tree for the simulations but the result using the DFS spanning tree was similar.

2. VALLEYWALK: Proposed scheme in Section 4.

3. LMS: Local Minima Searching proposed for P2P overlay networks [24]. Rather than following the recommendation in their paper, we used a random walk of length two, instead of three, because it worked better in our simulations. We added loop detection.

4. CHORD: As described in [7]

5. OPTIMAL: Each node chooses the closest key copy from the current position and forwards the query along the shortest path.

Because only ValleyWalk and LMS provide a native replication scheme, we introduced a simple replication method for RIGS, CHORD, and OPTIMAL. Given a replication number r and key k, we created equidistant r virtual keys V = {k + i/r| I = 0,1, ... , r - 1. Each node forwards the query to a neighbor who is the closest to any of the virtual keys. i.e., the next node u * has the minimum smallest distance to any virtual key among neighbors.

5.3 Metrics

We evaluate the performances of the lookup algorithms with the following metrics. Let us define three different lengths. Suppose node v tries to find key k for which r copies are stored in nodes {[u.sub.1], [u.sub.2], ... , [u.sub.r]} and [u.sub.1] is the closest from v. Suppose an algorithm finds a key at [u.sub.i] through path p. Search length is the length of the path p; shortest search length is the shortest path from v to [u.sub.i]; optimal search length is the shortest search path from v to [u.sub.1]. Then:

* Search-overhead = search length/optimal search length, performance compared to optimal solution

* Locality-overhead = shortest search length/ optimal search length, closeness of the found key

* Detour-overhead = search length/shortest search length, overhead due to detour

Tail bound of searching length: the probability that the search length is larger than K hops, that is, Pr(search length [less than or equal to] K).

5.4 Results

We first varied the replication factor from 1% to 30%, and compared the algorithms in terms of the overhead. Then, we compared the scalability as the query rate increases.

Search-overhead. Fig. 8-(a) compares the search-overhead of the algorithms. The search-overhead of OPTIMAL is, by definition, always one. The performance of RIGS is almost OPTIMAL. ValleyWalk has about five times the overhead of OPTIMAL when there is only one key in the network, but the overhead rapidly approaches one as replication increases. LMS has a similar pattern, but it has about 18 times the OPTIMAL hop count when there is only one replication, and about two times OPTIMAL at best. CHORD, although fully-structured, is eight times less efficient than OPTIMAL. Replication did not help CHORD compensate for its inherent design defect in multi-hop wireless networks.

Locality-overhead. Fig. 8-(b) compares the locality overhead. Both RIGS and ValleyWalk found very close key-holders and LMS maintained a distance of at most one and half times the OPTIMAL. CHORD ignored the locality and replication did not help.

Detour-overhead. Fig. 8-(c) shows how much the search path digresses from the shortest path to the found key. RIGS took the near shortest path and ValleyWalk approached the shortest path when replication was 5% or greater. LMS took about 17 times longer than the shortest path with 1% replication, and reduced its detour overhead down to 1.5 times the optimal solution when replication increased. CHORD took the longest detour to destinations for most replication factors.

Tail bound. Fig. 8-(d) shows the tail bound of the search length. For OPTIMAL and RIGS, most queries (95%) took about three hops, and for ValleyWalk they took five hops. However, for LMS, most queries (95%) took eight hops, while CHORD took more than 20 hops.

Scalability. In order to compare the scalability, we varied the total query rate, the sum of the per-node query rates, from 20 to 100 queries per second. As the query rate increases, wireless links become overloaded and packets are dropped. We measured the scalability by the success ratio of a network protocol between the querying node and a key-holder. The protocol starts when the querying node finds a key-holder and the protocol requires five round-trip messages to finish. A protocol instance succeeds when the querying node finds a key-holder and all the subsequent messages are delivered. The protocol success rate is the ratio of the number of successful protocol trials to the total number of queries generated. Fig. 9 shows that RIGS and ValleyWalk scale well, even with high query rates. We varied the network size and network density but observed similar results; those figures are not presented due to the space limit.

[FIGURE 8 OMITTED]

[FIGURE 9 OMITTED]

6. Conclusion

In this paper, we presented a novel approach to the peer-to-peer lookup problem in large-scale and stable multi-hop wireless networks, and proposed a fully-structured topology-dependent DHT scheme Ring Interval Graph Search (RIGS) and a loosely-structured scheme ValleyWalk. Simulation results show that RIGS achieves near-optimal search performance, even if there is only one object copy in the network. ValleyWalk can also achieve a near-optimal search performance when replication is 5% or greater. The comparison shows that our schemes are significantly more efficient than the existing P2P-lookup schemes.

We would like to express our great thanks to the Editor and unknown reviewers' very active and quick review process. We believe that their detailed review has enhanced the quality of our paper.

Received Jan 06, 2009; revised January 28, 2009; accepted January 29; published February 23, 2009

References

[1] S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan, S. Shenker, "GHT: A Geographic Hash Table for Data-Centric Storage," In Proceedings of the First ACM International Workshop on Wireless Sensor Networks and Applications, Atlanta, GA, 2002.

[2] Filipe Araujo and Luus Rodrigues and Jorg Kaiser and Changling Liu and Carlos Mitidieri, "CHR: A Distributed Hash Table for Wireless Ad Hoc Networks," In Proceedings of the Fourth International Workshop on Distributed Event-Based Systems (DEBS) (ICDCSW'05), Washington, DC, USA, 2005.

[3] Himabindu Pucha and Saumitra M. Das and Y. Charlie Hu, "Ekta: An Efficient DHT Substrate for Distributed Applications in Mobile Ad Hoc Networks," In Proceedings of the Sixth IEEE Workshop on Mobile Computing Systems and Applications, 2004.

[4] Zahn, Thomas and Schiller, Jochen, "MADPastry: A DHT Substrate for Practicably Sized MANETs," In Proc. of 5th Workshop on Applications and Services in Wireless Networks (ASWN2005), 2005.

[5] H. Sozer, M. Tekkalmaz, and I. Korpeoglu, "A peer-to-peer file sharing system for wireless ad-hoc networks," In The Third Annual Mediterranean Ad Hoc Networking Workshop (Med-Hoc-Net), 2004.

[6] P. Maymounkov and D. Mazieres, "Kademlia: A peer-to-peer information system based on the xor metric," In Proceedings of IPTPS02, Cambridge, USA, Mar. 2002.

[7] R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan, "Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications," In SIGCOMM, San Diego, CA, Sept. 2001.

[8] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Schenker, "A scalable content-addressable network. In SIGCOMM, vol. 31, pp. 161-172, Oct. 2001.

[9] A. Rowstron and P. Druschel, "Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems," In IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), pp. 329-350, Nov. 2001.

[10] B. Y. Zhao, L. Huang, J. Stribling, S. C. Rhea, A. D. Joseph, and J. D. Kubiatowicz, "Tapestry: A resilient global-scale overlay for service deployment," IEEE Journal on Selected Areas in Communications, vol. 22, no. 1, pp. 41-53, Jan. 2004.

[11] R. Bruno, M. Conti, , and E. Gregori, "Mesh networks: Commodity multihop ad hoc networks," IEEE Wireless Communications, vol. 43, Mar. 2005.

[12] N. Chang and M. Liu, "Revisiting the ttl-based controlled flooding search: optimality and randomization," In Mobi-Com, pp. 85-99, New York, NY, USA, 2004.

[13] Z. Cheng and W. B. Heinzelman, "Flooding strategy for target discovery in wireless networks," Wireless Networks, 2005.

[14] A. Gamal, J. Mammen, B. Prabhakar, and D. Shah, "Throughput-delay trade-off in wireless networks," In Proceedings of IEEE INFOCOM, 2004.

[15] J. Jun and M. Sichitiu, "The nominal capacity of wireless mesh networks," IEEE Wireless Communications, Oct. 2003.

[16] J. Li, C. Blake, D. S. D. Couto, H. I. Lee, and R. Morris, "Capacity of ad hoc wireless networks," In MobiCom, pp. 61-69, New York, NY, USA, 2001.

[17] M. Castro, P. Druschel, Y. Hu, and A. Rowstron, "Exploiting network proximity in distributed hash tables," FuDiCo, 2002.

[18] F. Dabek, M. F. Kaashoek, D. Karger, R. Morris, and I. Stoica, "Wide-area cooperative storage with cfs," In SOSP, pp. 202-215, New York, NY, USA, 2001.

[19] K. Gummadi, R. Gummadi, S. Gribble, S. Ratnasamy, S. Shenker, and I. Stoica, "The impact of dht routing geometry on resilience and proximity," In SIGCOMM, pp. 381-394, New York, NY, USA, 2003.

[20] K. Hildrum, J. D. Kubiatowicz, S. Rao, and B. Y. Zhao, "Distributed object location in a dynamic network," In SPAA, pp. 41-52, New York, NY, USA, 2002.

[21] C. G. Plaxton, R. Rajaraman, and A. W. Richa, "Accessing nearby copies of replicated objects in a distributed environment," In SPAA, pp. 311-320, New York, NY, USA, 1997.

[22] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, "Topologically-aware overlay construction and server selection," In INFOCOM, 2002.

[23] I. Clarke, S. G. Miller, T.W. Hong, O. Sandberg, and B.Wiley, "Protecting free expression online with freenet," IEEE Internet Computing, vol. 6, no. 1, pp. 40-49, 2002.

[24] R. Morselli, B. Bhattacharjee, A. Srinivasan, and M. A. Marsh, "Efficient lookup on unstructured topologies," In PODC, pp. 77-86, New York, NY, USA, 2005.

[25] P. Ganesan, Q. Sun, and H. Garcia-Molina, "Yappers: A peer-to-peer lookup service over arbitrary topology," In INFOCOM, San Francisco, California, USA, 2003.

[26] G. H. L. Fletcher, H. A. Sheth, and K. Brner, "Unstructured peer-to-peer networks: Topological properties and search performance," Lecture Notes in Computer Science, vol. 3601, pp. 14-27, 2005.

[27] C. Lv, P. Cao, E. Cohen, K. Li, and S. Shenker, "Search and replication in unstructured peer-to-peer networks," In Proceedings of the 16th annual ACM International Conference on supercomputing, 2002.

[28] D. J. Watts and S. H. Strogatz, "Collective dynamics of 'small-world' networks," Nature, vol. 393, no. 6684, pp. 440-442, June 1998.

[29] L. A. Adamic, R. M. Lukose, A. R. Puniyani, and B. A. Huberman, "Search in power-law networks," Physical Review, E, vol. 64, no. 4, 2001.

[30] M. Penrose, "Random Geometric Graphs," Oxford Studies in Probability, Oxford University Press, USA, July 2003.

[31] C. Avin and G. Ercal, "On the cover time and mixing time of random geometric graphs," Theoretical Computer Science, vol. 380 no. 1-2, pp. 2-22, 2007.

[32] S. Boyd, A. Ghosh, B. Prabhakar, and D. Shah, "Mixing times for random walks on geometric random graphs," SIAM ANALCO, Vancouver, 2005.

[33] A. Klemm, C. Lindemann, and O. P. Waldhorst, "A special-purpose peer-to-peer file sharing system for mobile ad hoc networks," in Vehicular Technology Conference (VTC), 2003.

[34] A. Duran and C.-C. Shen, "Mobile ad hoc p2p file sharing," In Wireless Communications and Networking Conference 2004, IEEE WCNC, vol. 1, pp. 114-119, 2004.

[35] Z. J. Haas, J. Y. Halpern, and L. Li, "Gossip-based ad hoc routing," IEEE/ACM Transactions on Networking, vol. 14, no. 3, pp. 479-491, 2006.

[36] C. Lindemann and O. P. Waldhorst, "A distributed search service for peer-to-peer file sharing in mobile applications," In Proceedings of the Second International Conference on Peer-to-Peer Computing, pp. 73, Washington, DC, USA, 2002.

[37] S. Aly and A. Elnahas, "Sustained service lookup in areas of sudden dense population," Wireless Communication and Mobile Computing, vol. 8, no. 1, pp. 61-74, Sep. 2006.

[38] ns2. http://www.isi.edu/nsnam/ns.

[39] Gnutella. http://www.gnutella.com.

[40] B. Yang and H. Garcia-Molina, "Efficient search in peer-to-peer networks," In PODC, pp. 77-86, New York, NY, USA, 2005.

[41] N. Li, J. Hou, and L. Sha, "Design and analysis of an MST based topology control algorithm," In IEEE INFOCOM, 2003.

[42] V. Rodoplu and T. H. Meng, "Minimum energy mobile wireless networks," IEEE JSAC, vol. 17, no. 8, pp. 1333-1344, Aug. 1999.

[1] R. Wattenhofer, L. Li, P. Bahl, and Y.-M. Wang, "Distributed topology control for power efficient operation in multi-hop wireless ad hoc networks," In IEEE INFOCOM, Apr. 2001.

Minho Shin (1) and William A. Arbaugh (2)

(1) Institute for Security, Technology, and Society, Dartmouth College, Hanover, NH, USA [e-mail: mhshin@cs.dartmouth.edu]

(2) Computer Science Department, University of Maryland, College Park, MD, USA [e-mail: waa@cs.umd.edu]

* Corresponding author: William A. Abraubgh

Minho Shin is a Postdoctoral Research Fellow of Institute of Security, Technology, and Society (ISTS) at Dartmouth College. He earned his M.S. and Ph. D in Computer Science from the University of Maryland, College Park, USA in 2003 and 2007, respectively. He earned his B.S. in Computer Science and Statistics from the Seoul National University, Seoul, Korea in 1998. His research interests are in wireless networks, wireless network security, and user privacy in people-centric sensing. He has filed several patents in U.S., Korea, and India, and he has refereed articles for many journals and conferences.

William A. Arbaugh is an assistant professor in the Department of Computer Science at the University of Maryland, College Park. His research interests include information systems security and privacy with a focus on wireless networking, embedded systems, and configuration management. He received a BS from the United States Military Academy at West Point, an MS in computer science from Columbia University, New York, and a PhD in computer science from the University of Pennsylvania, Philadelphia. He is on the editorial boards of the IEEE Computer and the IEEE Security and Privacy magazines.

(1) We assume that no two nodes have the same node-ID.
COPYRIGHT 2009 KSII, the Korean Society for Internet Information
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2009 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Shin, Minho; Arbaugh, William A.
Publication:KSII Transactions on Internet and Information Systems
Article Type:Technical report
Date:Feb 1, 2009
Words:9574
Previous Article:NJ+: an efficient congestion control mechanism for wireless networks.
Next Article:Modeling and simulation framework for assessing interference in multi-hop wireless ad hoc networks.
Topics:

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters