distributed hash tables for peer-to-peer mobile ad-hoc ... · pdf filedistributed hash tables...

Distributed Hash Tables for Peer-to-Peer MobileAd-hoc Networks with Security Extensions

Grant P. Millar, Emmanouil A. Panaousis and Christos PolitisWireless Multimedia & Networking (WMN) Research Group, Kingston University London, UK

Email: {g.millar, e.panaousis, c.politis}@kingston.ac.uk

Abstract— Serverless distributed computing, especially Mo-bile Ad-hoc NETworks (MANETs) have received signifi-cant attention from the research community. Peer-to-peeroverlay networks have the potential to accommodate large-scale, decentralised applications that can be integrated into aMANET architecture to enable peer-to-peer communicationamong different mobile peers. These overlay architecturesmust be very resilient and their utilisation, reliability andavailability must satisfy the needs of mobile computing. Onemust also heed the fact that the wireless nature of themedium introduces security vulnerabilities. The aim of thework described in this paper is twofold. First, we describeour peer-to-peer distributed hash table (DHT) architectureentitled Reliable Overlay Based Utilisation of Services andTopology (ROBUST). This is designed to be efficientlyapplied to MANETs. We additionally propose security ex-tensions to protect the ROBUST signalling messages againstmalicious activities. We evaluate the ROBUST performanceas well as the security extensions under varying levels ofmobility and network sizes by building a custom DHTmodule for the network simulator ns-2. The outcome ofthe results show negligible overhead introduced by theextensions giving credence to their application in securitysensitive scenarios.

Index Terms— peer-to-peer, mobile ad-hoc networks, dis-tributed hash tables, security

I. INTRODUCTION

The increase in computing power over time has causedan evolution in every day personal computers and laptopsmaking them lightweight and portable with capabilitiesto act as both routers and clients in the network. Thishas spawned the creation of Mobile Ad hoc Networks(MANETs), which encompass the peer-to-peer (P2P) adhoc paradigm. In MANETs all peers are able to sendand retrieve data independently as well as act as routers(or intermediaries) for clients whom need to send dataover multiple hops as a result of the target peer beingphysically further away than the maximum transmittablerange of the source peer.

The motive for using MANETs is that no additionalinfrastructure is needed other than the devices them-selves. Therefore to exploit the synergy of the peer-to-peer paradigm of MANETs, one must look towardsan integrated solution to applications and informationsharing, such as Distributed Hash Tables (DHTs). Themotive for using DHT in MANETs is due to an extremelyquick setup time in both application and network layerin addition to the fact that no additional infrastructure

is needed in either layer other than the devices them-selves. DHTs allow us to find the exact location of a partyor piece of information stored within the network, usinga piece of simple meta-data for example a name anddomain, as proposed in Peer-to-Peer Session InitiationProtocol (P2PSIP). However the use of DHTs is notlimited to simple name resolution and their distributedstructure also allows for fast propagation and high avail-ability of information through the network. When appliedto MANETs which have no central authority, DHTs couldprovide the answer to distributed services such as DNS(Domain Name System), P2PSIP, distributed storage andinformation sharing, whilst aiding service lookup anddiscovery. Last but not least, all types of data could bestored redundantly and accessed easily and quickly by anypeer.

A. Related Work

The area of research dedicated to aid the reductionof overhead from application layer architectures such asDHTs has seen significant activity in the recent past. Agreat amount of said research falls within the realmof static networks and Internet architectures, however amoderate amount of research can also be attributed tosolutions in MANETs. We will have a overview of theaforementioned works in this section.

The paper [1] describes an algorithm designed to createa perfect-ring overlay in order to distribute messagesto peers within a certain overlay group. A perfect-ringoverlay is denoted as an overlay where sent messagesare unidirectional and traverse all peers within a grouponce, before returning to the originator of the mes-sage. This can be useful when peers form groups orclusters which can be linked together in a ring struc-ture. Whilst most DHT-overlays use a single-ring struc-ture, the architecture proposed in [1] uses disjoint pathsand routes for connecting overlay peers whom do notform part of the main ring. The algorithm is not relianton any underlying infrastructure thus the overlay canfunction independently of the network layer and still beefficient. Another scientifically interesting issue is that thetopology mismatch problem where the overlay networktopology does not match that of the underlying networkcausing the overlay network to stretch out over the phys-ical network. This issue must be considered in all DHTsdesigned for MANETs. In [1] the authors propose to

1

288 JOURNAL OF NETWORKS, VOL. 7, NO. 2, FEBRUARY 2012

© 2012 ACADEMY PUBLISHERdoi:10.4304/jnw.7.2.288-299

negate the problem by sending messages with very shortTime To Live (TTL) when setting up the overlay. Thiscreates an overlay with very strong proximity betweenthe peers. The size of an optimised ring transmitted by amember of a group containing N members is O(2N) ∼O(N).

The authors of [2] specifically examine cross-layerDHT MANET protocols. The examined architectures areEtka [3], Mobile Peer-to-peer Protocol (MPP) [4], aGnutella optimisation for MANETs [5], FastTrack overAODV (Ad hoc On-demand Distance Vector) [6], andMADPastry [7]. Amongst these architectures, Etka andMADPastry are structured peer-to-peer overlays whilst therest are unstructured. The Etka [3] architecture tightly in-tegrates the structured P2P protocol based on DHTs withthe routing architecture of MANETs by mapping logicalDHT peer IDs to their MANET IP based counterpartscausing the two separate architectures to merge into onestructure. This is achieved by integrating the Pastry DHTwith the DSR (Dynamic Source Routing) MANET multi-hop routing protocol at the network layer. MADPastry[7] is a DHT substrate which acts by combining thePastry DHT with AODV MANET routing at the networklayer. This can lower the overhead needed to maintainthe DHT. While the architecture utilises three differentrouting tables (One akin to AODV’s routing table, anotherakin to Pastry’s routing table, and a leafset table) the onlytable requiring proactive management is that of the leaf-set table, with peers pinging their left and right respectiveleafs. The additional tables are updated by overhearingdata packets destined for other peers.

In the majority of the proposed DHTs for MANETspublished in the bibliography little thought has been givento security considerations. Especially, in all of the papersregarding DHT MANET protocols there is no mentionof security for the DHT signalling messages. The mostof the DHT-based P2P protocols take for granted thatthe participating peers behave legitimately and abstainfrom implementing major security measures. The latterare expected to be employed by software implementationsthat defend the P2P network against potential adversaries.

Adversaries within a P2P MANET network [8] arethose peers which intentionally do not follow the protocolrules. For instance, a malicious peer might provide legit-imate peers with erroneous lookup results or inoperativedata. In addition, as far as P2P systems inherently relyon the relationships among the participated peers, trustissues arise with a need to be addressed by proper securityextensions regarding signalling messages.

