VARON: Vehicular Ad hoc Route Optimisation for NEMO

www.elsevier.com/locate/comcom

Computer Communications 30 (2007) 1765–1784

VARON: Vehicular Ad hoc Route Optimisation for NEMO q,qq

Carlos J. Bernardos a,*, Ignacio Soto a, Marıa Calderon a,Fernando Boavida b, Arturo Azcorra a

a Universidad Carlos III de Madrid Avda. Universidad 30, 28911 Leganes, Spainb University of Coimbra Polo II, 3030-290 Coimbra, Portugal

Received 3 July 2006; received in revised form 9 February 2007; accepted 12 February 2007Available online 20 February 2007

Abstract

In this paper, we analyse the provision of enhanced communications between vehicles. It is expected that vehicles will have severalcommunication devices, and that a specialised node will provide external connectivity to these devices, i.e., the devices in the vehicle forma Mobile Network. We propose the use of Network Mobility communication solutions for providing access from the vehicles to an infra-structured network (e.g., the Internet) or for communication with other vehicles. The main contribution of this paper consists in a routeoptimisation solution for mobile networks – based on the use of mixed ad hoc and infrastructure communications – that enables inter-vehicle communications to be improved in terms of bandwidth and delay. The mechanism provides the same level of security thantoday’s IPv4 Internet, by means of reusing Mobile IPv6 security concepts, and the use of public key cryptography and CryptographicallyGenerated Addresses. The proposed solution is characterised and evaluated through extensive simulation, showing that it provides anefficient optimisation in vehicular communications.� 2007 Elsevier B.V. All rights reserved.

Keywords: Inter-vehicular communications; Network mobility; VANET; NEMO; Route optimisation

1. Introduction

Many people in modern societies spend a considerableamount of time in cars. Up to now, vehicular communica-tions have been mainly restricted to cellular communica-tion networks. Enabling broader communication facilities

0140-3664/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2007.02.011

q This work has been partly supported by the Spanish Governmentunder the POSEIDON (TSI2006-12507-C03-01) and IMPROVISA(TSI2005-07384-C03) projects.qq The work described in this paper is also partially based on results ofIST FP6 Integrated Project DAIDALOS II. DAIDALOS II receivesresearch funding from the European Community’s Sixth FrameworkProgramme. Apart from this, the European Commission has no respon-sibility for the content of this paper. The information in this document isprovided as is and no guarantee or warranty is given that the informationis fit for any particular purpose. The user thereof uses the information atits sole risk and liability.

* Corresponding author. Tel.: +34 916 246 236; fax: +34 916 248 749.E-mail addresses: [email protected] (C.J. Bernardos), [email protected]

(I. Soto), [email protected] (M. Calderon), [email protected] (F.Boavida), [email protected] (A. Azcorra).

in cars is an important contribution to the global trendtowards ubiquitous communications [1]. Vehicles shouldprovide access to the Internet and also communicationamong themselves, supporting new services andapplications.

Examples of services and applications (see Fig. 1) thatare of interest for automobile users are personal communi-cation services, Internet access services, vehicular specificservices such as traffic information or car diagnosis activi-ties, entertainment services, and broadcast/multicast ser-vices. The provision of these services and applications ina vehicular scenario poses some challenges that require tobe solved, mainly related to mobility management andsecurity.

It is expected that several devices within a vehicle willlikely benefit from having Internet connectivity (the so-called car-to-Internet scenario): internal sensors, on-boardcomputers, infotainment back-seat boards, etc.; but alsoexternal devices, such as laptops or PDAs, carried by pas-sengers. Therefore, our architectural assumption is that

mailto:[email protected]





Fig. 1. Some examples of applications and services in a vehicular scenario.

1 http://www.drive-thru-internet.org/.

1766 C.J. Bernardos et al. / Computer Communications 30 (2007) 1765–1784

networks will be deployed in cars, with specialised devices(Mobile Routers) providing nodes of these networks withthe external communication access. A Mobile Router, asit will be described later, not only provides connectivityto the network deployed in the car, but also manages trans-parently the mobility of the whole network, without putt-ing any additional requirements on the devices attachedto the mobile network. Since it is expected that in forth-coming 4G networks multiple access technologies will beavailable, Mobile Routers will benefit from this heteroge-neity by having more than one network interface (e.g.,GPRS/UMTS, WLAN and Bluetooth, among others),allowing the Mobile Router to forward the traffic throughthe most appropriate interface. As an example, in vehicularenvironments, the use of additional WLAN interfaces mayallow the creation of multi-hop ad hoc networks by severalvehicles, to optimise local (car-to-car) communications.

Besides the Internet access, there are several applicationswhich involve a vehicle-to-vehicle communication. Thiskind of scenario may be supported by using NetworkMobility solutions, so cars can communicate through thefixed infrastructure but, in this case, when the cars are closeenough, a further optimisation is possible, namely to com-municate directly using an ad hoc network. In this way,better bandwidth than the one in the communicationthrough the infrastructure can be achieved. Typically, thiswill be true even if we use a NEMO Route Optimisationsolution for the communication through the fixed Internet.The reason is that, although the number of hops can besimilar, the communication with the infrastructure will typ-ically use a technology with lower bandwidth (for example,UMTS) than the ad hoc network (for example, WLAN).Also, the ad hoc route will probably result in lower costs.

This paper presents a Route Optimisation solutioncalled Vehicular Ad hoc Route Optimisation for NEMO

(VARON). VARON allows local car-to-car communica-tions to be optimised, by enabling – in a secure way – theuse of a Vehicular Ad hoc Network (VANET) for localcommunications among cars (instead of using the infra-structure). In VARON, communications security in thead hoc network is provided through use of the infrastruc-ture, guarantying that the peer available through the adhoc network is the same that the one through the infra-structure. Besides, the robustness of VARON against adhoc routing attacks is build on the hop-by-hop authentica-tion and message integrity of routing messages, and the useof Cryptographically Generated Addresses. However, thisinvolves a performance cost, since cryptographic opera-tions, such as signature generation/verification, consumetime and energy. This cost could be of some concern, spe-cially in energy and resource constrained devices. However,in the case of Mobile Routers deployed in cars, this is not abig issue, since vehicles have a powerful and rechargeablesource of energy.

The remainder of this paper is organised as follows. Abrief summary of the background and related work is pro-vided in Section 2. Section 3 describes the security exploitsthat may appear in vehicular ad hoc car-to-car optimisa-tions. Our route optimisation mechanism for vehicularenvironments, VARON, is described in detail in Section4. Section 5 evaluates VARON through simulations.Finally, Section 6 concludes the paper.

2. Background and related work

This section summarises some of the concepts, terminol-ogy and related protocols that are used through the paper,and the related work and motivation for optimisationmechanisms in inter-vehicle communication scenarios.

2.1. Enabling internet connectivity in automobiles: Network

mobility

Fig. 2 shows an example of a vehicular scenario, thatinvolves both communications between nodes inside a vehi-cle and the Internet, also called car-to-Internet communica-tions (addressed in this section), and communicationsamong vehicles, called car-to-car communications(addressed in Section 2.2).

There are several approaches that may be used to enableInternet access from automobiles. Initially, only cellularradio technologies were taken into account [2]. Morerecently, with the success of the IEEE 802.11 WLAN tech-nology, it is being investigated how to overcome the limita-tions of existing cellular radio networks (e.g., cost, lowbandwidth, high delay, etc.), by making use of this technol-ogy and multi-hop ad hoc protocols. As an example, theDrive-thru Internet project1 proposed an architecture basedon the deployment of several roadside IEEE 802.11 Access

http://www.drive-thru-internet.org/

Fig. 2. Vehicular communications scenario.

C.J. Bernardos et al. / Computer Communications 30 (2007) 1765–1784 1767

Points (APs) to enable Internet access from passing-by vehi-cles. One of the challenges posed by this architecture is thatthere could exist ‘‘holes’’ in the connectivity, that would pre-vent vehicles from communicating. In [3], a solution to mit-igate this problem of intermittent connectivity is proposed,by means of a mechanism based on application gatewaysand proxies. Another drawback of this kind of solution isthat it does not support transparent mobility among differenttechnologies (e.g., a handover from WLAN to UMTS whenno WLAN APs are available). The ability to switch amongdifferent access networks is critical for future 4Gdeployments.

Vehicular communication scenarios involve groups ofdevices moving together, so it seems more appropriate touse a network mobility approach [4], instead of host centricsolutions, that would force each device within a car to man-age its own connectivity to the Internet (including all theissues related to mobility).

The Network Mobility (NEMO) Basic Support protocol[5], proposed by the IETF,2 extends the basic end-hostmobility solution, Mobile IPv6 [6], to provide networkmobility support. In this solution, a mobile network(known also as Network that Moves – NEMO3) is definedas a network whose attachment point to the Internet varieswith time. The router within the NEMO that connects tothe Internet is called the Mobile Router (MR). It isassumed that the NEMO has a Home Network, connectedto the Internet, where it resides when it is not moving. Since

2 http://www.ietf.org/.3 NEMO can mean NEtwork MObility or NEtwork that MOves

according to the context.

the NEMO is part of the Home Network, the Mobile Net-work Nodes (MNNs) have configured addresses belongingto one or more address blocks assigned to the Home Net-work: the Mobile Network Prefixes (MNPs). Theseaddresses remain assigned to the NEMO even when it isaway from home. Of course, these addresses only havetopological meaning when the NEMO is at home. Thus,when the NEMO is away from home, packets addressedto the Mobile Network Nodes will still be routed to theHome Network. Additionally, when the NEMO is con-nected to a visited network, the MR acquires an addressfrom the visited network, called the Care-of Address(CoA), where the routing architecture can deliver packetswithout any additional mechanism.

