Cross-Layer Mobile ChordP2P Protocol Design ForVANET

Che-Liang LiuDepartment of Electrical EngineeringNational Taiwan University

Chih-Yu WangDepartment of Electrical EngineeringNational Taiwan University

Hung-Yu Wei*Department of Electrical EngineeringNational Taiwan UniversityE-mail:hywei@cc.ee.ntu.edu.twCorresponding Author

Abstract: Efficient content distribution is one of the emerging applications in vehic-ular networks. To provide scalable content distribution in vehicular networks, Chordpeer-to-peer overlay could be applied. Most P2P protocols, including Chord, are de-signed for wired-line network, and might perform poorly in mobile networks. MobileChord (MChord) is proposed to enhance the P2P performance over vehicular ad hocnetwork (VANET). In addition, cross-layer design to improve MChord performance inVANET is also investigated. Extensive NS-2 simulations with vehicular mobility tracesare conducted to evaluate the P2P overlay performance in VANET. Mobile Chord andits cross-layer design outperforms the original Chord in various aspects, including ap-plication layer forwarding steps, query response ratio, correct query response ratio, andapplication delay.

1 Introduction

Vehicular networking technology has become one of themost promising communication infrastructures in manycountries. Various safety applications and entertainmentapplications will be supported over vehicular networks.Content delivery will be one of the key applications in ve-hicular wireless networks. Application layer peer-to-peeroverlay has a great potential to realize the efficient con-tent delivery over vehicular networks (Lee et al., 2007).For example, pushing location-dependent advertisementsto drivers through peer-to-peer overlay makes sense interms of technology scalability and business model (Nan-dan et al., 2006).

Vehicular ad hoc network (VANET) is one of the promis-ing architectures of vehicular networks. VANET sharessome common properties with MANET (mobile ad hocnetwork). However, there are some distinctive differencesbetween VANET and MANET: 1) vehicles move at veryhigh speed but stop at intersections when traffic lightsturn red, 2) since the route is restricted by the roads, themobility is more predictable compared with the random

movement of nodes in MANET. Furthermore, for publictransportation, like buses, which always follows predefinedroutes and time schedule, could be predicted more accu-rately than general vehicles, 3) vehicles usually have unlim-ited power supply by its equipped generator while nodesin MANET are usually battery-powered.

Peer-to-Peer (P2P) technology offers an alternative com-munication architecture from traditional client-server ar-chitecture. Nowadays, the most popular usages of P2Ptechnology are file-sharing and content delivery amongusers. In a P2P file-sharing network, users can publishand share their own possessions with others which are cur-rently online. P2P users can also download interesting filesfrom others. Unstructured or less-structure P2P protocols,as their names suggested, have no or a few restrictions onthe structure of the overlay. Hence, it is difficult for usersto locate the resources they need in an unstructured P2Pnetwork. In such case, flooding search seems to be the onlymethod to locate an object. However, this approach usu-ally results in so-called broadcast storm problem, whichleads to significant performance degradation in VANET.On the other hand, structured P2P protocols, such as

1

Chord(Stoica et al., 2001), Pastry(Rowstron and Druschel,2001), Tapestry(Ben et al., 2001) and CAN(Sylvia et al.,2001), are designed for locating objects effectively in wirednetworks. These structured protocols form a fully orga-nized overlay with the proposed protocols. Logarithmiccomplexity is achievable for key operations such as join-ing, maintaining, or querying in the P2P overlay. Due tothe attractive low overhead, researchers paid lots of atten-tion on Chord. Researchers strived to enhance the overlayperformance and to apply it to large scale deployment.Nevertheless, conventional P2P protocols usually assumereliable links among nodes. This is true in wired networkbut difficult to achieve in VANET due to the mobility, nodefailures, and packet corruption under error-prone wirelesscommunication environment. Therefore, these protocolsmight perform poorly in VANET.

Chord(Stoica et al., 2001) is one of the most popularstructured P2P protocols. Chord operates elegantly be-cause of the simplicity of the design and the scalability toconstruct large-scale overlay network with low complexity.In an N-node Chord overlay, each node only have to keepcontact just O(logN) nodes. A query can be done withinO(logN) steps. Furthermore, nodes only need to main-tain few local information (successor and predecessor) inorder to guarantee the consistency of Chord. However, inVANET, the long forwarding routes of the query packetforwarding path might differ from the underlying ad hocroutes. Moreover, the slow convergence occurs when manynodes join the overlay concurrently.

This paper is organized as follows. Section 2 describesthe related work. We elaborate our protocol design in Sec-tion 3. In Section 4, we introduce a cross-layer design toenhance proposed MChord. Results of intensive simula-tions under diverged scenarios are provided in Section 5.Finally, Section 6 concludes our work.

2 Related Work

2.1 Chord and Application-Layer DHT

Chord is an example of DHT-based P2P protocol. Fig. 1shows an illustrative example of a Chord overlay networkover VANET. Chord inherits many attractive features fromDHT abstraction such as fault-tolerant, scalable, fully dis-tributed, and self-organized. Every node and every objectis hashed into a predefined m-bits key space using a globaldigest function such as SHA-1, MD4, or MD5. The mes-sage digest of the digest function is treated as a globallyunique key of an entity (node or object). The key spaceand digest function must be selected carefully to make surethat with very high probability there does not exist two en-tities using the same identification. As Fig. 1 illustrates,each node is put on the ring wrapped at the possible max-imum and minimum of key space. Each node X maintainsits 1) successor, which is the node with the smallest keyamong keys larger than X’s, 2) predecessor, which is thenode with the largest key among keys smaller than X’s, 3)

