A Generic Polymorphic Unicast Routing Protocol for vehicular ad hoc networks

WIRELESS COMMUNICATIONS AND MOBILE COMPUTINGWirel. Commun. Mob. Comput. 2013; 13:1295–1308

Published online 23 August 2011 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/wcm.1181

RESEARCH ARTICLE

A Generic Polymorphic Unicast Routing Protocol forvehicular ad hoc networksAdel Ben Mnaouer1*, Chuan Heng Foh2 and Lei Chen2

1 College of Computer Engineering and Information Technology, Dar Al-Uloom University, Riyadh, Saudi Arabia2 School of Computer Engineering, Nanyang Technological University, Singapore

ABSTRACT

In this work, we present a new generic polymorphic routing protocol tailored for vehicular ad hoc networks (VANETs).Similar to the case of mobile ad hoc networks, the routing task in VANETs comes under various constraints that can beenvironmental, operational, or performance based. The proposed Polymorphic Unicast Routing Protocol (PURP) uses theconcept of polymorphic routing as a means to describe dynamic, multi-behavioral, multi-stimuli, adaptive, and hybridrouting, that is applicable in various contexts, which empowers the protocol with great flexibility in coping with the timelyrequirements of the routing tasks. Polymorphic routing protocols, in general, are equipped with multi-operational modes(e.g., grades of proactive, reactive, and semi-proactive), and they are expected to tune in to the right mode of operationdepending on the current conditions (e.g., battery residue, vicinity density, traffic intensity, mobility level of the mobilenode, and other user-defined conditions). The objective is commonly maximizing and/or improving certain metrics such asmaximizing battery life, reducing communication delays, improving deliverability, and so on. We give a detailed descrip-tion and analysis of the PURP protocol. Through comparative simulations, we show its superiority in performance to itspeers and demonstrate its suitability for routing in VANETs. Copyright © 2011 John Wiley & Sons, Ltd.

KEYWORDS

vehicular ad hoc network; routing protocols; polymorphic routing

*Correspondence

Adel Ben Mnaouer, College of Computer Engineering and Information Technology, Dar Al-Uloom University, PO Box 3535, Riyadh13314-7222, Saudi Arabia.E-mail: [email protected]

1. INTRODUCTION

Mobile ad hoc networks (MANETs) and vehicular adhoc networks (VANETs) are two representative types ofdynamic networks (DNs). Although a unified definitionof DNs is not obvious, we do characterize them as fol-lows: they are networks subject to frequent changes in theirstructural (i.e., topological) or functional (i.e., behavioral)characteristics, which may be based on hybrid architec-tures that are supposed to cope with different classes oftraffic or provide various classes of services.

Vehicular ad hoc networks represent a special type ofMANETs where mobile nodes (MNs) are mounted onvehicles and are characterized by more regular mobilitypatterns (following roads and traffic rules and conditions)and by irregular and fluctuating speed levels.

Some of the main hurdles in the deployment of efficientrouting protocols for MANETs are the randomness of themobility patterns of MNs and their limited battery supplies.

Another issue of concern is the wastage of signal powerwhen a single transmission rate is used. However, withVANETs considered, these two hurdles are almost elim-inated as the mobility patterns of MNs are more or lesspredictable, and the power supply is no longer a problemas an MN draws power directly from the vehicle host-ing it. Consequently, routing protocols for VANETs shouldbe designed with no concerns for power supply but withspecific constructs that should potentially benefit from theregularity of the mobility patterns.

Nevertheless, VANETs have their own specificities thatrelate to the fact that routing paths may experience highlevel of breakages during high-speed node mobility. Assuch, a trend in routing protocol design has focused onenhancing them with delay/disruption tolerance mecha-nisms and with opportunistic routing features [1–3].

Furthermore, as a further refinement of the designof routing protocols that are suited for DNs, a newparadigm known as polymorphic behavior-based routing

Copyright © 2011 John Wiley & Sons, Ltd. 1295

Polymorphic routing protocol for VANETs A. B. Mnaouer, C. H. Foh and L. Chen

was introduced in [4–7]. In general, polymorphic rout-ing protocols exhibit hybrid, adaptive, multi-stimuli-basedrouting. Such a protocol is designed to be empoweredwith various operational (i.e., behavioral) modes that aretriggered by specifically defined (context dependent) sur-rounding factors and with specially defined (mostly perfor-mance based) targets.

In this article, we exploit this new line of protocol designthat is gaining acceptance among the research communityacross different networking disciplines [5–8], and we pro-pose the Polymorphic Unicast Routing Protocol (PURP),that is a generic protocol designed for efficient routingin VANETs.

The design goal of this proposed generic protocol is tocapitalize on the suitability of the polymorphic behavior-based routing for DNs and to show its applicability forVANETs, specifically. As the issue of power is not of con-cern in VANETs, the PURP focuses only on the principlesof hybridization and adaptability.

The hybridization is illustrated by its hybrid behaviorwhere the Zone Routing Protocol (ZRP) [9] drives itsproactive mode of operation, and the Ad hoc On-demandDistance Vector (AODV) protocol [10] enforces its reactivebehavioral mode.

As for the adaptability dimension, it is illustrated bythe fact that the protocol’s parameters are adjusted adap-tively according to different network conditions, namely,the mobility level, the vicinity density level, and the traf-fic load level. The resulting protocol gets vested with apolymorphic behavior that ensures dynamism and flex-ibility of operations to ensure the best possible perfor-mance for the targeted criteria such as lower latency andreduced overhead.

The choice of the ZRP and the AODV protocol forthe construction of the PURP comes from the fact thatthey are proven efficient, although not necessarily the bestones. Any enhancement for them such as those proposedin [11] and [12] or any other protocols, which are foundbetter performing than these two, are also applicable tothe PURP. This clearly testifies to its genericity as the useof other combinations of protocol behaviors will result innew protocols with their own distinguished performances.However, the polymorphic nature will always be retained.

In the next section, a review of the state-of-the-art rout-ing protocols for VANETs is provided. A detailed descrip-tion of the PURP is given in Section 3. This sectionalso encompasses a subsection that describes some designissues for the proposed PURP. Then, in Section 4, we reporta simulation-based evaluation of the PURP where its per-formance is compared with its peers. The main conclusionsare drawn in Section 5.

2. STATE-OF-THE-ART REVIEW

A good coverage of some polymorphic and hybrid rout-ing protocols reported in the literature for MANETs canbe found in [5]. Additionally, we report a recent work

of one of authors of this work on polymorphic protocols.Indeed, in a recent work [8], Belghith et al. proposed a newpolymorphic routing protocol that combines the benefits ofproactive routing and a (newly proposed [13]) probabilisticrouting, in a timely and periodic manner in order to get thebest of each approach at the appropriate timing. The idea isbased on the observation that proactive routing informationgathered at the beginning of a routing period loses its accu-racy rapidly in presence of high mobility and thus becomesmore of a burden than an asset.