The goal of the network mobility support mechanisms[7] is to preserve established communications between theMNNs and their external Correspondent Nodes (CNs)despite movement. Packets of such communications willbe addressed to the MNNs’ addresses, which belong tothe MNP, so an additional mechanism to forward packetsbetween the Home Network and the NEMO is defined.The basic solution for network mobility support [5] essen-tially creates a bidirectional tunnel between a special nodelocated in the Home Network of the NEMO, called theHome Agent (HA), and the Care-of Address of the MR(see Fig. 3).

The NEMO Basic Support protocol [5] has the follow-ing limitations:

• It forces suboptimal routing, i.e., packets are always for-warded through the HA, following a suboptimal pathand therefore adding a delay in the packet delivery.

http://www.ietf.org/

Fig. 3. NEMO Basic Support protocol operation overview.


• It introduces non-negligible packet overhead, reducingthe Path MTU (PMTU). Specifically, an additionalIPv6 header (40 bytes) is added to every packet becauseof the MR–HA bidirectional tunnel.

• The HA becomes a bottleneck for the communication aswell as a potential single point of failure. Even with adirect path available between an MNN and a CN, ifthe HA (or the path between the CN and the HA orbetween the HA and the MR) is not available, the com-munication is disrupted.

These problems are exacerbated when consideringnested mobility (i.e., a mobile network gains connectivitythrough other mobile networks), since in this case the pack-ets are forwarded through all the HAs of the upper levelmobile networks involved.

Because of these limitations, it is highly desirable toprovide what has been called Route Optimisation (RO)support for NEMO [8], to enable direct packet exchangebetween a CN (that is, any communication peer on theInternet) and a Mobile Network Node (MNN), avoidingtraversing the Home Network. There exist severalNEMO RO proposals [9,10] that eliminate or mitigatethe aforementioned problems, although many of themrequire changes in the operation (i.e., upgrading the soft-ware) of CNs and/or MNNs and/or HAs. Furthermore,the additional load that may be required to perform newmobility functionalities to support a NEMO Route Opti-misation mechanism, may be too high for certain deviceswithin a car (e.g., sensors), because of their limitedcapabilities.

MIRON [11] is a proposal of a solution for RouteOptimisation that does not require upgrades in CNs,MNNs, or HAs. MIRON has two modes of operation:

• The MR performs all the Route Optimisation tasks onbehalf of those nodes that are not mobility capable –thus working as a Proxy MR [9].

• An additional mechanism, based on PANA [12] andDHCP [13], to support mobility-capable hosts (i.e.,Mobile Nodes attached to a NEMO) and routers (i.e.,nested Mobile Routers) that actually have mobilityand Route Optimisation capabilities to manage theirown Route Optimisation.

2.2. Optimising car-to-car communications

There exist several vehicular applications, such asmulti-player gaming, instant messaging, traffic informa-tion or emergency services, that might involve communi-cations among vehicles that are relatively close eachother (i.e., car-to-car communications) and may evenmove together (e.g., military convoys). These applica-tions are currently not well supported in vehicularscenarios.

Although automobiles can communicate with othervehicles through the infrastructure (the Internet) by meansof the NEMO Basic Support protocol, they could benefitfrom better bandwidth, delay and, most probably, cheapercommunication, by forming vehicular ad hoc networks(VANETs) and making use of the resulting multi-hopnetwork to directly communicate with each other. The


challenge is to achieve this direct communication throughthe VANET with a security level equivalent to the one pro-vided by today’s IPv4 fixed Internet.

VARON enables to optimise car-to-car communica-tions in a secure way by combining a Network Mobilityapproach – used to support car-to-Internet communica-tions – with a vehicular ad hoc approach – used whencommunication occurs between vehicles that are closeenough to communicate through an ad hoc networkformed by the Mobile Routers deployed within thosevehicles, and perhaps within other vehicles in theirsurroundings.

To the best of our knowledge, there is only one pro-posal, described in [14], that also proposes the combina-tion of NEMO and ad hoc approaches. The proposedmechanism in [14] assumes that each vehicle is a movingnetwork and the performance of inter-vehicular communi-cations is improved by creating and using a VANET. TheNEMO Basic Support protocol [5] is responsible for theprovision of global Internet connectivity to the movingnetwork, whereas an ad hoc routing protocol is runamong the Mobile Routers, creating an overlay VANETfor inter mobile networks connectivity. This schemeenables direct communication between cars’ devices thatbelong to the same overlay VANET (direct route),whereas the NEMO Basic Support protocol is used other-wise (nemo route). The problem with [14] is that it doesnot deal with the security aspects of the solution, andsecurity is a critical issue for the feasibility of these kindof solutions.

Security is one of the main issues of this kind ofsolution in car-to-car environments, since the use ofad hoc communications could enable malicious nodesto perform several types of attacks [15], such as stealingtraffic or flooding a particular node. Next sectiondescribes the security challenges posed by the use ofan ad hoc solution for direct car-to-car communications,summarising and classifying the attacks that VARONaims at avoiding. As it will be explained in more detailin Section 4, VARON benefits from the simultaneousreachability of vehicles through the infrastructure andthe ad hoc network to secure the communications inthe ad hoc part.

3. Exploits against vehicular ad hoc car-to-car optimisations

By using a Vehicular Ad hoc Network to route packetsof a local car-to-car communication, the performance ofthe communications in such a kind of scenario may begreatly improved – in terms of bandwidth and delay –when compared to data traversing an infrastructured net-work through a cellular radio network (e.g., UMTS).However, this kind of optimisation enables many differenttypes of attacks. In this section, we briefly describe somerelevant examples of attacks that would be possible if noadditional mechanisms were used to secure this optimisa-

tion. This would help us introducing all the security prob-lems that our proposal – VARON (described in Section 4)– avoids.

There are several types of attacks that may be performedagainst a vehicular ad hoc car-to-car optimisation. Next,we describe the most relevant ones:

• Prefix ownership attacks. Devices within a vehicle form amobile network, sharing a prefix (the Mobile NetworkPrefix), which is managed by the Mobile Router of thevehicle. It is necessary to provide Mobile Routers witha mechanism that enables them to mutually verify thata Mobile Router actually manages the Mobile NetworkPrefix it claims to (i.e., it is authorised to forward/receive packets addressed from/to that MNP). Other-wise, a malicious node would be allowed to spoof(‘‘steal’’) a certain prefix and get all the traffic addressedto this prefix from other MRs connected to the ad hocnetwork.

• Ad hoc routing attacks. The creation and maintenance ofthe ad hoc routes to locally exchange traffic betweenMRs connected to the VANET, is a critical issue fromthe security point of view. This task is performed byad hoc routing protocols, which still suffer from a lotof vulnerabilities, mainly due to the unmanaged andnon-centralised nature of ad hoc networks. Typicalexploits against existing ad hoc routing protocols maybe classified into the following categories [16]:Æ Modification attacks. A malicious node can cause redi-rection of data traffic or Denial-of-Service (DoS) atta-cks by introducing changes in routing control packetsor by forwarding routing messages with falsified values.As an example of this attack, a malicious node M couldprevent a legitimate node A from receiving traffic froma node B by advertising a shorter route to B than theone that the true next hop towards A advertises.

Æ Impersonation attacks. A malicious node can spoof theIP address of a legitimate node, and therefore steal itsidentity, and then perform this attack combined with amodification attack. The main problem of these attacksis that it is difficult to trace them back to the maliciousnode.

Æ Fabrication attacks. A malicious node can create andsend false routing messages. This kind of attack canbe difficult to detect, since is not easy to verify that aparticular routing message is invalid, specially when itclaims that a neighbour cannot be reached.

Some ad hoc secure protocols make impossible to per-form some of these exploits (such as ARAN [16]). How-ever, there is no mechanism that combines in a secureway a Network Mobility approach, to deal with the issueof vehicular global connectivity, and a Vehicular Ad hocNetwork, to optimise local car-to-car communications.By security, we mean a mechanism that is not vulnerablein the previously described ways.

4 Another example could be a car A from an emergency service convoycommunicating with another emergency car B.


4. Vehicular Ad hoc Route Optimisation for NEMO

(VARON)

In this section, we present a novel solution that providesRoute Optimisation for NEMO in vehicular environments,where a Vehicular Ad hoc Network (VANET) may besecurely created and used to optimise local communica-tions among vehicles.

It is assumed that the Mobile Router (MR) deployed ineach vehicle will have at least three network interfaces: oneor more ingress interfaces to communicate with the nodesinside the vehicle that belong to the NEMO (e.g., WLAN,Bluetooth), one or more egress interfaces to connect to theInternet (e.g., UMTS, WiMAX, even WLAN in somecases), and an additional ad hoc interface (e.g., WLAN)to communicate with neighbouring cars and set-up multi-hop networks (see Fig. 2). Compared with a normal MobileRouter (without any ad hoc optimisation), only one (adhoc) additional interface is required. It is important tonotice that Mobile Routers deployed in vehicles will notbe much concerned about energy or processing constraints,as opposed to personal mobile devices or other ad hoc sce-narios (such as sensor networks).

It is also assumed that vehicle’s devices will be always ableto communicate with other vehicle’s devices through theInternet, by using the NEMO Basic Support protocol. Onthe other hand, there may exist the possibility of enablingthese devices to directly communicate if a multi-hop vehicularad hoc network could be set-up by the involved vehicles andother neighbouring cars. VARON aims at making possible tobenefit from this optimisation opportunity in a secure way.