a list of nodes, called fingers, to ensure each operation canbe done within O(logN) steps. Each node is responsiblefor the ring segment [Key of X, Key of X’s successor). Inthat way, the work load can be averaged since the keys oc-cupied by nodes should be randomly distributed in the keyspace. Each node must maintain fresh information aboutits successor and predecessor. The simple approach to doso is direct message exchange realized with ping messages.A consistent state of the P2P overlay at any given instantis that every node currently deems correct nodes as itssuccessor and predecessor. The correctness of operationscould be guaranteed by reaching consistent state becauseeach operation with a specific key could be directed to theright node which is in charge of the key currently. Eachnode maintains a finger table which size is equal to thenumber of bits of the key space, m. The ith entry of afinger table records the first node of which key is largerthan Key+2i−1, where i = (1, 2, 3 . . . m). The logarithmiccomplexity is accomplished with finger table mechanism.Notice that neighbor nodes in the overlay are not necessaryclose in physical position.

2.2 P2P Protocol Enhancement

Researches show that P2P protocols in wireless networksmight not perform as well as they do in wired networks(Cramer and Fuhrmann, 2006)(Oliveira et al., 2005). Aprotocol using epidemic flooding to locate objects outper-forms Chord in terms of query response rate, which isone of the key performance metrics. They concluded thatmaintaining the overlay becomes impractical due to theuncertainty of node mobility and other characteristics ofMANET.

MeshChord(Burresi et al., 2008) uses location-dependent address to reduce traffic for maintainingthe overlay. With the help of location information, somemaintaining messages can be limited in local area. How-ever, each node must acquire the current identificationof the destination node before actual application layercommunication taking place. That waiting time untilresolving current location-dependent address of somenode may cause performance devaluation. Cramer etal. (Cramer and Fuhrmann, 2006) and Montresor etal. (Montresor et al., 2005) address the slow convergingproblem caused by the simple join procedure of Chordwhen many nodes join the overlay concurrently. Theyevaluate the problem and provide some enhancement inwired network. However, their proposed enhancementmight not be practical in MANET and VANET. Inaddition, other enhanced mechanisms are applied toDHT to improve performance in MANET. Ahmed et al.(Ahmed and Shirmohammadi, 2007) deploys multi-levelhashing technique to reduce routing overhead. Thomaset al. (Zahn et al., 2006) extends the DHT substrate tosupport range query in MANET.

.

2

2.3 Cross-layer design for P2P overlay

Ding and Bhargava (Ding and Bharat, 2004) investigatedthe design options under P2P over MANET scenarios.Overall system performance depends on both applica-tion layer overlay path selection and network layer rout-ing. Five network architectures: broadcast over broadcast,cross-layer broadcast, DHT over broadcast, broadcast overDHT, DHT over DHT, and cross-layer DHT are comparedand investigated.

CrossROAD(Delmastro, 2005), Ekta(Pucha et al., 2004)and its successor Ekta+(Pucha et al., 2006) use cross-layerdesign to boost performance of Pastry. Ekta applied cross-layer design between network layer routing and applicationP2P. A modified Pastry P2P protocol is closely integratedwith DSR routing. Routing hop count is used for eval-uating node proximity in P2P overlay. Ekta+ improvesEkta performance by introducing DHT message aggrega-tion at both network layer MANET and application layeroverlay. By aggregating small DHT messages and exploit-ing reusable routes, Ekta+ could reduce overhead and en-hance protocol efficiency. CrossROAD uses a cross-layerapproach to integrate Pastry P2P protocol and proactiverouting protocol, such as OLSR. P2P common API is cre-ated to support cross-layer design in CrossROAD. Networklayer information, such as routing table and information ofneighbor nodes, could be obtained through the API. Over-head is reduced with the cross-layer design.

DHT might be applied at network layer to establish mul-tihop relay routes. Virtual Ring Routing (VRR)(Caesaret al., 2006) is a routing protocol which uses ring struc-ture to route packets. VRR integrates DHT substrate intothe routing protocol itself, so locating an object can beachieved by key-based routing in such networks. However,additional care must be paid to realize such service. VRRuses a global naming function so that the identificationof a given node is unique and independent from currentgeographical location. A packet travels around in the net-work until it reaches a node which maintains the routeto that key. MA-Chord(Qi and Hong, 2007) is a unicastrouting protocol using a DHT substrate. MA-Chord usescluster-based address. Cluster heads dedicate in managingthe network to reduce overhead. While a process calledaddress resolution must finish before actual data trans-mission, a force delay is occurred when the cluster-basedaddress is not cached

3 Mobile Chord Protocol Design

We design mechanisms to reduce protocol overhead and al-leviate problems caused by node mobility and the frequenttopological change.

1. Aggressive table update: try to use any available in-formation to update finger table (for Chord) and over-lay table (for MChord).

2. Overlay table broadcasting: broadcast P2P overlay

information to neighboring MChord nodes instead ofusing unicast ping for keep-alive mechanism in Chord

3. Greedy forwarding: select the closest node in the over-lay table rather than the best finger in the Chord fin-ger table.

4. Passive bootstrapping: a new node learns the P2Poverlay network information by listening to overlaytable broadcasting rather than joining P2P overlaythrough hook nodes.

3.1 Aggressive Table Update

When a Chord node maintains the consistency of theP2P overlay, this node is expected to update the desiredrandom-chosen finger only, as shown in the pseudo-codesin (Stoica et al., 2001). Due to the sparsity of keys occu-pied by P2P overlay participants, this behavior is not ade-quate. For a Chord node, fingers, especially the ones withlower indexes, may share the same node as their target.If we only update a finger once and remain the others in-tact, the other fingers which have the same target addresswill become obsolete when the target address of the up-dated finger changes. So we relaxed that update criterion.Whenever a fresh update shows up, Chord will update allpossible fingers, successor and predecessor. Furthermore,whenever a packet is delivered to Chord, it will extract anyapplicable information and update fingers, successor andpredecessor, if it is feasible. Since we believe this updatemechanism is essential, we include this feature into boththe baseline Chord and MChord.

3.2 Overlay Table Broadcasting

Each node maintains the Chord overlay in a distributedmanner. A node periodically check whether other nodesare still online or not. This might be implemented bysending ping messages through unicast. Ping messages aresmall packets, which consume little resource in wired net-work. Nevertheless, in VANET, frequent sending smallpackets will severely degrade network performance. InVANET, sending a small unicast ping message might con-sume a large amount of radio resource because of the adhoc routing protocol.