B. Contributions

In this paper we will describe our P2P DHT forMANETs entitled ROBUST (Reliable Overlay BasedUtilisation of Services and Topology). ROBUST aims atdecreasing the average path length and lookup time whensending DHT messages thereby decreasing stretch, whiledecreasing the maximum path length from the acceptedO(logN) standard in DHTs designed for static networks

to O(logC)1 complexity seen in most common DHTsused today.

In addition to the above, we will describe securityextensions for ROBUST to protect the signalling mes-sages against cryptanalysers. These extensions include (i)a key exchange phase where ROBUST peers exchange apairwise symmetric key Kpwk material with their leafsetpeers as well as their super peers, (ii) a key refresh phasewhere peers generate new key material and exchange itwith their leafset peers as well as their super peers, (iii)a proximity synchronisation phase where peers that wishto join a new cluster, to lower delay, have to accomplisha secure handshake and exchange key material with theirnew super peer and leafset peers.

C. Analysis and structure of this paper

In this paper we have first theoretically describedthe ROBUST DHT architecture as well as its securityextensions. We have explained why ROBUST DHT is asuitable solution for MANETs and we have then discussedthe total packet overhead of the architecture mentioningall the different packet types. To evaluate the performanceof the architecture we have developed a module2 for ns-2(network simulator) which simulates the ROBUST DHTand its security features for MANETs at the packet-level.

The remainder of this paper is organised as follows. Insection II we describe and discuss the Reliable OverlayBased Utilisation of Services and Topology (ROBUST)DHT scheme and its security extensions. In section IIIwe describe the different types of packets of our modelas well as the overhead introduced by these packets. Insection IV we present the performance evaluation in termsof ns-2 simulation results. Section V concludes this paperdiscussing the benefits and the limitations of our solutionsas well as our plans for future.

II. PROPOSED ARCHITECTURE

Our proposed architecture is entitled ROBUST DHT[9] which stands for Reliable Overlay Based Utilisationof Services and Topology. The aim of the architec-ture is to decrease the average path length and lookuptime when sending DHT messages thereby decreasingstretch, while decreasing the maximum path length fromthe O(logN) complexity seen in most common DHTsused today, where N is the number MANET peers.

The concept central to our DHT is to use a clus-tered hierarchical topology. This means peers will beclustered together based on proximity in the underlyingMANET. The peers will be connected via a super peerwhich keeps track of peers within the cluster and alsocarries out cluster maintenance. Cluster peers will be ableto communicate with one another, however peers withineach cluster will forward their queries to their dedicatedsuper peer, if the destination lies outside of the cluster, the

1where N is the number of peers in the DHT and C is the numberof clusters in ROBUST DHT.

2using C++ and TCL programming languages.

2

JOURNAL OF NETWORKS, VOL. 7, NO. 2, FEBRUARY 2012 289

© 2012 ACADEMY PUBLISHER

peer will forward the query to the super peer responsiblefor the destination peer, the destination peer will thenreply to the request.

At any given time we need C clusters where C =d Nlog2 N e and N is the total number of peers in the

network. This gives us a total routing complexity ofO(log2 C) + O(1) and O(log2 C) ≤ O(log2 N).

To address the issue of scalability and reduce any onesuper peer from being bottlenecked, more clusters wouldneed to be factored into the DHT as the amount of peersincreases. We propose to investigate two algorithms toincrease the number of clusters. The first of which is when

Nlog2 N > 2C where C is the current number of superpeers, each cluster will split their responsible ID spaceby 2. This maintains a balanced load and only createsmore overhead due to moving keys at 2C. In the secondalgorithm we increase the number of clusters for everyC = N

log2 N and would need to decrease the size of eachcluster by:

100

C− 100

( Nlog2 N )

(1)

percent where C is the amount of current clusters. De-creasing the size of each cluster would leave ID spacebetween each cluster, therefore each cluster would need tobe moved in order to create a seamless ID space, resultingin a need to move a total of:

log2 N2

100· 100

( Nlog2 N )

(2)

data keys when the number of keys each peer is respon-sible for is O(log2 N) keys.

When the number of peers in the DHT decreases, thereis no longer a need for so many clusters if C < N

log2 Nhowever to limit overhead and to maintain a threshold, thenumber of clusters will only be decreased when N

log2 N <2C. This adaptive quality means that the overlay canmaintain a lower number of total hops during lookupsand decrease lookup latency whilst still being scalableand load balanced. When building the algorithm it hasbeen specifically modelled to deal with a lower numberof peers than that of DHTs created for use in massivenetworks. For instance DHT’s used on the Internet canencompass thousands of peers, we do not currently fore-see such possibilities in MANETs due to the restrictionsof the routing protocols later discussed in this paper.

Peer proximity is central to our algorithm and we havedesigned the architecture with this notion in mind. Fromthe start when peers join the overlay they contact thenearest bootstrap peer, which is the nearest super peer. Ifthe number of peers within the cluster is less than log2 Nthe peer will join that cluster after being given a peerIDby the super peer in order to maintain ID space equality. Ifthe the number of peers within the cluster is equal tolog2 N the super peer will forward the join request to itsclosest two super peers (the first numerically greater thanand less than its own peerID) these super peers will thenrun the same algorithm until the peer has joined a cluster

with a free space. The maximum number of steps to finda non-full cluster is denoted as O(log2 C).

The next step is to take into account mobility. Whenpeers move through the physical space, they may becloser physically to another super peer. In order tomaintain proximity a function aptly named proximitysynchronisation is proposed. This is achieved by superpeers periodically broadcasting a beacon to each of thepeers within their cluster, these peers then forward thebeacon to any peers around them with a 1 hop TimeTo Live (TTL). The result of this function is that ifa peer moves closer to another super peer, it can pingthe newly discovered super peer and compare its latencywith the current super peer with which it has establishedcommunications. If the newly discovered super peer iscloser, the peer sends a move request to the relevantsuper peer, if the cluster is not full the peer leaves theoverlay with its current ID and rejoins with an ID issuedby the new super peer. This only happens periodically tolimit overhead and the problem of a peer intermittentlyswitching between two close super peers.

The last factor taken into account in this paper for theproposed architecture is that of super peer election, thesuper peer should be the peer whom is optimally suitedto take the role. Therefore factors such as throughput, re-maining battery power and latency should be taken intoaccount. It is proposed that periodically the current superpeer will poll all of the peers within its cluster for a reli-ability metric u every 300 seconds so that the network isnot over saturated with super peer changes. The reliabilitymetric is calculated as the following; u = w1t + w2b +w3l. To allow flexibility in different scenarios, wi valuesare weights given to increase or decrease the impact factorof a given metric. The values of t, b and l are measured bysome threshold denoted as [v1v2, ..., vj ] where a highervalue equates to higher reliability. The data values used tocalculate the reliability metric are as follows; maximumthroughput t in bits per second, remaining battery powerb as a percentage of remaining power, and latency l whichis the average latency between the peer and every peer inthe cluster. This metric allows us to simply select the peerwith the highest reliability metric to be the super peer.