In our proposal, VARON, the MR is the node in chargeof performing the optimisation of the communications.The steps for carrying out this procedure are the following:

(1) Discovery of reachable MNPs. The MR needs to findout which other MRs are available within theVANET, that is, which Mobile Network Prefixesare reachable through its ad hoc interface.

(2) Creation of a secure ad hoc route between the MRs ofthe mobile networks that want to optimise the routethey are using to exchange traffic. The ad hoc routingprotocol used to create this route should provide cer-tain security guarantees making impossible to per-form any of the exploits described in Section 3. Themechanism used by VARON to set-up and maintaina secure ad hoc route is based on ARAN (Authenti-cated Routing for Ad hoc Networks) [16], modifiedand extended to fulfil the requirements of our Net-work Mobility based vehicular scenario.

Next, we describe in detail these two steps.

4.1. Discovery of reachable MNPs

Every MR announces its Mobile Network Prefix(MNP) by periodically broadcasting – through the ad hoc

interface – a message, called Home Address Advertisement

(HoAA), that contains its Home Address and an associatedlifetime, to allow this information to expire. These mes-sages are announced through the ad hoc interface, by usinga hop-limited flooding, so every MR becomes aware of theMNPs that can be reached through the VANET.

The MR’s HoA is chosen to belong to the NEMO’sMobile Network Prefix. The length of the MNP is fixedto 64 bits (/64) due to security reasons that will beexplained later. Hence, the MNP can be inferred directlyfrom the HoA (it is the network part of it). With theMRs’ announcements, every MR is aware of all theMR’s HoAs (and associated Mobile Network Prefixes) thatare available within the ad hoc network.

4.2. Creation of a secure ad hoc route

4.2.1. Building the ad hoc route

In case a Mobile Router detects that there is an ongoingcommunication between a node attached to it and a nodeattached to another MR that is available through theVANET and this communication is decided to be opti-mised (how this decision is taken is out of the scope of thispaper), the MR needs to build a multi-hop route to sendpackets directly through the ad hoc network.

An example (Fig. 4) is used to illustrate in more detailthe proposed mechanism. A device (e.g., a back-seatembedded video game system) in car A is communicatingwith another device in car B.4 This communication is ini-tially being forwarded through the Internet, following thesuboptimal path determined by the NEMO Basic Supportprotocol, thus traversing Home Networks A and B beforebeing delivered to the destination. We call this route Home

Route. By listening to the announcements received in the adhoc interface, MR A becomes aware that the destination ofsuch communication may be also reachable through aVANET formed by neighbouring VARON enabled vehi-cles. Then, MR A may decide to start using the vehicularad hoc network to route this traffic, instead of sending itthrough the Internet.

The first step in this optimisation process is that MR Amust learn and set-up a bidirectional route through thevehicular ad hoc network to MR B (the MR claiming tomanage MNP B). We call this route Care-of Route. Fordoing this, MR A (the originator MR) sends – throughits ad hoc interface – a Care-of Route Test Init (CoRTI)message (Table 1 summarises our notation) to its one-hop neighbours:

A! one-hop neighbours :

½CoRTI;HoAB;NA;HoAA;KAþ�KA�

This message includes, besides the identifier of the message(CoRTI), the final destination MR’s HoA (HoAB), a nonce

Fig. 4. Care-of Route discovery and validation.

Table 1Table of variables and notation

KA+ Public Key (and CGA related information) of MR AKA� Private Key of MR A½d�KA�

Data d digitally signed by MR ANA Nonce issued by MR AHoAA Home Address of MR ACoRTI Care-of Route Test Init message typeCoRT Care-of Route Test message typeCoRE Care-of Route Error message type


NA (to uniquely identify a CoRTI message coming from asource; every time an MR initiates a route discovery, it in-creases the nonce), the IP address of MR A (HoAA) and itspublic key (KA+), all signed with the MR A’s private key(KA�). When an MR receives through its ad hoc interfacea CoRTI message, it sets up a reverse route back to HoAA

(MR A’s HoA), by recording the MR from which it re-ceived the message (so it knows how to send a reply in caseit receives a message that has to be sent back to HoAA). Inorder to authenticate the message, a mechanism that se-curely binds the IP address of MR A (HoAA) with KA+ isneeded. One possibility is to use certificates issued by athird trusted party, as proposed in ARAN [16], but thissolution seems unfeasible for vehicular environments. In-stead, this secure binding is obtained by using a special typeof addresses: Cryptographically Generated Addresses(CGAs) [17].

Cryptographically Generated Addresses (CGAs) arebasically IPv6 addresses for which the interface identifieris generated by computing a cryptographic one-way hashfunction from a public key and the IPv6 prefix.5 The bind-ing between the public key and the address can be verifiedby re-computing the hash function and comparing theresult with the interface identifier (see Fig. 5). In thisway, if the HoA used by MRs is a CGA, a secure bindingbetween the MR’s HoA and the MR’s public key is pro-vided, without requiring any Public Key Infrastructure(PKI) to be available. Notice that by itself, CGAs do not

5 There are additional parameters that are also used to build a CGA, inorder to enhance privacy, recover from address collision and make brute-force attacks unfeasible. We intentionally skip these details. The interestedreader may refer to [17] for the complete procedure of CGA generation.

provide any guarantee of prefix ownership, since any nodecan create a CGA from any particular Mobile NetworkPrefix by using its own public-private key pair. But a nodecannot spoof the CGA that another node is legitimatelyusing, because it does not have the private key associatedwith the public key of that IP address.

A receiving MR (e.g., MR X in Fig. 4) uses MR A’spublic key (included in the message) to validate the signa-ture, then appends its own public key (KX+) to the message,and signs it using its private key (KX�). The signature pre-vents spoofing or message modification attacks, that mayalter the route or form loops. Then, it forwards the CoRTImessage:

X ! one-hop neighbours :

½½CoRTI;HoAB;NA;HoAA;KAþ�KA�;KXþ�KX�

Upon receiving this CoRTI message from neighbour MRX, MR Y verifies the signatures from the originator MRA and the neighbour MR X, stores the received nonce toavoid reply attacks and adds a route to HoAA throughHoAX (MR X). Then, the signature and public key of the

MOBILE NETWORK PREFIX (64 bits) CGA INTERFACE IDENTIFIER (64 bits)

NETWORKPREFIX

MOBILEPUBLIC KEY

Hash function

Fig. 5. Simplified overview of CGA creation and structure.


neighbour MR X are removed, and MR Y appends its ownpublic key, signs the message, and forwards it:

Y ! one-hop neighbours :

½½CoRTI;HoAB;NA;HoAA;KAþ�KA�;KYþ�KY�

This last step is repeated by any intermediate node alongthe path until the CoRTI message reaches the destination(the target MR, MR B) or the allowed hop limit expires.Notice that MR B, after receiving the CoRTI message,has the guarantee that only the node that has the privatekey associated with HoAA (KA�) could have sent the CoR-TI message.

Once MR B receives the CoRTI message, it generates areply message (including the received nonce NA), calledCare-of Route Test (CoRT), and unicasts it back followingthe previously learnt reverse path to the originator(MR A):

B! Y :

½CoRT;HoAA;N A;HoAB;KBþ�KB�

Each node in the reverse path performs a procedure similarto the one performed forwarding the CoRTI: the first MRin the reverse path that forwards the message (i.e., MR Y)verifies the signature and, if correct, adds its public keyKY+, signs the message and sends it to the next MR inthe path:

Y ! X :

½½CoRT;HoAA;NA;HoAB;KBþ�KB�;KYþ�KY�

MR X also sets up a reverse route back to MR B’s HoA byrecording the MR from which it received the message.

The remaining MRs in the reverse multi-hop route,when receiving the CoRT message, verify the signature ofthe previous MR, remove it and the associated publickey, add their public key, sign the message, forward it tothe next MR, and set-up the reverse route. In the example,when MR X receives the message from MR Y, it sends thefollowing to MR A:

X ! A :

½½CoRT;HoAA;NA;HoAB;KBþ�KB�;KXþ�KX�

When the originator MR (MR A in the example) receives theCoRT message, it verifies the signature and nonce returnedby the destination MR (MR B). Once this procedure is com-pleted, MR B has successfully established a route with MR Awithin the multi-hop vehicular ad hoc network. This route isbasically a temporal path (Care-of Route) to reach MR B’sHoA, additional to the default route that MR A may alwaysuse to send packets towards MR B (through the Internet,using the Home Route), and vice-versa.

4.2.2. Authenticating the Care-of Route

The Care-of Route cannot be used to forward packetsbetween NEMO A and NEMO B yet, since it has not beenproved either that MR A manages MNP A, or that MR Bmanages MNP B. Only the validity of a route to a node (Band A) with an address (HoAB and HoAA) for which thenode has the respective private key has been proved toMR A and MR B. It has not been verified that MR Aand MR B are actually the routers authorised to manageMNP A and MNP B, respectively. Without further verifi-cation, nothing could prevent an MR from stealing amobile network’s traffic. For example, a malicious nodecould be able to claim the ownership of a given IP address(an address belonging to MNP A) and steal packetsaddressed to that prefix (MNP A). This issue is similar tothat of Route Optimisation in Mobile IPv6, where a mech-anism is required to enable the Mobile Node to prove thatit owns both the Care-of Address and the Home Address.