Assume a reactive routing protocol, such as AODV, isused. If we perform the application-layer ping as keep-alivemechanism before network-layer route expiration, a shortinterval between two consecutive ping events is needed.This frequent ping events lead to high traffic load. If weapply a long time interval between two consecutive pingevents, the network-layer routes may be expired or nolonger valid. Network-layer routing agents has to repairthe routes with AODV route discovery process, which leadsto heavy traffic load as well. In addition, infrequent keep-alive update will result in staled information and damagethe consistency of the P2P overlay. As a result, the conven-tional ping-based keep-alive mechanism is not suitable forChord over VANET scenario. Heavy signaling overhead is

3

created by routing agents when a ping task is conductedin VANET.

Unlike P2P operation in wired-line network, packets lossis not a good indicator to P2P node failure in VANET. InVANET, packet loss might due to various causes includ-ing 1) route is under a reparation, 2) a temporal networkpartition occurs due to node mobility, 3) the packet is notreceived due to high packet error rate in wireless network.As packet dropping may due to various reasons, apply-ing unsuccessful ping event as explicit indicator for Chordnode failure is inappropriate. So we devised the overlay ta-ble broadcasting mechanism which exploits the nature ofwireless communication to address the problem. In wire-less communication, any node around the source can over-hear the packet. Overlay table broadcasting is very simplein concept. Every node maintains its own overlay tableabout other nodes which are currently in the P2P over-lay. Each node broadcasts a list to its one-hop neighborsperiodically. The list is a subset of its own overlay table.Whenever a node hears the broadcasted list, it will updateits overlay table. If an entry in the overlay table has notbeen updated after a predefined time period, the entry isinvalid and is purged from the table. The entry of the tablecan be implemented with a few fields, such as <networkaddress, the last update time>, or <network address, thelatest sequence number>.

Overlay table broadcasting uses localized one-hop com-munication instead of multihop unicast ping to save wire-less network resource. Overlay table broadcasting can beregarded as an aggregation of ping messages. Overlay ta-ble broadcasting mechanism has the following advantages:1) overlay table broadcasting is transmitted with one-hopwireless broadcasting and avoids multihop routing over-head 2) overlay table broadcasting message contains moreinformation than the conventional ping packet.

3.3 Greedy forwarding

A Chord node selects next hop from its acquaintance aboutthe network, that is, finger table. With the help of overlaytable broadcasting, MChord application does not need tomaintain finger table anymore. The overlay table is suffi-cient to maintain the P2P overlay and to forward an ap-plication packet. The forwarding criterion is simple. Eachnode forwards packets to the node of which identification isthe closest to the desired destination nodes. By forward-ing packet this way, the traffic load of forwarding querymessages can be significantly reduced.

3.4 Passive bootstrapping

The performance of nodes joining a P2P network affectsthe consistency and efficiency of a P2P protocol. When anode wants to join the P2P overlay, it will try to connectto a predefined node called hook node. A list of candi-date hook nodes is usually needed in conventional P2Pjoining procedures. However, having a list of predefinedhook nodes is impractical in VANET scenarios. In addi-

tion, the traffic congestion around hook nodes occurs whenmultiple nodes try to join the P2P overlay simultaneously.Although the congestion is a temporary phenomenon, theunbalanced traffic load around the hook nodes is not desir-able. We propose the passive bootstrapping mechanism toresolve this issue. When a node wants to join the overlay,it just starts up the P2P application. Then the new nodesets a timer with a random timeout and sends an overlaytable broadcasting to its 1-hop neighbors after the timerexpires. The following overlay table broadcasting messageis sent as usual. With the overlay table broadcasting tech-nique, each node will get acquaintance with other nodesgradually. No predefined hook nodes are required. Over-loaded traffic around the hook nodes is avoided.

4 Cross-layer enhancement for Mobile Chord

4.1 Cross-layer Knowledge Harvesting

Wireless packet transmission is broadcasting in nature.Even if a wireless packet is intended to be transmittedto a specific destination, the other nodes in the vicinitymay overhear that packet, too. Why not share a packetif it carries some information of common interest? By ex-ploiting the broadcasting nature of wireless medium, wecould facilitate the overlay information dissemination effi-ciently. Overlay table broadcasting is an exemplary designinspired by this philosophy. Overlay table is transmittedwith one-hop broadcasting, which distributes the informa-tion to neighboring nodes without significant overhead ofmultihop routing nor broadcast storms. In our design, in-dividual overlay table broadcasting is always one-hop, nonodes will rebroadcast anything to prevent the broadcaststorm problem.

To reach the efficient P2P over VANET design goal, across-layer design that exploits the broadcast nature ofwireless medium and harvests the available information isillustrated in Fig. 3. MAC layer will forward all P2P rele-vant information to the application layer Mobile Chord.After a successful reception of a Mobile Chord packet,modified MAC will send the packet to Mobile Chord appli-cation whether the destination matches the identificationof the node or not. After receiving the packets from MAC,Mobile Chord will extract whatever is useful to update itsoverlay table. For example, if a node overhears the queryfrom another node, it will get new information about theinitiator of that query. This valuable information mightbe useful for future P2P operation involving these nodes.Extracting information from packet destined to itself is theonly way the conventional Chord update its information.With the cross-layer design, overheard MChord packetsfrom neighboring node could be used for information up-date. Additionally, multihop relay is used in VANET. Anintermediate relay node could extract information from theen route Chord packets.

4

4.2 Knowledge Piggyback In Overlay Signaling

Although overlay table broadcasting helps to propagateP2P information over the network, the speed of propaga-tion may be slow. Through overlay table broadcasting,new information from some nodes reaches other distantnodes hop-by-hop through one-hop broadcasting. Whennew information finally arrives at a distant node, it maybe out-dated and may be pruned off quickly. For example,assume the interval of overlay table broadcasting is 10s andthe period that a table entry remains valid in is 20s, theinformation propagation distance is around four hops onaverage and is only two hops in the worst case. For somelarge networks, overlay table broadcasting may takes toomuch time to propagate fresh information.

