hierarchical location service for mobile ad-hoc...

Hierarchical Location Service for Mobile Ad-HocNetworks

Wolfgang Kieß�

Holger Füßler�

Jörg Widmer�

[email protected] [email protected] [email protected] Mauve

�[email protected]�

Lehrstuhl für Rechnernetze, University of Düsseldorf, Germany�Lehrstuhl für Praktische Informatik IV, University of Mannheim, Germany�

Ecole Polytechnique Fédérale de Lausanne (EPFL), Switzerland

Position-based routing has proven to be a scalable and efficient way for packet routing inmobile ad-hoc networks. To enable position-based routing, a node must be able to discoverthe location of the node it wants to communicate with. This task is typically accomplishedby a location service. In this paper, we propose a novel location service called HLS (Hier-archical Location Service). HLS divides the area covered by the network into a hierarchy ofregions. The top level region covers the complete network. A region is subdivided into sev-eral regions of the next lower level until the lowest level is reached. We call a lowest levelregion a cell. For a given node

�, one specific cell is selected on each level of the hierarchy

by means of a hash function. As�

changes its position it transmits position updates to theseresponsible cells. If another node wants to determine the position of

�it uses the same hash

function to determine the cells that may hold information about the position of�

. It thenproceeds to query the nodes in these cells in the order of the hierarchy until it receives areply containing the current position of

�. Because of its hierarchical approach HLS is

highly scalable and particularly well suited for networks where communication partnerstend to be close to each other. Due to the inherent scaling limitations of ad-hoc networks itis very likely that most ad hoc networks will display this property. Furthermore HLS is veryrobust to node mobility and node failures since it uses regions to select location serversand not a chain of mobile nodes as it is the case, e.g., for the well known Grid LocationService (GLS). We demonstrate these traits by providing extensive simulation data on thebehaviour of HLS in a wide range of scenarios and by using GLS as a benchmark.

I. Introduction

Mobile ad-hoc networks (MANETs) enable wirelesscommunication between mobile devices without re-lying on a fixed infrastructure. In these networks themobile devices themselves forward data from a senderto a receiver, acting both as router and end-systemat the same time. MANETs have a wide range ofapplications, e.g., range extension of WLAN accesspoints, data transmission in disaster areas and inter-vehicular communication. Studies [5] have shownthat position-based routing is a well-suited solutionfor the challenging task of routing in highly dynamicMANETs. As a prerequisite of position-based routingalgorithms, each node in the network must be able todetermine the position of the target node it wants tocommunicate with.

We assume that the nodes are able to determinetheir own position, e.g. by means of a positioning ser-

vice such as GPS. The task of locating the destina-tion is then accomplished by a location service, a dis-tributed service maintained directly by the participat-ing nodes. In this paper, we present the HierarchicalLocation Service (HLS).

The basic operation of HLS is as follows: the areaoccupied by the network is divided into a hierarchyof regions. The lowest level regions are called cells.Regions of one level are aggregated to form a regionon the next higher level of the hierarchy. Regions onthe same level of the hierarchy do not overlap. Forany given node

�one cell in each level of the hier-

archy is selected by means of a hash function. Thesecells are called the responsible cells for node

�. The

hash function takes a node ID (e.g. an IP Address),the level of the hierarchy and the node’s position as aninput and determines the responsible cell for a nodewith this ID on this level of the hierarchy as an out-put. As a node moves through the area covered by the

Mobile Computing and Communications Review, Volume 8, Number 4 47

network, it updates its responsible cells with informa-tion about its current position. When another node �needs to determine the position of node

�it uses the

hash function to determine those cells that may poten-tially be responsible for

�. It then queries those cells

in the order of the hierarchy, starting with the lowestlevel region. On the first level that contains both nodes�

and � the query will arrive at a responsible cell of�where it can be answered.Due to its hierarchical approach and because of us-

ing the concept of responsible cells HLS has somevery desirable properties:

� it does not use flooding

� the number of location servers scales logarithmi-cally with the size of the network

� it is well-suited for high node mobility

� it specifically supports non-uniform communica-tion patterns

� it is robust to node failures