The Return Routability procedure defined for MobileIPv6 is based on two messages sent by the CN, one sentto the Mobile Node’s Home Address and the other toMobile Node’s Care-of Address. Based on the content ofthe received messages, the Mobile Node sends a messageto the Correspondent Node [6,15]. By properly authenticat-ing the message, this procedure is enough to prove that theMobile Node has received both messages and therefore ithas been assigned (that is, owns) both the Home Addressand the Care-of Address at that time.

In VARON, we borrow from the Return Routability(RR) procedure some of the underlying security concepts.With the RR, the Correspondent Node is provided witha mechanism to verify that a Mobile Node is able to send


and receive packets from two different addresses. InVARON, what is needed is to provide a pair of end-pointMRs (which are communicating with each other throughthe Home Route) with a mechanism to verify that themulti-hop route within the VANET connects each of themwith the same network (the respective MNP) that each MRcan reach through the infrastructure when communicatingwith any address within the MNP of the other MR. In thisway, the two end-point MRs may choose to use that Care-of Route instead of the Home Route.

The essence of the Care-of Route authentication proce-dure in VARON is that the two end-point MRs involved ina particular Route Optimisation procedure request eachother to verify that the VANET Care-of Route may beused to send traffic between the two NEMOs. This is done(see Fig. 6) as follows:

• Each Mobile Router generates a key, Kmr, which can beused with any other MR. In addition, the MR generatesnonces at regular intervals. These nonces6 and Kmr willbe used to generate a security association between thetwo end-points MRs.

• Each MR creates two tokens and sends each of themthrough one of the possible routes (Care-of and Homeroutes). Tokens are generated from Kmr and a particularnonce.

• The first part of the Care-of Route authentication proce-dure is done at the same time – and using the same mes-sages – as the Care-of Route setup (described in Section4.2.1). The first token, called Care-of keygen token, issent piggybacked in the CoRTI message, plus a Care-

of cookie, and the index of the nonce used to generatethe token. The correspondent MR replies in the CoRTmessage, including its own Care-of keygen token, itsnonce index and copying the cookie received in theCoRTI message.

• The second token, called Home keygen token, is sent,plus a Home cookie and a nonce index, in a separatemessage, called Home Route Test (HoRT), through theMR–HA tunnel (protected by IPsec ESP in tunnelmode) configured by the NEMO Basic Support proto-col, using the routing infrastructure. In order to verifythat the correspondent MR is actually managing theIPv6 network prefix it claims to, that is, the Mobile Net-work Prefix assigned to the NEMO, the HoRT messageis sent to a random address within the MNP. The MRthat manages the prefix has to intercept7 that messagetherefore showing that it actually manages the MNP.8

6 Note that these nonces are different from the ones used during the adhoc route discovery and setup procedure.

7 It is not required the MR to continuously examine every receivedpacket in order to intercept HoRT messages. The MR may start inspectingpackets after sending (or receiving) a CoRT message.

8 This test does not guarantee that a node manages a certain prefix, butthat this node is at least in the path toward that prefix. This provides thesolution with a similar security level that today’s IPv4 Internet has.

The Mobile Network Prefix length used by VARONMRs is fixed to 64 bits (/64), in order to avoid a mali-cious node to ‘‘steal’’ a prefix. Otherwise, for instance,if an MR was assigned a /64 prefix, then with probabil-ity 1/2 it could try to spoof a /63 prefix (and steal its‘‘neighbours’’ packets). By fixing the MNP length, thisattack is no longer feasible.

As in the case of the Care-of Route test, the correspon-dent MR replies this message with another HoRT mes-sage, including its own Home keygen token and nonceindex, and copying the received cookie.

• Each MR uses the received Home and Care-of keygentokens to create a key, Kbm, that can be used to authen-ticate a Mobile Network Prefix Binding Update

(MNPBU) message9 – sent along the Care-of Route –,that enables the other MR to check that the Mobile Net-work (MNP) reachable through the VANET (Care-ofRoute) is the one reachable through the infrastructure.This verification can be done because each MR hasthe information required to produce the key when theMNPBU is received, and therefore authenticate themessage.

At this point VARON signalling has finished. MR A hasfound out that MR B – which owns HoAB and its associ-ated private key and that is reachable through the VANET– is also capable of receiving and sending packets sent toany address from the Mobile Network Prefix (MNP) Bthrough the infrastructure. This only happens if the HAresponsible of routing packets addressed to this MNP (thatis, HA B) is forwarding to MR B those packets addressedto MNP B. HA B only would be doing that if properauthentication has taken place and MR B is authorisedto manage MNP B. The same guarantee also holds forMR B regarding MNP A and MR A.

The Care-of Route authentication mechanism per-formed in VARON, as the Return Routability proceduredefined in Mobile IPv6, implicitly assumes that the fixedrouting infrastructure is secure and trusted. As long as thisis true, the mechanism defined is appropriate to secure theMobile Network Prefix Binding Update, since it does notintroduce any new vulnerabilities that were not possiblein today’s IPv4 Internet.

Once the process has been completed, the end-pointMRs (MR A and MR B) may exchange traffic using theset-up Care-of Route within the VANET.

9 The generation of this key (Kbm) and the keygen tokens, and theauthentication of the message follow the same mechanisms that theReturn Routability procedure [6,15] and the proposal to extend it tosupport network prefixes [18]. We explicitly avoid these details to make thepaper more readable (the interested reader may refer to [6,15] foradditional information).

MR A MR B

CoRTI

CoRT

HoRT

HoRT

MNPBU

through Infrastructure (Home Route)

through VANET (Care–of Route)

HA A HA B

HoRT

HoRTHoRT

HoRT

MNPBU

Fig. 6. Care-of Route authentication signalling.


4.2.3. Optimised routing using the VANET

Once the Care-of Route authentication procedure hasfinished, all MRs involved in the creation of the ad hocroute can forward packets to the HoAs of the end-pointMRs (see an example in Fig. 7). However, only the end-point MRs have verified the association of the correspond-ing MR’ HoA and the respective MNP. Intermediate MRs(i.e., MR X and MR Y in the example) have only learnthost routes towards the Home Addresses of the two end-point MRs (i.e., HoAA and HoAB). In order to route datatraffic between cars’ nodes with addresses belonging toMNP A and MNP B, each end-point has to tunnel thepackets towards the other MR’s HoA, through theVANET route. In this way, intermediate MRs in the adhoc route just forward the packets based on the host routes(with the end-point MRs’ HoAs as destination) added totheir routing tables during the ad hoc Care-of Route crea-tion process (see Fig. 7).

The Care-of Route discovery and validation signalling isrepeated periodically, both to refresh the ad hoc routes andto avoid time-shifting attacks. If an ad hoc route becomesinvalid (for example, because it expires) or it is broken, andtraffic is received through this route, a Care-of Route Error

(CoRE) message is sent (and forwarded) by each MR in the

Fig. 7. Overview of packet ro

path to the source MR. For example, if intermediate MR Yin Fig. 7 receives data traffic from MR A addressed to MRB and the link between MR Y and the next hop towardsMR B (in this case, MR B itself) is broken, then MR Ysends a CoRE message to the next MR along the pathtowards the source MR (MR A), which is MR X, indicat-ing that there is a problem with this Care-of Route:

Y ! X :

½CoRE;HoAA;HoAB;NY ;KYþ�KY�

This message is received by MR X, which after verifyingthe authenticity of the received CoRE, signs the message,adds its public key KX+ and the signature to the message(as performed by intermediate MRs when processing andforwarding CoRTI and CoRT messages) and sends it tothe next hop towards MR A.

Y ! X :

½½CoRE;HoAA;HoAB;NY ;KYþ�KY�;KXþ�KX�

Upon reception of this error message, the source MR (MRA in the example) switches to use the Home Route forsending packets and it may start a new route discovery pro-cedure to set-up a new optimised Care-of Route within the

uting within the VANET.


VANET. To avoid DoS attacks, a CoRE message indicat-ing that a route has become invalid is only processed by anMR if the neighbour that is forwarding the message is thenext hop of this route. Otherwise, malicious nodes wouldbe able to set as invalid any Care-of Route.

There exist several possible mechanisms that can be usedto detect that a Care-of Route is no longer working. As anexample, Mobile Routers may check if the data packetsforwarded within the VANET have been correctly receivedby the next hop making use of link layer acknowledgementframes (if the MAC layer supports that). If several dataframes have not been acknowledged, this may be used asan indication that the next hop is no longer reachableand therefore the Care-of Route is broken.

4.3. Security analysis

A malicious node M could attempt several attacks tothis scheme. Basically, there are two main types of attacks:those that try to modify the routing in the VANET, andthose that try to steal a prefix. In order to modify the adhoc routing, an attacker out of the routing path could tryto alter or fabricate routing messages. Such kind of attackis not feasible because all routing messages are crypto-graphically signed. An additional attack could be to tryto impersonate a legitimate node (spoofing its IP address),but this is not possible either, since the authenticity of amessage is guaranteed by the use of CGAs and publickey cryptography. Two possible examples of these attacksare described next.

A malicious node M can try to change an alreadyestablished ad hoc route by sending a CoRTI messageto an MR X that belongs to this multi-hop route, claim-ing that M can reach a certain MR A. But X will notaccept the message if it cannot validate it with the publickey corresponding to the HoA of MR A associated withthe route. Because M cannot create that part of theCoRTI message, it can try to copy it from a real CoRTImessage previously sent by MR A, but the nonce includedwill not be greater than the one stored in MR X that isassociated with the route. Notice that a legitimate updateof the route by MR A is allowed because it knows its ownprivate key and the nonce that must be included in theCoRTI message.