We propose the knowledge piggyback in overlay signal-ing mechanism. Piggyback overlay table on overlay sig-naling is simple to implement. Some P2P overlay pack-ets, such as Chord maintenance signaling packets or querypackets, may travel through a long physical distance. Wepiggyback the overlay table into these packets. When apiggybacked packet is received, the receiver not only pro-cesses information in the packet but also extracts the pig-gybacked overlay table and then updates its table. Afterthe receiver updates its table with fresh information, itwill rebroadcast these new data in subsequent overlay ta-ble broadcasting. As a result, the vicinal nodes around thereceiver will get the fresh information, too. Although thistechnique increases the size of overlay signaling messages,the fresh overlay information could be propagated furtherand faster. From the normalized disseminated overlayinformation per unit overhead perspective, the proposedscheme is more efficient.

If we integrate cross-layer design and piggyback overlaytable in the existing MChord signaling messages, the bene-fit will be significant. First, if a packet is supposed to travelacross the network such as query packets, carrying some-thing beneficial in that packet may not cause too muchoverhead compared to creating new packets, as neither ad-ditional ad hoc route discovery nor MAC layer contentionis needed. Second, when a packet transmits hop-by-hopfrom the origin to the destination, the nodes around theroute may overhear that useful information encapsulatedin the packet by cross-layer approach. Third, the integra-tion of the overlay table piggybacking with the cross-layerknowledge harvesting mechanism provides an efficient wayof overlay information dissemination which might requirefrequent overlay table broadcasting that causes heavy over-head. Actually, the overlay table piggybacking dissemi-nates information to a much wider range. In MChord,maintenance signaing messages are sent periodically tokeep the overlay table up-to-date and to detect node fail-ure. In our implementation, we piggyback the overlay tablein the Chord maintenance signaling messages. Other P2Psignaling message, such as query messages, could also pig-gyback with the overhead table. With cross-layer knowl-edge harvesting, all en route nodes and their neighbors willget fresh P2P overlay information.

5 Performance evaluation

We evaluate our design through intensive simulations un-der various environments. We use Network Simulator ver-sion 2.32(McCanne and Floyd, 2006) to do detailed packetlevel simulations. Each mobile node uses built-in 802.11MAC module and Wireless PHY without any adjustmentof default parameters. The radio transmission range isup to 250m. We use AODV as routing protocol with de-fault parameters. We implemented the Chord followingthe guideline with a little modification (see aggressive tableupdate). Mobile Chord is implemented with all advancedfeatures. The important parameters of Chord are shownin Table 1. Some parameters are determined by a uni-form random distribution; hence, the number of concurrentupdates and signaling events decreases. Unless otherwisespecified, a hook node is employed and each node joins theoverlay one by one in every second. Each node runs aninstance of Chord application on top of a UDP agent.

The vehicular network traffic scenario is created withthe NS-2 Random Trip Mobility Model Tool (PalChaud-huri et al., 2005). We captured four street maps with dif-ferent characteristics from U.S. TIGER (Levergood, 1998)database. Fig. 4 illustrates the street layouts of the threelocations. The first map is from the Rice University inHouston. The size of Houston street map is 1200m x1200m, and the speed setting of vehicles is between 10m/s and 20 m/s. A vehicle goes from one crossroad toanother, and decides the next crossroad to go with zerowaiting time. We believe this traffic scenario can give usa general evaluation on the performance enhancement ofMChord. To evaluate the effect of map size on Chordand MChord, we captured the maps sized 1600m x 1600mand 2400m x 2400m from New York City. Several speedsettings on traffic scenarios are also selected to evaluatethe effect of vehicular speed. We choose three ranges ofspeed: 5 m/s to 15 m/s, 10 m/s to 20 m/s, and 15 m/s to25 m/s to generate the vehicular traffic scenarios. In thelast map, we choose a 1600m x 1600m area in Idaho Stateto simulate a vehicular network in country area. We alsogenerate three traffic scenarios with three speed settings,which are 10 m/s to 20 m/s, 15 m/s to 25 m/s, and 20 m/sto 30 m/s. Actual queries starts at 1150 seconds. Afterthe bootstrapping phase, a P2P query with a random keyby a random node is sent every second for the P2P pro-tocol convergence. Totally 3800 queries are sent in eachtrial. Finally, at the end of each simulation run, an addi-tional 50 seconds is used to complete the last few queryevents. Every query has a second-chance if no answer isreturned in the first time. Each scenario is simulated 10times with different random seeds that produce differentmobility traces and queries.

5.1 Mobility Model Characteristics

We first briefly analyze the characteristics of the geographi-cal map and network mobility model. We analyzed the net-work scenarios under the assumption that nodes can con-

5

nect to other nodes within the default NS-2 802.11 trans-mission range 250m. We measured the average duration ofeach individual connection between two nodes in the sim-ulated network schemes. The results are shown in Fig. 8.We observed that the major factor in the duration of con-nection is the speed of vehicles. When the speed is lower,the connection duration will be longer. Another factor isthe street layout. With the same average speed setting,the connection duration in New York is much shorter thanin Idaho. This is because there are limited number of roadsand intersections in Idaho. When two vehicles are withincommunication range, it is highly possible they are still onthe same road for a while. In contrast, in New York City,the one of the two vehicles might turn into a different roadat one of the many intersections. So the connections cannot last for a long time.

We also analyze the degree of connectivity in theseschemes. The degree of connectivity is defined by the num-ber of connections a node can establish within one hop atany time instant. The results are shown in Fig. 9. Ob-viously, the degree of connectivity depends mostly on thenode density in the vehicular network. When the nodedensity increases, the degree of connectivity increases lin-early. From observations, the speed setting has little effecton this, so we only show one speed setting scheme in eachmap. A small network in 1200m x 1200m Houston haslarger degree of connectivity than 2400m x 2400m NewYork network. We have another interesting observationthat the degree of connectivity is larger in Idaho than inNew York. We believe this is because the map layout inIdaho is simpler, so vehicles are more likely on the sameroad. In New York vehicles usually are on different roads.