However, probabilistic routing can remedy to this back-wardness of the proactive routing and can take over thetask of providing accurate routes (computed probabilisti-cally) gradually in time, according to prescribed and care-fully selected threshold values depending on the currentmobility level. Very good results were reported with thisnew protocol that outperformed both proactive and prob-abilistic routings each considered alone [8]. This recentdevelopment again confirms the suitability of the polymor-phic behavior approach for the design of routing protocolsfor DNs.

In the remainder of this section, we will restrict our dis-cussion to some of the important works directed towardsVANETs. In [14], the authors address a path finding proce-dure named Geographic Source Routing (GSR). They usethe location information combined with the map informa-tion to calculate the route from a source to a destination anduse the source routing technique to determine the packetdelivery path. With the map information, the path can avoidobstacles of transmission so that the route is guaranteed tobe valid if there are no link breaks caused by mobility.

The authors of [1] define VANETs consisting of twocomponents: vehicles and infostations (fixed access pointsconnected to the Internet). Their proposed GeographicalOpportunistic Routing protocol uses a combination of theconcepts of geographical positioning and network delaytolerance. This protocol uses geographical information tocalculate the route to the destination and uses the delay-tolerant method to handle data transmission. In the delay-tolerant method, data transmission is not much concernedabout the end-to-end delay of one transmission. Thus,intermediate nodes can avoid unnecessary data packettransmissions by storing data packets and sending themlater to the destination nodes once paths leading to themare found.

The concept of routing for vehicle-based disruption-tolerant networks is proposed in [15]. The authors mainlydeploy a new protocol, named MaxProp, in the disruption-tolerant networks. Disruption-tolerant networks allow forrouting in networks where simultaneous end-to-end pathsare unstable or unlikely. The disruption-tolerant networksdescribed in [15] are similar to MANETs, and the delay-tolerant networks are as described in [1]. The data trans-mission in disruption-tolerant networks is the same as thatin the delay-tolerant networks; that is, an intermediate nodeis allowed to store a data packet and deliver it to the des-tination later. The authors mainly focused on local buffermanagement of the node for the storage of data packets.

1296 Wirel. Commun. Mob. Comput. 2013; 13:1295–1308 © 2011 John Wiley & Sons, Ltd.DOI: 10.1002/wcm

A. B. Mnaouer, C. H. Foh and L. Chen Polymorphic routing protocol for VANETs

The authors of [16] presented a so-called reliable geo-graphical multicast routing protocol. In this protocol, theinitiator node broadcasts geographical information withina limited zone. The process is similar to that of the AODV,where a node reactively sends out request messages andwaits for replies. Each node updates its routing informationusing the information extracted from the control packetsreceived and determines the routing path.

In [17], the authors propose a position-based quality-of-service (QoS) routing protocol for VANETs. The coreconcept of this protocol is based on dividing the wholearea into smaller uniform-size areas called grids. A sourcenode chooses one node within every grid along the trans-mission path for packet forwarding. The length of the edgeof each grid must guarantee that two nodes within two con-secutive grids are within their mutual transmission range.It is assumed that each node within the network is able toget the location information from a GPS device and candetermine its grid. The protocol establishes routing pathson-demand. Nodes selects a specific forwarding node inits grid for any path-finding process. Selected nodes in thegrids constitute the routing path until the destination.

Finally, the Connectivity-aware Routing (CAR) proto-col, proposed in [18], is a position-based routing protocolfor VANETs. The CAR protocol uses a periodically updat-ing HELLO message to maintain the neighbor’s mobilityand connectivity information. Each HELLO message con-tains the speed and the direction (named velocity vector)of the node. On receiving a HELLO message, the nodeuses the received information together with its own infor-mation to calculate the possible expiration time of a con-nection. Then, the node puts such a connection pair into itsneighborhood routing table (NRT).

When the source node requires a path to send the datato the destination, it generates a broadcast packet, withits coordinates and velocity vector, to look for the desti-nation. On receiving the broadcast packet, a node placesits own coordinates and velocity vector into the packettogether with some other information to guarantee connec-tivity, then forwards the packet. The routing is based onusing an anchor into the broadcasted packet that is definedwhen the angle between two velocity vectors is greater thana threshold value.

When the broadcasted packet finally reaches the des-tination node, this latter waits for a period for the otherbroadcasting packets from other possible routes. It thenchooses the best route and replies to the source followingthe reverse path of the selected route. The reply messagecontains the anchor points along the path so that the routeconsists in a series of anchor points towards the destination.

The aforementioned protocols exhibit different forms ofadaptive routing but did not specifically emphasize thoseadaptive features. In fact, most of them have defined com-plex behaviors that can be formalized (or broken down)into simpler sub-behaviors to deal with different condi-tions. For example, in the case of the GSR protocol [1],we could define the QoS requirement that may or may notuse delay tolerance in the network (e.g., in case of real-time

applications). This will lead to the definition of two typesof behaviors: delay-tolerant or non-delay-tolerant.

Another example is the case of the CAR protocol [18],where the periodically updating process can be made adap-tive. The node uses the number of neighbors (its vicinitydensity information) to determine the updating intervaltime. This may also call for formalizing two types ofbehaviors based on a threshold value of vicinity den-sity level.

With this line of thought, specifically dealing with sit-uations of high vicinity density (busy neighborhood), hightraffic intensity, or high mobility with appropriately definedbehaviors would enrich these protocols with capabili-ties that will realize better performance and consequentlywould provide better QoS. This is what we propose to doin the present endeavor.

3. DESCRIPTION OF THEPOLYMORPHIC UNICASTROUTING PROTOCOL

In this section, before presenting the detailed definitionand operation of the proposed PURP for VANETs, inthe first subsection, we give some design guidelines thatwe learned in designing the PURP. These guidelines are,up to a large extent, applicable when designing similarpolymorphic protocols useful for DNs such as MANETsand VANETs.

3.1. Design issues for polymorphicrouting in the Polymorphic UnicastRouting Protocol

For ad hoc networks in general (be it MANETs, VANETs,or others), it can be easily noticed that each environmentputs its own constraints on the routing tasks and requiresa desirable QoS. As such, polymorphic routing designshould take into consideration such constraints and require-ments. In addition, careful effort should be made to iden-tify the behavioral modes that are needed to cope with theconstraints and requirements of the routing task.

Commonly, environmental (or surrounding) factors maybe power supply level, vicinity density, traffic inten-sity, mobility level, signal strength, node reachability/coverability, and so on. Requirements might be lowlatency, high data rate (i.e., high data delivery), securityassurance, traffic prioritization, and so on.