A malicious node M that receives a CoRTI messagefrom an MR A could try to claim to a neighbour MR Xthat it is MR Z and not M (when sending the CoRTI mes-sage towards MR B). If MR Z is a legitimate networknode, this could mean that afterwards all the traffic willbe sent to it (DoS attack). But M will not be able to do thatbecause it does not have the private key associated with theHoA that MR Z is using.

One example of an attack based on spoofing a prefix willbe as follows. A malicious node M could create a HoAbelonging to the MNP managed by a legitimate MR A.The node M can create the HoA belonging to the MNPof MR A using its own public key so it can prove to other

nodes that it has the private key corresponding to thataddress. However, the Home Route Test will fail, so it can-not make another MR send to it the traffic addressed to theMNP of MR A. In this situation, the node M can set-up anad hoc route for its HoA (using its own private key), sincethe routes created in the VANET only define the forward-ing of packets addressed to MRs’ HoAs (see Fig. 7). There-fore, different routes for HoAs belonging to the same prefixcould coexist (although only one at most will belong tonon-malicious nodes). However, only legitimate end-pointMRs will success in performing the Home Route Testand, therefore, will be able to generate and send a validMNPBU (enabling the use of the Care-of Route). Noticethat packets sent to a legitimate IP address equal to aHoA used by a malicious node to create an ad hoc route,will reach the intended destination because they will tra-verse the ad hoc network encapsulated inside a tunnel withthe legitimate HoA.

There are some vulnerabilities and attacks that are stillpossible, resulting from the inherent nature of ad hoc net-works, such as certain Denial-of Service (DoS) – e.g., basedon non-collaborating nodes – or route discovery floodingattacks. But, notice that VARON nodes can always revertcommunications to the Home Route in case of the Care-ofRoute is not working.

5. Performance of VARON

In order to complete our discussion about the proposedsolution, an extensive simulation study was performed.Besides analysing the performance and costs of VARON,the value of some metrics using VARON are comparedto the ones obtained when plain NEMO Basic Supportprotocol [5] or MIRON [11] (as an example of a non adhoc Route Optimisation for NEMO) were used.

5.1. Computational cost

Each VARON Mobile Router must perform severalcryptographic operations (such as signing and verifying sig-natures) on each signalling message along a Care-of Route.These cryptographic operations are relatively expensive,especially when compared to the operation of the NEMOBasic Support protocol and other (insecure) ad hoc routingprotocols, that do very little (almost negligible) computa-tion per signalling message. However, it is important tonote that only the routing control messages that makethe state of the MR change or the MR perform an action(e.g., modifying the routing table, forwarding a message,etc.) are subject to signing/verifying. The signature of thoserouting messages that are discarded (e.g., because theyhave been already processed and are received again for-warded by a different MR) is not verified. Data packetsexchanged between nodes after a route has been set upare not processed by VARON either.

In order to evaluate the computational cost of VARON,several tests were conducted, measuring the raw processing

11 OPNET University Program, http://www.opnet.com/services/univer-sity/.12 VARON model has approximately 10000 lines of code.13 In the simulations, Care-of routes were marked as expired after 20 s.


time expended on each of the operations performed whenprocessing VARON routing packets for different key sizes.The cryptographic functions were implemented making useof the OpenSSL Library,10 which provides functions forgeneral purpose cryptographic tasks such as public and pri-vate key encryption/decryption and signature creation/ver-ification. The measurements were conducted in twodifferent types of devices that are likely to play the roleof a vehicular Mobile Router: a Linksys WRT54GS router(which is a small home and office broadband router,equipped with a 200 MHz processor, an IEEE 802.11gWLAN interface and an IEEE 802.3 Ethernet interfaceconnected to a VLAN capable 5-port switch) and a laptop(Intel Core-duo 2.0 GHz with 2 GB RAM).

The processing performed by an MR on VARON con-trol packets is composed of some of the following opera-tions (depending on the VARON message, not all ofthem are performed on each packet):

• CGA verif.: Verification of the CGA. If the message hasbeen forwarded by an intermediate MR, the CGAs ofboth the original sender and the forwarder have to bechecked.

• Sign. verif. 1: Verification of the signature of the senderMR.

• Sign. verif. 2: Verification of the signature of the for-warder MR (in case of the message has been forwardedby an intermediate MR).

• Sign. comp. 1: Computation of the signature by the sen-der MR when a new message is generated (e.g., aCoRTI/CoRT message).

• Sign. comp. 2: Computation of the signature by an inter-mediate MR when a message has to be forwarded (e.g.,a CoRTI/CoRT message).

Table 2 shows the results for each of the cryptographicoperations that are involved in the processing of VARONrouting messages. The processing time for the laptop andthe Linksys router were measured over three differentRSA key sizes: 512, 768, and 1024 bits. For both devices,an increase in the key size of 256 bits results in approxi-mately doubling the signature computation processing.The time required to verify a signature or a CGA is almostnegligible compared to the time required to compute signa-tures, as expected, because of the nature of public key cryp-tography. It is also interesting, although not verysurprising, the difference in processing times between thelaptop and the Linksys router. For each key size, the pro-cessing time is between 10 and 20 times slower on the rou-ter than on the laptop. The results obtained for the Linksysrouter for the 1024-bit RSA key have been used as input tothe simulations described in the next section. This will pro-vide us with more realistic results (that can be considered as

10 http://www.openssl.org/.

a lower bound on the performance if more powerfuldevices were used instead).

5.2. Simulation of VARON

We performed our simulations using OPNET.11 We sim-ulated 50 vehicles within a road. Each vehicular MR isequipped, in addition to the ingress interface (to provideconnectivity to the vehicular devices), with an emulatedUMTS egress interface (1 Mbit/s, 150 ms of average one-way delay) and an IEEE 802.11 (WLAN) interface (2Mbit/s, transmission power of 1 mW, receiver sensitivityof -95 dBm) in ad hoc mode. The UMTS interface has beenemulated because OPNET UMTS models did not properlysupport IPv6 at the time of performing the simulations.The UMTS channel has been modelled using a 1 Mbit/sWLAN 802.11b network, with an additional delay of150 ms per way. The link delay has been chosen based onprevious practical measurements [19–21]. In order toachieve global coverage, the transmission power of theWLAN nodes (MRs and the Access Point) that emulatesthe UMTS was set to 1 W. Considering the kind of analysisthat we were interested in performing, this set-up providedus with a reasonable model of a UMTS network.

The UMTS interface provides continuous Internet con-nectivity, whereas the WLAN interface enables formingmulti-hop vehicular ad hoc networks. UMTS and WLANwere chosen for the simulations because they are probablythe most realistic candidate access technologies for a vehic-ular communication scenario nowadays. However, differ-ent technologies may also be used by VARON (e.g.,IEEE 802.16e WiMAX for the MR’s egress interface),since the protocol is independent of the access technologyused by the Mobile Router.

In order to evaluate the worst case scenario, VARONwas simulated using 1024 bit RSA keys and the processingtime results shown in Table 2 for the Linksys router asinput for the simulations. All the VARON protocol, butthe detection of broken links and the generation of CoREmessages, was implemented using the OPNET simulator.12

By not implementing the detection of broken routes, aCare-of Route entry can only be removed from the IP rout-ing table of an MR when it expires.13 Hence, it may happenthat an MR tries to use a broken Care-of Route for sometime (until it expires), since MRs along the path are notable to detect a broken route and therefore they do notsend any CoRE message to the source MR – that wouldmake it stop sending the traffic through the VANET and

Expired Care-of routes are not kept in the IP routing table for 10additional seconds, so there is enough time for the Mobile Router torefresh the Care-of Route (in case there is data traffic being delivered usingthis route). These values were chosen after performing several sets ofsimulations aimed at finding good values for these parameters.

http://www.openssl.org/

http://www.opnet.com/services/university/

http://www.opnet.com/services/university/

Table 2Raw time required to perform the cryptographic operations required when processing VARON signalling packets

RSA key size (bits) Average ± Std. Dev. (ms)

CGA verif. Sign. verif. 1 Sign. verif. 2 Sign. comp. 1 Sign. comp. 2

Laptop512 0.47 ± 0.05 0.42 ± 0.05 0.40 ± 0.02 2.36 ± 0.09 2.46 ± 0.20768 0.47 ± 0.02 0.52 ± 0.04 0.52 ± 0.01 5.09 ± 0.16 5.13 ± 0.43

1024 0.59 ± 0.16 0.87 ± 0.05 0.89 ± 0.09 12.03 ± 0.27 11.94 ± 0.36

Linksys512 13.58 ± 0.07 11.06 ± 0.06 11.08 ± 0.07 45.90 ± 0.37 45.86 ± 0.28768 14.08 ± 0.93 12.72 ± 0.71 12.57 ± 0.43 79.86 ± 0.78 80.64 ± 1.31

1024 13.73 ± 0.38 14.47 ± 0.06 14.52 ± 0.08 136.61 ± 0.41 136.66 ± 0.44


revert to use the Home Route. Thus, VARON perfor-mance obtained from the simulation results is worse thanthe one that would be obtained if the protocol were com-pletely implemented.

A random delay uniformly distributed between 0 and 1second was added before forwarding a HoAA message inorder to minimise collisions. This random delay was intro-duced because it was observed that the performance whenHoAA messages were forwarded immediately after theirreception was quite poor. This is related to the 802.11MAC protocol, which does not perform a ready-to-send/clear-to-send (RTS/CTS) exchange for broadcast packets,and therefore does not prevent high probabilities of colli-sion of broadcast packets from appearing in relativelydense networks such as the simulated one (50 nodes).