Another important factor in a vehicular network is thedegree of partitioning. Ideally, we would prefer one un-partitioned network. In reality, a vehicular network maybe partitioned into small groups due to physical or rout-ing limitations. Nodes in different groups cannot connectto each other. We observed that the average number ofgroups is still almost unaffected by the speed settings. Asshown in Fig. 10, the main factor is the street layout.Networks in Idaho has much smaller average number ofgroups than the case in New York. As we expected, theHouston map has the lowest number of groups because ofthe smallest map size and the high degree of connectivity.The network in 2400m x 2400m New York has the largestnumber of groups. It is worthy to mention that nodes dis-tributes unevenly among groups. In most case, one groupis dominant and other groups only consist of a few nodes.

We evaluate the performance of Chord and MChord withthe following metrics.

1. Application layer forwarding steps: the number ofhops that a query message is processed by applica-tion layer. The minimum value of application layerforwarding steps of a responded query is two. Onecontributed from the response node. Another is fromthe query initiator. If a node commits it as the nodewho should answer its query, the query is responded

immediately. We called such queries as immediatequeries. Immediate queries are excluding from cal-culation. Also, if queries fail at the first time and beresponded at the second time, the application stepscause by first time are excluding from calculation.

2. Query response ratio: the ratio of queries is re-sponded. Noted, even a query is responded, the an-swer may be wrong since the inconsistency of the over-lay.

3. Correct query response ratio: the ratio of queries iscorrect corresponding to the current overlay. For ex-ample, node A with ID 12345678, node B with ID23456789, and node C with ID 34567890 are currentlyin the overlay. Node A loses contact from B due toconsecutive ping message loses, temporal network par-tition, etc. As a result, A will think he is responsi-ble for the keys ranging from 12345678 to 34567890;however, there is a node B with key 23456789. If aquery with key 13456789 and A response, the queryis though to be correct since A should cover the key.While if a query with key 24567890 and A response,the query is considered to be wrong since that is B’sresponsibility to answer the query. Any nodes, includ-ing A, can repair their views of the overlay. As timegoes by, A is supposed to fix the anomaly. As a re-sult, queries answered by wrong nodes are consideredwrong.

4. Delay: after a query is sent, the delay measures thetime passes by until a successful reception of answer.Queries with delay equal to zero, that is, immediatequeries, are excluding from calculation.

5.2 Bootstrapping Performance

We first evaluate the performance of passive bootstrap-ping under Houston scenario. The result is illustrated inFig. 2. A consistent state is that every node in the over-lay has correct information about its successor. The av-erage duration that the P2P overlay reaching consistentstate is plotted. Every node starts its MChord instanceat the beginning of a simulation. Experiments repeat 10times. Since the size of the map among experiments isfixed, the speed of reaching consistency becomes higheras the node density grows. As Fig. 2 shows, the passivebootstrapping mechanism outperforms basic hook-node so-lution slightly. Passive bootstrapping not only convergesfaster than hook-node solution, but also prevents networkcongestion around the hook nodes since passive bootstrap-ping does not try to connect to hook nodes.

5.3 Traffic Reduction

Table 2 summarizes one of the Houston 80-node networksimulations. This example is used to demonstrate the traf-fic reduction in MChord and MChord with cross-layer ex-tension. MChord reduces not only application layer traffic,

6

but also network layer traffic because 1) MChord uses over-lay table broadcasting instead of unicast ping. No routeis built or maintained, so lots of signaling overhead due toroute discovery is saved. 2) An overlay table broadcastingmessage contains more information than a unicast ping, somore packets are saved. In addition, in such network, theChord introduces heavy traffic that lead to network con-gestions. A big fraction of packets are dropped due to thecongestion. MChord with cross-layer enhancement savesmore traffic when using a long overlay table broadcast-ing interval. We can calculate the number of overlay tablebroadcasting packet is about 114,286 in MChord and about13,115 in MChord with cross-layer extension. Between twoof them, it could save about 101,171 packets. Indeed, itsaves 97,791 packets in this simulation. Also, the AODVin NS2 do not use hello message. To determine whether alink is still there or not relies on the feedback from 802.11MAC. If a route breaks, a packet through this route can-not be acknowledged by the intended receiver. So 802.11MAC will retransmit this packet again and again until itreaches the retry limit. When a packet reaches the retrylimit of 802.11 MAC, the packet is dropped by 802.11 MACand 802.11 MAC will send a signal to AODV to indicatea link failure of some vicinal node. Due to the vehicu-lar mobility, a link is vulnerable to break. Most packetsare dropped due to mobility, i.e. link failure. Since onlyunicast packets need routes, so the packet dropping dueto reach retry limit are almost the same In MChord withand without cross-layer enhancement. The big fraction ofChord packet is dropped is inevitable and reasonable.

5.4 Vehicular Network P2P Performance

Fig. 5 illustrates the performance of Chord and MChordwith and without cross-layer enhancement under Houstonscenario. It is clear that MChord beats Chord by a consid-erable amount under any giving metrics. Chord cannot geta high performance in query response ratio or in correctquery response ratio. MChord reflects very good query re-sponse ratio and correct query response ratio. We can con-clude that the approach Chord using in wired network isnot adequate in vehicular network. The theoretical averageapplication steps are 1/2O(log N). In vehicular network,maintaining a route between two nodes is cost-prohibitivebecause of the considerable overhead. Construct a routeon-demand seems a good solution. A Chord query needs toconstruct O(log N) routes to complete the query correctly.Each application step needs a route construction if thereis no route available. It is very rare in a vehicular networkwithout group mobility that a connection could exist for along time. Making every route available to finish a queryis not easy and costs a lot of resource. Furthermore, dueto the vehicular mobility, the connection cannot last verylong. As a result, Chord fails to get a good correct queryresponse ratio. On the other hand, MChord can reduce ap-plication steps to almost two. MChord can finish a querymore quickly. That is the major reason MChord outper-form Chord. The query delay of Chord seems better than

of MChord. In Chord, however, most query responses arewrong. No matter how quickly a response presents, thatmatters almost nothing if the response is wrong. Now weturn to overlay consistency, the overlay consistency is theratio of the number of nodes which have correct succes-sor to the number of all nodes in the network. It is clearMChord always keeps in high consistency while Chord isnot. That is also evidential that correct query responseratio is low in Chord.