For each of the environmental factors (or conditions),threshold values should be set in a way that reaching theselevels would trigger a change in behavior. For example, forour proposed PURP, threshold values are set for the trafficintensity that is much of concern in urban area (i.e., cor-responding to VANETs). This had the effect of regulatingthe proactiveness level of the routing protocol of the MN.Subsequently, this should lead, automatically, to reducingdata traffic jam around the nodes.

Wirel. Commun. Mob. Comput. 2013; 13:1295–1308 © 2011 John Wiley & Sons, Ltd. 1297DOI: 10.1002/wcm


In addition, the vicinity density around an MN is alsoan important factor that should influence its behavior. ForVANETs considering car-to-car communication, a highervicinity density would mean a higher probability of a trafficjam, which may result into high jamming of the commu-nication channels between the MNs. Thus, strict reactiverouting behavior would be appropriate in that situation.

In another recent work [8], the authors proposed a simi-lar polymorphic routing design where the threshold valuesare chosen according to some previous simulation resultson the efficiency range of the proactive routing. From theseresults, the authors showed that, for any given network,relative average speed precise instants (within a periodicrouting time span) can be deduced at which the perfor-mance of the proactive routing drops below a certain min-imum acceptable level of routing information accuracy.Beyond instants, a mode switch is forced to a backuprouting scheme that is based on probabilistic estimationto restore the accuracy of the generated routing paths toacceptable levels.

The second dimension in the design is the hybridizationof the protocol. This is usually achieved by either adoptingexisting commodity-off-the-shelf protocols as the driversof either reactive or proactive behaviors of the polymor-phic protocol or proposing new algorithms for these modesof operations that would be suitable for the operationalenvironment in hand.

Next, the adaptability feature of the protocol can beenforced by defining different grades of a certain opera-tional mode that would be switched into, on the basis oftriggers set according to threshold values of environmentalfactors. For example, the level of proactivity can be definedin several ways that will regulate the participation of thenode in the periodic data collection operations. For thePURP, three proactive modes were defined, namely, Proac-tive Mode 1, Proactive Mode 2, and Proactive Mode 3.

In the case of the protocol proposed in [8], two gradesof probabilistic routing were defined on the basis that thelengths produced using this routing scheme are usuallylonger than those produced by the proactive routing. Thus,a limit L was set on the difference in number of hops(in average) between the routes produced by the proba-bilistic routing and those produced by the proactive one.Setting (the integer) L higher will result in longer but morealternative and valid routes to destination. The value of Lwas used to set grades of probabilistic routing that can beadopted to serve a particular routing strategy.

Another issue that has to be tackled for polymorphicrouting is the coordination between nodes with regardsto their respective current mode of operation. For eachMN, it is essential that each change in its mode of oper-ation should be broadcast to its immediate surroundingnodes. These nodes should record the new mode changeand update the corresponding entries in their routing tables(such as the time-to-live (TTL) of the node’s entry). Inaddition, there should be a provision for a default modeof operation to which all the nodes could resort when theyloose synchronization with each other, in order to prevent

any hysterical behavior. With regards to the PURP, thepure reactive routing behavior was set as the default modein case coordination could be established with neighbor-ing nodes.

With connection to the above, there should be alsoappropriate mechanisms to avoid mode switch fluctuations.This may happen with some environmental factors such aswith the mobility speed, as vehicles may change speed fre-quently (up and down) around a mobility threshold value,which may result in frequent mode switch. Possible reme-dies can be either defining a range of the threshold valuesor monitoring the time gaps between successive modeswitches due to the same criterion.

3.2. Behavior of the Polymorphic UnicastRouting Protocol

For the PURP, we identify the parameters of interests asthe mobility speed, the vicinity density, and the trafficintensity. We define two traffic load level thresholds, onemobility level threshold, and one vicinity density thresh-old. These inputs are easily obtainable from each MN.The mobility level may come directly from the vehicle’sspeedometer, the vicinity density level is computed frommonitoring the exchanged control packets, and the trafficload is measured by periodical detection of channel usage.

The rationale for choosing two traffic intensity thresh-olds comes from the fact that in urban areas the likelihoodof car traffic jams is high, and its direct impact on datatraffic jams is straightforward. Thus, we chose two levelsof thresholds to be able to tune to less proactive behaviorsgradually in the presence of increasing data traffic.

Choosing different threshold levels for mobility canhave also its own rationale, especially, if we would liketo have various behaviors in presence of different mobil-ity levels. However, in our opinion, urban areas wouldhave usually a high number of vehicles moving around,and even in high mobility, alternative routes for data trans-mission would be found easily. Moreover, if road sideunits [19] are used, additional connectivity paths are madeavailable. Consequently, this will not warrant an increaseof proactiveness.

As for vicinity density thresholds, we have chosen onesingle level, taking into account the results reported in[20–22], which concur on the fact that maintaining at leastsix neighbors leads to high reliability of a network interms of connectivity for medium-sized networks. Conse-quently, a single cutoff point around that connectivity levelwas chosen and adopted in the simulation. Specific set-ting of these threshold values is not a trivial task as weare handling dynamically changing systems. However, pre-deployment threshold level tuning is possible through sim-ulation experiments such as those presented in Figures 4and 5, described later in this paper.T _TH1 and T _TH2 denote the different threshold

values for traffic load level, where T _TH1 > T _TH2.M_TH denotes the mobility speed threshold, and V _TH



denotes the vicinity density threshold value. These willdictate the choice of the appropriate behavioral mode foran MN to engage into.

The four behavioral modes of operation are as follows:

(1) Proactive Mode 1 (PM1): When an MN is in PM1,it periodically updates its neighborhood topologyand topology information by sending out an updatepacket with the zone radius R set as the TTL, andthe update interval is set to a tunable parametervalue i . The MN also maintains an NRT that storesthe topology and information saved in the receivedupdate packets.

(2) Proactive Mode 2 (PM2): The behavior of an MN inPM2 is similar to that of an MN in PM1; however,the zone radius is set toR�1. (a moderate proactivestate).

(3) Proactive Mode 3 (PM3): The behavior of an MN inPM3 is similar to that of an MN in PM2; however,the update interval is set to 2� i (the least proactivestate).

(4) Reactive Mode (RM): An MN in RM does not sendout update packets but maintains the NRT usinginformation stored in the received packets.

The algorithm is shown as follows:

Algorithm 1 Polymorphic algorithm.if TrafficLoad > T_TH1 then

if the MN is not in RM, it switches to RM.then it notifies neighbors about the mode switch.

elseif TrafficLoad < T_TH2 then

if the MN is not in PM1, it switches to PM1.then it notifies neighbors about the mode switch.

elseif Vicinity< V_TH OR Mobility>M_TH then

if the MN is not in PM2, it switches to PM2.then it notifies neighbors about the mode switch.

elseif the MN is not in PM3, it switches to PM3.then it notifies neighbors about the mode switch.