The remainder of this paper is structured as follows:In Section II we give an overview of related work. TheHLS algorithm is described in detail in Section III.Section IV contains the results of the simulation ofHLS with ns-2. The paper is concluded with a sum-mary and an outlook to future work in Section V.

II. Related Work

A location service consists of two algorithmic com-ponents, the location update and the location requestcomponent. The location update is responsible fordistributing information about the current location ofa target node � to a set of nodes called the locationservers of � . If a source � wants to discover thelocation of � , it launches a location request whichis routed through the network to one of the locationservers of � . The location server can either answerthe request itself or forward it to � for answering.

The range of possible designs of the update and re-quest component are limited by two extremes: floodposition updates or do not send any updates at all.If updates are flooded, each node becomes locationserver for each other node and no requests are nec-essary. If no updates are sent, each node is its ownand only location server, therefore requests need to beflooded in the network.

A location service which uses flooding to spreadposition information is DREAM [1], the DistanceRouting Effect Algorithm for Mobility. With DREAM,

each node floods its position information in the net-work with varying flooding range and frequency. Thefrequency of the flooding is decreased with increasingrange. Thus, each node knows the location of eachother node whereas the accuracy of this informationdepends on the distance to the node. The Reactive Lo-cation Service (RLS) [7] marks the other extreme ofthe design space: it uses flooding in its request com-ponent. RLS is only active if a node � needs to dis-cover the location of another node � . The request isflooded to all nodes in the network. Upon receivingthe request, � generates an answer and sends it backto � . Both of these extremes involve flooding the net-work. In contrast, an efficient location service shouldbalance the cost of updates and requests to avoid this.

A location service that does not require floodingis Homezone [3]. In the Homezone location service,each node is assigned an area (the so called Home-zone) in the ad-hoc network via a hash function. Lo-cation updates are sent to all the nodes in the home-zone. Location requests are answered by one of thenodes in this area. A major disadvantage of this de-sign is the single fixed homezone. Nodes are not lim-ited in their movements. As a result, nodes may be faraway from their homezone and their updates may haveto travel long distances. Furthermore, even requestsfrom nodes close to the target node must be forwardedall the way to the homezone. This can lead to high net-work load and latency. In contrast to Homezone ourapproach does not rely on a single homezone. Insteada hierarchy of regions is responsible for maintainingthe location of a node. As a consequence both updatesand requests from nodes that are close to the target re-main mostly local while additionally the robustness ofthe location service is increased.

The Grid Location Service (GLS) [10] divides thearea containing the ad-hoc network into a hierarchyof squares forming a quad-tree. Each node selectsone node in each element of the quad-tree as a loca-tion server. Therefore the density of location serversfor a node is high in areas close to the node and be-comes exponentially less dense as the distance to thenode increases. The update and request mechanismsof GLS require that a chain of nodes based on nodeIDs is found and traversed to reach an actual locationserver for a given node. The chain leads from the up-dating or requesting node via some arbitrary and somededicated nodes to a location server. As investigatedin [8], traversing the chain of mobile nodes may leadto significant update and lookup failures if node mo-bility is high: as soon as one of the dedicated nodesin the chain cannot be reached the update or request

48 Mobile Computing and Communications Review, Volume 8, Number 4

L1 L2 L3 L4

L5

L6 L7

L8

L9 L10 L11 L12

L15

A

L13L14

L16

��

� ��

��

��

�� !"#$%&'()

*+,-./

012345

6789

:;<=

>?

@A

BCDEFGHI

JK LM NO

PQRSTUVW