Fig. 6 and 7 illustrate the performance of Chord andMChord with and without cross-layer enhancement underIdaho and New York scenarios. MChord still beats Chord.As mentioned in the previous section, queries with less ap-plication steps tend to success. In these scenarios, onlyChord query which travels shorter can reach the respon-dent node, so the delay of Chord seems better than thatof MChord. Although there are limited responses in theoriginal Chord, most of the query results are wrong. Whennode density is so low that reaching others are not easy,the query response ratio and correct query response ra-tio are low. Because only queries travel not too far canget a response, the delay is small, too. When the nodedensity grows, reaching others becomes easier. As a re-sult, the query response ratio and the correct query re-sponse ratio increase. While delay also increases, this isbecause the connectivity is still not enough to let a sta-ble connection proceed. As the network becomes denserand denser, the query response ratio and the correct queryresponse ratio boost. Moreover, the delay drops in thedensely connected scenario. It is very interesting that per-formance drops only slightly when the speed of vehiclesincreases. The proposed MChord can complete a querywithin a short time that is less than the connected timeduration in high-speed cases. Most communication over-head contributes from 802.11 MAC layer RTS/CTS/ACKand delay of route request from AODV. MChord saves a lotof unnecessary application steps. As a result, MChord cancomplete queries and response on time even when vehiclesdrive at very high speed while Chord cannot.

5.5 Overlay Table Broadcasting Interval

We adjust the interval of overlay table broadcasting from[3,4] to [15,16] and [30,31] with and without MChord cross-layer enhancement. The results are shown in Fig. 11.It is clear that MChord without cross-layer enhancementperforms terriblely when the overlay table broadcasts lessfrequently. When node density becomes higher, MChordbehaves better.

With a given broadcast interval parameter, nodes willhear more overlay table broadcasting during a fixed pe-riod when node density is higher. Thus, the performanceis enhanced because of the more overlay information indense networks. The situation changes when we deployMChord cross-layer enhancement. As expected, perfor-mance degrades at shorter broadcast intervals, as informa-tion is updated less frequently. An interesting observationis that MChord performance degrades more compared with

7

cross-layer MChord. The cross-layer knowledge harvest-ing and knowledge piggybacking could effectively increasethe speed of overlay information update, even under infre-quent broadcasting operating conditions. The cross-layerenhancement for MChord could reduce the overlay tablebroadcasting overhead while maintaining good overlay pro-tocol consistency. As a result, we could apply MChordwith cross-layer enhancement to provide efficient P2P overVANET operation.

5.6 Comparative Performance in Different Mobil-ity Schemes

We compare the results from different network mobilityschemes. We first discuss the correct query response ratio.In Fig. 12 we observed that the correct query responseratio is majorally affected by the map size. Networks in1200m x 1200m Houston map have the best correct queryresponse ratio while networks in 2400m x 2400m New Yorkmap have the worst performance. In the same size of maps,networks in Idaho outperform networks in New York. Thisis because the number of partitioned groups is less in Idaho,as we discussed in Fig. 10. If the network is less par-titioned, the query initiator and the query responder aremore likely in the same reachable group. The P2P querycan be correctly responded only when the two nodes arein the same partitioned group.

Next, we compare the average delay in different networkschemes. The map size still affects the delay greatly. InFig. 13 we can see the network in Houston has lower de-lay while in the larger New York map the delay is muchhigher. In 2400m x 2400m New York map, delay increasesas the number of nodes increases. Similarly, we could alsoobserve that in the 1600m x 1600m New York and Idahomaps, but the curve transition is at different node num-ber parameter. Two factors: transmission distance andthe degree of connectivity affect delay. When the num-ber of nodes increases, the number of partitioned groupsdecreases and the size of connected groups grows. The dis-tance and the hop counts between two nodes in the samegroup increases due to the larger group size. However, thedegree of connectivity also increases, so it is possible to finda shorter route with fewer hops. The curve transition hap-pens when the node density is large enough to find shorterroutes easily.

Finally, we discuss the no responded queries in differentmobility schemes. The no responded query ratio is theratio of queries without any response from other nodesto by the total query events. In Fig. 14, we observedthat the major factor is still the network partitioning issue.When nodes are in different groups, it is impossible tohave response from the respondent node. We observed thatthe curve of no response ratio is very similar to the curveof partitioned group number in Fig. 10. An interestingobservation is that the no response ratio in the 2400m x2400m New York is not as high as we expected from thepartitioned group curve. This is because the number ofgroups in the network is too large that the consistency

cannot be hold in Mobile Chord. The inconsistency resultsin a significantly amount of false information. Althoughthe nodes may respond to the query, the responses areusually false.

6 Conclusion

Cross-layer design to improve P2P overlay performanceover vehicular ad hoc network is investigated. The base-line Chord protocol performance and the enhanced Mo-bile Chord performance are compared with extensive NS-2simulation. The proposed Mobile Chord scheme performswell in the challenging VANET environment while Chorddoes not. The P2P overlay consistency of Mobile Chordis significant higher than that of the baseline Chord. Theproposed bootstrapping technique also reduces control sig-naling cost and improves P2P network convergence timein highly dynamic vehicular environment. Cross-layer de-sign for Mobile Chord could effectively reduce the signalingcost by efficiently disseminating P2P overlay information.In summary, Mobile Chord outperforms Chord in termsof overlay consistency, the number of application layer for-warding steps, query response ratio, correct query responseratio, and the average query delay.

Acknowledgement

This work was supported by the National Science Councilof Taiwan under Grant NSC-97-2221-E-002-138-MY2.

REFERENCES

Ahmed, D. T. and Shirmohammadi, S. (2007) ‘Multi-levelhashing for peer-to-peer system in wireless ad hoc envi-ronment’, IEEE International Conference on PervasiveComputing and Communications Workshops