In order to evaluate the performance of VARON underdifferent real-case scenarios, VARON experiments wereperformed varying the following two parameters:

(a) Vehicle speed. Different simulations were run foraverage vehicle speeds of 1, 5, 10, 20, 40, 50, 70, 90,100 and 120 km/h.14 The speed of a node is a randomvariable, uniformly distributed between 0.9v and 1.1v,where v is one of the previous mean speed values.Therefore, in each simulation, nodes have differentspeeds, but still very similar. This represents real lifescenarios, such as vehicles in a city or motorway,where the relative speed of vehicles moving in thesame direction is low.

(b) Initial vehicle density. Different simulations were runfor initial vehicle densities of 200, 100, 50, 25, 20,13.33, 10, 8, 6.67, 5, 4 and 3.33 vehicles/km.15

For each combination of the previous parameters, thirtydifferent simulations were performed, changing the speedsand initial positions of the vehicles, as well as the seed ofthe random number generator of the simulator. The fol-lowing metrics were evaluated:

14 The maximum speed limit in Spain is 120 km/h.15 This means that at the beginning of each simulation, the 50 nodes were

uniformly distributed within a road of a length of 0.25, 0.5, 1, 2, 2.5, 3.75,5, 6.25, 7.5, 10, 12.5 and 15 km, respectively, and then they started to moveat their respective speeds.

(1) Average end-to-end throughput. This is the mean TCPthroughput obtained when performing bulk file trans-fers. This evaluates the improvement in terms ofthroughput obtained when using VARON, as wellas the possible effects that the use of VARON mayhave in TCP (e.g., due to the Home M Care-of Routehandovers).

(2) Average Care-of Route acquisition latency. This is theaverage delay between the sending of a Care-of RouteTest Init packet by an originator MR for discoveringand establishing a Care-of Route to a target MR, andthe receipt of the Mobile Network Prefix BindingUpdate message that makes the MR add a Care-ofRoute entry to its IP routing table. This includesthe delays of the signalling messages sent throughthe VANET (CoRTI, CoRT and MNPBU), the pro-cessing time due to the cryptographic operations per-formed on each routing message and the delay due tothe use of the infrastructure (Home Route) to sendHoRT messages.

(3) Average Care-of Route length. This is the averagelength of the Care-of Route discovered and set-up by VARON. It is calculated by averaging thenumber of hops taken by MNPBU messages toreach their destination (the path followed by anMNPBU message is the same that the one thatdata packets sent through the VANET would fol-low afterwards).

(4) Average frequency of route changes. This is the aver-age number of Home M Care-of Route changes perminute. This evaluates the stability of the Care-ofroutes discovered by VARON.

(5) Average Care-of Route data packet fraction. This isthe fraction of delivered data packets that are sentthrough a Care-of Route. This evaluates the fractionof data traffic that is actually forwarded through anoptimised route, and therefore the likelihood of usingVARON to optimise a traffic communicationbetween two vehicles that are relatively close eachother.

(6) Average VARON signalling load (bytes). This is theratio of overhead bytes to delivered data bytes usinga Care-of Route. This metric was measured countingthe amount of VARON signalling bytes received at a


Mobile Router and the amount of data bytes receivedthrough the Care-of Route (data packets receivedthrough the Home Route were not taken intoaccount for this calculation).

(7) Average VARON signalling load (packets). Similar tothe previous metric, but a ratio of signalling packetsto data packets overhead.

On each simulation only two nodes out of the 50 werecommunicating each other. Simulations involving morenodes communicating simultaneously were also performedto validate the correct operation of the solution. Thethroughput and signalling load metrics were obtained sim-ulating a scenario in which a 2 MB file is transferred from avehicle to another, using FTP. For the rest of the metrics,the scenario consisted of a UDP VoIP flow (GSM,24.2 kbit/s, 50 packets per second) sent from a vehicle toanother.

To simulate the delay added by the use of the NEMOBasic Support protocol [5] and the traversal of the respec-tive Home Networks of the involved vehicles, an additionaldelay (one-way) of 36 ms was introduced in the infrastruc-ture network. This additional latency represents the delayrequired to go through two Home Networks located inEurope (the value was chosen based on real RTT measure-ments16 obtained from the PingER project [22]).

17 It should be recalled that in the simulations each vehicle moves with aconstant velocity, which is a random variable uniformly distributed between0.9v and 1.1v (the mean speed, v, is varied from 1 to 120 km/h). This causesthat in those scenarios where the mean speed (v) is higher, the relative speed

5.3. Simulation results

Simulation results are presented next in Figs. 8–13.Results are plotted using three-dimensional graphs, so theimpact of the vehicle density and speed on each of the sim-ulated metrics can be easily evaluated. Each data point isan average of thirty simulations run with different ran-domly generated mobility patterns (but following the con-siderations described above about speed and movementwithin a road).

Fig. 8 shows the average route acquisition latency, thatis the time taken by VARON to find and set-up a Care-ofRoute. VARON requires each MR along the path to per-form several cryptographic operations when processing acontrol packet, such as the verification and generation ofdigital signatures and CGAs. This is computationallydemanding and therefore adds additional delay to the over-all route acquisition time. Another source of latency in theroute acquisition time is the use of the infrastructure net-work (i.e., Home Route) in the Care-of Route validationprocess, that causes an additional delay – equal to thesum of the RTTs of each MR to its respective HA – inthe Care-of Route discovery time. Therefore, the routeacquisition time is higher in VARON than in other adhoc routing protocols, although in VARON this time doesnot have a direct impact on normal data packet forward-ing, as data traffic delivery is guaranteed by the use of

16 Available at http://www-iepm.slac.stanford.edu/pinger/.

the Home Route. Since an important contribution to theoverall route acquisition time comes from the crypto-graphic operations performed on each hop, this time ishigher when the vehicle density decreases, because in a lesspopulated VANET, the average number of intermediateMRs involved in a communication is higher (this will beshown later in Fig. 9). However, if the average distancebetween vehicles is too high (that is, the vehicle density isquite low), this may lead to the situation where only direct1-hop communications are possible (this explains why theroute acquisition time decreases for very low vehicledensities).

Vehicle speed has also an effect on the Care-of Routeacquisition time – although this effect is minor than thevehicle density – especially in highly populated scenarios.This effect is caused by the fact that it is more likely thatmore intermediate nodes are required to participate inthe Care-of Route in high speed scenarios, since the dis-tance between two vehicles that are communicatingincreases (because the relative speed of the vehicles ishigher than in low mobility scenarios17).

Fig. 9 shows the average Care-of Route length. Theresults shown in this graph basically confirm what has beendiscussed in the previous paragraph, that is, the strongdependency that the route acquisition time has on the num-ber of hops of the Care-of Route. Since the delay caused bythe HoRT messages traversing the infrastructure is thesame for each route, independently of its length, the costof performing cryptographic operations on each hop isan important factor in the route acquisition time. Obtainedresults show that for highly populated scenarios, two MRswithin the VANET are able to communicate directlyalmost always. For very low populated scenarios, the aver-age number of hops of a Care-of Route decreases, since it ismore difficult to establish a route within the VANET,unless the two MRs can communicate directly. Vehiclespeed also has an impact on the length of the route, at fas-ter speeds the Care-of Route length increases (the reasonfor that is the same that the one for the increment in theacquisition time explained above).

From the obtained average number of hops involvedin a Care-of Route, it may be deduced that VARON,although it is not designed to explicitly find the shortestpath in terms of number of hops, usually finds the short-est route, since the first CoRTI received at the targetMR normally travels along the shortest path (this maynot be true in situations of network congestion, wherethe fastest path may not be the shortest). Therefore,

of two moving vehicles will be also higher. For example, if v is 120 km/h, thespeed of each vehicle is uniformly distributed between 108 and 132 km/h, sothe relative velocity of two vehicles may be up to 24 km/h.

http://www-iepm.slac.stanford.edu/pinger/

11.522.533.544.555.56

1 1.5 2 2.5 3 3.5 4 4.5 5 5.5log (Initial vehicle density (vehicles/km)) 020

4060

80100

120

Vehicle speed (km/h)

11.5

22.5

33.5

44.5

55.5

6