XYZ[ \] ^_`a

bc defg hijklmnopq rs

tu

vwxyz{

|}

~��

��

��

��

��

�� ¡ ¢£

¤¥¦§ ¨©ª«¬®¯

°±

²³ ´µ ¶·¸¹º»

Figure 1: DLM Location Servers (L1—L16) for anode A, inspired by [15]

message is lost. In order to avoid this problem, HLSuses the concept of responsible cells and does not relyon a chain of mobile nodes for update and lookup ofposition information.

DLM [15], the Distributed Location Managementscheme, uses a grid to partition the area of the networkas shown in Figure 1. In DLM the smallest squaresare assigned the highest level. Squares of the highestlevel are aggregated to form an area of the next lowerlevel. This is repeated until the whole area of the net-work is covered by a single area which is assigned thelevel 0. In the example the smallest squares are as-signed the level 3, sixteen of them are aggregated toform a region of level 2. Four level 2 regions forma level 1 region, four level 1 regions form the wholenetwork as a single level 0 region. DLM then selectsone level as the granularity for the distribution of lo-cation servers. In the example this is level two. Foreach node DLM selects one highest level (smallest)square in each of these regions. In each of the selectedhighest level squares, one node is chosen as locationserver. In the example the location servers for node Aare designated as ¼¾½ to ¼¿½ÁÀ . In order to reduce up-date overhead, the information about the location ofa node becomes more detailed the closer a locationserver is to a node. DLM does not rely on a chain ofmobile nodes and is therefore more robust to mobil-ity than GLS. On the other hand the even distribu-tion of location servers reduces its scalability: when-ever a node crosses the borders of a level-1 region orwhen periodic updates for maintaining a soft state aretransmitted, all location servers have to be updated.

Since the location servers are evenly distributed inthe network the resulting message overhead is simi-lar to that of network-wide flooding. In contrast, HLSuses a hierarchy of location servers and thereby com-pletely avoids communication patterns that are simi-lar to flooding the network. In addition the hierarchi-cal approach of HLS specifically supports communi-cation patterns where communicating nodes tend tobe close to each other. Given the well known scalingbehaviour of ad-hoc networks [4] it is very likely thatmost ad-hoc networks will display this property.

III. Hierarchical Location Service

To show how HLS works in detail, we first describethe structure of the hierarchy of regions. We then ex-plain how cells responsible for the tracking of a nodeare selected and how location updates and request aresent. Finally we show how the algorithm deals withcells that do not contain any nodes.

III.A. Area partitioning

HLS partitions the area containing the ad-hoc networkin cells. This partitioning must be known to all partic-ipating nodes. The shape and size of the cells can bechosen arbitrarily according to the properties of thenetwork. The only prerequisite is that a node in agiven lowest-level cell must be able to send packetsto all other nodes in the same cell. This can eitherbe achieved by choosing an appropriate cell size, i.e.,the distance between any two points in the cell mustbe smaller than the radio range, or by implementinga cell-wide broadcasting mechanism. 1 It is not re-quired that the area in which the MANET is deployedis fully covered by cells. Thus, HLS is applicable toareas containing obstacles such as buildings.

The cells are grouped hierarchically into regions ofdifferent levels. A number of cells forms a region oflevel one, a number of level-one regions forms a level-two region and so on. Regions of the same level mustnot intersect, i.e., each region of level Â is member ofexactly one region of level ÂÄÃÅ½ . An example for thearea partitioning is shown in Figure 2.

III.B. Responsible cells

HLS places location information for a node � in a setof cells. We call these cells the responsible cells (RC)of � . In the following, we say “ � updates a respon-sible cell Æ ” when � sends an update packet to an

1Note that this does not amount to flooding since such broad-casts are limited to the size of a lowest-level cell.


Figure 2: Grouping cells to form regions: cell, regionon level one and region on level two

arbitrary node within or close to Æ . This node be-comes location server for � . It is possible that sub-sequent updates arrive at different nodes within thatcell, for example because nodes have moved. A cellmay therefore contain multiple location servers for anode. Moreover, we assume that all necessary routingfor HLS is done with a position-based routing proto-col like GFG [2] or GPSR [5].

A node � selects one responsible cell for each levelin the hierarchy. For a given level Â , the RC is selectedaccording to the following algorithm:

1. Compute the set �ÈÇÉ�¿ÊËÂÍÌ of cells belonging to theregion of level Â which contains � .

2. Select one of these cells with a hash functionbased on characteristics of � (like the number ofcells in S) and the node ID of � .

A possible hash function is the simple, modulo-basedfunction: ÎÏÇÉ�¿ÊËÂÍÌÑÐ ID ÇÉ�ÒÌÔÓÄÕ×ÖÏØÙ�ÚÇÉ�¿ÊËÂÍÌÛØ . Withthe number calculated with this hash function, one ofthe cells in �ÈÇÉ�¿ÊËÂÍÌ is chosen. As a result of the aboveselection, � has exactly one responsible cell on eachlevel and it is guaranteed that the RC for � of levelÂ and node � share the same level- Â region. An ex-ample for the selection of RCs is shown in Figure 3for a three-level hierarchy. The large circles mark theregions and the cells with the numbers are the respon-sible cells. The node and its RC on level one share thesame level-one region, the RC of level two lies withinthe same level-two region as the node and so on.

An interesting observation is the following: if allcells are computed and marked which may become re-sponsible cells as a node moves through the network,we get a structure similar to the one shown in Fig-ure 4. All cells marked here are candidates for respon-sible cells. These candidate cells are connected witharrows to visualize their hierarchical, tree-like struc-ture. We call this structure candidate tree. The rootof the tree is the single RC candidate on the highest

1

2

3

1 2

3node

Figure 3: Example for responsible cells of a node

Figure 4: Candidate tree in a three level hierarchy

level. The leaves are the candidates for responsiblecells on the lowest level. As a node � moves throughthe network, a different subset of candidate cells willbecome responsible cells.

The candidate tree is different for each node andcan be computed from the hash function and the nodeID. Selecting the responsible cells for a node � canbe seen as selecting the branch in the tree which endsin the current level-one region containing � .

III.C. Location update

There are two different methods for HLS to updatelocation servers, the direct location scheme and theindirect location scheme.

To update its location servers according to the di-rect location scheme, a node computes its responsiblecells as explained in Section III.B. Position updatesare then sent to all RCs at the same rate. This updatescheme is called “direct” because a location server di-rectly knows the position of the node. In Figures 5(a)and 5(b), the location information in the RCs is repre-


sented as a pointer to the position of the node. In thisscheme all responsible cells must be updated when-ever the node has moved a distance large enough torender the position information in the location serversuseless (Figure 5(b)). While this can be done withoutmuch overhead for close location servers, updating theRCs on a higher level which tend to be farther awaymay cause a significant amount of network load.

The number of necessary single hop transmissionsto update a location server on level Ü depends on thesize of a region on that level. In the following we as-sume that the regions have a quadtree topology withÂ being the number of nodes in the network and d be-ing the diameter of the level-1 region. In the worstcase, the update packet for a given level must tra-verse the whole region of that level. Therefore, if anode needs to update all its location servers, the cost isÝ ÇßÞàÃâáãÞàÃÒäåÞàÃâæãÞàÃèçéçéçêÃâáãëíìïîðÞ×ÌñÐ Ý ÇËÇêáãëóòÑ½ÛÌôÞ×Ì . Withthe diameter D of the whole area being õöÐ÷á ëøìïî Þ ,this can be rewritten as

Ý ÇËÇêáåëÈòù½ÛÌôÞ×ÌúÐ Ý ÇËÇêáãëûò½ÛÌýüþËÿ�� ÌâÐ Ý Çßõ Ì . As the size of an area covered byn nodes grows with

Ý Ç � ÂÍÌ for a fixed node density,the worst case update costs for an update to all levelsis therefore

Ý Çßõ ÌñÐ Ý Ç � Â Ì .The network load can be reduced with the indi-

rect location scheme where the location servers onhigher hierarchy levels only know the region of thenext lower level a node is located in. More precise lo-cation information is not necessary on higher levels.As shown in Figure 6(a), the pointers which representthe location information do no longer point to the lastknown position. They point to the responsible cell onthe next lower level. Thus, this update scheme createsindirect location knowledge in the location servers. Incontrast to GLS, the chains established here do notconsist of moving nodes but of cells with fixed posi-tions making the scheme robust to high node mobility.

Given an ideal environment with no packet loss, alocation server on level Â needs to be updated onlywhen the node moves to another level- Ç Â ò ½ÛÌ region.Thus, the responsible cell on level one will be the onlycell which is updated if the node moves within theboundaries of the level-1 region (Figure 6(b)). Cellson higher levels need to be updated only if the RCon the next lower level changes (Figures 6(c), 6(d)).Hence, update traffic generated by a node is mostly lo-cal. The majority of the update packets have to travelonly a few hops whereas long-distance updates arerarely sent. Depending on the movement pattern ofthe nodes, the indirect location scheme may thereforereduce the costs for updates significantly. However,the worst case where all location servers have to be

1

2

3

(a) all RCs have exactknowledge of the nodesposition

1

2

3

(b) the node moves: allRCs must be updated

Figure 5: Direct location scheme

1

2

3

(a) RCs only haveknowledge about thenext lower region

1

2

3

(b) update the RC onlevel one

1

2

3

(c) update RC on leveltwo, change RC on levelone

1

2

3

(d) update RC on levelthree, change RC onlevel one and two

Figure 6: Indirect location scheme

updated is still possible (e.g., when a node crosses theboundaries of the highest level region), thus the worstcase effort remains at

Ý Ç � ÂÍÌ .To overcome location server failures which can oc-

cur for both update schemes, we have chosen a softstate approach. As this leads to possibly unnecessaryupdates-especially for the indirect update scheme-other mechanisms to overcome these losses such asthe use of backup location servers could be investi-gated in the future to further reduce network traffic.

III.D. Handovers

Since the identification of a location server dependsonly on its position, a node leaving a responsible cellcan no longer be location server for information be-


longing to this responsible cell. In this case, the in-formation belonging to the cell just left is handed overto this cell and treated like an update: the handoverpacket is forwarded to a node in or close to the cellwhich becomes the new location server.

III.E. Position Requests

To successfully query the current location of a tar-get node � , the request of a source node � needs tobe routed to a location server of � . When queryingthe position of � , � knows the ID of � and thereforethe structure of the candidate tree defined via the hashfunction and � ’s ID. It furthermore knows that � hasselected a RC for each region it resides in. Thus, therequest only needs to visit each candidate cell of theregions containing � . The candidate cell of the regionwith the lowest level containing both � and � is perdefinition a responsible cell, and so are the candidatecells of all higher levels.� computes the cell which � would choose as re-sponsible cell if it were in the same level-one regionand sends its request to this cell. When the requestpacket arrives at the first node

�within the bound-

aries of the candidate cell, it is processed as follows:

1. Node�

broadcasts the request to all nodes withinthe candidate cell. This is called cellcast request.

2. Any node which receives this cellcast request andhas location information in its location databasesends an answer to

�.

3. If�

receives an answer for its cellcast request,the request is forwarded to the target node � .

4. Otherwise�

forwards the request to the corre-sponding candidate cell on the next level.

With this mechanism, the request is forwarded fromcandidate cell to candidate cell until a location serverfor � is found or the highest level candidate cell hasbeen reached.

The algorithm ensures that in the worst case the re-quest is forwarded to the top-level RC, the candidatecell which is guaranteed to be also a responsible cell.In this worst case, the request has a complexity similarto the one given above for the updates,

Ý Ç � ÂÍÌ . Usu-ally, the request reaches a responsible cell on a lowerlevel, in particular if communication partners tend tobe close to each other. The level of the first candidatecell which is also a responsible cell for � depends onthe distance between � and � . The closer the twonodes are, the earlier the branch of the candidate treeselected by � for its updates and the one calculated

by � for its request will match. The branches “meet”on level Ü , if a level- Ü region is the lowest-level regionwhich contains � and � . An upper bound for the av-erage distance the request packet has to travel to finda location server is

Ý Çêá�� Þ×ÌñÐ Ý ÇßÞ×Ì with Þ being thediameter of a level- Ü region. Obviously, all candidatecells computed for this request with a level higher thanÜ are responsible cells as well.

Examples for requests are given in Figure 7. Here,location servers are updated according to the indirectlocation scheme. If the two nodes are located in thesame level-1 region as shown in Figure 7(a), the can-didate cell on level one also is a responsible cell andshould contain a location server. The request can bedelivered and answered directly. In Figure 7(b), � islocated in the same level-2 region as � . The requestis forwarded via the candidate cell on level one to theresponsible cell on level two which should contain alocation server. In the third example presented in Fig-ure 7(c), � and � are located in different level-2 re-gions. The request is forwarded to the candidate cellson level one and two, then it reaches the RC on levelthree and eventually finds a location server for � .

As shown in the examples, a request packet is for-warded only within the boundaries of the lowest levelregion where both nodes reside in. The communica-tion complexity of a request depends on the distancebetween sender and target of the request. If commu-nication is local, so is the request behaviour of HLS.

III.F. Empty cells

A problem which has not been addressed so far areempty or unreachable cells, i.e. a location update orrequest packet is sent to a cell which does not containa node or which is unreachable due to a partitionednetwork. In HLS this problem is solved as follows:if an update can not be forwarded to the target cell,the node detecting this becomes a temporary locationserver. Thereafter, the information is treated by thehandover mechanism explained above like any otherlocation information outside its target RC: the tempo-rary location server regularly tries to hand the infor-mation over to the target cell.

If a request looks for a location server in an emptycell, it cannot be determined if the cell is a respon-sible cell or a candidate cell. There are two ways toproceed if a request cannot reach the cell it is sent to:either search the neighbourhood for a temporary loca-tion server or forward the request to the next higherlevel. For HLS we have chosen a combination: for allbut the highest level requests are forwarded to the nextlevel while on the highest level the neighbourhood of


0

20

40

60

80

100

10 30 50

succ

ess

rate

[%]

speed [m/s]

HLSGLS

(a) 25 Nodes per square kilometer

0

20

40

60

80

100

10 30 50

succ

ess

rate

[%]

speed [m/s]

HLSGLS

(b) 100 Nodes per square kilometer

Figure 14: The percentage of successfully answered queries of HLS and GLS at varying nodes densities

that HLS achieves good results at low communicationcost. It is only slightly influenced by high node speedsand scales well with the geographic extension of thenetwork due to its pure position-based routing of up-dates and requests. Even in the largest scenario simu-lated, an area of 5 � 5 kilometers populated with 1875nodes, HLS’ performance did not degrade perceptiblycompared to smaller scenarios5 .

Our simulations also revealed areas where HLS canbe improved further, in particular for networks withlow node density where empty cells are frequent. Wesee two main directions that can be followed in or-der to alleviate this problem: the use of more aggres-sive caching strategies and reconsidering how posi-tion information is stored. Even though the formerrequires a careful consideration regarding the time acached entry remains valid, it can be realized as aconceptually straight forward adaptation of existingapproaches. The latter requires more extensive mod-ifications: In HLS there exists one location server ineach responsible cell. This causes problems when thelocation server leaves the cell (because the locationinformation has to be handed back into the cell) orsimply fails. More importantly it reduces the successrate for low node densities because an increasing num-ber of responsible cells no longer contain any nodesthat can act as a location server. It may therefore beworthwhile to investigate the use of the GeographicHash Table (GHT) system proposed in [13] which hasbeen initially developed for data storage in sensor net-works. GHT stores information in those nodes that

5Due to computational limitations, this scenario has been sim-ulated with a simplified MAC layer which does not produce col-lisions.

form a perimeter around a point. In case of HLS thispoint would be the center of the responsible cell. Thenode closest to this point is responsible for regularlysending the information to the other members of theperimeter. If the closest node fails, another memberof the perimeter will sent an update after a timer hasexpired and a new closest node can be elected. Themain benefits of using GHT would be that responsi-ble cells may be empty without any negative impact(the perimeter used for storing the location informa-tion would simply be outside of the responsible cell)and that the robustness is increased. A disadvantageof using GHT may be the increased complexity of themechanism in combination with a higher network loadfor maintaining the information in the GHT system.

In addition to these two main directions of futurework dead reckoning could be employed to prolongthe validity of location information. Furthermore, ifall nodes in the network move in the same directionand therefore most of the predefined cells are empty,the HLS algorithm should be adapted to this situation.Another interesting idea are cells moving accordingto a predictable pattern, e.g. along a highway. Withthe time information of the GPS signal, it can be com-puted at which point of the highway the cells are lo-cated. A location server moving along the highwaymay stay location server for a long time because itstays in the cell which is also moving. Therefore, lesshandovers are necessary and communication overheadis reduced while the functionality stays the same.

Concluding, we believe that a hierarchical approachwhere cells are responsible to maintain position in-formation is very promising as location service forMANETs. While there are still many ways to improve


upon HLS as presented here, we were able to showthat in particular for settings with large networks, highnode mobility or moderate to high node density HLSalready outperforms existing approaches.

References

[1] S. Basagni, I. Chlamtac, V. R. Syrotiuk, andB. A. Woodward. A Distance Routing Effect Al-gorithm for Mobility (DREAM). In Proceedingsof the fourth annual ACM/IEEE InternationalConference on Mobile computing and network-ing (MobiCom ’98), pages 76–84, Dallas, Texas,October 1998.

[2] P. Bose, P. Morin, I. Stojmenovic, and J. Urru-tia. Routing with guaranteed delivery in ad hocWireless Networks. In Proceedings of the 3rdinternational workshop on Discrete algorithmsand methods for mobile computing and commu-nications (DIAL-M ’99), pages 48–55, Seattle,WS, August 1999.

[3] S. Giordano and M. Hamdi. Mobility Manage-ment: The Virtual Home Region. Technical Re-port SSC/1999/037, EPFL-ICA, October 1999.

[4] P. Gupta and P. Kumar. The Capacity of Wire-less Networks. IEEE Transactions on Informa-tion Theory, 46(2):388–404, March 2000.

[5] B. N. Karp and H. T. Kung. GPSR: GreedyPerimeter Stateless Routing for Wireless Net-works. In Proceedings of the sixth annualACM/IEEE International Conference on Mo-bile computing and networking (MobiCom ’00),pages 243–254, Boston, Massachusetts, August2000.

[6] M. Käsemann. Beaconless Position-Based Rout-ing for Mobile Ad-Hoc Networks. Master’sthesis, Department of Mathematics and Com-puter Science, University of Mannheim, Febru-ary 2003.

[7] M. Käsemann, H. Füßler, H. Hartenstein, andM. Mauve. A Reactive Location Service for Mo-bile Ad Hoc Networks. Technical Report TR-02-014, Department of Computer Science, Univer-sity of Mannheim, November 2002.

[8] M. Käsemann, H. Hartenstein, H. Füßler, andM. Mauve. Analysis of a Location Service forPosition-Based Routing in Mobile Ad Hoc Net-works. In Proceedings of the 1st German Work-shop on Mobile Ad-hoc Networking (WMAN

2002), GI – Lecture Notes in Informatics, pages121–133, March 2002.

[9] W. Kieß. Hierarchical Location Service for Mo-bile Ad-hoc Networks. Master’s thesis, De-partment of Computer Science, University ofMannheim, 2003.

[10] J. Li, J. Jannotti, D. S. J. DeCouto, D. R. Karger,and R. Morris. A Scalable Location Service forGeographic Ad Hoc Routing. In Proceedings ofthe sixth annual ACM/IEEE International Con-ference on Mobile computing and networking(MobiCom ’00), pages 120–130, Boston, Mas-sachusetts, August 2000.

[11] M. Mauve, J. Widmer, and H. Hartenstein. ASurvey on Position-Based Routing in MobileAd-Hoc Networks. IEEE Network, 15(6):30–39,November/December 2001.

[12] The ns-2 network simulator. http://www.isi.-edu/nsnam/ns/.

[13] S. Ratnasamy, B. N. Karp, L. Yin, F. Yu, D. Es-trin, R. Govindan, and S. Shenker. GHT: a ge-ographic hash table for data-centric storage. InProceedings of the first ACM international work-shop on Wireless sensor networks and applica-tions (WSNA 2002), pages 78–87, Atlanta, Geor-gia, September 2002.

[14] E. M. Royer, P. M. Melliar-Smith, and L. E.Moser. An Analysis of the Optimum Node Den-sity for Ad hoc Mobile Networks. In Proceed-ings of the IEEE International Conference onCommunications, Helsinki, Finland, June 2001.

[15] Y. Xue, B. Li, and K. Nahrstedt. A scalablelocation management scheme in mobile ad-hocnetworks. In Proc. of the IEEE Conference onLocal Computer Networks (LCN’2001), Tampa,Florida, November 2001.


hierarchical location service for mobile ad-hoc...

Documents