Ben, Y. Z., John, D. K., and Anthony, D. J. (2001)‘Tapestry: An infrastructure for fault-tolerant wide-arealocation’, Technical report , University of California atBerkeley.

Burresi, S., Canali, C., Renda, M. E., and Santi, P. (2008)‘MeshChord: A location-aware, cross-layer specializa-tion of chord for wireless mesh networks (concise contri-bution)’ In Sixth Annual IEEE International Conferenceon Pervasive Computing and Communications.

Caesar, M., Castro, M., Nightingale, E. B., O’Shea, G.,and Rowstron, A. (2006). ‘Virtual ring routing: networkrouting inspired by dhts’, In SIGCOMM ’06: Proceed-ings of the 2006 conference on Applications, technolo-gies, architectures, and protocols for computer commu-nications , pp. 351-362.

8

Cramer, C. and Fuhrmann, T. (2006). ‘Bootstrappingchord in ad hoc networks not going anywhere for awhile’, In Fourth Annual IEEE International Conferenceon Pervasive Computing and Communications Work-shops.

Cramer, C. and Fuhrmann, T. (2006). ‘Performance evalu-ation of chord in mobile ad hoc networks’, In MobiShare’06: Proceedings of the 1st international workshop onDecentralized resource sharing in mobile computing andnetworking, pp 48-53.

Delmastro, F. (2005). ‘From Pastry to CrossROAD:Cross-layer ring overlay for ad hoc networks’, In Third IEEEInternational Conference on Pervasive Computing andCommunications Workshops, pp 60-64.

Ding, G. and Bharat, B. (2004). ‘Peer-to-peer file-sharingover mobile ad hoc networks’, In Proceedings of the Sec-ond IEEE Annual Conference on Pervasive Computingand Communications Workshops, pp 104-108.

Lee, K., Lee, S.-H., Cheung, R., Lee, U., and Gerla, M.(2007). ‘First experience with CarTorrent in a real vehic-ular ad hoc network testbed’,IEEE Mobile Networkingfor Vehicular Environments Conference,pp 109-114.

Levergood, B. (1998). ‘US Census Bureau: By USDepartment of Commerce. Washington, DC: TheAgency’,Government Information Quarterly Vol. 15,No. 1, pp 147-151.

McCanne, S. and Floyd, S. (2006) ‘ns-2 Network Simula-tor’, Obtain via: http://www.isi.edu/nsnam/ns.

Montresor, A., Jelasity, M., and Babaoglu, O. (2005).‘Chord on demand’, In Fifth IEEE International Con-ference on Peer-to-Peer Computing, pp 87-94.

Nandan, A., Tewari, S., Das, S., Gerla, M., and Kleinrock,L. (2006). ‘AdTorrent: Delivering Location CognizantAdvertisements to Car Networks’, WONS’ 06.

Oliveira, L. B., Siqueira, I. G., Macedo, D. F., Loureiro,A. A. F., Hao Chi, W., and Nogueira, J. M. (2005).‘Evaluation of peer-to-peer network content discoverytechniques over mobile ad hoc networks’, In Sixth IEEEInternational Symposium on World of Wireless Mobileand Multimedia Networks, pp 51-56.

PalChaudhuri, S., Le Boudec, J., and Vojnovic, M. (2005).‘Perfect simulations for random trip mobility models’,Annual Simulation Symposium: Proceedings of the 38th annual Symposium on Simulation, Vol. 4, No. 6, pp72-79.

Pucha, H., Das, S. M., and Hu, Y. (2006). ‘Ekta+: oppor-tunistic multiplexing in a wireless DHT’, In MobiShare’06: Proceedings of the 1st international workshop onDecentralized resource sharing in mobile computing andnetworking, pp 69-71.

Pucha, H., Das, S. M., and Hu, Y. C. (2004). ‘Ekta:anefficient DHT substrate for distributed applications inmobile ad hoc networks’,In Sixth IEEE Workshop onMobile Computing Systems and Applications, pp 163-173.

Qi, M. and Hong, J. (2007). ‘MA-Chord: A new ap-proach for mobile ad hoc network with DHT based uni-cast scheme’, In International Conference on WirelessCommunications, Networking and Mobile Computing,pp 1533-1536.

Rowstron, A. and Druschel, P. (2001). ‘Pastry: Scalable,decentralized object location, and routing for largescalepeer-to-peer systems’,Middleware, pp 329-350.

Stoica, I., Morris, R., Karger, D., Kaashoek, M. F.,and Balakrishnan, H. (2001). ‘Chord: A scalable peer-to-peer lookup service for internet applications’. SIG-COMM ’01: Proceedings of the 2001 conference on Ap-plications, technologies, architectures, and protocols forcomputer communications, pp 149-160.

Sylvia, R., Paul, F., Mark, H., Richard, K., andScott, S. (2001). ‘A scalable content-addressable net-work’,SIGCOMM Computer Communication, Vol. 31,No. 4, pp 161-172.

Zahn, T., Wittenburg, G., and Schiller, J. (2006). ‘To-wards efficient range queries in mobile ad hoc networksusing DHTs’. MobiShare ’06: Proceedings of the 1st in-ternational workshop on Decentralized resource sharingin mobile computing and networking, pp 72-74.

9

Successor Reachability Check Interval [4, 6] secQuery timeout [9, 11] secOverlay Table Broadcasting Period (MChord) [3, 4] secOverlay Table Entry Expiration Time (MChord) 60 secFinger Entry Reachability Check Interval (Chord) [5, 7] secMaximum Retry of Finger Entry (Chord) 3 ping losesRandom Finger Entry Update (Chord) [15, 18] sec

Table 1: The important parameters of Chord and MChord

Chord MChord Cross-layerMChord*

Number of AODVRREQ

16326 13250 17912

Number of AODVRREQ packets

650729 503191 582379

Chord introduced pack-ets at application layer

674809 215168 117377

Chord packet drops 531621 84857 76555Number of Chord pack-ets dropped by reach-ing retry limit at 802.11MAC

418784 72029 71268

Table 2: The traffic analysis of a 80-node network (*: over-lay table broadcast interval=[30, 31])� �� � � �� � �

