2010 Mobile Chord-For Graph

  • Upload
    kanjai

  • View
    218

  • Download
    0

Embed Size (px)

Citation preview

  • 8/12/2019 2010 Mobile Chord-For Graph

    1/16

    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:[email protected] 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 p oorly 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 and

    its 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-danet 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 very

    high 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    2/16

    Chord(Stoicaet 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. Logarithmic

    complexity 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 describes

    the 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 maintains

    its 1) successor, which is the node with the smallest keyamong keys larger than Xs, 2) predecessor, which is thenode with the largest key among keys smaller than Xs, 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 Xs successor). Inthat way, the work load can be averaged since the keys oc-cupied by nodes should be randomly distributed in the key

    space. 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 largerthanKey+ 2i1, wherei = (1, 2, 3 . . .m). The logarithmic

    complexity 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 some

    node 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. Thomas

    et al. (Zahn et al., 2006) extends the DHT substrate tosupport range query in MANET.

    .

    2

  • 8/12/2019 2010 Mobile Chord-For Graph

    3/16

    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(Puchaet al., 2004)and its successor Ekta+(Puchaet 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 called

    address 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 both

    the 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 damage

    the 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    4/16

    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 neighbors

    periodically. 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 , or .

    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 to

    resolve 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 design

    inspired 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    5/16

    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 further

    and 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 packet

    level 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 an

    instance of Chord application on top of a UDP agent.The vehicular network traffic scenario is created with

    the 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 us

    a 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    6/16

  • 8/12/2019 2010 Mobile Chord-For Graph

    7/16

    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, so

    more 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(logN). 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 toconstructO(logN) 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. When

    node 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    8/16

    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 table

    broadcasting 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 query

    response 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 x

    2400m 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 CommunicationsWorkshops

    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., OShea, 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    9/16

    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 MobiShare06: 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 sharing

    in mobile computing and networking, pp 72-74.

    9

  • 8/12/2019 2010 Mobile Chord-For Graph

    10/16

    Successor Reachability Check Interval [4, 6] secQuery timeout [9, 11] secOverlay Table Broadcasting Period (MChord) [3, 4] secOverlay Table Entry Expiration Time (MChord) 60 sec

    Finger 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    11/16

    30 40 50 60 70 80 90 10010

    15

    20

    25

    30

    35

    40

    Number of nodes

    Time(sec)

    Passsive bootstrapping

    Hook Node Join

    Passive Bootstrapping

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

    Figure 3: Cross-layer design

    Figure 4: Maps from Houston, Idaho, and New York

    11

  • 8/12/2019 2010 Mobile Chord-For Graph

    12/16

    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

    Responseratio

    (a) Query response ratio and correct query response ratio

    Chord Query response ratio

    MChord Query response ratio

    CL MChord Query response ratio

    Chord Correct query response ratio

    MChord Correct query response ratio

    CL 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

    Application

    steps

    (b) Application layer forwarding steps

    Chord

    MChord

    CL 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

    Delay(sec)

    (c) Query delay

    Chord

    MChordCL MChord

    0 1000 2000 3000 4000 5000

    0

    0.2

    0.4

    0.6

    0.8

    1

    Time (sec)

    Consistency

    (d) Overlay consistency

    Chord

    Mobile 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    13/16

    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

    Responseratio

    (a) Query response ratio and correct query response ratio

    Chord Query response ratio

    MChord Query response ratio

    CL MChord Query response ratio

    Chord Correct query response ratio

    MChord Correct query response ratio

    CL 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

    Application

    steps

    (b) Application layer forwarding steps

    Chord

    MChord

    CL 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

    Delay(sec)

    (c) Query delay

    Chord

    MChordCL 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

    Responseratio

    (d) Correct query response ratio Idaho

    1600 Idaho 15

    1600 Idaho 20

    1600 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

  • 8/12/2019 2010 Mobile Chord-For Graph

    14/16

    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

    Responseratio

    (a) Query response ratio and correct query response ratio

    Chord Query response ratio

    MChord Query response ratio

    CL MChord Query response ratio

    Chord Correct query response ratio

    MChord Correct query response ratio

    CL 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

    Applicationsteps

    (b) Application layer forwarding steps

    Chord

    MChord

    CL MChord

    30 40 50 60 70 80 90 100 110 1200

    0.5

    1

    1.5

    2

    2.5

    3

    Number of nodes

    Delay(sec)

    (c) Query delay

    Chord

    MChord

    CL 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

    Responseratio

    (d) Correct query response ratio New York

    1600 New York 15

    1600 New York 20

    1600 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

    Time(sec)

    Average connection duration in different maps

    1200 Houston 15

    1600 Idaho 15

    1600 Idaho 20

    1600 Idaho 25

    1600 New York 10

    1600 New York 15

    1600 New York 20

    2400 New York 10

    2400 New York 15

    2400 New York 20

    Figure 8: Average connection duration

    14

  • 8/12/2019 2010 Mobile Chord-For Graph

    15/16

    30 40 50 60 70 80 90 100 110 1200

    2

    4

    6

    8

    10

    12

    14

    16

    18

    20

    Number of nodes

    Numberofdegrees

    Degree of connectivity in different maps

    1200 Houston

    1600 Idaho

    1600 New York

    2400 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

    Numberofgroups

    Average partitions in different maps

    1200 Houston

    1600 Idaho

    1600 New York

    2400 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

    Correctqueryresponseratio

    Broadcasting interval

    MChord 3

    MChord 15

    MChord 30

    CL MChord 3

    CL MChord 15

    CL MChord 30

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

    15

  • 8/12/2019 2010 Mobile Chord-For Graph

    16/16

    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

    Responseratio

    Correct query response ratio

    1200 Houston 15

    1600 Idaho 15

    1600 New York 15

    2400 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

    Delay(sec)

    Delay Time

    1200 Houston

    1600 Idaho

    1600 New York

    2400 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

    Noresponseratio

    No response ratio

    1200 Houston

    1600 Idaho

    1600 New York

    2400 New York

    Figure 14: No response ratio

    16