Scholarly article on topic 'Design and Experimental Evaluation of a Vehicular Network Based on NEMO and MANET'

Design and Experimental Evaluation of a Vehicular Network Based on NEMO and MANET Academic research paper on "Electrical engineering, electronic engineering, information engineering"

0
0
Share paper
Keywords
{""}

Academic research paper on topic "Design and Experimental Evaluation of a Vehicular Network Based on NEMO and MANET"

Hindawi Publishing Corporation EURASIP Journal on Advances in Signal Processing Volume 2010, Article ID 656407, 18 pages doi:10.1155/2010/656407

Research Article

Design and Experimental Evaluation of a Vehicular Network Based on NEMO and MANET

Manabu Tsukada,1 Jose Santa,2 Olivier Mehani,1 Yacine Khaled,1 and Thierry Ernst1

1INRIA Paris, Rocquencourt Domaine de Voluceau Rocquencourt, B.P. 105, 78153 Le Chesnay Cedex, France 2 Department of Information and Communications Engineering, University of Murcia, Campus de Espinardo, 30100 Murcia, Spain

Correspondence should be addressed to Manabu Tsukada, manabu.tsukada@inria.fr

Received 1 December 2009; Revised 19 July 2010; Accepted 5 September 2010

Academic Editor: Hossein Pishro-Nik

Copyright © 2010 Manabu Tsukada et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Mobile Ad hoc Network (MANET) routing protocols and Network Mobility (NEMO) Basic Support are considered key technologies for vehicular networks. MANEMO, that is, the combination of MANET (for infrastructureless communications) and NEMO (for infrastructure-based communications) offers a number of benefits, such as route optimization or multihoming. With the aim of assessing the benefits of this synergy, this paper presents a policy-based solution to distribute traffic among multiple paths to improve the overall performance ofa vehicular network. An integral vehicular communication testbed has been developed to carry out field trials. First, the performance of the Optimized Link State Routing protocol (OLSR) is evaluated in a vehicular network with up to four vehicles. To analyze the impact of the vehicles' position and movement on network performances, an integrated evaluation environment called AnaVANET has been developed. Performance results have been geolocated using GPS information. Second, by switching from NEMO to MANET, routes between vehicles are optimized, and the final performance is improved in terms of latency and bandwidth. Our experimental results show that the network operation is further improved with simultaneous usage of NEMO and MANET.

1. Introduction

Terrestrial transportation is one of the most important services that support humans' daily life. Intelligent Transportation Systems (ITS) aim at enhancing road traffic safety and efficiency as well as optimizing social costs and improving drivers' comfort by providing services such as fleet management, route guidance, billing, or infotainment. These days, communication technologies are more and more considered as a key factor for ITS deployment however, new approaches are needed to integrate mobile networks in the vehicle field.

IPv6 can be a good base technology to fulfill several ITS communication requirements, thanks to its extended addressing space, embedded security, enhanced mobility support, and autoconfiguration advances. Moreover, future vehicles will embed a number of sensors and other IPv6-enabled devices [1]. A number of ITS applications can be

conceived when sensors deployed in vehicles are connected to the Internet and data collected from them is shared among vehicles and infrastructure. Since the speed and position of vehicles can be shared in real time, valuable information about traffic conditions can be inferred. For example, by reporting brake events, vehicles driving towards the affected road segment can be warned in advance and authorities can be ready for possible fatalities.