end ifend if

end if

Our design of the PURP described in Algorithm 1 aimsat improving the overall protocol’s performance. Effec-tively, when an MN is in a high traffic load scenario(> T_TH1), the MN is forced to perform in RM. In con-trast, when such MN is in a low traffic load scenario(< T_TH2), the MN runs PM1.

In extremely high traffic load scenarios, massive datatransmission could exhaust the channel capacity and cause

high traffic jams (due to collisions). In such cases, the reac-tive mode is ideal because the PM usually aggravates theburden on the channel, and the on-demand characteristicof reactive mode could effectively reduce the generationof control packets transmission and mitigate the trafficchannel usage so as to free more traffic channel capac-ity for data transmission. On the contrary, when the inputtraffic load is low, PM modes lead to faster response totransmission requests.

In case of medium-traffic load situation, the MN’s vicin-ity density level and mobility level are taken into con-sideration to determine the MN’s behavior. The MN mayoperate in a moderate proactive mode (i.e., PM2) if itsvicinity density level is low (< V_TH) or if its mobilitylevel is high. In contrast, the MN may operate in a leastproactive mode (i.e., PM3) when the vicinity density levelis high and the mobility level is low.

When the vicinity density level is high, the MN hasmany neighbors around it. It switches to an RM to reducecongestion while still guaranteeing fast response to trans-mission requests as the on-demand building of transmis-sion paths will converge quickly because of the availabilityof links.

For the consideration of a node’s mobility level, whenthe mobility level is high, topology changes occur morefrequently; that is, link breaks and link repairs will hap-pen more often. In such a case, more proactiveness leads tobetter performances because the MNs can be much moreacquainted with topology information. Thus, with efficientand timely topology information, more accurate routingcan be realized.

With the aforementioned considerations, we choose theleast proactive mode, PM3, in high vicinity density and lowmobility level scenario. Otherwise, a moderate proactivemode PM2 is used.

In terms of complexity, the protocol’s operation isstraightforward as the proposed algorithm has no built-inrepetitive or loop statements. The execution is performedperiodically checking all the possible environmental con-ditions and checking the current state and the course ofactions needed.

3.3. The finite-state machine design of thePolymorphic Unicast Routing Protocol

We seek a formal specification to describe our pro-posed PURP protocol using a finite-state machine (FSM).Figure 1 shows the FSM design describing our PURPprotocol operation. The e’s denote events, the m’s denotemethods to perform along with system-state transitions,and the T’s denote timers used in the protocol. The ini-tial state is by default PM1. For instance, the node movesto state PM2 following the reception or occurrence of theevents ‘e8’ (i.e., when traffic load has been changed tomedium while mobility is high or vicinity density is low).Following that a notification of mode change is sent toits neighbors. The node in state PM2 moves to state PM3



e5/m5

e5/m5e5/m5

e7/m5e6/m5

e10/m5, e13/m5e11/m5, e12/m5

e6/m5

e8/m5

e7/m5

e9/m5

e7/m5

e8/m5

e6/m5

e9/m5

e1: Route establishment request or a new/received packet ready to transmit/forwarde2: Neighbour's mode change indication packet receivede3: T3 expirede4: Neighbour's routing table receivede5: T5 expirede6: Traffic load changed to low levele7: Traffic load changed to high levele8: Traffic load changed to medium level when mobility level is high or vicinity level is lowe9: Traffic load changed to medium level when mobility level is low and vicinity level is highe10: Vicinity level changed from high to low when mobility level is low and traffic load is mediume11: Vicinity level changed from low to high when mobility level is low and traffic load is mediume12: Mobility level changed from high to low when vicinity level is high and traffic load is mediume13: Mobility level changed from low to high when vicinity level is high and traffic load is medium

m1: Establish the route or transmit the new/received packetm2: Update routing table according to the received neighbour's mode change indication packetm3: Reset T3 and broadcast its routing tablem4: Reset T5 and update routing table according to the received neighbour's routing tablem5: Send mode change indication packet

T3: Routing table broadcast timerT5: Neighbour's routing table received timer

PM1e6

e1

PM2e1

e8

RMe1

e7

PM3e9

e1

e3/m3e2/m2 e4/m4e3/m3e2/m2 e4/m4

e3/m3e2/m2 e4/m4 e3/m3e2/m2 e4/m4

Figure 1. Finite-state machine diagram of the Polymorphic Unicast Routing Protocol. PM, proactive mode; RM, reactive mode.

following the reception or occurrence of the events ‘e9’(i.e., when traffic load has been changed to medium whilemobility is low or vicinity density is high. Again an ‘m5’notification of mode change needs to be sent to the neigh-bors). The move from PM1 to RM is triggered by theoccurrence of the events ‘e5’ (expiration of T5) or ‘e7’(when traffic load becomes high). In all cases, a notifica-tion is sent to the neighbors. The other mode changes canbe analyzed in the same way.

3.4. Routing issues

The detailed implementation of each of the four behavioralmodes is given as follows. As stated earlier, the PURPis built using the proactive behavior of the ZRP and thereactive behavior of the AODV. In addition, the protocolis augmented with the multipoint relay (MPR)-based opti-mization mechanism of the Optimized Link State Rout-ing (OLSR) [23]. This is carried out with the objectiveof reducing the amount of control packets forwarded. We

describe next its proactive and reactive behaviors, as wellas the adopted optimized forwarding mechanism.

3.4.1. Routing tables and identifiers.

Each MN maintains two routing tables. One routingtable, which is called forwarding table (FT), containsentries about the route to each destination. Each entry inFT has the following fields: destination address, destinationsequence number, next hop address, and lifetime.

The other routing table, which is called reverse pathtable (RPT), maintains the reverse path information withinthe path finding procedure. Each entry in RPT containsthe following fields: destination address, source address,source sequence number, broadcast id, expiration time forreverse path and last hop.

Each MN also maintains a monotonically increasingsequence number. Such a sequence number is used to extin-guish the stale routing information in the routing table andto prevent loops. The detailed usage of the routing tablesand identifiers are described as follows.



3.4.2. Proactive behavior.

When an MN is in either of the three proactive modes, itsends out periodically update packets that has a TTL set tothe zone radius. The update packets contain the FT of thisMN. When an MN receives an update packet, it updates itsFT. If the MN already has an entry that has the same desti-nation address with the information from the update pack-ets, it compares the destination sequence number in thetwo entries. If the sequence number in the update packetis greater than the one in the FT, the MN updates its corre-sponding entry, replaces the destination sequence numberin the FT with the one received in the update packet, setsthe next hop address field to the address from which theupdate packet is received, and refreshes the lifetime. Ifthe update packet contains an entry that does not exist inthe FT, the MN inserts such entry into the FT and replacesthe next hop address field to the address from which theupdate packet is received. After updating the FT, if the MNis in the MPR set, it reduces the TTL by 1 and forwardsthe packet.