� � � � �� � � � � �� � �� � � � � �

Figure 1: An example of Chord overlay over VANET

10

30 40 50 60 70 80 90 10010

15

20

25

30

35

40

Number of nodes

Tim

e (s

ec)

Passsive bootstrapping

Hook Node JoinPassive Bootstrapping

Figure 2: The seconds MChord needs to reach consistent state in a vehicular network

Application

Transport

Network

Physical

MAC

Figure 3: Cross-layer design

S 22900 m

N 25300 m

Span 2400 m

W 56900 m E 59300 m

S 21000 m

N 22600 m

Span 1600 m

W 12000 m E 13600 m

S 6400 m

N 8000 m

Span 1600 m

W 3200 m E 4800 mFigure 4: Maps from Houston, Idaho, and New York

11

30 40 50 60 70 80 90 1000

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Res

pons

e ra

tio

(a) Query response ratio and correct query response ratio

Chord − Query response ratioMChord − Query response ratioCL MChord − Query response ratioChord − Correct query response ratioMChord − Correct query response ratioCL MChord − Correct query response ratio

30 40 50 60 70 80 90 1001.5

1.6

1.7

1.8

1.9

2

2.1

2.2

2.3

2.4

2.5

Number of nodes

App

licat

ion

step

s

(b) Application layer forwarding steps

ChordMChordCL MChord

30 40 50 60 70 80 90 1000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

Number of nodes

Del

ay (

sec)

(c) Query delay

ChordMChordCL MChord

0 1000 2000 3000 4000 5000

0

0.2

0.4

0.6

0.8

1

Time (sec)

Con

sist

ency

(d) Overlay consistency

ChordMobile Chord

Figure 5: Vehicular network in Houston (a) Query response ratio and correct query response ratio (b) Application layerforwarding steps (c) Query delay (d) Overlay consistency in an 80-node network

12

30 40 50 60 70 80 90 100 110 1200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Res

pons

e ra

tio

(a) Query response ratio and correct query response ratio

Chord − Query response ratioMChord − Query response ratioCL MChord − Query response ratioChord − Correct query response ratioMChord − Correct query response ratioCL MChord − Correct query response ratio

30 40 50 60 70 80 90 100 110 1201.5

1.6

1.7

1.8

1.9

2

2.1

2.2

2.3

2.4

2.5

Number of nodes

App

licat

ion

step

s

(b) Application layer forwarding steps

ChordMChordCL MChord

30 40 50 60 70 80 90 100 110 1200.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

Number of nodes

Del

ay (

sec)

(c) Query delay

ChordMChordCL MChord

30 40 50 60 70 80 90 100 110 1200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Res

pons

e ra

tio

(d) Correct query response ratio − Idaho

1600 − Idaho − 151600 − Idaho − 201600 − Idaho − 25

Figure 6: Vehicular network in Idaho (a) Query response ratio and correct query response ratio (b) Application layerforwarding steps (c) Query delay (d) Correct query response ratio in different speed

13

30 40 50 60 70 80 90 100 110 1200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Res

pons

e ra

tio

(a) Query response ratio and correct query response ratio

Chord − Query response ratioMChord − Query response ratioCL MChord − Query response ratioChord − Correct query response ratioMChord − Correct query response ratioCL MChord − Correct query response ratio

30 40 50 60 70 80 90 100 110 1201.5

1.6

1.7

1.8

1.9

2

2.1

2.2

2.3

2.4

2.5

Number of nodes

App

licat

ion

step

s

(b) Application layer forwarding steps

ChordMChordCL MChord

30 40 50 60 70 80 90 100 110 1200

0.5

1

1.5

2

2.5

3

Number of nodes

Del

ay (

sec)

(c) Query delay

ChordMChordCL MChord

30 40 50 60 70 80 90 100 110 1200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Res

pons

e ra

tio(d) Correct query response ratio − New York

1600 − New York − 151600 − New York − 201600 − New York − 25

Figure 7: Vehicular network in New York (a) Query response ratio and Correct query response ratio (b) Applicationlayer forwarding steps (c) Query delay (d) Correct query response ratio in different speed

30 40 50 60 70 80 90 100 110 12015

20

25

30

35

40

45

Number of nodes

Tim

e (s

ec)

Average connection duration in different maps

1200 − Houston − 151600 − Idaho − 151600 − Idaho − 201600 − Idaho − 251600 − New York − 101600 − New York − 151600 − New York − 202400 − New York − 102400 − New York − 152400 − New York − 20

Figure 8: Average connection duration

14

30 40 50 60 70 80 90 100 110 1200

2

4

6

8

10

12

14

16

18

20

Number of nodes

Num

ber

of d

egre

es

Degree of connectivity in different maps

1200 − Houston1600 − Idaho1600 − New York2400 − New York

Figure 9: Degree of connectivity

30 40 50 60 70 80 90 100 110 1200

2

4

6

8

10

12

14

16

18

Number of nodes

Num

ber

of g

roup

s

Average partitions in different maps

1200 − Houston1600 − Idaho1600 − New York2400 − New York

Figure 10: Number of partitioned network groups

30 40 50 60 70 80 90 100 110 1200.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Number of nodes

Cor

rect

que

ry r

espo

nse

ratio

Broadcasting interval

MChord − 3MChord − 15MChord − 30CL MChord − 3CL MChord − 15CL MChord − 30

Figure 11: Interval of overlay table broadcasting: 3s, 15s, and 30s

15

30 40 50 60 70 80 90 100 110 1200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Res

pons

e ra

tio

Correct query response ratio

1200 − Houston − 151600 − Idaho − 151600 − New York − 152400 − New York − 15

Figure 12: Correct query response ratio

30 40 50 60 70 80 90 100 110 1200

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

Number of nodes

Del

ay (

sec)

Delay Time

1200 − Houston1600 − Idaho1600 − New York2400 − New York

Figure 13: Average delay

30 40 50 60 70 80 90 100 110 1200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

No

resp

onse

rat

io

No response ratio

1200 − Houston1600 − Idaho1600 − New York2400 − New York

Figure 14: No response ratio

16