A. ROBUST Signalling

This section describes the signalling packets neededto maintain the ROBUST DHT. The model consists ofthe list of inputs followed by the computational func-tions, followed by a practical example in the performanceevaluation section. The formulas also indicate the packetoverhead which provide insight into the efficiency of theproposed architecture due to the sensitivity of MANETsto network congestion when a high number of packetsare being exchanged. This can be evidenced by thelarge number of duplicate packets sent and received byMANET nodes on the transport layer due to expiring ofthe round trip timer which is estimated using previoussent packets. Thus, the higher the amount of packetsbeing routed around the MANET the higher the delay

3



jitter occurs causing high variance in round trip time(RTT); causing even more duplicate packets.

Within the DHT, single overlay hops can be at-tributed to multiple physical hops on the underlyingnetwork. Thus, in a typical overlay we can denote theupper bound on hops as DHThmax = O(log2N) wheren is equal to the total number of peers in the overlaynetwork. However in ROBUST we reduce this by routingrequest through super peers and hence having an upperbound on hops described as DHThmax = O(log2 C).

In the model we assume the underlying transport layerprotocol is UDP as used in OpenDHT [10] this is due tothe fact that the DHT must have access to transport infor-mation in order make decisions such as whether to removea peer due to packet loss, we expect reliable transfers byuse of acknowledgement packets and sequence numbersin the DHT and the use of round trip timers. We cancalculate the total packets (space) needed for DHT datagathering, and overlay maintenance for each peer denotedas:

DHTproc = DHTget(no gets) +DHTput(no puts)

+DHTack +DHTsync(tsync) +DHTls up(tls)

+DHTping(tping) +DHTclstr beacon(tbeacon)

+DHTprox sync(tprox sync)

+DHTjoin(no joins)(3)

where the DHT functions are denoted below. First DHTgets (data retrieval) are calculated as follows:

DHTget = 2DHTget req ·DHThmax · no gets (4)

This equation has been derived based on the factthat there are two packet types sent for one get request(GET and GET SUCCESS) therefore the total must bemultiplied by a factor of 2, we then take into accounteach overlay hop denoted as DHThmax and multiply itfor the total number of gets for the systems, in order toget the spacial overhead. Similarly we calculate all putsin the DHT as:

DHTput = 2DHTput req ·DHThmax · no puts (5)

We then calculate the packets required for data synchro-nisation across all peers for a particular given leafset:

DHTsync = (DHTsync vals+

DHTstr keys) ·DHThmax ·T

tsync

(6)

where DHTsync vals is the synchronisation requestpacket, DHTstr keys are the storage keys held at theleafset peer for which both the requesting peer and theleafset peer are responsible and tsync is the periodicsynchronisation interval. The function for leafset updatingis denoted as:

DHTls up = (DHTpull ls +DHTpush ls) ·DHThmax ·T

tls(7)

where DHTpull ls denotes the leafset pullrequest, DHTpush ls denotes the keys of all theleafset peers required and tls equates to the periodicleafset update interval. We can describe the function forpeers joining the overlay as:

DHTjoin = DHTjoin req ·DHThmax · C · no joins(8)

where DHTjoin req equates to the join requestpacket, which is forwarded to the nearest super peer witha free space in the cluster C this is multiplied by thenumber of peers which join the network no joins. Wecan calculate all pings in the DHT as:

DHTping = DHTls peer ·DHThmax ·T

tping(9)

where DHTls peer is the leafset list for a given peer, andtping is the periodic ping interval. When a super peer(SP ) broadcasts a cluster beacon every tbeacon timeperiod containing its own information to all of its 1 hopneighbours (DHT1 hop) to determine whether the peerhas a better like to the new super peer rather than its oldsuper peer, we can describe this transaction as:

DHTclstr beacon = [(DHTbeacon+

+DHTping) ·DHT1 hop] ·T

tbeacon(10)

We will now examine the Proximity synchronisationfunction, which is called periodically at every tprox sync

interval and acts when a peer moves closer to anothersuper peer SP ′ and consequently should move to the newcluster by adopting a new ID in the DHT space in orderto reduce stretch in the overlay and delay. The overheadof this function can be denoted as:

DHTprox sync = (DHTmove req +DHTmove rep

+DHTpart ·DHThmax

+DHTbroad part ·DHTls

+ 3DHTls up

+ 3DHTsync) ·DHTmove peer

(11)

where DHTmove req is the request to join the new clus-ter, sent from the joining peer to the super peer calledSP ′. DHTmove rep is the reply from the super peer SP ′

to the joining peer indicating whether there is room inthe cluster for the peer to join. DHTpart is a packet sentfrom the joining peer to the super peer SP indicatingthat the joining peer is leaving the cluster for whichSP is responsible. The super peer SP will then removethe joining peer from its leafset if the peer is included

4



and removes the peer from its cluster set which containsinformation about all of the peers within the cluster forwhich SP is responsible. DHTbroad part symbolises thepackets sent from SP to all of the peers within theoriginal leafset (DHTls) of the joining peer relaying tothem the information that the joining peer has left thecluster. These peers will then remove the joining peerfrom their leafset. DHTmove peer refers to the number ofpeers with high enough mobility in order to pass the mo-bility awareness threshold which is derived by comparingthe round trip time (RTT) found by DHTclstr beacon ofSP and SP ′. We finally calculate the total number ofacknowledgement messages needed to acknowledge allthe above mentioned packets as follows:

DHTack = DHTget +DHTput +DHTsync +DHTls up

+DHTping +DHTclstr beacon +DHTprox sync

(12)

B. Assumptions and limitations of ROBUST DHT

One limitation of the ROBUST DHT appears whena super peer disconnects from the network. This causestemporary instability in the DHT as a new super peerwill need to be elected. During this time DHT routingfrom and to the affected cluster will be lengthened fromO(logC) to O(logN). This occurs due to peers fallingback to traditional DHT routing using their leafset peersto route information.