3.4.3. Reactive behavior.

The reactive behavior is similar to the behavior ofAODV. When an MN has packets to send to a destination,it first looks up its routing table to see whether it alreadyhas a route to it. If found, it simply sends the data to theMN through the next hop field. If not, the source MN gen-erates a route request (RREQ) packet with the followingfields: source address, source sequence number, destina-tion address, destination sequence number, broadcast ID,and hop count. The two fields, source address and sourcesequence number, uniquely identify the RREQ. The broad-cast ID is incremented whenever the source generates anew RREQ. The source MN broadcasts this RREQ to allits neighbors.

On receiving an RREQ, an MN first looks up in its RPT.If there is an entry that has the same source address andbroadcast ID, it means that the MN received a redundantRREQ, and it drops it. Otherwise, the MN looks up inits FT to see whether it has some information to the des-tination. If it finds that it has an entry to the destinationand the destination sequence number is greater than theone in the RREQ, the MN generates a route reply (RREP)to the source MN. If not, the MN updates its RPT usingthe information in the RREQ, sets the last hop field tothe address from which the RREQ is received and thenforwards the RREQ.

Eventually, a RREQ reaches an MN that possesses aroute to the destination. The MN then generates an RREPwith the following information: source address, destinationaddress, destination sequence number, hop count, and life-time. The RREP is sent through the reverse path to reachthe source MN that builds up the route.

On receiving the RREP, an MN updates its FT to insertthe information received. The next hop field is set to theMN from which the RREP is received. An MN propa-gates the first RREP received for the same source MN. If

multiple RREPs are received, the RREP with the greatestdestination sequence number is processed. If two or morehave the same sequence number the one that has the small-est hop count will be used. The processing includes updat-ing the FT and forwarding it according to the RPT. Then,when the source MN receives the RREP, it can begin datatransmission. Later, it can update its routing information ifa better route is discovered.

When a link break is detected, the upstream MN ofthe break generates a unique RREP with a fresh destina-tion sequence number and a hop count field that is set tounlimited. Then, the MN propagates the RREP to all activeupstream neighbors. Those MNs subsequently relay thismessage to all active source MNs. When the source MNreceives such RREP, it can restart a path-finding proce-dure if it still needs the route to the destination. The newpath-finding procedure is the same as described earlier.

Figure 2 depicts the flowchart summarizing the routingbehavior specific of the PURP described earlier.

4. SIMULATION AND SENSITIVITYANALYSIS

We first validate our algorithm through simulation to eval-uate the performance with fixed behaviors and scenarios.After that, we perform a simulation-based comparison ofthe performance of the PURP against the AODV, DynamicSource Routing (DSR), ZRP, and the OLSR.

The rationale of comparing our proposed protocolagainst the aforementioned ones is that careful analysis ofthe protocols discussed here or available in the literaturereveals that many of them (not all) are using derivatives orvariants of the AODV and DSR and the likes.

Furthermore, as discussed earlier, the genericity of theprotocol makes it open to the combination of several reac-tive, proactive, hybrid, or others types of protocols thatwould empower the proposed protocol with a polymor-phic behavior that suits the intrinsic dynamic behaviorof VANETs.

4.1. Simulation scenarios

The simulation of the aforementioned protocols was imple-mented using the GLOMOSIM (CS Department of UCLA,Los Angeles, USA) library [24]. Two parameters, R andi , were pre-configured for the PURP, where R denotes thezone radius (in number of hops) and i a tuning factor usedfor determining the update interval and lifetime of tableentries.

Mobile nodes are placed randomly in a 5000 m by5000 m area. The radio propagation range for each MNis set at 225 m, and the channel operates at 2 Mbps. Thepopular IEEE 802.11b MAC is used as the wireless trans-mission technology at the link level. The traffic load is aconstant bit rate (CBR), and the size of the data packet isset to the typically used 512 bytes.



Listen

Is DEST inFT?

RREQdetected

BroadcastRREQ

Update RPT

No

Forward RREQ,Send RREP

based on RPT

Is a RREQwith samesource in

RPT?

RREP detected

No

IsDEST in

FT?

New PKTgenerated

No

Listennode =source?

Yes

Forward RREPbased on RPTand setup FT

No

Forward PKT

Yes Is DEST inFT?

PKTReceived

Yes

Yes

Update FT

UD_PKT detected

Yes

No

PKT: PacketUD_PKT: Update PacketDEST: DestinationFT: Forwarding TableRPT: Rerverse Path Table

Listennode =DEST?

Process PKT

No

Yes

Figure 2. Flowchart of the Polymorphic Unicast Routing Protocol. RREQ, route request; RREP, route reply.

A CBR traffic model was used in order to simulateextreme traffic intensities when needed so that the resultswould be applicable in extreme situations.

In all simulations, the Manhattan mobility model[25–27] was adopted and used. This model uses a grid roadtopology. It was proposed for the movement in urban area,where the streets are in an organized manner.

We have chosen the Manhattan mobility model over theFreeway [28] model (suitable for freeway mobility pat-terns) because the former allows to check and experimentbetter the conditions of high traffic intensity, high vicin-ity density, and high speed (sometimes, when permitted)that is provided better by the Manhattan mobility modeland that will ensure relatively frequent change of behav-ioral mode by the PURP. We could have used the CitySection Mobility [28,29]; however, with regards to the abil-ity of testing the polymorphic behavior of the PURP, we areexpecting comparable results to the case when the Man-hattan mobility model is used, as it is the closest mobilitymodel to it. Moreover, as a matter of fact, we do expect thatany mobility model used will benefit from the polymor-phic behavior in a different way than others, and this has todo with the ability of the mobility patterns experienced bythe MNs to trigger mode switches that will reflect directly

on the performance. We are prospecting these extensiveexperimentations as a future extension of the current work.

In our simulation experiments, the total area is dividedinto a 25 � 25 grid, and each MN can only move alonggrid lines. Each grid line runs two lanes in different direc-tions. At the intersection of the grid line, the direction goeseither to the left or right. We use 0.5, 0.25, and 0.25 asthe probabilities for an MN to move forward, turn left, orright, respectively.

Each MN has a time interval with the lengths from 1to 10 s; at the end of the time interval, the MN changesits speed. For example, if the maximum speed is n forthe system, and the current speed is v, the speed of MNfor the next time interval is taken randomly and uniformlyfrom v � 0:1n to v C 0:1n. In addition, the newly chosenspeed is bounded by .0; n�. We have a pre-defined valueof Safe_Distance; when the distance of two MNs, whichare within the same lane and have the same direction, issmaller than the Safe_Distance, the trailing MN shouldmodify its speed so as not to exceed the foregoing MN.In other words, we do not consider overtaking. We have setthe Safe_Distance value to 100 m.