In order to deal with communication requirements of ITS applications [2], on-the-move and uninterrupted Internet connectivity is necessary. Network Mobility (NEMO) Basic Support has been specified by the IETF (Internet Engineering Task Force) NEMO Working Group [3] to provide on-the-move IP connectivity maintaining addressing configuration. NEMO is an essential part of the Communication Architecture for Communications Access for Land Mobiles (CALM)) (http://www.calm.hu/), currently being standardized at ISO [4]. The European ITS Communication

Architecture defined by COMeSafety [5] and ETSI [6] also integrates NEMO and IPv6 to provide and maintain Internet connectivity to vehicles.

Additionally, Mobile Ad hoc Networks (MANETs) can be used for vehicular communications without depending on any third-party infrastructure. Several MANET protocols have been specified by the IETF MANET Working Group. These routing protocols are classified as reactive or proactive [7], depending on whether communication routes are created when needed or they are continuously maintained. The Optimized Link State Routing (OLSR) protocol has been specified at IETF as a proactive protocol [8]. This protocol has been chosen in the present research to create a Vehicular Ad hoc Network (VANET), since it is a well-know implemented, tested, and standardized protocol in the MANET literature.

This paper describes the work done to combine NEMO and MANET/VANET in a design that distributes traffic among multiple paths to improve the overall performance of the vehicular network. A complete testbed has been developed and used to experimentally evaluate the system. The rest of the paper is organized as follows. Network technologies related to vehicle communications are summarized in Section 2. Section 3 outlines scenarios and objectives of our network platform. Our integrated evaluation environment for vehicular networks and the Linux-based implementation are described in Section 4. Experimental results are covered in the following two parts: Section 5 deals with the performance of the VANET subsystem, while Section 6 evaluates the integrated MANEMO performance, both indoor and outdoor, considering field trials of the IPv6 mobility testbed of the Anemone project [9]. Finally, Section 7 concludes the paper summarizing main results and addressing future works.

2. Network Technologies in Vehicular Communications

This section presents a brief overview of relevant networking technologies in vehicular communications. Several research fields highly related to the work described in this paper, regarding NEMO and MANET, are also introduced, such as Multihoming, Route Optimization, and MANEMO.

2.1. VANET. Vehicular Ad hoc Networks (VANET) are a particular case of MANET, but they are characterized by battery constraints free, high speed, GPS-equipped nodes, and regular distribution and movement. First, vehicles have batteries better than the ones integrated in mobile terminals or sensor devices. Moreover, they are recharged while the vehicle's engine is on. Hence, it is not necessary to take specific measures to save energy resources (e.g., avoid signaling traffic). Second, mobility conditions of road vehicles are different from the ones given in common portable terminals. The relative speed between two vehicles driving in opposite direction can reach 300 km/h. Thus, in some scenarios, the lifetime of routing entries can be extremely short. Third, GPS information can be assumed to be available in many cases,

since an increasing number of vehicles are equipped with navigation systems. Position and movement information can be used to improve network performances. Additionally, the movement and density of vehicular nodes are not random, since vehicles drive along roads. This makes the position of nodes somehow predictable.

Although there are many works related to VANET applications, as well as basic research at the physical link and network layers in vehicular communications, there is an important lack of real evaluation analysis. Many VANET solutions and protocols could be considered as nonpractical designs if they were tested in real scenarios, as it has been proved for MANETs [10]. Performance of VANET protocols based on a pure broadcast approach can be more or less predictable in simple configurations, even if not experimentally evaluated. However, the number of issues concerning real performances of multhop designs is much larger. There are works related to real evaluations of VANET designs [11, 12], and a limited literature for concrete cases of multi-hop transmissions [13], but there is an important lack on works evaluating routing protocols on VANETs. This paper details the works carried out towards easing the experimental evaluation of a multi-hop and IPv6-based vehicular network. The design covers the integration of various communication technologies to overcome common problems in VANETs, such as penetration rate or the need of Internet connectivity.

OLSR is a well-known protocol in the MANET literature. Since the application of MANET concepts in the particular VANET case is a common procedure, the results given in this paper assess how a common ad hoc proactive protocol operates under vehicular conditions. Because vehicles are not constrained by battery restrictions, one may think that a proactive protocol tuned for highly dynamic topologies could be suitable in the vehicular domain. Evaluating this idea is an interesting point in the work. Moreover, the existence of stable implementations of OLSR and its popularity among real ad hoc deployments have encouraged us to create a reference point in the VANET literature with real multi-hop experiments based on this protocol. The testbed platform presented in next sections is prepared to change the routing protocol, thus it will be extended with future implementations of pure-VANET protocols in the frame of our research on georouting [14].

2.2. NEMO. The NEMO Basic Support functionalities involve a router on the Internet to allow mobile computers to communicate with mobile or static remote nodes. The application ofNEMO in ITS is direct and it is done as follows. A Mobile Router (MR) located in the vehicle acts as a gateway for the in-vehicle Mobile Network and manages mobility on behalf of its attached nodes (Mobile Network Nodes, or MNNs for short). MR and a fixed router in the Internet, its Home Agent (HA), establish a bidirectional tunnel to each other which is used to transmit packets between the MNNs and their Correspondent Nodes (CN).

The possible configurations offered by NEMO have been classified in [15], according to three parameters: the number

Figure 1: Generic intervehicle communication scenario. Network nodes inside vehicles communicate with their peers via the VANET or through the Internet using NEMO.

Figure 2: Prototype vehicles used in the field experiments.

x of MRs in the mobile network, the number y of HAs serving the mobile network and the number z of MNPs (Mobile Network Prefixes) advertised in the mobile network. In this paper, we focus on the "single MR, single HA and single MNP" configuration, commonly called (x, y, z) = (1,1,1).

2.3. Multihoming. Mobile Routers can be shipped with multiple network interfaces such as Wi-Fi (IEEE 802.11 a/b/g and more recently 802.11 p), WiMAX (IEEE 802.16-2004/e-2005) or GPRS/UMTS. When an MR simultaneously maintains several of these interfaces up and thus has multiple paths to the Internet, it is said to be multihomed. In mobile environments, MRs often suffer from scarce bandwidth, frequent link failures and limited coverage. Multihoming brings the benefits of alleviating these issues.

NEMO Basic Support establishes a tunnel between the Home Agent's address and one Care-of Address (CoA) of the MR, even if the MR is equipped with several interfaces. In [16], it is proposed the Multiple Care-of Addresses Registration (MCoA), an extension of both Mobile IPv6 and NEMO Basic Support, to establish multiple tunnels between MRs and HAs. Each tunnel is identified by its Binding Identification Number (BID). In other words, MCoA deals with simultaneous usage of multiple interfaces.

2.4. Route Optimization. Route Optimization allows to sort the communication path between a mobile router (or a host) and a correspondent node that is not connected to the Home Agent at a concrete moment. In NEMO, all the packets to and from MNNs must be encapsulated within the tunnel between MR and HA. Thus, all packets to and from CNs must go through HA. This causes various problems and performance degradations. One could imagine the delay of using the HA tunnel when both nodes could (in the worst case) be in the same transiting network. A standardized solution for Route Optimization is still missing for NEMO Basic Support, while there exists one for Mobile IPv6 [17]. Main drawbacks of such NEMO behavior can be classified as follows.

(1) Suboptimal routes are caused by packets being forced to pass by HA. This leads to an increased delay which is undesirable for applications such as realtime multimedia streaming.

(2) Encapsulation with an additional 40-bytes header increases the size of packets and the risk of fragmentation. This results in a longer processing time for every packet being encapsulated and decapsulated both at MR and HA.

(3) Bottlenecks in HA is an important problem, since a significant amount of traffic for MNNs is aggregated at HA, particularly when it supports several MRs acting as gateways for several MNNs. This may cause congestion which would in turn lead to additional packet delays or even packet losses.

(4) Nested Mobility which occurs when a Mobile Router get attached to other Mobile Routers. This could arise, for example, when passengers carry a Personal Area Network or in scenarios where the same outbound MR is used by several vehicles. Nested Mobility further amplifies the aforementioned route suboptimality.

Figure 3: Topology of the vehicular network and Internet connectivity.

The previous route optimization issues of NEMO are identified in [18] by the IETF whereas the solution space is analyzed in [19]. Requirements for Route Optimization in various scenarios have been described for vehicle networks in [20] and for aeronautic environments in [21].

2.5. MANEMO. Both MANET and NEMO are layer-three technologies. NEMO is designed to provide global connectivity, while MANET provides direct routes in wireless local area networks. MANEMO combines both concepts to provide several benefits related to route optimization.

Since direct routes are available in MANETs, they can provide direct paths between vehicles. These paths can be optimal and free from NEMO tunnel overhead [22, 23]. Possible topology configurations with MANEMO have been described in [24], while issues and requirements have been summarized in [25]. In addition, MANEMO has already been suggested for vehicular communications. For example, VARON [26] focuses on NEMO route optimization using MANET. It also provides the same level of security as the current Internet, even if communications are done via the MANET route.

3. Scenario and Objectives

This paper focuses on the scenario of intervehicle communication shown in Figure 1. Sensors installed in the vehicle are connected to the Internet to share real-time information, and on-board computers or mobile terminals (i.e., MNNs) are connected to the mobile network within the vehicle. Vehicles are connected to the Internet everywhere and anytime with multiple interfaces using NEMO. Each MR, acting as a gateway for the mobile network, supports both NEMO and MANET connectivity.

In this paper, the focus is on investigating the operation and performance of the simultaneous usage of VANET and NEMO routes. An initial set up of a field testbed based

on four-wheeled electric vehicles was carried out, called CyCabs [27], to identify issues and requirements of real environments. This testbed helped us to prepare a feasible study considering issues such as wireless links features, connectivity changes or vehicles' movement. The experiments presented in the following sections were conducted using up to four common commercial vehicles (Citroen C3s) as depicted in Figure 2.

Among the different advantages of the developed testbed, three main capabilities can be remarked. First, apart from studying traffic flows sent through the fixed network, it is possible to evaluate VANET performances in detail using an integrated testing environment. Second, the testbed is open to develop and validate any ITS application. Third, a number of different scenarios can be tested to analyze the operation of all network layers working together.

In order to measure the network performance of a VANET, various metrics should be considered. The bandwidth, round-trip time (RTT), jitter, packet delivery ratio (PDR), and number of hops are measured for various communication types (e.g., UDP, TCP, or ICMPv6). Geographic metrics, such as speed, position and distance between cars are also collected and linked with the previous network mea-suraments. As far as authors know, there are no integrated tools that perform all this tasks at once.

Several issues arise when the previous performance measurements are collected and linked. These can be grouped in the next three classes.

(1) Path awareness. This comprises the problem of determining the route followed by packets from source to destination in a dynamic topology.

(2) Performance measurements hop-by-hop. Performance data is usually collected in an aggregate end-to-end manner by classical network analysis tools (e.g., ping6 or IPerf), but is not accessible on a per-hop basis. Hence, it is not easy to identify where packets are lost, for instance.

Experiments

Sender (UDP, TCP, ICMPv6 traffic generation)

Sender script

Iperf and ping6 logs

Tcpdump GPS log

(Optional)

Processing

Tcpdump GPS log

AnaVANET

Tcpdump GPS log

Iperf log

(Optional)

Analysis

XML statistics

Packet traces

Graphic generator

I 2 Ü 0

0 50 100 150 200 250 300 350 400 Time (seconds)

Distance between MR3 and MR2 Distance between MR2 and MR1

Figure 4: Experimental setup and data processing units.

(3) Movement awareness. The route followed by vehicles in the physical world is also an important issue to further identify the cause of network problems due to real mobility conditions.

Moreover, in preceding works [28], switching from a NEMO to a MANET route gave benefits regarding route optimization in terms of bandwidth and delay. In this paper, we also propose to distribute traffic into multiple paths to improve the global network performance. This simultaneous usage of NEMO and MANET has been experimentally evaluated within our testbed.

4. Vehicular Network Design and Testbed Architecture

Our network architecture setup is detailed in this section. First, the global architecture is introduced in Section 4.1. Sections 4.2 and 4.3 focus on describing the evaluation environment used to analyze the VANET performance and the general MANEMO architecture, respectively.

4.1. Vehicular Network Architecture. The testbed comprises a combination of vehicle-to-vehicle and infrastructure-based

Routing table

Figure 5: Classic routing. A single routing table is used, and packets are forwarded along the route with the longest matching prefix.

database Routing tables

Figure 6: Policy routing. Depending on several criteria, each packet is routed according to one of several routing tables.

networks, as Figure 3 depicts. Each vehicle is equipped with a mobile router, with at least two interfaces: an Ethernet link and an 802.11b adapter in ad hoc mode. MNNs connect to the in-vehicle network via its Ethernet interface (an internal managed Wi-Fi network could also be used for this purpose), while the ad hoc Wi-Fi interface is used for the inter-vehicle connections. In Figure 3, MR1 and MR2 are also connected to an infrastructure network using another 802.11 interface in managed mode. MR1 has an additional 3G modem to establish a second link to the Internet (PPP link provided by SFR (SFR is a french mobile telephony operator partially owned by Vodafone) ). MR1 is supported by HA1 at INRIA Rocquencourt and MR2 is supported by HA2 inside Irisa's network. Both networks are located in France and interconnected via Renater (French backbone for education and research) using a direct 6in4 tunnel to work around some IPv6 firewalling problems (the testbed sites are 12 IPv4 hops apart).

4.2. VANET Experimentation Subsystem. An experimentation tool has been designed to overcome the issues related to VANET evaluation described in Section 3. This software covers the VANET part of the testbed architecture (i.e., bottom part of Figure 3).

4.2.1. Data Acquisition and Postprocessing Fusion with Ana-VANET. An overview of the experimental evaluation process is presented in Figure 4. The four vehicles previously described are considered here, although the system can support any number of vehicles. A sender terminal (MNN), connected to one of the in-vehicle networks, is in charge of generating data traffic towards a receiver terminal (MNN) inside another vehicle. Both sender and receiver save a high level performance log according to the applications used to generate network traffic. All MRs keep track of sent or forwarded data packets using tcpdum (http://www.tcpdump.org/) and log the vehicles' position. All these data are then postpro-cessed by the AnaVANET software.

AnaVANET is a Java application which traces all data packets transmitted or forwarded by mobile routers. It thus

detects packet losses and can generate both end-to-end and per-hop statistics, as well as join these measurements with transport level statistics from the traffic generation tool. AnaVANET generates XML files with statistics at a one second granularity, and packet trace files listing the path followed by each data packet.

The XML statistics file is uploaded to a Web server, which uses the Google Maps API to graphically replay the tests and show performance measurements in a friendly way, as can be seen in Figure 4. A screenshot of this web application is available on Figure 10 in Section 5. All experiments which have been performed up to now can be replayed and main performance metrics can be monitored at any time, by using the control buttons on the left side of the web page. The replay speed can be adjusted and a step-by-step mode has been implemented. On the map, the positions and movements of the vehicles are depicted along with their speed and distance to the rest of cars. The amount of transferred data, throughput, packet loss rate, round-trip time, and jitter, both per-hop and end-to-end, are also displayed. Main network performances can be graphically checked looking at the width and color of the link lines among vehicles.

The Graphic Generator module gives another view of the network performance. It processes both the XML statistics and packet traces to generate several types of graphs using GNUPlot (http://www.gnuplot.info/).

4.2.2. Traffic Analysis and Performance Metrics. Three different types of traffic have been considered over the IPv6 VANET in the tests.

UDP: A unidirectional transmission of UDP packets, from the sender to the receiver terminal has been generated using IPerf (http://iperf.sourceforge.net/). The packet length is 1450 bytes to avoid IP fragmentation, and they are sent at a rate of 1 Mbps.

TCP: A TCP connection is established between the sender and receiver terminals without any bandwidth limit.

—> Packets transmission - - > Entries addtion

Figure 7: Internal route updating and selection mechanisms. NEMO and OLSR routes are stored in completely independent routing tables.

Figure 8: Network topology of the MANEMO demonstration system.

f <?xml version =" 1.0" encoding =" utf-8"? >

< markers >

< marker interval =" 2.0" transfer =" 649" bandwidth =" 2660" lat =" 48.8375" lng=" 2.1010" offset_lat=" 6.59"

offsetjng =" 7.21" distance =" 9.77" time =" 1195225195"/ > \< /markers > J

Figure 9: XML data file generated based on IPerf measurements.

IPerf is again used as the traffic generator. The segment size is 1440 bytes.

ICMP: The Windows XP ping6 utility is used to generate IPv6 ICMP echo request packets at the sender node and to receive echo reply packets from the remote note.

These three traffic types have been used to analyze hop-by-hop and end-to-end network performances, considering the most extended metrics for MANET evaluations [7]. In the TCP case, statistics from IPerf with a 0.5 second granularity, such as the current throughput, are directly used by AnaVANET for performance analysis. Each ICMPv6 and UDP packet is, however, traced across nodes. Since there is

BOS t«f«nn.n:i

..............1.................. "

Figure 10: AnaVANET replaying a VANET experiment. Buildings avoid a direct line-of-sight communication, thus forcing the usage of multihop routes.

no fragmentation for UDP packets, a direct correspondence exists between MAC and IP packets. At this level, the packet delivery ratio (PDR), number of hops and jitter are calculated. For ICMPv6 tests, the RTT is logged to analyze the network delay.

Jâ # 100 « .2 60 g 20

J 5= 100 60

* Hops --- Jitter

Time (seconds)

% g 20

J £ 100

| 2 20

Js 5= 100 « .2 60 3 20

200 300 400 Time (seconds)

100 200 300 400

Time (seconds) PDR from MR2 to MR1

100 200 300 400 Time (seconds)

PDR from MR3 to MR2

0 100 200 300 400 Time (seconds)

1 1 1 1 ____1......

■ 1 I 1

L - "...........

- - , i h | , ........

PDR from MR3 to MR1

Figure 11: UDP performances over a multihop VANET of three cars moving in an urban environment.

4.3. MANEMO Implementation. A policy routing algorithm has been developed and integrated in the architecture to allow simultaneous usage of NEMO and MANET. This subsystem allows vehicles to communicate with each other over both the fixed and VANET networks at the same time, as was illustrated in Figure 3.

4.3.1. Policy Routing. The system has been implemented on GNU/Linux (kernel 2.6.21.3). To distribute packets to multiple paths simultaneously from a MR, a policy routing scheme has been designed. Classic routing mechanisms are not suitable because of the "longest match" principle. As shown in Figure 5, packets arriving to the MR are forwarded to the routing table entry which has the longest prefix in common with the destination address. In the MANEMO case, MANET routes typically have longer prefix lengths than

NEMO ones. The formers are thus used in priority when they are available in the routing table. NEMO routes then have the least preference and are used as default routes. A single routing table can be used for switching between routes but not for simultaneous usage of NEMO and MANET.

To solve the previous problem, we propose multiple routing tables using a Route Policy Database (RPDB), as shown in Figure 6. To achieve this goal, the Netfilter (http://www.netfilter.org/) framework is used. The RPDB allows to maintain several independent routing tables in the kernel. Each packet can then be routed according to any of these tables. The determination of which routing table that should be used in a particular case is up to the implementation. It is usual to route depending on the type of flow that is being treated. This mechanism allows distributing packets to multiple concurrent routes at the same time.

-10 -5 0 5

Time (seconds)

-5 0 5

Time (seconds)

Time (seconds)

- Average ...... 3rd

---1st ----4th

-- 2nd

Time (seconds)

- Average ---2nd

---1st ...... 3rd

Average ...... 3rd

1st ----4 th

th idt

-5 0 5 10

Time (seconds)

- Average ---2nd

---1st ...... 3rd

Time (seconds)

- Average ---2nd

---1st ...... 3rd

- Average ...... 3rd

---1st ----4th

---2nd

-5 0 5

Time (seconds)

- Average ...... 3rd

---1st ----4th

---2nd

th idt

Time (seconds)

- Average ...... 3rd

---1st ----4th

---2nd

Figure 12: Network throughput at corners and straight roads for the UDP multihop test.

nd 400

- Always 3G

---3G or managed

----Any interface

Figure 13: Impact of route changes on the RTT, measured using ICMPv6 packets in the absence of background traffic.

4.3.2. Implementation Details. NEPL (NEMO Platform for Linux) (http://software.nautilus6.org/NEPL-UMIP/) version 20070716 has been installed on MRs along with olsrd (OLSR Daemon) (http://www.olsr.org/) version 0.5.3. NEPL is developed and distributed freely by Nau-tilus6 (http://www.nautilus6.org/) within the WIDE project (http://www.wide.ad.jp/). NEPL is based on MIPL (Mobile IPv6 for Linux) (http://www.mobile-ipv6.org), developed by the Go-Core (Helsinki University of Technology) and Nautilus6 projects.

The OLSR daemon has been adapted to the routing scheme proposed in Section 4.3.1. In this way, OLSR routing entries are maintained in one of the multiple routing tables of the kernel. The NEMO daemon already handles policy routing when patched for MCoA support (http://software .nautilus6.org/MCoA/).

NEMO and OLSR daemons operate independently in MRs. The NEMO one maintains its binding update list and NEMO routes, while the OLSR daemon takes care of MANET routes. As shown in Figure 7, both NEMO and MANET routing entries are kept up-to-date in separate tables.

When started, both daemons add rule entries that specify which packets should be routed according to which routing table (these are removed at the execution end). MRs have multiple routing tables, which save NEMO and MANET routes, and the default one (depicted as MAIN in Figure 7), which saves the rest of routes. There is the same number of NEMO routing tables than egress interfaces on the MR. Each of these routing tables has a specific BID. The MANET routing table is used for traffic that should be routed directly to neighboring vehicles, and the MAIN table is mostly used to route OLSR signaling.

Packets from MNNs arrive at the MR containing the source and destination addresses and ports, as well as the flow type information. Packets are distributed according to

the latter mark to either the NEMO or MANET routing tables. Packets matched with a NEMO routing table are transmitted to the tunnel bound to the HA, while packets matched with the MANET table are transferred to other OLSR nodes directly.

4.3.3. Demonstration Platform. As a demonstration of the policy-based MANEMO system, the performance measured in a communication between two vehicles is shown on a website (http://fylvestre.inria.fr/~tsukada/experiments/), mapped to their geographical positions. The data have been collected during field trials on the Promotion Days of the Anemone Project (12-14th December 2007). This project aims at developing a large-scale testbed for mobile communication technologies. Our demonstration was an example of a third party system using the mobility testbed.

Measurements were made with a GPS-enabled IPerf (http://gforge.inria.fr/frs/?group_id=620&release_id=915) in a topology as shown in Figure 8. This diagram illustrates in detail the MANEMO part of the general vehicular network described at the beginning of this section in Figure 3. MNN1 works as an IPerf server and MNN2 is the client. IPerf reports the amount of transferred data and used bandwidth. Additionally, the GPS patch appends location information (latitude and longitude) as well as the offset and distance from the starting point. Only a regular GPS receiver is needed.

The demonstration can be performed either in realtime or log mode. The former shows network performances mapped with position in real time on the website, while the latter saves them on the MNN's local disk to be displayed later (see Figure 18).

In real-time mode, XML files are generated from measured metrics and positions every two seconds by MNN1. An example XML output is shown in Figure 9. The remote web server periodically gets the data file from MNN1 using

—I— 3G or managed -*- Any interface

Figure 14: Closer look at the RTT values collected when the adhoc interface is turned on and off.

ê 3000

g 2000

-11b managed is available --11b "

^_11b ad-hoc_^

"vailable

100 150 200 250 300 Time (seconds)

i=i Any interface 3G or managed

Figure 15: Evolution ofthe throughput ofthree TCP flows between MNNs using routing policies.

11b managed is available -■ 11b ad-hoc - ■

/l/VIP*1 fWT

ï' tj ^A^^N^W^y ''

100 150 200 250 300 Time (seconds)

- Always 3G

---3G or managed

...... Any interface

Figure 16: RTT between MNNs with three background TCP flows.

wget. The real-time mode has the advantage of everyone can immediately check the network operation. Measurements can, however, be slightly affected by the XML file transfers, as they are carried over the NEMO route. By contrast, this effect is not present in log mode. Main results of these experiments are later analyzed in the paper using the log mode.

5. VANET-Only Performance Evaluation

This section presents an experimental evaluation of our VANET testbed. Here, we only consider the lower part of the architecture shown in Figure 3. Then, field trials have been performed using the integrated evaluation environment described in Section 4.1. Seven different scenarios with

various mobility patterns have been evaluated, using the three types of traffic previously described (UDP, TCP, and ICMPv6). This section analyzes one of our urban scenarios as reference. See [29] for a complete description of all the experiments.

5.1. Experimental Setup Details. In the VANET evaluation shown in Figure 4, mobile routers use only the routing table given by OLSR to forward data packets. MNN1 is a Mac OS X 10.4 laptop and MNN2 is a Windows XP Professional PC. An embedded computer is used as MR in each car. It consists of a Soekris net4521 board with a Texas Instruments ACX111 Mini-PCI 802.11 b/g wireless transceiver and a compact flash memory card. The wireless interface has been setup for 11 Mbps operation, emulating an

11b ad hoC i 11b managed 11b manage ^variable d

is available is availabk <-»

\ \ ft I \ iL........ Vn

/^-A A i » \ M : M A ' t\ ^^^ W/-/ A

60 80 100 Time (seconds)

i=i Any interface 3G or managed Always 3G

Figure 17: Throughputs of three TCP streams in a field experiment. Performances are less stable than in the indoor case.

Table 1: OLSR Parameters for the VANET-only experiments.

Parameter Value (default)

HELLO interval 0.5 sec (2.0 sec)

HELLO validity 6.0 sec (6.0 sec)

HNA interval 3.0 sec (5.0 sec)

HNA validity 9.0 sec (15.0 sec)

802.11 b device. This computer is also connected via a serial port to a Trimble AgGPS 323 GPS receiver. Both the Wi-Fi and the GPS antennas are affixed on the roof of the car.

The timing parameters of the OLSR daemon installed in MRs have been modified as showed in Table 1, to accommodate mobility conditions of a vehicular network. These modifications enable MRs to discover topology changes more quickly.

5.2. Non-Line-of-Sight Multihop Communication. This scenario considers a typical urban environment where buildings prevent a direct line of sight between the source and destination cars. A multi-hop network is better suited to provide a robust connectivity under these conditions.

During 600 seconds of test, a unidirectional transmission of UDP packets is generated from MNN1, in vehicle 3, to MNN2, in vehicle 1. As was explained in Section 4.2, the packet size is 1450 Bytes to avoid IP fragmentation and they are sent at a rate of 1 Mbps.

The results of this experiment (along with the rest of performed trials) is available on a public website (http://fylvestre.inria.fr/~tsukada/experiments/vanet-jose/), and can be replayed to graphically show the performance of the network during the tests (see Figure 10).

The experiment was performed in the Rocquencourt campus of INRIA. This area contains a set of small buildings surrounded by streets, as can be seen in Figure 10. The

four streets showed in the image, which round three of the buildings, have been chosen for this scenario. They stand in a 100 X 100 m square area. Three vehicles have been driven around the buildings, trying to block the direct link between cars one and three. The speed of the vehicles was kept between 15 and 30 km/h. The right and left roads visible in Figure 10 are very narrow and some communication problems were experienced when approaching the corners.

The results collected in the UDP tests are plotted in Figure 11. The several graphs show the results collected during four tests around the buildings. The upper plot shows the number of hops used in the paths followed by UDP packets whereas the lower graphs show the end-to-end and per-link PDR. PDR is computed every second, while the number of hops is plotted for each packet transmitted from the sender node. When no hops are drawn, the route to the destination vehicle is not available. Zero hops means that the packet was sent by the first MR, but was not received by any other. Negative values represent those packets that did not arrive to their destination, but reached some intermediate hops.

As can be seen, a direct relation exists between PDR and number of hops. When the number of hops is equal to or lower than zero, PDR decreases. When the vehicles drive along the same street, some direct paths (one hop) appear. On the contrary, when the distance between the sender and the receiver cars is large enough, the two-hop routes are used. These different types of paths can also be observed with the per-link PDR. Whereas the direct link (MR3-MR1) gives intermediate PDR values, the PDR between consecutive vehicles is almost identical and close to 100% when the two-hop link is used, due to the lower distances between nodes.

The performance obtained in the scenario has been analyzed according to the location of vehicles: corner and straight road. As can be seen in Figure 12, each corner is called SE, NE, NW, SW, and according to its position (i.e., South-East for SE). In the same way, straight roads have been assigned the names E, N, W, and S. Numbers below corner and road names indicate the time in which car 2 (vehicle in the middle) passes these points. For example, for SE, numbers 97, 257, 419, and 537 mean that car 2 passes the SE corner at times 97s, 257s, 419s, and 537s. At these times, the sender vehicle is at the next road (E in this case) and the receiver vehicle is at the previous one (S). On the other hand, when the middle vehicle is at a straight road, the sender vehicle reaches the next corner and the receiver vehicle is at the previous corner. The driving order is SE - E - NE -N - NW - W - SW - S, and three and a half complete rounds have been considered. The analysis starts at time 97s at SE corner, and it ends at 594 s at NW.

As can be seen in Figure 12, the throughput obtained has been mapped with corner and straight road segments, and it has been analyzed for each round at periods of ±10 seconds. A dotted line shows the result of each trial considered in the segment, and a bold line shows the average bandwidth. One can notice the two different bandwidth patterns obtained at corners and straight roads. Communication performance increases in corner scenarios, while it decreases at straight roads. When the intermediate vehicle reaches a corner, the

direct path between the source and the destination vehicle is blocked, thus a multi-hop route is established in the network. At this moment, a good bandwidth is noticeable. When the heading vehicle turns again in the next corner, a multi-hop route still maintains connectivity but, as soon as car 3 and 2 cannot maintain the communication link, the network performance falls. This can be seen in the last ten seconds of straight road graphs in Figure 12. The effect of loosing the link between vehicles 2 and 1 is also present when the intermediate vehicle left the corner (last seconds of corner graphs and first seconds of straight road graphs), but it is less noticeable, since these two vehicles were arbitrarily driven more closely during tests.

Results obtained for segment W shows a different behavior than for the rest of straight roads. This is explained by the special physical conditions of the environment. First, this stretch comprises a narrow street surrounded by buildings on both sides. As can be seen in Figure 10, these conditions are only present in this segment, since the rest of roads have a clear space on one side. This fact enables the reflection of signals on the various walls. Moreover, the second interesting condition identified in road W is the greater altitude of the sender car with regard to the receiver car, when these are located near corners NW and SW, respectively. About five meters of altitude difference increases the packet reception probability, and a direct path between cars 1 and 3 is even noticeable at this segment. This can be checked at time 367s in Figure 11. It is interesting to note that buildings on this INRIA area are quite low, about 3.5 meters, what complements the altitude effect. The rest of direct paths collected in the trials belong to segments S and E, which do have open areas on one ofthe sides.

6. MANEMO Performance Evaluation

For the case of the MANEMO subsystem described in Section 4.2, measurements of latency and throughput have been collected using both the VANET and the infrastructure segments of the testbed (Figure 3). A set of indoor and oudoor experiments have been conducted also at the Roc-quencourt campus of INRIA and this section presents and analyzes most interesting results.

6.1. Experimental Setup Details and Initial Tests. Attending to the global testbed setup in Figure 3, tests have been carried out generating traffic from MNN1 towards MNN2 using the best available communication route (i.e., NEMO or MANET). MNN1 is a Mac OSX 10.4 laptop and MNN2 is a Windows XP tablet PC. As was done for VANET-only experiments, OLSR settings have been adjusted with the values shown in Table 2. These have been chosen to maintain a tradeoff between the delay experimented when a topology change occurs and the network overload that implies control messages. Signaling traffic, apart from reducing the effective bandwidth of the network, it consumes computation resources on the nodes. For these experiments, OLSR settings have been adjusted to be aware of topology changes faster than in VANET-only tests in Section 5, with

Figure 18: Website screen shot of the MANEMO experiment.

^ 2000

Ü 1500 h

+ + + + # + +

ffiMftfrSfcI++ + + + *■'+' ' " '+"

ï^ +. + f+Ii f- +\ ? +++ f— — + iw + jj + ft+ v*—i. —

4." TL J! + + +. . + 44- +■ t I.

;;;;;;;;;;; io

Distance (meters) i=i Average throughput ♦ Throughput

Figure 19: Relation between distance and bandwidth using the MANEMO system.

the aim of performing fast route changes between NEMO and MANET.

Some initial tests were performed to check the operation of the network. One issue that had to be solved was radio interferences between 802.11b managed and ad hoc networks. Even when channels were chosen with a good distribution the problem persisted. To overcome this drawback, the bandwidth of MR1 interfaces were limited to 2 Mbps using a Linux' QoS system based on tc (Traffic Control) (http://www.linux-foundation.org/en/Net:Iputils). Network performance measurements under static conditions, and without any policy, between MNN1 and MNN2 are summarized in Table 3, including three different routes. RTT results is the average of 100 packets of ICMPv6 between MNNs and throughput results have been obtained averaging results obtained during a total of ten minutes of TCP tests.

Table 2: OLSR parameters for the MANEMO experiments.

Parameter Value

HELLO interval 0.5 sec

HELLO validity 1.5 sec

HNA interval 1.0 sec

HNA validity 3.0 sec

Table 3: Performance of the MANEMO system under static

conditions and depending on the route type.

Route & interface RTT Throughput

NEMO over 3G 279.43 ms 416 kbps

NEMO over 802.11b managed 32.74 ms 1977 kbps

OLSR over 802.11b ad-hoc 8.58 ms 1987 kbps

As can be seen, the results of the UMTS link offer the worse results, due to the delay of the operator's network and the bandwidth limited by the radio coverage and the available resources in the cell. The 802.11b link improves these results, offering bandwidth capabilities equivalent to the ad hoc case. However, the delay induced by the managed mode and the relay access point impact on the RTT results.

6.2. Indoor Test Scenario. The policy-based MANEMO system has been firstly evaluated in an indoor testbed, to avoid interferences of other equipments and difficulties to trace the movement of MRs. The following experiments have been performed without any vehicle. Neither MRs nor MNNs have moved during a reference experiment of 300 seconds. It clearly demonstrates the performance expected for longer times or subsequent trials.

MNN1 has three addresses (A, B, and C) in the MNP, and MR1 distributes traffic from the mobile network via multiple paths depending on the source address. Packets from source address A or to port number 5102 are always forwarded via the 3G interface. Those from source address B or to destination port 5101 are routed via the Wi-Fi managed interface when it is available. Otherwise, they are forwarded over the 3G interface. Traffic from source address C or to destination port number 5009 is transmitted via whatever available interface, prioritizing the most efficient (i.e., prefer ad hoc to managed Wi-Fi and only use 3 G if no other link is available). Table 4 summarizes these policies and indicates priorities in case several routes can be chosen. MR2 distributes returning flows into its managed and ad hoc interfaces according to the third policy, since it does not have any 3 G interface. The Home Agents distribute flows to match these policies and avoid asymmetric routes.

For this indoor experiment, connection and disconnection events have been created using a shell script and common system tools. From t = 0 to t = 60, both Wi-Fi managed and ad hoc interfaces of MR1 are down. At t = 60, the managed interface comes up. At t = 120, the ad-hoc one is made available. From t = 120 to t = 180, all the interfaces are up and running. At t = 180, the ad-hoc link is turned off.

At t = 240, the managed one is also switched off. The 3 G interface is always available throughout the test.

6.2.1. Latency Measurements. To measure the RTT between MNNs, MNN1 sends 56 Bytes ICMPv6 echo request packets from all addresses (A, B, and C) to MNN2 once every 0.5 sec. There is no other traffic. These packets are distributed according to the policies described above. Results are showed in Figure 13. The average RTT on the NEMO route over 3 G has been 261.9 ms. Changing paths to the NEMO route over the managed Wi-Fi interface, has reduced the RTT to an average of 34.72 ms, which represents an 87% improvement. During the time the ad hoc mode has been available, the average RTT collected on the OLSR route (ad hoc link) has been 7.93 ms. In this way, route optimization using MANEMO has further reduced the latency by 26.79 ms, what represents an extra improvement of77%.

For the two periods where the three ICMPv6 flows are carried over the 3G network (from t = 0 to t = 60 and from t = 240 to t = 300) an offset of 20 ms of delay between them is noticeable. It has been checked that the transmission ofthe three echo request packets in a consecutive way results in a first-in first-out problem due to transmission and reception times needed by the 3G driver. The extra overload incurred by the NEMO and tunnel and the L2TP (Layer-2 Tunneling Protocol) tunnel, necessary to support IPv6 traffic in the 3G network, increases the impact of this effect.

Figure 14 gives a closer look at the RTT results when the ad hoc interface goes up/down and routes thus change. At t = 120, the ad hoc interface comes up, and then direct route information of both MNPs are exchanged. At t = 122.5, the RTT obtained for the marked packet is 21.27 ms, which comprises an intermediate value between NEMO and OLSR modes. This is because the ICMPv6 echo request has used the NEMO route, while the echo reply has returned through the ad hoc one. It takes 2.5 seconds for OLSR routing entries to be added to MR1's table after the ad hoc link has been connected. By contrast, the route is changed back from OLSR to NEMO 1.5 sec after the ad hoc link is disconnected. During this switching phase, three packets have been lost (From t = 180 to t = 181.5), due to the sudden disconnection of the ad hoc interface.

6.2.2. Throughput Measurements. To measure the throughput between MNNs, MNN1 sends three TCP streams to MNN2 by means of IPerf, with destination port numbers 5102, 5101 and 5009, in the same routing scenario used above. At the same time, MNN1 also sends 56 Bytes ICMPv6 echo request packets as in the previous section. IPerf gives a report once every two seconds and ping6 gives it every 0.5 seconds. A reference test has been chosen among the set of performed tests. Figure 15 shows the achieved throughput with stacked area graph and Figure 16 shows the observed RTT when the TCP flows are active.

A summary of throughput results is given in Table 5. The average total throughput on the NEMO route over 3G is 455 kbps from t = 0 to t = 60. Since an 802.11b managed network is available from t = 60 to t = 120, the flows

Table 4: Flow distribution policies for MR1. Smaller numbers reflect higher priorities.

Policy Targets 3G Managed Wi-Fi Adhoc Wi-Fi

Always 3G Source address A or destination port 5102 1 X X

3G or managed Source address B or destination port 5101 2 1 X

Any interface Source address C or destination port 5009 3 2 1

are distributed in two paths and the average throughput increases up to 1913 kbps, which represents an improvement of 76% (1458 kbps). From t = 120 to t = 180, ad hoc connectivity is also available. The average total throughput increases again up to 3752 kbps when the three TCP flows are distributed through the three paths, which represents a new improvement of 49% (1837 kbps).

The average RTT between MNNs is also listed in Table 5. The RTT on the NEMO route is about 400 ms when the three TCP streams are transmitted using the 3G link. When two TCP streams are diverted to the 802.11b managed interface, from t = 60 to t = 120, the RTT over the 3G link decreases by about 280 ms, which represents an improvement of 30%. The RTT also decreases from 400 ms to about 130 ms for policies "3G or managed" and "Any interface" when Wi-Fi managed is available, which comprises an improvement of 68%. In addition, a further 50% (approx.) of improvement is observed for policies "3G or managed" and "Any interface" when all the interfaces on MR1 are available, since each communication technology is used by only one flow.

6.3. Field Experiment. The system has been evaluated with a set of field trials performed on the Telecom Bretagne/INRIA Rennes campus. 40 access points have been installed in this area. The test has been performed in a straight road surrounded by buildings, where two access points have been installed at two far away locations. The source vehicle starts moving at a speed of 10 km/h from a position before the first access point, while the destination vehicle with MR2 has been parked next the two access points. Both MRs were mounted inside the vehicles. Three TCP flows were transmitted from MNN1 to MNN2 as in the previous tests. The flow distribution policies of MR1, MR2, HA1 and HA2 are also identical to those of the indoor testbed but, obviously, periods of 802.11 connectivity are not simulated now.

The switch between access media and/or networks has a clear impact on the available bandwidth, as can be seen in Figure 17. From t = 0 to t = 60, the path between MNNs is only via the NEMO route over 3G. The average total throughput of the TCP flows is 344 kbps during this period. The throughput in this field experiment is 111 kbps less than in the indoor experiment. This is mostly due to obstacles and movements of the vehicle equipped with MR1. From t = 62 to t = 86 and from t = 106 to t = 116, the NEMO route through managed Wi-Fi is available, since the moving vehicle is near one access point each time. The

average total throughput of the TCP stream at these two periods is 1430.83 kbps and 957.34 kbps, respectively. From t = 124 to t = 130, the OLSR route over the VANET is available. The average throughput increases until 2408.4 kbps during this period.

In the evaluation, the NEMO route on the 802.11b managed interface has been used for 24 seconds for the first access point, and then an additional 10 seconds for the second one. As the speed of the vehicle was 10km/h, the coverage of the access points can be estimated to be between 30 and 65 meters. The ad hoc interface has been available during six seconds, thus the VANET range can be estimated to be 17 meters. In this case, the antennas of both MRs were located inside the vehicles. 802.11 performance could therefore be improved by mounting external and/or more powerful antennas.

6.4. Impact of Geographical Location on Network Performance. In the previous section, the range of the available access points and VANET links are estimated considering a simplification of the driving speed and the time of connection. This section presents more thorough range measurements. These have been collected by maintaining MR1 (and thus MNN1) moving in a 65 meters radius around the position of MR2, and reporting the achievable throughputs. None of the MRs have gone out of the access points' coverage and a building sometimes block the VANET route. As the wireless access points are quite close to the test site, the managed interface has been forcibly limited to 1 Mbps to account for more distant APs and highlight which network path MR1 uses. By contrast, the ad hoc interface was not limited and the average throughput between MRs using this interface was 2685 kbps.

The position-mapped throughputs were measured at INRIA Rocquencourt in France, using the GPS-patched version of IPerf. To obtain a high density of throughput data around MR2, the evaluation was actually performed without vehicles. MR1 has been carried by a human at an average speed of 4 km/h. It starts moving from the position of MR2 and comes back to the same position within 250 seconds. The experiments were run eight times. All the results are publicly available (http://fylvestre.inria.fr/-tsukada/experiments/).

A screenshot of the Web application can be seen in Figure 18. The website displays the throughput between MNNs by varying the size of the blue circles at each measure point. All tests can be displayed by selecting the Log option. Clicking on one of the circles reveals additional information,

Table 5: Total throughput of three TCP flows and RTT between MNNs.

Policy Available interfaces

3G only 3G and managed All interfaces

Throughput

Always 3G 156 kbps 262 kbps 276 kbps

3G or managed 184 kbps 733 kbps 1612 kbps

Any interface 114 kbps 918 kbps 1863 kbps

Total 455 kbps 1913 kbps Round-Trip Time 3752 kbps

Always 3G 389ms 277 ms 275 ms

3G or managed 411 ms 127 ms 64 ms

Any interface 432 ms 130 ms 64 ms

including the test time, location and offset from the starting point, transferred data size and bandwidth in the last two seconds. All the data can be shown at once with the Show Log button. Users can also analyze the results by changing data density and see the trajectory of MR1 (and thus MNN1).

Throughput results depending on the distance between MNNs can be seen in Figure 19. Data points show the throughput obtained at the current distance, while the bar graph represents an average for five meters. Values over 1 Mbps (the arbitrary limitation on the managed Wi-Fi link) are those recorded when the VANET route was available. One can see that it is available up to 40 meters. Between (approx.) 20 and 40 meters, throughput measurements spread over a wide range from 100 kbps to 2700 kbps, because media handovers between the managed and ad hoc interfaces are performed in these zones.

An asymmetrical tendency of the ad hoc link ranges has been observed. From the collected results, it turns out that the OLSR route is usable over a longer distance when two vehicles are getting further from one another than when they are getting closer. This hysteresis behavior is due to OLSR's initial delay caused by the period of sharing HELLO packets. This fact is further analyzed in [29].

7. Conclusions and Future Works

A proposal to distribute data traffic in vehicular communications combining NEMO and VANET has been presented. This comprises an integral communication platform for the ITS frame, which has been experimentally evaluated by means of a complete and open testbed. In a first stage, an integrated evaluation environment for VANET enabled us to analyze the network performance in detail in both per-hop and end-to-end manners, also considering the movement of vehicles. The evaluation environment provides novel performance metrics for VANET, according to the current literature, such as the number ofhops used to deliver a packet or the per-link PDR, in addition to typical statistics, such as end-to-end packet delivery ratio, round-trip delay time, jitter or bandwidth. Although it has been tuned to dynamic conditions, the OLSR protocol shows limitations to efficiently update routing tables under stressful conditions, as it has been seen above all in the MANEMO evaluation. A more

VANET-oriented protocol developed at INRIA, in frames of the GeoNet Project (http://www.geonet-project.eu/) will be evaluated through new field trials, using the presented test-bed. This is located inside the geographic-based routing proposals, which are demonstrating to be the correct direction in vehicular network research.

The MANEMO proposal has been evaluated using common vehicles in real environments. Up to four vehicles have been setup to carry out a number of experiments. In our system, mobile routers use multiple egress interfaces simultaneously with NEMO and OLSR. The latter could thus mitigate the sub-optimality caused by NEMO routes. Previous experiments results showed that MANEMO with route switching from NEMO to MANET improved network performance in terms of latency and bandwidth. It can now be stated that MANEMO with simultaneous usage of NEMO and MANET can achieve further improvements on a integrated vehicular network. Experimental results show that the achievable throughput and delay are improved when a set ofinterfaces (3G, 802.11 b managed and 802.11 b ad hoc) are available.

Among the different research lines that are now active regarding this work, we plan to extend the MANEMO system as follows. First, evaluation results show that network performances such as latency and bandwidth dynamically change according to available interfaces, mobility or obstacles. Adaptive applications are thus desirable in these environments. Second, traffic flows have to be allocated to appropriate paths depending on the application demands and network performances. Since real-time applications are sensitive to handovers, an intelligent path allocation is required. Third, traffic between MNNs has been distributed according to policies manually specified by the administrator. As an MR can only control its outbound traffic, policy changes on an MR may create asymmetric routes. By introducing common filter rules and a exchanging procedure among MRs and HAs [30, 31], policies on each entity can be synchronized. Fourth, currently, the position-mapped reports for the MANEMO case are focused on bandwidth statistics. Network metrics such as latency, packet loss rate or layer-two information will be considered in further analysis for the whole MANEMO system, in the line of the work carried out for the VANET segment.

Acknowledgments

The authors would like to thank the partners of European project Anemone, and more specifically Telecom Bretagne and INRIA Rennes who built the IPv6 mobility testbed from which the MANEMO experiments exposed in this paper have largely benefited.

References

[1] T. Ernst, "The information technology era of the vehicular industry," ACM SIGCOMM Computer Communication Review, vol. 36, no. 2, pp. 49-52, 2006.

[2] Y. Khaled, M. Tsukada, J. Santa, J. Choi, and T. Ernst, "A usage oriented analysis of vehicular networks: from technologies to applications," Journal of Communications, vol. 4, no. 5, pp. 357-368, 2009.

[3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, "Network mobility (NEMO) basic support protocol," RFC 3963 (Proposed Standard), January 2005.

[4] IS0/TC204 WG16. ISO/WD 21210, "CALM—medium and Long Range, High Speed, Air Interfaces parameters and protocols for broadcast, point to point, vehicle to vehicle, and vehicle to point communication in the ITS sector—IPv6 Networking," Working draft, February 2009.

[5] R. Bossom, R. Brignolo, T. Ernst et al., "European ITS communication architecture—overall framework—proof of concept implementation," Tech. Rep. Version 2.0, EC "Information Society Technologies" Programme, March 2009.

[6] T. Kosch, I. Kulp, M. Bechler, M. Strassberger, B. Weyl, and R. Lasowski, "Communication architecture for cooperative systems in Europe," IEEE Communications Magazine, vol. 47, no. 5, pp. 116-125,2009.

[7] Z. Chang, G. Gaydadjiev, and S. Vassiliadis, "Routing protocols for mobile ad-hoc networks: current development and evaluations," in Proceedings of the Annual Workshop on Circuits, Systems and Signal Processing, pp. 489-494, Veldhoven, The Netherlands, November 2005.

[8] T. Clausen and P. Jacquet, "Optimized link state routing protocol (OLSR)," RFC 3626 (Experimental), October 2003.

[9] L. Bokor, N. Montavont, P. Di Francesco, T. Ernst, T. Hof, and J. Korva, "ANEMONE: a pan-European testbed to validate IPv6 mobility technologies," in Proceedings of the International Symposium on Applications and the Internet, Workshop on Network Mobility (SAINT WONEMO '07), Hiroshima, Japan, 2007.

[10] C. Tschudin, H. Lundgren, and E. Nordstrom, "Embedding MANETs in the real world," in Proceedings of the 8th IFIP Conference on Personal Wireless Communications, vol. 2775 of Lecture Notes in Computer Science, pp. 578-589, September 2003.

[11] V. González, A. Los Santos, C. Pinart, and F. Milagro, "Experimental demonstration ofthe viability of IEEE 802.11b based inter-vehicle communications," in Proceedings of the 4th International Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities (TridentCom '08), pp. 1-7, Innsbruck, Austria, 2008.

[12] J. P. Singh, N. Bambos, B. Srinivasan, and D. Clawin, "Wireless LAN performance under varied stress conditions in vehicular traffic scenarios," in Proceedings ofthe 56th IEEE Vehicular Technology Conference (VTC '02), vol. 2, pp. 743747, Vancouver, Canada, September 2002.

[13] M. Jerbi, S.-M. Senouci, and M. Al Haj, "Extensive experimental characterization of communications in vehicular ad

hoc networks within different environments," in Proceedings of the 65th IEEE Vehicular Technology Conference (VTC '07), pp. 2590-2594, Dublin, Ireland, 2007.

[14] M. Tsukada, I. Ben-Jemaa, H. Menouar, W. Zhang, M. Goleva, and T. Ernst, "Experimental evaluation for IPv6 over VANET geographical routing," in Proceedings ofthe 6th International Wireless Communications and Mobile Computing Conference, pp. 736-741, Caen, France, June 2010.

[15] C. Ng, T. Ernst, E. Paik, and M. Bagnulo, "Analysis of multihoming in network mobility support," RFC 4980 (Informational), October 2007.

[16] R. Wakikawa, V. Devarapalli, G. Tsirtsis, T. Ernst, and K. Nagami, "Multiple Care-of Addresses Registration," RFC 5648 (Proposed Standard), October 2009.

[17] D. Johnson, C. Perkins, and J. Arkko, "Mobility support in IPv6," RFC 3775 (Proposed Standard), June 2004.

[18] C. Ng, P. Thubert, M. Watari, and F. Zhao, "Network mobility route optimization problem statement," RFC 4888 (Informational), July 2007.

[19] C. Ng, F. Zhao, M. Watari, and P. Thubert, "Network mobility route optimization solution space analysis," RFC 4889 (Informational), July 2007.

[20] R. Baldessari, T. Ernst, A. Festag, and M. Lenardi, "Automotive industry requirements for NEMO route optimization," January 2009.

[21] W. Eddy, W. Ivancic, and T. Davis, "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks," RFC 5522 (Informational), October 2009.

[22] R. Wakikawa, K. Okada, R. Koodli, A. Nilsson, and J. Murai, "Design of vehicle network: mobile gateway for MANET and NEMO converged communication," in Proceedings ofthe 2nd ACM International Workshop on Vehicular Ad Hoc Networks (VANET '05), pp. 81-82, September 2005.

[23] J. Lorchat and K. Uehara, "Optimized inter-vehicle communications using NEMO and MANET," in Proceedings ofthe 2nd International Workshop on Vehicle-to-Vehicle Communications (V2VCOM '06), July 2006.

[24] R. Wakikawa, T. Clausen, B. McCarthy, and A. Petrescu, "MANEMO topology and addressing architecture," July 2007.

[25] R. Wakikawa, P. Thubert, T. Boot, J. Bound, and B. McCarthy, "Problem statement and requirements for MANEMO," July 2007.

[26] C. J. Bernardos, I. Soto, M. Calderón, F. Boavida, and A. Azcorra, "VARON: vehicular ad hoc route optimisation for NEMO," Computer Communications, vol. 30, no. 8, pp. 17651784, 2007.

[27] C. Pradalier, J. Hermosillo, C. Koike, C. Braillon, P. Bessiére, and C. Laugier, "The CyCab: a car-like robot navigating autonomously and safely among pedestrians," Robotics and Autonomous Systems, vol. 50, no. 1, pp. 51-67, 2005.

[28] M. Tsukada and T. Ernst, "Vehicle communication experiment environment with MANET and NEMO," in Proceedings of the International Symposium on Applications and the Internet, Workshop on Network Mobility (SAINT WONEMO '07), p. 45, Hiroshima, Japan, January 2007.

[29] J. Santa, M. Tsukadat, T. Emstt, and A. F. Gomez-Skarmeta, "Experimental analysis of multi-hop routing in vehicular ad-hoc networks," in Proceedings ofthe 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular Networks in Conjunction with the International Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities and Workshops (TridentCom '09), Washington, DC, USA, April 2009.

[30] C. Larsson, M. Eriksson, K. Mitsuya, K. Tasaka, and R. Kuntz, "Flow Distribution Rule Language for Multi-Access Nodes," IETF, Work in progress, draft-larsson-mext-flow-distribution-rules-02, February 2009.

[31] H. Soliman, G. Tsirtsis, N. Montavont, G. Giaretta, and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support," IETF, Work in progress, draft-ietf-mext-flow-binding-04, November 2009.