Another limitation of ROBUST DHT is based on therestrictions of MANET routing protocols, at the timeof writing IETF has two main RFCs in this area andwork is ongoing. Due to the still experimental protocolsbeing used in MANETs, with larger networks high de-lay and packet loss can be expected, which invariablyaffects the DHTs functionalities. We try to counter thisby making the DHT topology as close as possible tothat of the MANET in order to lower the overheadincurred. One of the main reasons for this discrepancy isdue to frequent route changes which can cause multipleduplicate packets and network congestion as described inthe paper [11]. This was later confirmed by the authorsin [12] where using a real-world testbed implementationof OLSR, the authors found mobility incurs a large delayeven for a small sized MANET, in this specific case theauthors used up to 5 MANET peers and experienced anend-to-end delay of over 3 seconds due to transport layerand interference issues.

In Fig. 1 we show an overview of the DHT architec-ture. The box at the top of the figure represents a top downoverview of the network containing two clusters whereC1 represents cluster 1 and C2 represents cluster 2. Thedashed lines around these clusters represent the broadcastradius for the super peers for each cluster SP1 and SP2

respectively. Each step of the diagram is explained indetail below:

1) Peer P1 moves out of transmission range of su-per peer SP1 and subsequently into transmission

SP1 SP2

P2 P1

P1

SP1

SP2

P1 P1

2.

1.

3.

4.

ls1 ls2 ls3 ls4 ls5 ls6

5. 5. 5. 5. 5. 5.

ls1 ls2 ls3 ls4 ls5 ls6

6. 6.

7. 7.

8.

P2

9.

10.

11.

12.

SP beacon, 1 TTL

C1

C2

C1 C2

Figure 1. An overview of the described DHT architecture.

range of super peer SP2, therefore receiving theDHTclstr beacon packet from said super peer andgaining knowledge of its presence.

2) P1 then compares SP1RTT with SP2RTT overa period of 3tbeacon to confirm the results withthe realisation SP2RTT < SP1RTT . P1 thereforesends a DHTmove req packet to SP2 to ascertainwhether there is space in the cluster for the peerto join (as previously stated clusters can must bewithin size log2N with a variance of +2 peers inorder to maintain an equally distributed ID space).

3) SP2 sends P1 a DHTmove rep packet stating ifthere is indeed room in the cluster and if so, sendsa new ID prefix for peer P1 and also the IPs of P1snew closest predecessor (closest peer ID lower thanP1) and successor (closest peer ID higher than P1)in the cluster.

4) If there is space for P1 to join the cluster C2, itthen sends a DHTpart packet to its previous superpeer SP1 notifying it that P1 is leaving the clusterand subsequently removes all previous nodes fromits leafset.

5) Upon SP1 receiving the DHTpart packet, it firstsends a DHTbroad part packet to P1s previousleafset peers notifying them that P1 has left thecluster, they subsequently remove the peer from allof their DHT routing tables as does SP1.

6) P1 then sends a DHTls up packet to its predecessorand successor nodes, they add the node to theirleafset and reply to P1 with the leafset peers whichfall within P1s leafset.

7) The leafset nodes of peer P1 learn of his existencethrough the leafset update function which runsevery tls period and chooses a random existing

5



leafset peer to sync with.8) The leafset peers of P1 run the DHTsync data syn-

chronisation function every tsync interval randomlychoosing a leafset peer to synchronise data valuesfor which both the peers are responsible. In thisway peer P1 will receive all of the data values it isresponsible for.

9) Peer P2 of cluster C1 submits a DHTget req to itssuper peer SP1 whom then compares the ID lookupstored in the request with the ID’s of all of the othersuper peers in the overlay which it knows of.

10) SP1 then forwards the request to the super peerwith the closest peer ID to that of the ID stored inthe request which in this case is SP2.

11) SP2 receives the DHTget req and forwards it to thepeer within the cluster with the closest peer ID tothe ID stored in the request which is P1.

12) Peer P1 receives the request and sends the datastored under the specified ID directly back to P2

using its IP address.

C. Security Extensions

According to ROBUST different types of signallingmessages have to be exchanged amongst peers during thenetworks’ lifetime. Thus potential attackers could find away to exploit security vulnerabilities which appear dueto the transmission of these messages. To give a clearpicture of how harmful the existence of malicious peersagainst the ROBUST DHT can be we have derived themaximum length of an overlay (logical) route in hopsbetween a source and a destination peer. This is equal tologC+2 where C is the number of clusters in the overlaynetwork. Further, C = d N

log2 N e namely the maximumlength of an overlay route is

logN − log(logN) + 2 (13)

Assuming that the probability of a peer to be malicious ism the probability to have a secure route namely a routethat consists only of legitimate peers is equal to

Psecure route = (1−m)logN−log(logN)+2 (14)

From this we can derive that the impact of the attackeris severe even for a small fraction of malicious peers. Thussecurity provisions to maintain reliable communicationunder malicious activities must be provided.

To cope with external adversaries the ROBUST DHTneeds to be extended in a way that peers will exchangecryptographic material. In this context we describe in thefollowing how peers as well as super peers exchangecryptographic pairwise symmetric keys. These keys willthen be used to encrypt ROBUST signalling informationin a pairwise manner. This means that each pair of peers(including super peers) will use a specific symmetric keyto encrypt the signalling information.

We assume that in the beginning of the networkslife, a global 128-bit symmetric AES (Advanced En-crypted Standard) pre-shared key called a network widekey (Knwk) has been installed in all the devices of the

mobile peers. Similarly groups of users who wish toshare data securely can use such a pre-shared key muchlike common security encryption standards use today forexample Wired Equivalent Privacy (WEP) and 802.11ipre-shared key mode (PSK). The use of Knwk defendsa MANET against man-in-middle attacks during the ex-change of the peers’ pairwise symmetric keys. Anotherway of acquiring the Knwk it could consider a secureside channel (e.g. bluetooth) communication or physicalcontact in the beginning of the network’s lifetime. It isalso worth mentioning here that the use of symmetricrather than asymmetric cryptography is due to asymmetriccryptographic algorithms being in the order of 1000times slower than symmetric algorithms as well as theyintroduce higher energy cost [13].

On the other hand, the reason why we do not use theKnwk for the duration of the network’s lifetime is dueto the ample opportunities for cryptanalysers to retrievethe key material. By exchanging pairwise symmetric keysand refreshing at a certain interval we minimise the risk ofsuccessful cryptanalysis activities whilst we prevent com-promised peers to read information exchanged betweenother peers assuming that there is very limited probabili-ties a peer to be compromised before the exchange of thepairwise symmetric keys.

The security extensions for the ROBUST signallingmessages consist of three main phases as described inthe following;• key exchange phase: during this phase ROBUST

peers exchange their pairwise 128-bit AES symmet-ric keys Kpwk with their leafset peers and their superpeers by sending a DHTkey exch. To this end, peersuse the Knwk to encrypt the DHTkey exch as wellas the ROBUST packet header.