Figure 3 depicts a layout of the grid according to whichthe MNs move along the grid lines. It illustrates the grid



Figure 3. Grid layout for moving mobile nodes.

lines followed by moving vehicles and the correspondingtransmission ranges of each of them and how they overlapand create a dense area (with high vicinity density).

For the performance measures, we evaluate the deliv-ery ratio, end-to-end delay, and overhead against mobilityspeed, network traffic load, and the total number of MNs.

4.2. Sensitivity analysis

4.2.1. Protocol validation.

In the protocol validation simulation, we have definedtwo different simulation settings. In the first one, we forcethe MNs to stay in either PM1 or RM mode with thetraffic load level set to high (50 packets/s), medium (30packets/s), or low (10 packets/s). There are 1000 MNs uni-formly spread within the defined area. The MN mobilityspeed varies from 20 to 80 km/h.

Figures 4 and 5 show the result of this simulation.Figure 4(a) depicts the deliverability ratio, and Figure 4(b)depicts the average end-to-end delay for different trafficlevels against mobility. Figure 5(a) depicts deliverabilityratio, and Figure 5(b) depicts average end-to-end delay

for a medium traffic and various mobility levels versusnetwork size.

We can observe in Figure 4(a) that PM1 outperforms RMin terms of deliverability when the traffic load level is lowand slightly when it is medium, whereas, in high trafficload scenario, RM achieves better deliverability.

However, in Figure 4(b), in terms of end-to-end delay,PM1 mode exhibits superior performance than that ofthe RM mode for low and medium traffic levels andlooses the ground in case of high traffic loads. This comesfrom the fact that, in high load, the PM1 mode generatesmore overhead traffic that affects the deliverability and thedelay negatively. It can also be noticed that the mobilityspeed does not affect the performance of both types ofmodes considerably.

In the second simulation set, we force the MNs tostay in PM1 or RM while maintaining a medium traf-fic load (30 packets/s), and varying the mobility levelbetween high (80 km/h) and low (20 km/h), correspondingto urban driving speeds in modern cities. The total numberof MNs within the defined area varies from 400 to 1600.Figure 5(a,b) shows the results of this simulation. We canobserve that, in terms of deliverability, PM1 outperformslargely the RM, up until a high level of vicinity density.This superiority of the PM1 mode is also reflected on theresults on the end-to-end delay (Figure 5(b)).

In addition, a clear trend in the curves show an increasein good performance up to a certain level of vicinity den-sity, above which a decrease in performance is noticed.This testifies that, for each setting, there is an optimal levelof vicinity density that gives the best performance and suitsthe choice of the protocols parameters.

The last observation that we can draw from these resultsis that high mobility speed affects negatively any opera-tional mode of the protocol, which is a clear confirmationof an expected result.

4.2.2. Mobility speed.

In this scenario, 1000 MNs were uniformly spreadwithin the defined area. The MN mobility speed varies

0.4

0.5

0.6

0.7

0.8

0.9

1

20 30 40 50 60 70 80

Del

iver

y R

atio

(%

)

Mobility Speed (m/s)

RM High LoadPM1 High Load

RM Medium LoadPM1 Medium Load

RM Low LoadPM1 Low Load

(a) Delivery ratio for different traffic load levels

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

20 30 40 50 60 70 80Ave

rage

End

-to-

end

Del

ay (1

0-1s)


RM High Load

PM1 High Load

RM Medium Load

PM1 Medium Load

RM Low Load

PM1 Low Load

(b) Average End-to-end delay for different traffic load levels

Figure 4. Protocol performances for different modes versus Mobility. PM, proactive mode; RM, reactive mode.



0.84

0.845

0.85

0.855

0.86

0.865

400 600 800 1000 1200 1400 1600

Del

iver

y R

atio

(%

)

Number of nodes

RM Medium Load High SpeedPM1 Medium Load High Speed

RM Medium Load Low SpeedPM1 Medium Load Low Speed

(a) Delivery ratio for medium traffic & various mobility levels

0.58

0.6

0.62

0.64

0.66

0.68

0.7

0.72

0.74

400 600 800 1000 1200 1400 1600Ave

rag

e E

nd

-to

-en

d D

elay

(10

-1s)

Number of nodes

RM Medium Load High SpeedPM1 Medium Load High Speed

RM Medium Load Low SpeedPM1 Medium Load Low Speed

(b) Average End-to-end delay for medium traffic & various mobility levels

Figure 5. Protocol performances for different modes versus number of nodes. PM, proactive mode; RM, reactive mode.

from 20 to 80 km/h. The traffic load is set to 20 packets/s,and 100 source MNs were simulated.

Our focus here is on the sensitivity of the mobility to var-ious performance parameters. Figure 6(a–c) respectivelyshows the delivery ratio, the average end-to-end delay, andthe control overhead packets versus the mobility speed.From the results, we see that the PURP protocol tops the

other peer protocols protocols for the delivery ratio with arelatively low end-to-end delay.

The polymorphic behavior of PURP is indicated inFigure 6(c) where PURP adjusts its mode during opera-tion, which generates control packets lesser than that of theproactive routing protocol but more than that of the reactiverouting protocols. Note that although the control packets

0.86

0.87

0.88

0.89

0.9

0.91

0.92

0.93

20 30 40 50 60 70 80

Del

iver

y R

atio

(%

)


PURPAODV

DSROLSR

ZRP

(a) Delivery ratio versus mobility speed

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

20 30 40 50 60 70 80Ave

rag

e E

nd

-to

-en

d D

elay

(10

-1s)


PURPAODV

DSROLSR

ZRP

(b) End-to-end delay versus mobility speed

2.4

2.6

2.8

3

3.2

3.4

3.6

3.8

4

4.2

4.4

20 30 40 50 60 70 80

Co

ntr

ol p

acke

ts/D

ata

pac

kets


PURPAODV

DSROLSR

ZRP

(c) Control overhead versus mobility speed

Figure 6. Protocol performances versus mobility speed. PURP, Polymorphic Unicast Routing Protocol; AODV, Ad hoc On-demandDistance Vector; DSR, Dynamic Source Routing; OLSR, Optimized Link State Routing; ZRP, Zone Routing Protocol.



per data packet of PURP is higher than those of reactiverouting protocols due to its proactive mode, the proactivemode occurs when the channel is lightly loaded; hence,it does not cause a negative impact on the performance,which is clearly shown in Figure 6(a,b).

4.2.3. Mobile nodes’ vicinity density.

The total number of MNs within the defined area variesfrom 400 to 1600. Each MN moves constantly with a pre-defined speed of 40 km/h. The traffic load is 20 packets/s.Again, in this scenario, we use 100 source MNs.