Average Care—of Route length (# of hops)

Fig. 9. Average Care-of Route length.

11.21.41.61.822.22.42.62.833.2


4060

80100

120


11.21.41.61.8

22.22.42.62.8

33.2

Average Care—of Route acquisition latency (s)

Fig. 8. Average Care-of Route acquisition latency.


VARON seems to perform well at finding the shortestCare-of Route.

Fig. 10 shows the average frequency of route changes,that is the number of times during the lifetime of a com-munication flow that the route used to forward the pack-ets switches from a Care-of Route to the Home Route,and vice-versa. This metric is important in order to eval-uate the stability of the optimised Care-of routes.Obtained results show that the frequency of route changesgrows when the vehicle density decreases, which is anexpected behaviour, since in highly populated scenariosthe Care-of Route average length is small, so it is lessprobable that the route changes because there are lessinvolved MRs. In very low populated scenarios, the fre-quency of route changes decreases, because it is less likely

that a Care-of Route can be established and used, andtherefore the number of route changes is smaller (i.e.,most of the times traffic is forwarded through the HomeRoute).

Fig. 11 shows the average Care-of Route data packetfraction, which is the fraction of delivered packets thatare received through a Care-of Route. Therefore, this met-ric represents the likelihood of optimising the traffic byusing the VANET. Obtained results show that there aremore opportunities of optimising a communication in highpopulated scenarios and that the speed has also a smalleffect on the probability of establishing a Care-of Route(in highly mobile scenarios the probability is lower). Thisresult is also expected, since in those situations where asmall number of hops is required to communicate two

0

0.5

1

1.5

2

2.5

3


2040

6080

100120


0

0.5

1

1.5

2

2.5

3

Average frequency of route changes

Fig. 10. Average frequency of route changes.


MRs, it is easier to set-up a Care-of Route, which is, more-over, more stable.

Fig. 12 shows the average end-to-end TCP throughputobtained results.18 In order to compare the performanceobtained by VARON with other approaches, the TCPthroughput obtained with the NEMO Basic Support proto-col and MIRON are also shown. Fig. 12a shows the resultswhen VARON is enabled in the vehicles. The TCPthroughput decreases with decreasing vehicle density, sincein scenarios with low population of vehicles, it is harder toset-up a Care-of Route, longer paths (see Fig. 9) are usuallyrequired, and the configured routes have short lifetimes(see Fig. 10). As it was shown in Fig. 11, this leads to alow fraction of data traffic being sent through the VANET,and therefore the overall performance is poor. Besides, thefact of not having implemented the detection of brokenroutes has also an impact on the obtained TCP through-put, since the packet loss – that may be experienced whena route breaks until it is deleted from the IP routing table(after its expiration) – makes TCP congestion protocolreduce its transmission rate.19 Actually, for very low vehi-cle densities, the performance obtained with the NEMOBasic Support protocol (approximately 275 kbit/s, asshown in Fig. 12b) or MIRON (approximately 300 kbit/s, as shown in Fig. 12c) is better than with VARON. How-ever, obtained results show that for scenarios not so lowpopulated – as urban or even inter-urban scenarios, wherevehicles are typically distributed within roads with inter-

18 In the experiments, the following configuration was used on the nodes:a TCP receive buffer size of 87,380 bytes and the TCP Window Scaleoption enabled. This represents a standard TCP configuration nowadays(this is the default configuration of a Linux-2.6 machine).19 The retransmission threshold behaviour used in the simulations was

configured according to the TCP standard and ensuring that connectionscould not break because of excessive retransmission attempts.

vehicle distances of less than 150 m – VARON outperformsboth NEMO Basic Support protocol and MIRON. Forhigh vehicle densities (e.g., traffic jams), the TCP through-put obtained with VARON is close to 1 Mbit/s, which is agreat improvement over the non vehicular optimised proto-cols (NEMO and MIRON). This improvement is providedby VARON because of two main reasons:

• VARON enables the use of a VANET network builtusing an access technology – such as IEEE 802.11 – thattypically has more bandwidth that the access technologyused by a vehicle to connect to the Internet (e.g., GPRS/UMTS).

• VARON enables direct data packet forwarding withinthe VANET, avoiding to use the infrastructure networkand therefore reducing drastically the end-to-end delay.Since TCP performance is heavily dependent on theround trip time (RTT) between the communicationpeers, this end-to-end delay reduction contributes tothe TCP throughput improvement.

The last simulated metric was the signalling load intro-duced by VARON. Fig. 13 shows the signalling load, mea-sured both in bytes and packets. Obtained results show thatthe overhead introduced by VARON, because of periodicHoAA messages and the Care-of Route discovery, is notnegligible. VARON’s byte signalling load (shown inFig. 13a) reaches almost 70% in low populated and highspeed scenarios, although it is about 20% for the rest ofthe scenarios (e.g., urban and inter-urban). Results showthat there is a constant amount of overhead caused bythe periodic HoAA flooding, but the main contributionto this overhead comes from the Care-of Route discoveryand set-up signalling.

Although VARON’s byte signalling is not negligible, it isrelatively low in most of the scenarios. VARON’s packet

0

200

400

600

800

1000


2040

6080

100120


0

200

400

600

800

1000

Average TCP Throughput (kbit/s)

VARON

0

200

400

600

800

1000


4060

80100

120


0

200

400

600

800

1000


NEMO

0

200

400

600

800

1000


2040

6080

100120


0

200

400

600

800

1000


MIRON

a b

c

Fig. 12. Average end-to-end TCP throughput.

0102030405060708090100


4060

80100

120


0102030405060708090

100

Average Careof Route data packet fraction

Fig. 11. Average Care-of Route data packet fraction.


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7


4060

80100

120


00.10.20.30.40.50.60.7

Average routing load (# control bytes per data bytes delivered)

(bytes)

0

5

10

15

20

25

30

35


4060

80100

120


05

101520253035

Average routing load (# control packets per data packet delivered)

(packets)

a b

Fig. 13. Average VARON signalling.


overhead (shown in Fig. 13b) results show that VARONrequires a great amount of small signalling packets to work(the number of received VARON signalling packets evenreaches 35 times the number of data packets in the worst casescenario). This is caused by the periodic HoAA flooding andalso by the flooding nature of the Care-of Route discoverysignalling. Besides, the same signalling is required periodi-cally to refresh an already established route.

VARON’s overhead may seem to be very high andtherefore it may be argued that it is not a good optimisa-tion mechanism. However, there are several considerationsthat should be taken into account:

• Almost all the signalling required by VARON is sentthrough the ad hoc interface. This interface is not usedto send non optimised regular traffic and it has typicallyno cost associated. It may be argued that sending somany packets imposes a non negligible energy cost,but in vehicles this cost is not so important, since theyhave a powerful and rechargeable source of energy.On the other hand, the computational cost associatedto sending this signalling may have an impact on theoverall performance of the Mobile Router. Simulationshave taken into account the cost associated to the cryp-tographic computations performed on each packet, butforwarding a packet has also a cost, that depending onthe MR’s capabilities may be relevant.

• The VARON simulated model does not implement thedetection of broken links and the CoRE associated sig-nalling. By implementing this missing part, other config-uration parameters – such as the periodic timersinvolved in the Care-of Route discovery and refresh-ment – could be set to less aggressive values (in termsof periodicity and, therefore, associated overhead).The refreshment of a Care-of Route – through periodicCoRTI/CoRT signalling – could even be removed if the

algorithm followed to detect broken links is goodenough and ensures that all broken links can bedetected. If not, it could always be optimised, for exam-ple by not re-doing the full Care-of Route discovery pro-cess (that involves a partial flooding of the VANET),but just sending a probe packet through the establishedCare-of Route to check if it is still working.

Although graphs only display average values for the dif-ferent simulated metrics, the normalised standard deviationhas also been calculated. Obtained results show that thenormalised standard deviation is higher in the low popu-lated and high mobile scenarios than in the high populatedand low mobile scenarios, meaning that former scenariosare more unstable than the latter ones.

One important conclusion that can be drawn from thesimulation work is that in highly mobile and low populatedscenarios, it is more difficult to set-up a multi-hop routebetween two vehicles, mainly because of the instability inthe ad hoc routing. Therefore, most of the chances of com-munication involve routes with a very low number of hops.An example of communication scenario that will greatlybenefit from VARON optimisations would be that of mil-itary convoys or emergency service operations, where agroup of vehicles move together.

6. Conclusions

In this paper, we have analysed the problem of enablingcommunications from and between vehicles. A first step isthe provision of connectivity to the Internet. Cars will likelyhave specialised devices (Mobile Routers) that will providenetwork access to the rest of the devices in the car, i.e., thecar will contain a Mobile Network. For this reason we pro-pose the application of Network Mobility solutions to thisscenario. The NEMO Basic Support protocol is the straight-


forward option. The performance limitations of this scenariocan be partially overcome through the application of aNEMO Route Optimisation solution.

In this paper we have proposed VARON, a solution thatenables optimal direct vehicle-to-vehicle communication,using an ad hoc network. VARON benefits from the simul-taneous reachability of vehicles through the infrastructureand the ad hoc network to secure the communications inthe ad hoc part. Although the proposed solution doesnot preclude the possibility of performing some Denial ofService attacks, that are inherent to the ad hoc environ-ment, these attacks only affect the ad hoc route and thevehicles can always fall back on the communicationthrough the infrastructure if needed. The benefit of the pro-posed mechanism is a clear improvement in end-to-endthroughput and delay with security guarantees similar tothose available in infrastructure communications.

The proposed protocol has been validated and evaluatedthrough extensive simulation conducted with OPNET.Results show that VARON improves significantly the per-formance in terms of TCP throughput when compared toother approaches such as the use of plain NEMO Basic Sup-port protocol or a generic Route Optimisation solution forNEMO – such as MIRON – not suited for vehicular environ-ments in which cars obtain Internet access from a low-band-width and high-delay access technology (e.g., GPRS/UMTS). Simulation has also shown that in highly mobileand low populated scenarios, the probability of using theVANET to route traffic is low, because of the instability inthe ad hoc routing. Most of the opportunities of optimisedcommunication involve routes with a very low number ofhops (less than 5 hops). Hence, scenarios such as urbanand inter-urban communications (e.g., traffic jams, vehiclesin a motorway) may greatly benefit from deployingVARON, especially in the case of a group of vehicles movingtogether, such as military convoys or emergency serviceoperations. On the other hand, it is not worth using VARONin highly mobile and low populated scenarios – such as high-ways – since the probability of optimising a communicationis very low and its lifetime would be very short.

Although the paper has presented VARON as a solutionsuited for vehicular environments, its applicability is notlimited to that scenario. Actually, any scenarios involvingmobile networks that are able to set-up an ad hoc network,are good candidates for VARON deployment. For exam-ple, passengers on a train carrying their Personal Area Net-works (PANs) may be using peer-to-peer file sharing orInstant Messaging (IM) applications while travelling (e.g.,by using a PDA or laptop connected to a mobile phonewith 3G and WLAN capabilities acting as the Mobile Rou-ter). If the two users involved in the peer-to-peer communi-cation are located within the same train, their MRs maydecide to bypass the routing infrastructure and directlysend their traffic using a direct ad hoc communication.

An interesting issue that we have not analysed in thispaper is the applicability of VARON to provide RouteOptimisation in nested NEMO scenarios. Additionally,

when VARON is not used in vehicular environments, thepower consumption of the solution may be an issue, andtherefore it is interesting to study how VARON performsin battery-limited environments. We are currently workingon both topics in order to understand if VARON applica-bility can be also extended to these two scenarios.

Acknowledgements

We thank Marcelo Bagnulo, Alberto Garcıa-Martınezand Manuel Uruena for their helpful comments that con-tributed to improve VARON design.

References

[1] W. Kellerer, C. Bettstetter, C. Schwingenschlogl, P. Sties, K.-E.Steinberg, H.-J. Vogel, (Auto) Mobile communication in a heteroge-neous and converged world, IEEE Personal Communications 8 (6)(2001) 41–47.

[2] O. Andrisano, R. Verdone, M. Nakagawa, Intelligent transportationsystems: the role of third generation mobile radio networks, IEEECommunications Magazine 38 (9) (2000) 144–151.

[3] J. Ott, D. Kutscher, The ‘‘Drive-thru’’ architecture: WLAN-basedinternet access on the road, in: IEEE Vehicular Technology Confer-ence (VTC), vol. 5, 2004, pp. 2615–2622.

[4] H.-Y. Lach, C. Janneteau, A. Petrescu, Network mobility in beyond-3G, IEEE Communications Magazine 41 (7) (2003) 52–57.

[5] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert, NetworkMobility (NEMO) Basic Support Protocol, Internet Engineering TaskForce, RFC 3963 (Proposed Standard) (January 2005).

[6] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6, InternetEngineering Task Force, RFC 3775 (Proposed Standard) (June 2004).

[7] T. Ernst, Network Mobility Support Goals and Requirements,Internet Engineering Task Force, draft-ietf-nemo-requirements-06.txt (work-in-progress) (November 2006).

[8] C.-W. Ng, P. Thubert, M. Watari, F. Zhao, Network Mobility RouteOptimization Problem Statement, Internet Engineering Task Force,draft-ietf-nemo-ro-problem-statement-03.txt (work-in-progress) (Sep-tember 2006).

[9] C.-W. Ng, F. Zhao, M. Watari, P. Thubert, Network Mobility RouteOptimization Solution Space Analysis, Internet Engineering TaskForce, draft-ietf-nemo-ro-space-analysis-03.txt (work-in-progress)(September 2006).

[10] E. Perera, V. Sivaraman, A. Seneviratne, Survey on NetworkMobility Support, ACM SIGMOBILE Mobile Computing andCommunications Review 8 (2) (2004) 7–19.

[11] M. Calderon, C.J. Bernardos, M. Bagnulo, I. Soto, A. de la Oliva,Design and experimental evaluation of a route optimisation solutionfor NEMO, IEEE Journal on Selected Areas in Communications 24(9) (2006) 1702–1716.

[12] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig, A. Yegin, Protocol forCarrying Authentication for Network Access (PANA), InternetEngineering Task Force, draft-ietf-pana-pana-11.txt (work-in-pro-gress) (March 2006).

[13] R. Droms, J. Bound, B. Volz, T. Lemon, C.E. Perkins, M. Carney,Dynamic Host Configuration Protocol for IPv6 (DHCPv6), InternetEngineering Task Force, RFC 3315 (Proposed Standard) (July 2003).

[14] R. Wakikawa, H. Matsutani, R. Koodli, A. Nilsson, J. Murai, Mobilegateways for mobile ad-hoc networks with network mobility support,in: Proceedings of 4th International Conference on Networking(ICN), 2005, pp. 361–368S.

[15] P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark,Mobile IP Version 6 Route Optimization Security Design Back-ground, Internet Engineering Task Force, RFC 4225 (Informational)(December 2005).


[16] K. Sanzgiri, D. LaFlamme, B. Dahill, B.N. Levine, C. Shields,E.M. Belding-Royer, Authenticated Routing for Ad Hoc Networks,IEEE Journal On Selected Areas In Communications 23 (3) (2005)598–610.

[17] T. Aura, Cryptographically Generated Addresses (CGA), InternetEngineering Task Force, RFC 3972 (Proposed Standard) (March2005).

[18] C. Ng, J. Hirano, Extending Return Routability Procedure forNetwork Prefix (RRNP), Internet Engineering Task Force, draft-ng-nemo-rrnp-00.txt (work-in-progress) (October 2004).

[19] T. Melia, A. de la Oliva, I. Soto, C.J. Bernardos, A. Vidal,Analysis of the effect of mobile terminal speed on WLAN/3Gvertical handovers, in: Proceedings of the 2006 IEEE GlobalTelecommunications Conference (GLOBECOM), San Francisco,California USA, 2006.

[20] A. de la Oliva, T. Melia, A. Vidal, C.J. Bernardos, I. Soto, A. Banchs,A case study: IEEE 802.21 enabled mobile terminals for optimisedWLAN/3G handovers, Mobile Computing and CommunicationsReview, in press.

[21] P. Vidales, C.J. Bernardos, I. Soto, D. Cottingham, J. Baliosian, J.Crowcroft, MIPv6 experimental evaluation using overlay networks,Computer Networks, in press.

[22] W. Matthews, L. Cottrell, The PingER project: active Internetperformance monitoring for the HENP community, IEEE Commu-nications Magazine 38 (5) (2000) 130–136.

Carlos J. Bernardos received a Telecommunica-tion Engineering degree in 2003 and his Ph.D. inTelematics in 2006, both from the UniversidadCarlos III de Madrid where he has been aresearch and teaching assistant of TelematicsEngineering since 2003. He has been involved ininternational research projects related withFourth Generation networks, like the ISTMOBY DICK project, and currently ISTDAIDALOS. He is working now on IP-basedmobile communication protocols.

He has published several papers in these topics in international magazinesand conferences.

Ignacio Soto received the TelecommunicationEngineering degree in 1993, and the Ph.D. inTelecommunications in 2000, both from theUniversity of Vigo, Spain. He has been a researchand teaching assistant of Telematic Engineeringat University of Valladolid since 1993 until 1999,and at University Carlos III de Madrid since thatyear. He is an Associate Professor at UniversityCarlos III de Madrid since 2001. He has beeninvolved in international and national researchprojects related with mobility support in packet

networks, wireless networks, and advanced networks.He has published several papers in these topics in technical books, mag-
azines and conferences.
Marıa Calderon received the Computer ScienceEngineering degree and the Ph.D. degree inComputer Science from the Universidad Politec-nica de Madrid (UPM), Madrid, Spain, in 1991and 1996, respectively.She is an Associate Professor in the TelematicEngineering Department, Universidad Carlos IIIde Madrid. She has published over 20 papers inthe fields of advanced communications, reliablemulticast protocols, programmable networks,and IPv6 mobility, in outstanding magazines and

conferences, such as IEEE Network Magazine, IWAN, and IEEE-PROMS-MMNET. Some of the recent European research projects in
which she has participated are LONG, GCAP, DAIDALOS, COST-263,and E-NEXT.
Fernando Boavida received is Ph.D. in Informat-ics Engineering in 1990, and he currently is FullProfessor and President of the Department ofInformatics Engineering (DEI) of the Faculty ofSciences and Technology of the Universityof Coimbra. He is the leader of the Laboratory ofCommunications and Telematics (LCT) of DEIand the Strategic Director for Communicationsand Information Technology of the University ofCoimbra.His main research interests are Mobile and Ambi-

entNetworkingandScalableNetworking(qualityofserviceissues, largescaledistributed architectures and management). He was the chairman of the
Program Committee of QofIS’2001, IDMS-PROMS’2002, NETWORK-ING 2006 and WWIC 2007 international conferences. His publicationsinclude two books, four book chapters, and around 30 papers in nationalconferences and75 papers in international refereed journals andconferences.He participated in European initiatives/projects such as RARE, EWOS,COST263, E-NET, E-NEXT, EuQoS, WEIRD and CONTENT.
Arturo Azcorra received his TelecommunicationEngineering degree from the Universidad Polit-ecnica de Madrid in 1986 and the Doctor degreein 1989 from the same University. In 1992 hegraduated as Master in Business Administrationfrom Instituto de Empresa, the second mostprestigious Business School in Spain.He is currently full Professor at Universidad Car-los III de Madrid. He is an IEEE Senior member,an ACM-SIGCOMM member and an InternetSociety member. On March 2007 has been

appointed as Chief Scientific Advisor of the international research instituteIMDEA Networks.
He has participated in a large number of European research projects in theframe of ESPRIT, RACE, COMETT, Telematics, ACTS and IST pro-grams, having coordinated the European Networks of Excellence E-NEXTand CONTENT. He has published over 100 scientific papers in national andinternational magazines and conferences.

VARON: Vehicular Ad hoc Route Optimisation for NEMO

Documents

Transcript of VARON: Vehicular Ad hoc Route Optimisation for NEMO