• key refresh phase: the task of this phase is forany given peer to generate new key material andexchange with their leafset peers and super peerby sending them a DHTkey refr every tkey refr

seconds. For the encryption and transmission ofthe new keys, peers use the previous establishedsymmetric keys Kpwk.

• proximity synchronisation phase: during this phasepeers move closer to a new super peer SP ′ and con-sequently should move to the new cluster by adopt-ing a new ID in the DHT space. In this case, peersmust use the Knwk to send their symmetric keysto their new leafset peers in addition to the newsuper peer. Therefore before they join the new clusterthey send a DHTpart packet to all of their previousleafset peers and super peer.

All phases consist of a 2-way handshake between twopeers as illustrated in Fig. 2 and 3. It is worth stressinghere the following;• Since the security extension algorithm is dis-

tributed, there is a possibility both peers that partic-ipate in a handshake send their Kpwk to each otherat almost exactly the same time consequently havingtwo different Kpwk at the end of the handshake. To

6



{Kpwk}Knwk

Application Layer

Transport Layer

Peer 1

{Ack}Knwk

Peer 2

Figure 2. The 2-way handshake between two peers which are ex-changing a pairwise symmetric key Kpwk during the key exchange orproximity synchronisation phase.

{Kpwk'}Kpwk

Application Layer

Transport Layer

Peer 1

{Ack}Kpwk

Peer 2

Figure 3. The 2-way handshake between two peers which are exchang-ing a pairwise symmetric key Kpwk during the key refresh phase.

avoid this issue, we have assumed that both peerskeep track of the exact time they send their Kpwk. Ifthey receive a K ′pwk from the target peer beforethey receive an acknowledgement for the Kpwk theypreviously sent, they will compare the send time ofthe received K ′pwk with the time they sent the Kpwk

to the target node if the send time of Kpwk < K ′pwk

they will discard the key K ′pwk and use Kpwk forencryption with the target peer following suit.

• The 2 steps in the handshake combined with a roundtrip timer are adequate to guarantee that the sender ofthe Kpwk will know that the other peer has receivedthe {Kpwk}Knwk

3, when it receives the acknowl-edgement in the second step of the handshake. If thesender of the Kpwk does not receive the aforesaidacknowledgement within the certain RTT (round triptime), it resends the key packet to the target peerassuming the original packet was dropped.

• The purpose of the key refresh is to harden theability of a compromised peer to reveal any pairwisekey material and information from any encryptedsignalling packets. This is based on the fact that acompromised peer would need to overhear the keyexchange of the first pairwise key which is encryptedwith the Knwk in addition to the subsequent keysthereafter making it extremely hard for an attackereven with the Knwk to decrypt refreshed Kpwk

messages.• To satisfy confidentiality for the different DHT sig-

nalling packets, as previously presented, we use oneof the Knwk, Kpwk depending on the type of theROBUST packet.

In Table I we summarise the different DHT signallingpackets as well as the required keys per packet typeregarding the different phases of the proposed security

3the notation {A}K means that A has been encrypted with thecryptographic key K.

extensions. Authentication and integrity are both satis-fied by ROBUST using HMAC (Hash-based MessageAuthentication Code). To this end, a hash function isapplied to the cipher-text of the message using the propersymmetric key, depending on the DHT signalling packettype. The receiver of the signalling checks the messagedigest to verify the authenticity of the sender and toidentify whether the message was altered compared to theone sent by the originator (due to intermediate MANETnodes routing the packet).

D. Assumptions and limitations of the Security Extensions

One of the limitations of our work, is the use of acommon symmetric key called network wide key (Knwk)shared amongst all the peers. Within this context, weassume that in the beginning of the networks life aKnwk has been installed in all the devices of the mo-bile peers. Another way of acquiring the Knwk couldbe established by peers initiating security associationamongst each other by means of secure side channel(e.g. bluetooth) communication or physical contact in thebeginning of the network’s lifetime.

A further assumption of the security extensions forROBUST signalling messages is that the beacon packetused to advertise super peers existence in order to estimateproximity to said super peer by a normal DHT peer mustalways be encrypted by the Knwk due to its broadcastnature.

Regarding the proximity synchronisation phase we haveassumed that peers joining a cluster communicate the newpairwise symmetric key for future transactions with theirnew super peer, as well as their new leafset peers. Thisis accomplished by using the Knwk, as the overheadrequired to use existing secure channels4 is deemed tooutweigh the risks.

III. PERFORMANCE EVALUATION

In this section, we use simulations to verify the integrityof the proposed model and showcase the benefits of usingour proposed solution. We next use an event based sim-ulator, customised with our implementation of ROBUSTprotocol, to validate the proposed model and optimisationsolution. The authors have developed a simulator modulefor the packet-level network simulator ns-2. The simulatorincorporates all DHT packets and functions needed fora fully implemented DHT and the implementation isbased on the ROBUST DHT clustered architecture withdynamic mobility considerations. In addition, the differentphases of the security extensions are implemented fullyin ns-2 and are utilised in order to route ROBUSTpackets. Further lower layers are also simulated in thens-2 simulator and these characteristics are taken intoaccount.

The setup of our network comprises of randomly dis-tributed peers throughout an area of 1km2. For smaller

4going through their previous super peer SP for which both thejoining peer and the SP ′ have established pairwise symmetric keys.

7



TABLE I.LIST OF REQUIRED SIGNALLING ROBUST PACKETS AND ASSOCIATED CRYPTOGRAPHIC KEYS

ROBUST packet before the key exchange phase after the key exchange phase proximity synchronisation phase

before or during the refresh phase

DHTget req Knwk Kpwk -

DHTput req Knwk Kpwk -

DHTping Knwk Kpwk -

DHTbeacon Knwk Knwk -

DHTjoin req Knwk Knwk -

DHTack Knwk Kpwk Kpwk

DHTsync vals Knwk Kpwk Kpwk

DHTstr keys Knwk Kpwk Kpwk

DHTpull ls Knwk Kpwk Kpwk

DHTpush ls Knwk Kpwk Kpwk

DHTmove req - - Kpwk

DHTmove rep - - Kpwk

DHTpart - - Kpwk

DHTbroad part - - Kpwk

DHTkey exch Knwk - Knwk

DHTkey refr Knwk Kpwk

networks such as ten peers, the peers are considerablycloser together in order to stay within transmission rangeof one another. Puts and Gets (Data transmission andretrieval) are called in the DHT at a rate of one requestper second. The number of peers simulated ranges fromten peers to seventy peers with increments of twentypeers. The authors specifically chose this amount of peersto represent smaller networks and also investigate thescalability of the aforementioned approaches. During teststhe authors found the threshold 90ms to be sufficient toallow peers to change cluster when SN RTT is less thanSN ′RTT +90ms. The threshold is needed so that peersdo not move cluster when even a small delay increaseis experienced. In addition to the threshold we have alsoimplemented the algorithm to always take the best RTTfor the current super peer SN and the worst RTT for thenew super peer SN ′ over three subsequent RTTs. Thisensures that we can guarantee the super peer SN ′ to havea better RTT than SN for a total duration of 3tbeacon. Allsimulations were run for a total of 1000 seconds simu-lation time. This was chosen in order for the DHT andnetwork to stabilise. In the simulation experimentationsregarding the ROBUST DHT we have assumed staticsuper peers. One of the limitations of our simulations arethe fact churn is not simulated per-se. This is due to thefact the authors have decided to only simulate mobilitychurn in this paper as adding churn would detract fromthe goal of investigating these results. We consider twomain different scenarios in our simulations; one withoutsecurity extensions (pure ROBUST) and one with securityadditions for signalling (secure ROBUST). The values forthe intervals of the different DHT functions are basedon those used in OpenDHT [10]. The list of simulation

parameters can be seen in table II.

TABLE II.SIMULATION PARAMETERS

Network size (number of peers) 10, 30, 50, 70Number of clusters needed (C) 4, 7, 9, 12

Percentage of mobile peers 0%, 25%, 50%Area size 1000m x 1000m

Data packet payload size 512 bytesMANET Routing protocol OLSR

MAC layer 802.11bLink bandwidth 11Mbit/s

Maximum transmission range 250mNode moving speed 1m/sec

Maximum number of overlay hops O(log2 C) + 2

Types of traffic UDP (All aforementionedDHT and security packets)

Maximum number of traffic connections ls+ C

Simulation time 1000 secDHT data distribution Random

DHT node ID distribution RandomNumber of DHT get requests (no gets) 1/sec

Data synchronisation interval (tsync) 3 secLeafset update interval (tls) 4 sec

Neighbour ping interval (tping) 5 secSuper peer change RTT threshold 90msCluster beacon interval (tbeacon) 10 secKey refresh interval (tkey refr) 300 sec

Proximity synchronisation interval 60 sec(tprox sync)

The process of packet initialisation to its definitive endis described below.

8



0.0325 0.0649 0.0974 0.12990.2

0.6

1

Cum

ulat

ive

Dis

trib

utio

n F

unct

ion

delay (sec)

10 peers/non−security10 peers/security30 peers/non−security30 peers/security50 peers/non−security50 peers/security70 peers/non−security70 peers/security

Figure 4. The cumulative distribution function of the DHTget req fromtransmission to completion of the request for the 8 scenarios where noneof the peers are mobile.

• packets are originated from the ROBUST protocolitself and then passed to the ROBUST sent agentwhich maintains connections and keeps track ofpackets RTTs using pings.

• subsequently when a RTT expires when a packet issent the packet is resent since it is assumed that ithas been dropped.

• the sent agent also keeps track of the packet sequencenumbers so then the packet sent down the stack tothe routing protocol (we have chosen OLSR [14](Optimised Link State Routing).

• the latter then computes the best route to send thepacket and forwards the packet over the intermediatepeers of the MANET until it reaches the destination.

• the destination node pushes the packet up the stackthus it is then received by the ROBUST agent whichsends an acknowledgement packet back to the sourcenode and computes any information/ data stored inthe packet.

The graph in Fig. 4 shows the cumulative distributionfunction of end-to-end DHTget req requests for 10-70peers in a state with and without security when thenetwork has no mobility (all peers are static). One cansee from this figure that when the network is ad-hoc asapposed to mobile ad-hoc the delay experienced whengetting data from the DHT is minimal as for 90% of allcases the end-to-end delay is less than 100ms. We cansee that in almost all cases the security and non-securityscenarios experience roughly the same delay (within a5ms variance) except for 70 peers where the variance isextended to less than 20ms. The higher experienced delayhere for 70 peers without security can be attributed to aslight variation of the distribution of peer and data IDs inthe DHT, i.e. the data IDs are distributed more evenly inthe non-security scenario creating more DHTsync packetsand higher redundancy, at the cost of slightly higher delay.

Fig. 5 demonstrates the cumulative distribution functionof end-to-end DHTget req requests for 10-70 peers in astate with and without security when the network has 25%mobility (25% of the peers are moving at 1m/sec). As onewould expect the delay in smaller networks (10-30 peers)

0 0.5 1 1.5 2 2.5 30.2

0.6

1

Cum

ulat

ive

Dis

trib

utio

n F

unct

ion

delay (sec)


Figure 5. The cumulative distribution function of the DHTget req fromtransmission to completion of the request for the 8 scenarios with 25%of the peers mobile.

is very small with 80% of the round trip times (RTT)being less than 70ms due to no congestion, interferenceand the fact that peers hardly move out of a 1 hoprange. When the network size is increased to 50 peerswhere 13 peers are moving, we see slightly higher delaydue to broken links causing packet retransmition and morepackets being sent over the network increasing congestion(primarily DHTprox sync packets when a node movescluster). We see this evidently more for 70 peers (18moving) where the delay increases greatly. The resultshere show a clear indication that adding the securitypackets increases delay due to the time the peer has towait to establish keys before transmitting data, howeverfor 30 and 50 peers this is less than 50ms, whereas for70 peers this is increased to less than 600ms. The greatdifference here is due to a much higher rate of peersmoving cluster causing higher delays due to packet lossand interference as confirmed in the paper [12]. Packetloss can cause very high delay times in get request RTTsuch as those experienced here due to the dropped packettimer implemented in ROBUST. Based on the OpenDHTimplementation [10] when a packet is sent and a roundtrip timer is started with an expiry time of the RTT ofthe last successfully transmitted packet to the specifictarget peer, if the timer expires the packet is retransmittedand the expiry time is doubled. Due to this the RTTcan increase exponentially when experiencing particularlyhigh packet loss.

The graph Fig. 6 presents the results of the cumulativedistribution function for end-to-end DHTget req requestsfor 10-70 peers in a state with and without security whenthe network has 50% mobility (50% of the peers aremoving at 1m/sec). In keeping with the results for 25%mobility we can see that the smaller network sizes (10-30) experience less than 210ms delay for 80% of the re-quests, while this is significantly higher than the previousresults, it is not unexpected due to the increasing volatilityof the network. In this scenario the network with 50 peershas a sharp increase in the end-to-end delay comparedwith Fig. 5 due to the aforementioned factors, mainlyresultant of peers moving more frequently. One can see

9



0 0.5 1 1.5 2 2.5 30.2

0.6

1

Cum

ulat

ive

Dis

trib

utio

n F

unct

ion

delay (sec)


Figure 6. The cumulative distribution function of the DHTget req fromtransmission to completion of the request for the 8 scenarios with 50%of the peers mobile.

0 250 500 750 10000

2

4

6

8

10

dela

y (s

ec)

simulation time (sec)

50 nodes/security/non−mobility50 nodes/security/25%−mobility50 nodes/security/50% mobility

Figure 7. The end-to-end DHTget req delay for 50 peers for thescenarios with 0%, 25% and 50% of the peers mobile with securityextensions enabled.

again the overhead of security only marginally affectingthe delay with a maximum different with 70 peers of300ms.

One can see a sample of end-to-end delay forDHTget req requests for 50 peers with security extensionsenabled in Fig. 7 following the trend of the previousgraphs we can clearly see that he delay for 50% of thepeers mobile is much more varied than the other twoscenarios as expected. It is interesting to note that duringthe stabilisation period of 200 seconds we do not see highdelay for any of the scenarios. However when the peersbecome mobile around 200 seconds the delay for a smallpercentage of the DHTget req requests increases rapidly.

Fig. 8 displays the number of peers whom changecluster due the DHTprox sync which compares the RTT ofa new super peer with that of their current super peer. Wecan see a general trend here which shows that the peerswithout security change cluster more times than the peerswith the security extensions enabled. If we compare thistrend to what we see in Figs. 4-6 where the end-to-enddelay for scenarios without security is lower, one can seethat the DHTprox sync actually reduces overall end-to-end delay due to greater proximity of the overlay peersto their physical network neighbours.

Fig. 9 represents the total number of packets received

10 30 50 70

10

50

90

130

num

ber

of c

lust

er c

hang

es

number of peers

non−mobility/non−securitynon−mobility/security25% mobility/non−security25% mobility/security50% mobility/non−security50% mobility/security

Figure 8. The number of peers whom change cluster due to theDHTprox sync function for the number of peers 10-70 for all the abovementioned scenarios.

10 30 50 70

0.5

0.9

1.3

1.7

2.1

2.5

2.9

3.3

3.7

x 105

Tot

al p

acke

t ove

rhea

d (p

acke

ts)

number of peers

non−mobility/non−securitynon−mobility/security25%−mobility/non−security25%−mobility/security50%−mobility/non−security50%−mobility/security

Figure 9. The total packet overhead for the 6 mobility and securityscenarios for each number of peers.

during the networks lifetime during each scenario for agiven number of peers. Here one can see that for eachscenario the security extensions add a noticeable numberof packets in the results, but still not enough to add anyreal difference in terms of congestion. It is interestingto note that for scenarios 10-50 peers the results arehardly distinguishable from each other, this shows thatthe threshold for DHTprox sync impacts more in the 70peer network than all of the others due to higher RTTdelay variance.

Confirming the notion in Fig. 9, in Fig. 10 one candetermine the actual real number of total security pack-ets received during the networks lifetime to be negli-gible, with the maximum number of security packetsreceived at 70 peers with 50% mobility as expected dueto DHTprox sync. One can say with clarity that adding3600 packets to a total over 3 × 105 would not produceany noticeable difference in network behaviour, on thecontrary any resulting impact from the security wouldhave to be delay wise, while waiting for a packet toarrive due to the congestion caused by the total numberof packets. This is more noticeable with the securityextension as one has to wait for this procedure to completebefore transmitting secure data. The results in fig. 10 donot include duplicate packets sent, which might result

10



10 30 50 70100

600

1100

1600

2100

2600

3100

3600

Sec

urity

ove

rhea

d (p

acke

ts)

number of peers

non−mobility25% mobility50% mobility

Figure 10. The packet overhead experienced due to security extensionsfor ROBUST for each of the different mobility levels and for all thenumber of peers.

10 30 50 70

200

500

800

1100

1400

1700

2000

2300

Cum

ulat

ive

tota

l pac

ket l

oss

(pac

kets

)

number of peers

non−mobility/non−securitynon−mobility/security25%−mobility/non−security25%−mobility/security50%−mobility/non−security50%−mobility/security

Figure 11. The cumulative packet loss experienced for each of the 6mobility scenarios.

in more overall packets being sent from the securityfunction.

The results in Fig. 11 provide insight into the cu-mulative packet loss experienced during the networkslifetime for any given number of peers simulated foreach mobility scenario with and without security. One cangather that while there is packet loss, it is not experiencedon a large scale. While the general trend shows that thesecurity scenarios have a slightly higher packet loss, whencompared with the total number of packets received thisamounts to less than 1 percent. The reason for such a lowpacket loss can be explained by using the results fromthe paper [11] as a guide. Due to frequent route changemultiple copies of a single packet can be received, thiscauses a lot of duplicate packets in the network and aphenomenon we experienced with a high impact whensimulating 70 peers with high mobility due to congestion.

IV. CONCLUSION

In this paper the authors have proposed using anew DHT architecture entitled ROBUST in order toshare and disseminate data and information through-out MANETs based on the P2P paradigm which bothnetworks share. The authors have extended this notionto encompass security extensions in order for all DHTtransactions to be private between only those participating

in the overlay and appear encrypted to any intermediateMANET nodes. To this end the authors have simulatedthe proposed architecture and extensions in the packet-level simulator ns-2. The results show that while there is aslight difference in performance when applying aforemen-tioned security extensions to the DHT, the impact of theseextensions is negligible for the overwhelming majorityof cases. It can be seen however that when increasingthe number of peers so much as 70, higher delays canoccur when many peers are moving. The authors attributethis to a number of different phenomenon which occurwhen mobility is introduced such as the transport issueshighlighted in [11] where a high variance in RTT occurswhen routes change often, leading to underestimation ofRTT for many packets causing unnecessary duplicates tobe sent, further congesting the network and increasingdelay.

The resulting contributions from this paper are impor-tant for the future design and implementation of P2Pprotocols for MANETs, especially in the cases where datasecurity and confidentiality is of high importance. Futurework in the area of P2P for MANETs must address thescalability issues experienced when a high number ofpeers are mobile. While ROBUST goes some way toaddressing this problem with proximity synchronisation, itis clear that a lot of the encountered discrepancies stemfrom an inefficient transport protocol which should beaddressed. The authors main focus of future work will bewithin the area studying how mobility affects DHTs andsolutions to the problems that entails, as well as improvingthe simulator by adding new transport protocols, addingsuper peer election, enhancing proximity synchronisationand investigating the effects of churn.

One can clearly see the advantages of having secureP2P overlays in MANETs, adding much functionality toan otherwise desolate landscape in terms of services andinformation sharing while maintaining secure communi-cation between trusted peers. The advancement of solu-tions to the problems posed in the previously mentionedscenarios and the continued research into future serviceswill ensure that MANETs do have functionality whichgoes beyond that of simply acting as gateways to moreservice rich architectures such as the Internet.

ACKNOWLEDGMENT

This work was undertaken in the context of theproject ICT SEC-2007 PEACE (IP-based EmergencyApplications and serviCes for nExt generation networks)with contract number 225654. The project has receivedresearch funding from the European 7th FrameworkProgramme.

REFERENCES

[1] A. Banerjee and C.-T. King, “Building ring-like overlayson wireless ad hoc and sensor networks,” IEEE Trans.Parall. and Distr. Syst., vol. 20, no. 11, pp. 1553 –1566,nov. 2009.

11



[2] M. Bisignano, G. Di Modica, O. Tomarchio, and L. Vita,“P2p over manet: a comparison of cross-layer approaches,”Proc. of Database and Expert Systems Applications(DEXA), pp. 814 –818, sep. 2007.

[3] H. Pucha, S. M. Das, and Y. C. Hu, “Ekta: An efficientdht substrate for distributed applications in mobile ad hocnetworks,” Proc. IEEE WMCSA, pp. 163–173, 2004.

[4] R. Schollmeier, I. Gruber, and F. Niethammer, “Proto-col for peer-to-peer networking in mobile environments,”Computer Communications and Networks, 2003. ICCCN2003. Proceedings. The 12th International Conference on,pp. 121 – 127, oct. 2003.

[5] M. Conti, E. Gregori, and G. Turi, “A cross-layer opti-mization of gnutella for mobile ad hoc networks,” Proc.ACM MOBIHOC, pp. 343–354, 2005.

[6] B. Tang, Z. Zhou, A. Kashyap, and T. Chiueh, “An inte-grated approach for p2p file sharing on multi-hop wirelessnetworks,” Proc. of IEEE WIMOB, vol. 3, pp. 268–274,2005.

[7] T. Zahn and J. Schiller, “Madpastry: A dht substrate forpracticably sized manets,” Proc. of ASWN ( Applicationsand Services in Wireless Networks) Conference, June 2005.

[8] D. Chopra, H. Schulzrinne, E. Marocco, and E. Ivov,“Peer-to-peer overlays for real-time communication: secu-rity issues and solutions,” IEEE Communications Surveys& Tutorials, vol. 11, no. 1, pp. 4–12, First Quarter 2009.

[9] G. Millar, E. Panaousis, and C. Politis, “Robust: Reliableoverlay based utilisation of services and topology foremergency manets,” in Proc. IEEE Future Network andMobileSummit, Florence, Italy, Jun. 2010.

[10] S. Rhea, D. Geels, T. Roscoe, and J. Kubiatowicz, “Han-dling churn in a dht,” in Proc. USENIX, ser. ATEC ’04.Berkeley, CA, USA: USENIX Association, 2004.

[11] D. Kim, H. Bae, and C. K. Toh, “Improving tcp-vegasperformance over manet routing protocols,” IEEE Trans.on Veh. Techn., vol. 56, no. 1, pp. 372 –377, jan. 2007.

[12] L. Barolli, M. Ikeda, F. Xhafa, and A. Duresi, “A testbedfor manets: Implementation, experiences and learnedlessons,” Systems Journal, IEEE, vol. 4, no. 2, pp. 243–252, June 2010.

[13] F. Anjum and P. Mouchtaris, Security for wireless Ad hocnetworks. Wiley, 2007.

[14] T. Clausen and P. Jacquet, “Rfc 3626: Optimizedlink state routing protocol (olsr).” [Online]. Available:http://tools.ietf.org/html/rfc3626

Grant P. Millar is currently a Ph.D student at the Faculty ofScience Engineering & Computing (SEC), School of Comput-ing & Information Systems (CIS), Kingston University, Lon-don, UK. He works in Wireless Multimedia & Networking(WMN) Research Group as well as giving the occasional lectureon various subjects of the networking realm within the CISMfaculty.

Grant received his M.Sc in Networking and Data Commu-nications at Kingston University and his B.Sc in ComputerAnimation at the University of Portsmouth, UK. Grant is astudent member of the IEEE and the IEEE CommunicationsSociety.

Emmanouil A. Panaousis is currently a research Ph.D. stu-dent at the Faculty of Science Engineering & Comput-ing (SEC), School of Computing & Information Systems(CIS), Kingston University, London, UK. He works in theWireless Multimedia and Networking (WMN) Research Groupas well as giving the occasional lecture on various subjectswithin the TCP/IP and wireless networking field.

Emmanouil was born in Athens, Greece and he receivedhis M.Sc., with distinction, in Computer Science at the De-partment of Informatics of the Athens University of Eco-nomics and Business and his B.Sc. in Informatics and Telecom-munications at the National and Kapodistrian University ofAthens. He has published more than 20 papers in internationaljournals, conferences and standardisation bodies. He is also apatent holder. Emmanouil’s previous work experience includeslaboratory assistant in Athens University of Economics andBusiness, assistant in Foundation for Research and Technology- Hellas (FORTH) and Institute of Applied and ComputationalMathematics (IACM). Emmanouil is a student member of theIEEE, the IEEE Communications Society and the IISP (Instituteof Information Security Professionals).

Christos Politis is a Reader (Assoc. Prof.) of Wireless Com-munications at Kingston University London, UK, Faculty ofScience Engineering & Computing (SEC), School of Computing& Information Systems (CIS). There he leads a research teamon Wireless Multimedia & Networking (WMN) and teachesmodules related to communications. Christos is the Field Leaderfor the ’Wireless Communications’ and ’Networks and DataCommunications’ postgraduate courses at Kingston.

Prior to this post, he was the Research and Development(R&D) project manager at Ofcom, the UK Regulator andCompetition Authority. There he managed a number of projectsacross a wide range of technical areas including cognitiveradio, polite protocols, radar, LE Applications, fixed wirelessand mobile technologies. Christos’ previous positions includetelecommunications engineer with Intracom Telecom in Athensand for many years he was a post-doc research fellow in theCentre for Communication Systems Research (CCSR) at theUniversity of Surrey, UK. He is being active with Europeanresearch since 2000 and has participated in several EU, nationaland international projects. Christos was the initiator and theproject manager of the IST UNITE project. He is a patentholder, and has published more than 100 papers in internationaljournals and conferences and chapters in two books. Christoswas born in Athens, Greece and holds a PhD and MSc fromthe University of Surrey, UK and a B.Eng. from the TechnicalUniversity of Athens, Greece. He is a senior member of theIEEE and member of the Technical Chamber of Greece.

12



distributed hash tables for peer-to-peer mobile ad-hoc ... · pdf filedistributed hash tables...

Documents