Figure 7 plots delivery ratio, end-to-end delay, andcontrol overhead of all considered protocols against thenetwork size. As shown in Figure 7(a–c), again, PURPoutperforms other protocols in almost all situations. Pre-cisely, PURP gives the highest delivery ratios among allwith low end-to-end delay. There is only a small range ofvicinity density level where OLSR has slightly lower end-to-end delay. This is because OLSR is a pure proactiveprotocol, with a certain number of MNs when the rout-ing information can be well maintained; the packet deliverycan be performed with the least time; hence, OLSR givesthe lowest end-to-end delay in that region. However, asthe number of MNs increases, bandwidth usage for the

control packet transmission increases dropping the datapacket transmission opportunity, and thus, the end-to-enddelay for OLSR increases.

The switching between proactive and reactive modesresults in a moderate control packet transmission as indi-cated in Figure 7(c) where PURP transmits more (less)control packets than that of the reactive (proactive) rout-ing protocols.

4.2.4. Network traffic load.

This experiment studies the effect of network traffic loadon the performance. We consider 1000 MNs distributedwithin the defined area. The number of sent packets rangesbetween 1 and 60 packets/s. Each MN moves constantlywith a predefined speed of 40 km/h. The same setting of100 source MNs applies in this scenario.

Figure 8(a) shows the delivery ratio against traffic load,and Figure 8(b) shows the average end-to-end delay versustraffic load. As can be seen from the figures, all protocolsperform similarly in this experiment. However, for compar-ison, PURP performs better than other protocols althoughslightly. This is because PURP is based on the imple-mentation of other protocols, with slight modifications;hence, PURP shares some performance limitation of those

0.87

0.88

0.89

0.9

0.91

0.92

0.93

0.94

400 600 800 1000 1200 1400 1600

Del

iver

y R

atio

(%

)

Number of nodes

PURPAODV

DSROLSR

ZRP

(a) Delivery ratio versus number of nodes

0.4

0.5

0.6

0.7

0.8

0.9

400 600 800 1000 1200 1400 1600Ave

rag

e E

nd

-to

-en

d D

elay

(10

-1s)

Number of nodes

PURPAODV

DSROLSR

ZRP

(b) End-to-end delay versus number of nodes

2

2.5

3

3.5

4

4.5

5

400 600 800 1000 1200 1400 1600

Co

ntr

ol p

acke

ts/D

ata

pac

kets

Number of Nodes

PURPAODV

DSROLSR

ZRP

(c) Control overhead versus number of nodes

Figure 7. Protocol performances versus number of nodes. PURP, Polymorphic Unicast Routing Protocol; AODV, Ad hoc On-demandDistance Vector; DSR, Dynamic Source Routing; OLSR, Optimized Link State Routing; ZRP, Zone Routing Protocol.



0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50 60

Del

iver

y R

atio

(%

)

Network Traffic Load (packets/sec)

PURPAODV

DSROLSR

ZRP

(a) Delivery ratio versus network traffic load

0

0.5

1

1.5

2

2.5

3

0 10 20 30 40 50 60Ave

rag

e E

nd

-to

-en

d D

elay

(10

-1s)

Network Traffic Load (packets/sec)

PURPAODV

DSROLSR

ZRP

(b) End-to-end delay versus network traffic load

Figure 8. Protocol performances versus network traffic load. PURP, Polymorphic Unicast Routing Protocol; AODV, Ad hoc On-demandDistance Vector; DSR, Dynamic Source Routing; OLSR, Optimized Link State Routing; ZRP, Zone Routing Protocol.

protocols. In this case, little performance gain is resultedfrom applying the polymorphic behavior, especially inpresence of heavy network traffic load.

5. CONCLUSION

We have presented a novel routing protocol suitable fordynamic, multi-constrained wireless networks (mostly adhoc). In the design of our protocol, we propose to empowerit with several, carefully studied behavioral modes thatenables the MNs to choose the right mode of operationthat suits the current environmental factors/situation thatwill help achieve the best performance with regard tospecific metrics.

The proposed PURP protocol was vested with a poly-morphic routing behavior, that is, a behavior with mul-tiple forms of operations. This made the routing processdynamic, adaptive, and able to react to multiple exterioror interior stimuli in order to better respond to routingrequests.

We have made some simulations of the PURP and con-trasted its performance with some of its peers. Results ofthe simulation showed how the PURP outperformed itspeers in most cases. This also shows the effectiveness ofthe proposed design.

Finally, for our proposed PURP protocol, we do notclaim that the combination of the AODV and ZRP-basedreactive and proactive behaviors is in any way idealistic,but rather, it is illustrative and concept proving.

REFERENCES

1. Leontiadis I, Mascolo C. Geopps: geographical oppor-tunistic routing for vehicular networks. In IEEEWorkshop on Autonomic and Opportunistic Commu-nications (Colocated With WOWMOM07), Helsinki,Finland, June 2007.

2. Banerjee N, Corner MD, Levine BN. An energy-efficient architecture for DTN throwboxes. In IEEEInfocom 2007 International Conference, 2007;776–784.

3. Sandulescu G, Nadjm-Tehrani S. Opportunistic DTNrouting with window-aware adaptive replication. InAsian Internet Engineering Conference (AINTEC),18–20 November, November 2008.

4. Mnaouer AB, Chen L, Foh CH, Tantra JW. A newpolymorphic multicast routing protocol for MANETs.In IEEE International Conference on Communications(ICC), Seoul, South Korea, May 2005.

5. Mnaouer AB, Chen L, Foh CH, Tantra JW. TheOPHMR: an optimized polymorphic hybrid multicastrouting protocol for MANET. IEEE Transaction onMobile Computing May 2007; 6(5): 551–562.

6. Qiao C, Mei Y, Yoo M, Zhang Z. Polymorphiccontrol for cost-effective design of optical networks.European Transactions on Telecommunications (ETT)2000; 11(1): 17–26.

7. Miguel ID, Monroy IT, Gonzalez JC. Nature-inspiredrouting and wavelength assignment algorithms foroptical circuit-switched polymorphic networks. Fiberand Integrated Optics 2004; 23: 157–170.

8. Belghith A, Mnaouer AB, Idoudi H. Polymorphic rout-ing using proactive and probabilistic approaches forMANETs. In Proceedings of the 1st InternationalWorkshop on Future Trends on Design and Analysis ofDynamic Networks (FTDA-DN08), in conjunction withQshine, July 31st 2008.

9. Haas ZJ, Pearlman MR. The Zone Routing Protocol(ZRP) for ad hoc networks. Internet Draft, draft-ietf-manet-zone-zrp-02.txt, June 1999.

10. Perkins CE, Belding-Royer EM, Das SR. Ad hocon-demand distance vector (AODV) routing. InternetDraft, draft-ietf-manet-aodv-13.txt, February 2003.



11. Samar P, Pearlman MR, Haas ZJ. Independent zonerouting: an adaptive hybrid routing framework for adhoc wireless networks. IEEE/ACM Transactions onNetworking 2004; 12(4): 595–608.

12. Lee SJ, Gerla M. AODV-BR: Backup routing in ad hocnetworks. In Proceeding of ieee wireless communica-tions and networking conference (WCNC), 2000.

13. Belghith A, Idoudi H, Molnar M. Proactive proba-bilistic routing in mobile ad hoc networks. In Pro-ceedings of the International Conference on WirelessNetworks, ICWN ’08, Las Vegas, USA, 2008. July14–17, 2008.

14. Lochert C, Hartenstein H, Tian J, Fubler H,Herrmann D, Mauve M. A routing strategy for vehic-ular ad hoc networks in city environments. In IEEEIntelligent Vehicles Symposium (IV 2003), Columbus,Ohio, June 2003.

15. Burgess J, Gallagher B, Jensen D, Levine BN.MaxProp: routing for vehicle-based disruption-tolerantnetworks. In INFOCOM 2006, 25th IEEE Inter-national Conference on Computer Communications,Barcelona, Spain, April 2006.

16. Kihl M, Sichitiu M, Ekeroth T, Rozenberg M.Reliable geographical multicast routing in vehicularad-hoc networks. In 5th International Conference onWired/Wireless Internet Communications, May 2007.

17. Sun W, Yamaguchi H, Yukimasa K, Kusumoto S.GVGrid: a QoS routing protocol for vehicular adhoc networks. In 14th IEEE Workshop on Quality ofService, June 2006.

18. Naumov V, Gross TR. Connectivity-aware routing(CAR) in vehicular ad-hoc networks. In 26th IEEEInternational Conference on Computer Communica-tion (INFOCOM), Anchorage, Alaska, May 2007.

19. Hinsberger A, Wieker H, Riegelhuth G, Zurlinden H.Benefits and technology of an intelligent road side unitsystem for vehicle to infrastructure and infrastructureto centre communication. In Proceedings of the 14thWorld Congress and Exhibition on ITS, Beijing, China,9–13 October 2007.

20. Kleinrock L, Silvester JA. Optimum transmission radiifor packet radio networks or why six is a magic num-ber. In Proceedings of the IEEE National Telecommu-nications Conference, 1978.

21. Takagi H, Kleinrock L. Optimal transmission rangesfor randomly distributed packet radio terminals. IEEETransactions on Communications 1984; 32: 246–257.

22. Hou T, Li V. Transmission range control in mul-tihop packet radio networks. IEEE Transactions onCommunications 1986; 34: 38–44.

23. Clausen T, Jacquet P. Optimized link state routingprotocol. Internet Draft, draft-ietf-manet-olsr-11.txt,January 2003.

24. UCLA Computer Science Department Parallel Com-puting Laboratory and Wireless Adaptive MobilityLaboratory, “GloMoSim: A Scalable Simulation Envi-ronment for Wireless and Wired Network Systems”.http://pcl.cs.ucla.edu/projects/glomosim/.

25. Bai F, Sadagopan N, Helmy A. IMPORTANT: aframework to systematically analyze the impact ofmobility on performance of routing protocols foradhoc networks. In INFOCOM, 2003.

26. Sadagopan N, Bai F, Krishnamachari B, Helmy A.Paths: analysis of path duration statistics and theirimpact on reactive MANET routing protocols. In Pro-ceedings of the 4th ACM international Symposium onMobile Ad Hoc Networking and Computing, 2003.

27. Bai F, Sadagopan N, Helmy A. User manualfor important mobility tool generators in NS-2simulator. http://nile.usc.edu/important/mobility-user-manual.pdf.

28. Djenouri D, Soualhi W, Nekka E. VANET’s mobilitymodels and overtaking: an overview. In 3rd Interna-tional Conference on Information and CommunicationTechnologies (ICTTA), Anchorage, UK, April 2008;1–6.

29. Davies V. Evaluating mobility models within an ad hocnetwork, Colorado School of Mines, Colorado, USA,2000.

AUTHORS’ BIOGRAPHIES

Adel Ben Mnaouer received his BScdegree in Computer Science from the‘Ecole Supérieure des communica-tions (SUP’COM)’ of Tunisia in 1985and the Meng and PhD degrees inElectrical and Computer Engineer-ing from the University of Fukuiand from Yokohama National Uni-versity, Japan, in 1993 and 1997,

respectively. From 1997 to 2010, he served as an aca-demic staff of several universities such as YokohamaNational University (1997–1999), CS dept of SultanQaboos University, Oman (1999–2002), School of Com-puter Engineering at Nanyang Technological Univer-sity, Singapore, (2002–2005), the ‘Ecole Supérieure deTechnologie et d’Informatique’, 7th November univer-sity, Tunisia (2005–2008). Dr. Ben Mnaouer served in theCentre of Information and Communication technologies ofthe University of Trinidad and Tobago (UTT) as an asso-ciate professor (2008–2010). Since September 2010, heis an associate professor with the College of ComputerEngineering and Information Technology of Dar Al UloomUniversity, Saudi Arabia.

His research interests are in the areas of protocoldesign and analysis of wired and wireless (4G, MANETs,



VANETs, Sensor and Mobile) networking and in clusterand grid computing. He has served/has been serving inthe TPC of scores of international conferences, such as theIEEE ICC, GLOBECOM, LCN, and WCNC. He organizedand chaired workshops, and technical sessions in severalinternational conferences. He offers regular peer reviewservices to several international journals on computer sci-ence and networking. Dr. Ben Mnaouer is a senior memberof the IEEE Communication Society.

Chuan Heng Foh (S00M03) receivedthe BS degree in Electronic Engi-neering from Fu Jen Catholic Univer-sity, Taipei Hsien, Taiwan, in 1992,the MS degree from Monash Uni-versity, Victoria, Australia, in 1999,and the PhD degree from the Uni-versity of Melbourne, Australia, in

2002. From July 2002 to December 2002, he was a lecturerat Monash University. He is currently an assistant profes-sor with the School of Computer Engineering, NanyangTechnological University, Singapore. His research inter-ests include protocol design and performance analysis ofmobile wireless and optical networks. He is a member ofthe IEEE.

Chen Lei received the BEng degreefrom the School of Information Sci-ence and Technology at Nankai Uni-versity, Tianjin, China, in 2002, andhis PhD degree in Computer Engi-neering, from Nanyang TechnologicalUniversity (NTU), Singapore 2009.His research interests include multi-cast routing protocols for MANET,

polymorphic routing algorithms, and mobility estimationfor MNs. He is a student member of the IEEE.


A Generic Polymorphic Unicast Routing Protocol for vehicular ad hoc networks

Documents

Transcript of A Generic Polymorphic Unicast Routing Protocol for vehicular ad hoc networks