Thouraya Toukabri

Manabu Tsukada

Thierry Ernst
email: thierry.ernst@inria.fr

Lamjed Bettaieb
email: lamjed.bettaieb@esprit.ens.tn

Experimental evaluation of an open source implementation of IPv6 GeoNetworking in VANETs

ISO TC204 and ETSI TC ITS are developing a set of standards for Cooperative ITS (Cooperative Intelligent transportation Systems) which will allow ITS stations i.e. vehicles, the road infrastructure and other peers reachable through the Internet to cooperate and exchange information with one another in order to enhance road safety, traffic efficiency and comfort for all road users. In situations where the exchange of information has to transit through the Internet, the use of IP, more specifically IPv6, is crucial and meets ITS needs for reliable and scalable communication capabilities in vehicular networks. An implementation of Cooperative ITS communication protocols is necessary to validate extensively the ETSI and ISO Cooperative ITS standards. In this paper, we describe CarGeo6, an ongoing open-source implementation of the IPv6 GeoNetworking capabilities of the ITS station reference architecture based on the output of the GeoNet European Project. CarGeo6 combines IPv6 and GeoNetworking capabilities into a common protocol stack for the transmission of IPv6 packets into a given geographical area. This paper reports the validation process and the network performance evaluation of CarGeo6 as well as a comparison of these results with GeoNet results.

I. INTRODUCTION

Road safety, fleet control, Geo-localization, infotainment and other applications are new road services that need not only new control technologies for vehicles and the infrastructure (sensors capacity, high image processing, complex data handling...) but also efficient data transmission between vehicles and the infrastructure. A new vision of Intelligent Transportation Systems (ITS) is born: Cooperative ITS. The idea is based on conceiving and deploying a transportation system in which the roadside infrastructure, vehicles, and remote entities cooperate to enhance road safety, traffic efficiency and comfort of road users (drivers, passengers, pedestrians, fret carriers). With this new revolutionary concept of Cooperative ITS, the pure fiction of communicating vehicles is becoming a reality in which suitable communication forms, architectures and techniques are deployed to combine in an efficient way the internal control function of the vehicle with its external communication function.

As we are talking about vehicles moving at high speed on highways, a geographic position-based routing protocol (GeoNetworking) was defined and specified by the Car to Car Communication Consortium (C2C-CC) 1 in order to distribute information to all vehicles in a given road area. Moreover, in situations where the exchange of information has to transit through the Internet and considering today's Internet predomination in mostly all communication systems, Internet-based communication scenarios are crucial for vehicular communications in order to keep the whole system up to date with the new technological achievements in favor of the ubiquitous Internet. IPv6 takes its place within these new ITS communication architectures, thanks to its advantages like extended address space, embedded security, enhanced mobility support and ease of configuration, in boosting new Internet and ITS usages.

IPv6 is then an opportunity to use the Internet differently in ITS and expanding it with GeoNetworking could result in an efficient, scalable (addresses for an unlimited number of vehicles) and flexible (the protocol is extensible and any underlying wireless technology could be accommodated) vehicular communication system for safer roads and a sustainable development of the road network.

The GeoNet European Project2 was the first experimental work investigating the use of IPv6 in vehicular communications. The project ran for two years between 2008 and 2010 and was setup to study, implement and demonstrate the combination of IPv6 with GeoNetworking capabilities as designed by the C2C-CC. The project issued an architecture and the functional specification of the architecture components [START_REF] Bettaieb | 1.2 Final GeoNet Architecture Design[END_REF], [2]. It provided two implementations of C2C-CC's GeoNetworking capabilities and their integration with an IPv6 stack running on top and extended with additional features. The project proved the concept combining both IPv6 and GeoNetworking. It also published experimental test results and a performance evaluation conducted both indoor and outdoor to evaluate the performance of IPv6 GeoNetworking [START_REF]7.1 GeoNet Experimentation Results[END_REF], [START_REF] Tsukada | Experimental evaluation for IPv6 over VANET geographic routing[END_REF].

Unfortunately, both implementations of the GeoNetworking capabilities developed within the GeoNet project were proprietary. Only the binary code was made available to other GeoNet partners. Considering the lack of access to the code as a restraint for the continuous validation and performance improvement of IPv6 GeoNetworking, the idea of developing an open source prototype of the IPv6 GeoNetworking protocol stack came. Indeed, an open source implementation is justified by the fact that open source has gained more ground with the rise of the Internet in the recent past years.The promise of open source is mainly of a better quality, higher reliability, more flexibility, and a lower cost. It will also provide a playground to all Cooperative ITS stakeholders who have no knowledge in networking but need the necessary communications capabilities to test new applications.

This paper introduces CarGeo6 3 , an open source implementation of IPv6 GeoNetworking. The project is a Linux-based prototype implementation that has been developed conforming with GeoNet specifications [2]. CarGeo6 has been validated and tested in the indoor testbed and outdoor. Network performance has been evaluated in different scenarios that involved sometimes only vehicles (V2V: Vehicle-to-Vehicle), vehicles and the roadside infrastructure (V2R: Vehicle to Roadside) or vehicles and the Internet (V2I: Vehicle to Internet).

The paper is structured as follows: First, we introduce the general ITS station reference architecture the CarGeo6 basic concepts rely on. In the third and the fourth sections, we highlight CarGeo6 particularities and the enhancements it brought to IPv6 GeoNetworking and to the architecture design. Then, the last section is dedicated to the report of some preliminary experimental results on the network performance.

II. THE ITS STATION REFERENCE ARCHITECTURE

ISO TC204 WG16, known as CALM (Communications Access for Land Mobiles) is working for ten years on a communication architecture supporting a variety of media types (infrared, microwave, 2G/3G, ...), a variety of networking protocols (IPv6, FAST) for a variety of Cooperative ITS needs (communication profiles) and access network load. Such an interface management component requires input from various layers and is thus a cross-layer function. With such a cross layer function combined with IPv6 mobility support functions (NEMO, MCoA) [5], continuous Internet connectivity can be maintained over transient communication interfaces (i.e. not breaking ongoing communications after vertical handover from e.g. 802.11p to 3G) or transient access points (from one roadside ITS station supporting 802.11p to another one). This architecture has been developed, validated and demonstrated in the CVIS project [START_REF] Moe | CVIS Performance Test Results: Fast Handovers in an 802.11p Network[END_REF] for a number of Cooperative ITS applications.

In parallel, the C2C-CC worked on a communication architecture and the specification of the GeoNetworking protocol for multi-hop 802.11p communications between vehicles and the road infrastructure.

In an effort towards harmonization, the European Commission's COMeSafety Specific Support Action issued an European ITS Communication Architecture which has then led to the definition of a uniform communication architecture 3 CarGeo6 open source implementation: www.cargeo6.org known as the ITS station reference communication architecture (see Figure 1) standardized at both the European level within ETSI TC ITS (Technical Committee for Intelligent Transport Systems) and the international level within ISO TC 204 (WG16). Both ISO and ETSI architecture specifications [START_REF]Intelligent Transport Systems (ITS); Communications Architecture[END_REF], [START_REF]2010 Intelligent transport systems -Communications access for land mobiles (CALM) -Architecture[END_REF] are based on the same terminology and tend to converge although there are still differences between the two until all standards composing this architecture are revised and aligned. The cross-layer design originally introduced by ISO TC204 WG16 is now clearly represented on the architecture diagram (ITS station management plane), though the cross-layer functions to be offered are still under discussion at the ETSI and ISO standardization level. Such an architecture would be deployed on various types of ITS stations involved in Cooperative ITS communications, but different features would be supported according to the type of ITS station, deployment environment and user needs. Types of ITS stations include the vehicle ITS station, the roadside ITS station, the personal ITS station and central ITS stations. The vehicle ITS station could be a private car, an emergency vehicle, a truck, a bus, a taxi, or even a tramway. The distinction is only made at the level of the subset of features and applications supported. The central ITS stations are typically road traffic servers, service providers, etc. The roadside ITS station type includes roadsigns, variable message signs (VMS), traffic lights, electric charging points and Internet access points dedicated for Cooperative ITS. The personal ITS station type includes nomadic devices such as mobile phones, digital car keys, etc. In the future, more ITS stations may be defined.

As a result, this ITS station architecture combines all types of communications: Vehicle-to-Vehicle (V2V) and Vehicle-to-Roadside (V2R) using IPv6 or GeoNetworking or a combination of both over IEEE 802.11p or other media; Vehicleto-Central (V2C) using IPv6 over any kind of media (e.g. 802.11p via a roadside ITS station, 802.11n via a public WIFI network, or 3G via the cellular network); Roadside-to-Central (R2C) using IPv6 over optic fiber, cellular networks, WiMaX. In this paper, we focus on V2V communications as described on Figure 2.

III. IPV6 GEONETWORKING ENHANCEMENTS

The ITS station architecture illustrated in Figure 1 comprises multiple protocol stacks at the ITS station Network and Transport layer. As shown, GeoNetworking (GeoRouting on the figure) and IPv6 are two independent protocol stacks but these could be combined. The combination of IPv6 and GeoNetworking capabilities into a common protocol stack has been introduced and validated by the GeoNet project [START_REF] Bettaieb | 1.2 Final GeoNet Architecture Design[END_REF]. This resulted mainly in the design, integration and implementation of a set of components that allow sending IPv6 packets over a VANET managed by a GeoNetworking protocol. In addition to the GeoNetworking protocol (C2CNet), the newly developed components are mainly the adaptation of IPv6 over GeoNetworking (IPv6 over C2CNet) and Mobile Network Prefix Provisioning (MNPP4 ) [START_REF] Lee | Mobile network prefix provisioning (mnpp)[END_REF]. In addition, some existing IPv6 features/components have also been integrated in the IPv6 stack such as MLDv2 to enable multicast over GeoBroadcast (Geographically scoped broadcast) and IPv6 mobility support (NEMO and MCoA) [START_REF] Devarapalli | Network Mobility (NEMO) Basic Support Protocol[END_REF]. These contributions are detailed in the following sub-sections.

The transmission of IPv6 over GeoNetworking (i.e. IPv6 over C2CNet) has recently been specified and standardized by ETSI [START_REF]Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Protocols[END_REF], based on GeoNet results, but this standard doesn't contain all the capabilities specified by the GeoNet project (it only allows to route IPv6 packets over a link with GeoNetworking capabilities, but not to geographically distribute IPv6 packets as realized by the GeoNet project).

Overall, the contributions of the GeoNet project proved to the ITS community that both IPv6 and GeoNetworking is needed for several ITS safety and traffic efficiency applications and proved the feasibility of this concept in real experiments reported in [START_REF]7.1 GeoNet Experimentation Results[END_REF].

A. C2CNet: a GeoNetworking protocol

C2CNet is a GeoNetworking protocol proposed by the C2C-CC and then implemented and experimented by the GeoNet project. C2CNet is defined as a communication layer that enables GeoNetworking mechanisms (geographical addressing and routing). C2CNet includes position-based routing mechanisms adapted to vehicular communications and use, in particular, the Greedy Perimeter Stateless Routing (GPSR) algorithm [START_REF] Karp | Gpsr: Greedy perimeter stateless routing for wireless networks[END_REF]. GPSR uses the greedy forwarding algorithm which routes data using information of direct neighbors (in the same wireless range). Besides, the C2CNet mechanism defines a new network header that carries the C2C identifier (identifier of the ITS station) of the source and the destination as well as their geographic positions acquired from the Positioning module (see Figure 3). Each node in the VANET domain is then identified by its unique C2CNet ID which is exchanged between the vehicle and its direct neighbors.

In addition, C2CNet defines also a mechanism for geographic multi-hop communications, in which a given vehicle could communicate with another vehicle not in his wireless range. This mechanism is called Location Service and provides a Request/Reply based mechanism that allows the source vehicle to request if the destination is in the wireless range of one of its immediate neighbors. In this case, intermediate nodes are called C2CNet Forwarders and are in charge of relaying the message until the destination using C2CNet Geo-Routing mechanisms.

B. Adaptation of IPv6 over C2CNet

The IPv6 over C2CNet sub-module as specified in GeoNet [2] is the adaptation module that allows passing IPv6 packets coming from the IPv6 stack to the C2CNet layer. This submodule is in charge of acquiring necessary IPv6 parameters such as the IPv6 address, performing IP Next Hop determination and IPv6 address resolution over the C2CNet link. IPv6 packets are then sent to C2CNet through the GeoIP SAP (Service Access Point between IP and GeoNetworking), the piece of software that links the IPv6 layer to the C2CNet layer. All incoming packets from the IPv6 stack and going to the wireless interface are mapped according to their packet type into C2CNet packets with a given destination range. The mapping from IPv6 schemes to C2CNet schemes is done as shown in table I. Application data is encapsulated in IPv6, C2CNet and IEEE 802.11p [START_REF]IEEE Standard for Information technology -Telecommunications and information exchange between systems -Local and metropolitan area networks -Specific[END_REF] headers in that order and each header designates a different entity. At the C2CNet layer, IPv6 packets are encapsulated with a C2CNet header where the IP Next Hop is designated by the destination C2CNet identifier. Until the packet reaches the IP Next Hop 5 , all intermediary nodes only check the packets C2CNet header and ignore its IPv6 header. Only the IP Next Hop consults the IPv6 header to make a forwarding decision to the IPv6 destination node.

C. Cross-Layer Functions

In addition to the communication interface management function which is by design a cross-layer function, and as a result of the GeoNet project, INRIA is advocating for two additional cross-layer functions not yet part of the ITS station management plane: Positioning and Geo-destination. The Positioning module is in charge of computing a precise position of the vehicle based on the fusion of the information received by both the ITS station network and transport layer (GeoNetworking) and the ITS station facilities layer (CAM 6 , DENM 7 , LDM 8 ) [START_REF]Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service[END_REF]- [START_REF]Intelligent transport systems (its); vehicular communications; basic set of applications; local dynamic map (ldm); rationale for and guidance on standardization[END_REF]. The Geo-destination module is needed by the ITS station network and transport layer (IPv6 GeoNetworking) to determine in which geographical area an IPv6 multicast packet should be transmitted by the GeoNetworking sub-layer.

D. IPv6 Multicast and GeoDestination

According to GeoNet reference scenarios [START_REF] Bettaieb | 1.2 Final GeoNet Architecture Design[END_REF], many use cases of ITS road safety and traffic efficiency applications need to send a message to a set of nodes in the VANET within a specific geographical area. Existing solutions, such as unicasting the packets to those multiple destinations or broadcasting them in the entire VANET, do not provide the suitable mechanisms to ensure distributing packets in an efficient way from the 5 Designates the next hop from an IP viewpoint. It is the destination node to which the packet is delivered by the C2CNet forwarding mechanism 6 CAM: Cooperative Awareness Message 7 DENM: Decentralized Environmental Notification Message 8 LDM: Local Dynamic Map sender to their receivers. The transmission of a packet to the set of interested nodes is known as multicasting, by opposition with broadcasting which is flooding all nodes.

The challenges in GeoNet were to extend IPv6 multicast so that only nodes within a certain geographic area could be addressed, i.e. geographically scoped multicast. Several approaches were discussed in [2] such as encoding the geographic coordinates of the geographic destination area (GeoDestination) in the IPv6 multicast address (which means providing a new IPv6 address format), recording the GeoDestination in a new extended header (which means providing extensions to the IPv6 protocol) or using encapsulation. The solution finally adopted in GeoNet is a solution making use of the cross-layer nature of the ITS station: the IPv6 multicast address is statically mapped to a corresponding GeoDestination ID which is in turn mapped to a GeoDestination at the ITS station management layer (Geo-destination module). The GeoDestination is provided to the C2CNet module through the MN-SAP based on the GeoDestination ID embedded in the IPv6 multicast address and passed by IPv6 to C2CNet through the GeoIP SAP. IPv6 multicast packets are then simply Geo-Broadcasted at the C2CNet layer within the GeoDestination around the originating node or a target node. Nevertheless, GeoDestination is a new concept proposed in GeoNet but not entirely specified. It is still not being considered in ETSI and ISO standards.

IV. THE CARGEO6 OPEN SOURCE IMPLEMENTATION

Issued from the collaboration between the Tunisian school ESPRIT and INRIA, the French institute of research in computer science, CarGeo6 is a stable open source implementation combining IPv6 and GeoNetworking protocol blocks of the ITS station network and transport layer of the reference architecture. The software is a Linux-based prototype programmed in the C language and released under a LGPLv2 license (Lesser GNU Public License).

The implementation currently comply with the architecture and specifications published by the GeoNet European Project [START_REF] Bettaieb | 1.2 Final GeoNet Architecture Design[END_REF], [2]. It ill be improved in the short term in order to comply with the most recent ETSI standards on GeoNetworking and IPv6 GeoNetworking [START_REF]Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Protocols[END_REF], [START_REF]Transport & Network; Vehicular Communications; Part 1: Requirements for GeoNetworking and Data Transport Protocol[END_REF]. The prototype is validated on the same testing platform as the one used in the GeoNet project experimentations [START_REF]7.1 GeoNet Experimentation Results[END_REF].

Figure 4 shows the implementation design of CarGeo6 and the origin of the contributions (from CarGeo6 partners or earlier sources). It is also envisioned to extend it with ITS station facilities layer capabilities (CAM, DENM, SAM 9and LDM) and ITS station management plane capabilities (interface management, remote ITS station management).

The GeoNetworking layer referred to as the C2CNet layer in the GeoNet documents and the SAPs between the ITS station Network and Transport layer and the ITS station access layer (IN-SAP) were implemented by ESPRIT. ESPRIT also provided an implementation of the Positioning module that INRIA contributed a protocol allowing direct communication between nearby ITS stations (Mobile Network Prefix Provisioning) [START_REF] Lee | Mobile network prefix provisioning (mnpp)[END_REF], its integration with IPv6 mobility support (NEMO and MCoA) [START_REF] Devarapalli | Network Mobility (NEMO) Basic Support Protocol[END_REF], IPv6 multicast (MLDv2) and the adaptation module between the IPv6 protocol suite and GeoNetworking (IPv6 over C2CNet). In particular, this latest component contains the internal GeoIP SAP that encapsulates IPv6 packets into GeoNetworking packets through a virtual TUN/TAP network interface.

The IPv6 stack being implemented in the kernel space, an adaptation module has been implemented in the user space in order to send IPv6 packets to the new GeoNetworking software implemented by ESPRIT in the user space. This adaptation module, referred as the IPv6 over C2CNet submodule in GeoNet documents, should perform the IP Next Hop determination: The software looks up in the main routing table using LibNetlink 10 messages to find the IPv6 destination address and then brings up the information to the user land. At this level, the IPv6 destination address is matched with a unique destination GeoNetworking Identifier, referred as C2CNet ID in GeoNet. So far, the software performs a look up in the Location Table 11 to determine if the destination could be reached using single hop Geo-Routing protocol (the IP Next Hop is a neighbor) or multi-hop Geo-Routing protocol.

Once the destination scope is determined, the GeoIP SAP 10 LibNetlink: A library for accessing the netlink service in the linux kernel 11 Location Table: a routing table implemented at the GeoNetworking layer that contains the list of neighbor vehicles and their C2CNet IDs (see Figure 4), referred to as the C2C-IP SAP in GeoNet documents, creates and mounts a virtual TUN/TAP interface named tun0, performs the appropriate mapping operation on the IPv6 packet to a GeoNetworking packet and then sends it to the GeoNetworking layer. At this level, the appropriate header is added and the packet is send on the wireless link. The implementation design of the IPv6 GeoNetworking mechanism is illustrated in Figure 5 in the case of a multi-hop scenario.

CarGeo6 also implements IPv6 multicast over GeoNetworking as specified in GeoNet [START_REF] Bettaieb | 1.2 Final GeoNet Architecture Design[END_REF], [2]: IPv6 multicast packets are mapped at the GeoIP SAP into GeoBroadcast packets within a specific GeoDestination. The multicast group is then mapped tp a GeoDestination ID and a specific radius around a point given by its coordinates. CarGeo6 currently implements this mechanism with a static GeoDestination table maintained at the GeoNetworking layer inside the adaptation module. A future contribution from CarGeo6 will be to specify the GeoDestination module as a part of the ITS station management plane and ensure the communication between this module and the GeoNetworking layer through cross layer management functions (MN-SAP primitives).

V. INDOOR PERFORMANCE EVALUATION OF CARGEO6

In this section, we report experimental performance results of our CarGeo6 implementation used in V2V communication scenarios. Experiments were conducted in the indoor platform using single hop and multi-hop configurations at the GeoNetworking layer. We used the IEEE 802.11g wireless communication protocol for the ad-hoc network between MRs and Ethernet links between MRs and their Mobile Network Nodes (MNNs). MRs have both IPv6 and GeoNetworking capabilities, whereas MNNs are simple IPv6 hosts with no GeoNetworking capabilities. We only report end-to-end IPv6 unicast communications from in-vehicle host MNN1 attached to mobile router MR1 to in-vehicle host MNN2 attached to mobile router MR2, over the underlying GeoNetworking layer. Generally, the performance depends on the network configuration. In our case, it depends particularly on the number of GeoNetworking hops (C2CNet hops) over which packets are transmitted through from the source node (MNN1) to the destination (MNN2) and the overhead brought by the additional GeoNetworking header. As such, we considered both single hop and multi-hop configurations at the GeoNetworking level.

GeoNetworking (C2CNet) GeoNetworking (C2CNet)

GeoIP SAP

IPv6 over C2CNet

GeoIP SAP

IPv6 over C2CNet Geo-Routing

Fig. 5. Implementation of IPv6 over C2CNet in CarGeo6

The testbed we set in our indoor platform (see Figure 6) is composed of 3 MRs and 2 MNNs. The test consists on sending IPv6 unicast packets from MNN1 to MNN2 using for the first experiment a direct link communication between MR1 and MR2 and in the second experiment using an intermediate GeoNetworking Node. As we could not use real GPS devices indoor due to poor signal reception, geographic positions of nodes are given by a static GPS sender software that runs in each of them.

A. Evaluation methodology and metrics

Our test methodology consists on executing scripts on the IPv6 hosts attached to each MR in order to evaluate several performance parameters. Results of the performance scripts are recorded in log files in IPv6 hosts and are parsed in order to generate graphs for each evaluation metric. The performance is evaluated according to some network metrics and configurable parameters summarized in Table II. We note that the hop count is an important configurable parameter to take into consideration when evaluating the network performance of IPv6 GeoNetworking particularly the latency. Theoretically, we can get most basic network performance in a single hop configuration. On the other hand, the multihop configuration adds processing delay and overhead. In the following results, we experimented a multi-hop scenario with one hop forwarder.

To evaluate latency, we used ping6 to send ICMPv6 packets from MNN1 to MNN2 in order to measure the Round Trip Time (RTT) between the two end nodes. The purpose of using ping6 is to test Latency in bidirectional communications and the packet loss. Besides, we used iperf for the UDP performance evaluation: iperf is a client/server software that generates UDP traffic at the client side and collects information about the packet delivery ratio at the server side. Throughput is then calculated according to the data collected at the client side.

B. Latency evaluation

The latency is evaluated by the RTT value indicated in the ping6 output. The ping6 output indicates the minimum, maximum and average RTT for a given size of packet. The test consists on sending 100 ICMPv6 requests every 0.1ms with different packet size values increased each time by 20Bytes and varying from 20Bytes to 1500Bytes. The ping6 output indicates also the packet loss average for each size of ICMPv6 packet. We report in Figure 7 and Figure 8 the results we had for a ping6 from MNN1 to MNN2 in both single hop and multi-hop configurations.

1) Single hop scenario: Figure 7 indicates first that there is packet loss for a packet size exceeding 1300Bytes. This is explained by the fact that we fixed the MTU of the TUN/TAP virtual interface to 1350Bytes in our test, which means that packets from 1320Bytes and more are automatically dropped as no fragmentation mechanism is neither enabled nor implemented at the TUN/TAP interface. The lack of a fragmentation mechanism at the GeoNetworking layer could also have an impact on the packet loss: The maximum MTU is fixed to 1500Bytes. The figure shows also that the average RTT for all packet size values varies mostly between 2ms and 10ms except for a packet size of 370Bytes where we noticed a 25ms maximum average RTT value with 8% packet loss. If we compare these results to GeoNet results [START_REF]7.1 GeoNet Experimentation Results[END_REF], [START_REF] Tsukada | Experimental evaluation for IPv6 over VANET geographic routing[END_REF] for the same test, we can say that CarGeo6 average RTT values are globally better than GeoNet average RTT. Same as for the packet loss, values are almost similar in both implementations. However, these results could be improved by the implementation of an IP Next Hop cache. Currently, the IP Next Hop is resolved for each IPv6 packet at the IPv6 over C2CNet sub-module (adaptation module) which implies a processing delay on the RTT. The IP Next Hop cache avoids the software resolving the IP Next Hop address for packets having the same destination address. In other words, the cache will keep in a periodically refreshed table the destination C2CNet ID of an IP Next Hop and will not repeat this operation for packets having the same destination.

Besides, the packet loss values (maximum of 11%) could also be improved. Even if the indoor testbed is intended to minimize interferences impact on the experiment, we cannot suppress definitely this constrain that could be caused by wireless engines located in the proximity of the testbed. Thus, interference impact could be avoided by the choice of a less noisy wireless channel and the isolation of the testbed as well as possible. The activation of QoS at the wireless interface could also improve the packet loss but may imply unfortunately an overhead.

2) Multi-hop scenario: As depicted in Figure 8, we can see that global values of RTT and packet loss are significantly higher with one C2CNet Forwarder node than in the single hop configuration. The minimum packet loss value is 40% for a 1340Bytes packet size. Moreover, as in single hop case, packets are lost for packet size values over 1350Bytes due to the lack of fragmentation mechanisms at the C2CNet layer. The maximum average RTT is also noticed for a 370Bytes packet size. Globally, RTT values in multi-hop are about 10 times higher than RTT values in single hop case and more than 40% packets are lost. As written before, RTT values could generally be improved by the implementation of an IP Next Hop cache but we assume that this is not sufficient in the multi-hop case. RTT and packet loss high values are caused also by the Location Service mechanism implemented at the C2CNet level. This mechanism is responsible for finding the C2CNet ID of a node not in the neighborhood of the source. A process of Request/Reply packets is then triggered in order to find that ID. This mechanism implies a lot of waiting time until the source gets the reply with the C2CNet ID of the destination: the more we have intermediary nodes the bigger is the RTT and chances of packet loss. To improve this, a multi-hop beaconing mechanism where the source beacon is relayed until the destination through intermediary C2CNet forwarders could be added.

C. Overhead between GeoNetworking and IPv6

In order to evaluate the overhead between IPv6 and GeoNetworking, we compare in Figure 9 the RTT values for different packet size for IPv6 without GeoNetworking and for IPv6 with GeoNetworking. The figure shows that the overhead between IPv6 and GeoNetworking in the single hop case is about 3ms, while it reaches 30ms in the multi-hop case. We think that this overhead (multi-hop case) could be reduced if we implement the multi-hop beaconing mechanism instead of the Location Service mechanism.

D. UDP performance in Single hop scenario

In this part, we report UDP performance results for the single hop case. The performance is evaluated according to packet delivery ratio values and the throughput at the receiver side. The test consists on varying the datagram size from 100Bytes to 1900Bytes for different values of the UDP sending rate varying from 250Kbits/sec to 2Mbits/sec. Figure 10 shows the packet delivery ratio in the single hop case. The packet delivery ratio is low when the datagram size is too small: 60% packets are delivered for a 700Bytes datagram size and 250Kbits/sec sending rate. The maximum packet delivery values (97% to 100%) are registered for a datagram size between 1150Bytes and 1380Bytes and with 250Kbits/sec sending rate. Though, only 50% packet delivery is registered for these same datagram sizes with 1Mbits/sec sending rate. Datagrams size (Byte) 250Kbits/sec 500Kbits/sec 750Kbits/sec 1000Kbits/sec 1250Kbits/sec 1500Kbits/sec 1750Kbits/sec 2000Kbits/sec Fig. 10. UDP performance in single hop case Figure 11 shows the throughput delivered in the same test. Throughput is maximized for all rates with 1360Bytes datagram size. Besides, the maximum throughput value is registered for 420Bytes datagram size with 1250Kbits/sec, 1750Kbits/sec and 2Mbits/sec sending rates. We decided to limit our measurement interval to 2Mbits/sec sending rate because packets are dropped for rates more than this value.

In comparison with GeoNet results for UDP performance [START_REF]7.1 GeoNet Experimentation Results[END_REF], [START_REF] Tsukada | Experimental evaluation for IPv6 over VANET geographic routing[END_REF], CarGeo6's performance for UDP is currently poor but could be improved. Possible reasons for this results could be first wireless media issues due to interference as mentioned before. The same test will be done in the future with the 802.11p wireless media.

Besides, the quality of the C2CNet link could also be the issue. As we suspect processing delays at the GeoNetworking layer, this could have an impact on the UDP traffic transmission from the source to the destination. To verify this assumption, we plan to develop a ping6-alike tool that measures the latency between two nodes at the GeoNetworking layer.

Currently, our assumption is the following: With the iperf tool, the server sends statistic information about the link state to the client (sender node) periodically after receiving a certain number of datagrams. If packets take too much time to arrive, and as UDP is an unreliable protocol, the server could send state information of the link before receiving the packets. This means that late arrived packets could be considered as lost. Moreover, we noticed according to the Figure that, the bigger the sending rate is, the lesser packets arrive to the destination. This could confirm the assumption that the processing time implies too much delay on the communication: the bigger the packet is, the bigger the processing delay will be, and the bigger the chance to lost the packet is. In this paper, we presented CarGeo6, an open source implementation of IPv6 GeoNetworking complying to the GeoNet specifications [2]. We reported our first experimentation performance results of CarGeo6 for a single hop and multi-hop scenarios. We tried to evaluate some performance aspects of the implementation such as the latency, the packet delivery ratio for UDP and the UDP throughput. The current results analysis showed some performance issues. The performance could be enhanced with the implementation of some extension features like the IP Next Hop cache to enhance latency and multi-hop beaconing to enhance performance in the multi-hop case. We also plan to conduct more experiments in order to investigate the reasons of the poor performance in UDP and also TCP and bring out the current implementation to a more stable state.

Future work on CarGeo6 consists mainly on enhancing the indoor performance and testing the implementation outdoor using vehicles in more realistic scenarios. For this work, we took the GeoNet experiments as a reference [START_REF]7.1 GeoNet Experimentation Results[END_REF]. Next, IPv6 over GeoNetworking will be adapted in order to comply with ETSI specifications on IPv6 GeoNetworking [START_REF]Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Protocols[END_REF], [START_REF]Transport & Network; Vehicular Communications; Part 1: Requirements for GeoNetworking and Data Transport Protocol[END_REF].

Then, a second step is the integration in CarGeo6 of other components defined in the ITS station reference architecture, in particular ITS station facilities such as CAM (Cooperative Awareness Message), DENM (Decentralized Environmental Notification Message, SAM (Service Advertisement Message) and LDM (Local Dynamic Map) and cross-layer ITS station management capabilities such as interface management and selection. One of the key elements on which we are working also is the specification and definition of the SAPs between the Network and Transport layer and the other ITS station layers i.e the ITS station facilities and access layers and the ITS station security and management vertical planes.

Fig. 1 .

 1 Fig. 1. ITS station reference architecture

Fig. 2 .

 2 Fig. 2. V2V communications between ITS stations

Fig. 3 .

 3 Fig. 3. IPv6 GeoNetworking packet headers

Fig. 4 .

 4 Fig. 4. CarGeo6 implementation design and contributions

Fig. 6 .

 6 Fig. 6. Indoor testbed for V2V communications

Fig. 7 .

 7 Fig. 7. ICMPv6 performance in single hop case

Fig. 8 .

 8 Fig. 8. ICMPv6 performance in multi-hop case

Fig. 9 .

 9 Fig. 9. Overhead between C2CNet and IPv6

Fig. 11 .

 11 Fig. 11. UDP throughput in single hop case

table location table Geo -Routing GeoNetworking (C2CNet) IN-SAP Userland Kernel MR1 MR2 MR3 (Forwarder node) Routing NETLINK Geo-Routing Location service location table Userland Kernel Userland Kernel look up in routing table refer location table DATA flow Packet flow Action

 locationGeo

C2C-CC:www.car-to-car.org

GeoNet project: www.geonet-project.eu

MNPP: a solution to advertise the IPv6 prefix of a router (MRs and ARs) to other nearby routers in order to avoid the transmission of packets via the HA when routers are directly reachable over the IPv6 C2CNet link or any conventional wireless link.

SAM: Service Advertisement Message

ACKNOWLEDGMENT

The authors would like to thank the Tunisian developers from the ESPRIT school for their efforts in the development of the CarGeo6 GeoNetworking layer and for their collaboration with the IMARA team (INRIA) for bringing CarGeo6 to its present state. Special thanks goes also to all IMARA team members for their support and help during CarGeo6 experimentations.


Satoru Noguchi
email: satoru-n@is.naist.jp

Manabu Tsukada
email: manabu.tsukada@inria.fr

Thierry Ernst
email: thierry.ernst@inria.fr

Atsuo Inomata

Kazutoshi Fujikawa
email: fujikawa@itc.naist.jp

Location-aware service discovery on IPv6 GeoNetworking for VANET

Service discovery is an essential component for applications in vehicular communication systems. While there have been numerous service discovery protocols dedicated to a local network, mobile ad-hoc networks and the Internet, in vehicular communication systems, applications pose additional requirements; They need to discover services according to geographical position. In this paper, we propose a location-aware service discovery mechanism for Vehicular Ad-hoc NETwork (VANET). The proposed mechanism exploits IPv6 multicast on top of IPv6 GeoNetworking specified by the GeoNet project. Thanks to the GeoBroadcast mechanism, it efficiently propagates service discovery messages to a subset of nodes inside a relevant geographical area with encapsulating IPv6 multicast packets. We implemented the mechanism using CarGeo6, an open source implementation of IPv6 GeoNetworking. Our real field evaluation shows the system can discover services with low latency and low bandwidth usage in VANETs.

I. INTRODUCTION

Applications for Intelligent Transportation System (ITS) aim at providing road users with improved traffic safety, traffic efficiency, and additional values in vehicular communication systems [START_REF] Papadimitratos | Vehicular communication systems: Enabling technologies, applications, and future outlook on intelligent transportation[END_REF]. Recently various ITS stakeholders have been working on specifying ITS applications [START_REF]CAR 2 CAR communication consortium manifesto, overview of the C2C-CC system, version 1.1[END_REF], [START_REF]Intelligent Transport Systems (ITS), Vehicular Communications (VC), Basic Set of Applications, Definitions[END_REF]. Such ITS applications are distributed applications composed of a number of distinct services; software or hardware entities integrated into wide variety of nodes in vehicular ad-hoc networks (VANET), in which most participants are mobile nodes embedded in vehicles.

As applications need to orchestrate necessary services remotely, a Service Discovery Protocol (SDP) that dynamically discovers available services is essential. Although we can consider to introduce a static configuration, a centralized directory server that provides information of available services, or traditional broadcast to discover services, such solutions are not applicable because of the characteristics of ITS services: (i) services are mostly nomadic in VANETs, thus available services in a VANET are time-varying, (ii) a VANET may not be capable of introducing a stable node (i.e. centralized entity). On the other hand, SDPs enable applications to dynamically find the existence, characteristics and communication endpoints of services by querying service's attributes (possibly in cooperation with centralized entities). Even though the physical and logical location of services change frequently, SDPs can efficiently discover a set of actually available services.

Although A number of SDPs have been proposed to find nomadic services within mobile ad hoc networks (MANETs), discovering ITS services in VANETs raises further requirements: (i) applications need to discover services according to geographical location because ITS-related services are highly dependent on geographical location, such as cameras embedded in a particular intersection, vehicles within a certain radius of a corner, etc. (ii) Services should be discovered as quickly as possible due to stringent latency requirements of ITS applications (i.e. from 10ms to 1000ms [START_REF] Karagiannis | Traffic safety applications requirements[END_REF]). (iii) ITS applications need to avoid consuming unnecessary bandwidth.

A potential solution is to use multicast in cooperation with ad-hoc routing protocols so that it can efficiently react to the change of the network topology due to the mobility of the vehicles and also avoid unnecessary broadcasting (i.e. flooding) to all vehicles in the area. IPv6 multicastbased SDPs, specifically Service Location Protocol version 2 (SLPv2) [START_REF] Guttman | Service Location Protocol, Version 2[END_REF] and multicast DNS (mDNS) with DNS-based service discovery (DNS-SD) [START_REF] Cheshire | Multicast dns[END_REF], [START_REF] Cheshire | Dns-based service discovery[END_REF], may therefore be possible foundation for service discovery in VANET.

However, at this moment such solutions do not support the "geographic service discovery" requirement (i) mentioned above. In addition, they can manage geographical location as a service's attribute within the SDP mechanism in the application layer, it means that service discovery messages are delivered to unnecessarily large number of nodes since IPv6 multicast itself sends packets to all nodes which belong to a corresponding multicast group that represents a particular type of service. Consequently the requirement "efficient bandwidth consumption" (iii) mentioned above is not met either.

In this paper, we propose a service discovery mechanism that locates services inside a particular geographical area in VANETs. The proposed mechanism is composed of IPv6 multicast-based service discovery in combination with geographical addressing and routing; SLPv2 with RFC 3111 [START_REF] Guttman | Service Location Protocol Modifications for IPv6[END_REF] modification by IETF, and IPv6 GeoNetworking defined by the GeoNet project 1 . Modifications of SLP for IPv6 specified in RFC 3111 enable SLP to use multiple IPv6 multicast groups which allows one-multicast-address-forone-service usage. IPv6 GeoNetworking furthermore enables 1 The FP7 European project GeoNet. http://geonet-project.eu/ !"#$% "&&'(() #'*+,-. The rest of this paper is organized as follows. Section II overviews vehicular communication systems, service discovery, existing SDPs, and IPv6 GeoNetworking. Section III describes functional requirements of SDPs for ITS applications and then proposes our location-aware service discovery mechanism harmonized with SLPv2 and IPv6 GeoNetworking. We then present field evaluation results in Section IV. Section V finally concludes the paper.

!"#$#% &'()( *+&,-.+%!"#%()/),'0 !"#$#% 1'2)+3%4516 !"#$#% &'()( 1'/7(,7+%!"#%()/),'0 !"#$#% 1'2)+3%4516 1'/7(,7+%!"#%()/),'0 !"#$#% 1'2)+3%4816 !"#$#% &'()( *+&,-.+%!"#%()/),'0 !"#$#% 1'2)+3%4816

II. SERVICE DISCOVERY IN VEHICULAR COMMUNICATION

SYSTEMS

In vehicular communication systems, VANETs are composed of vehicles and the roadside.

In our study, the ITS equipment deployed in the vehicles and roadside infrastructure comply with the ITS station reference architecture from ISO/ETSI [START_REF][END_REF], [START_REF]Intelligent Transport Systems -Communications access for land mobiles (CALM) -Architecture. International Organization for Standardization[END_REF], [START_REF] Papadimitratos | Vehicular communication systems: Enabling technologies, applications, and future outlook on intelligent transportation[END_REF]. Each ITS station is assumed to be equipped with at least a router i.e. mobile router (MR for the vehicle ITS station) or access router (AR for the roadside ITS station). Other nodes (e.g. hosts running applications, cameras, gateways to the CAN bus, ...) are possibly connected to the routers through an ITS station internal network. Routers have at least (i) one wireless egress interface to communicate with other routers, and (ii) one wired/wireless ingress to connect to the ITS station internal network. IPv6 works as a mandatory network layer communication protocol and the routers provides certain network prefixes to their attached nodes. The AR provides Internet access to MRs. Fig. 1 shows the network architecture of the vehicular communication system.

ITS applications are distributed applications composed of several different services: software or hardware entities integrated into attached nodes developed by several ITS stakeholders. As applications may consume multiple services through an identical application process, services shall be self-contained, modular, and application independent entities so that service consumers can share and reuse existing services. Possible functions of services in the vehicular communication systems are (i) to provide vehicle's/roadside's characteristics (e.g. vehicle's mechanical condition, colors of traffic light, etc.), or sensor data acquired with embedded camera, radar, etc. (ii) to process consumers' request (e.g. manipulate electronic gates, perform payment, notify drivers with road traffic information) and (iii) to aggregate road traffic information from other vehicles and the roadside.

Prior to communicate with necessary services, applications obviously need to know the existence and communication endpoints using SDPs that dynamically discover actually available services. Thanks to SDPs, applications only need to specify a name and specific attributes of the service, then SDPs return a list of actually available services containing communication endpoints of attached nodes that operate the corresponding service.

SDPs are composed of service consumer (SC), service provider (SP), and service directory (SD). SPs operate services for SCs and possibly register available services to SDs, while SCs try to discover services by asking SPs and SDs. SDs are centralized cache entities that act as services' directory. SDs may not be introduced to a small network (i.e. local network), or mobile network (i.e. infrastructure-less VANET) in which such a centralized entity does not fit the characteristics of the network. From the architectural point of view, SDPs are considered as a set of mechanisms such as service description language, discovery function, registration function, and routing for each function [START_REF] Mian | A survey of service discovery protocols in multihop mobile ad hoc networks[END_REF]. In this paper we particularly concentrate on the functions and the routing mechanism.

A. Service discovery protocols

SLPv2 standardized by IETF introduces three system components: User Agent (UA), Service Agent (SA), and optional Directory Agent (DA), which behave as the above-mentioned SC, SP, and SD respectively in the context of this paper. In SLPv2, a SC issues a Service Request (SrvRqst), which contains a type and attributes of the requested service, to SPs or SDs. If SPs and/or SDs satisfy the request, they return a Service Reply (SrvRply), which contains URL representation of all available services in the considered network, to the SC. SPs join a particular IP multicast group, then the SC can either directly send SrvRqst to SPs via IP multicast or to SDs via unicast. On the other hand, SPs always return SrvRply to SCs via unicast.

RFC 3111 provides a modification of SLPv2 and enables SLPv2 to operate service discovery over IPv6. While the original SLPv2 is using only one IPv4 multicast address, the modification allows to use multiple IPv6 multicast addresses assigned for each service (available address range is FF0X::1:1000-FF0X::1:13FF). SPs join the multicast groups that correspond to the service type of their services. The multicast address is calculated according to a hash algorithm, which generates a numerical value (0-1023: corresponds to the multicast address range) from a service type's string representation. From the communication point of view, the benefit of this modification is to send the service discovery messages to a specific subset of nodes that join a corresponding IPv6 multicast group in the considered network. If there is a large number of SPs that operate several different services in a network, such a modification can significantly reduce bandwidth usage.

mDNS with DNS-SD also provides a service discovery mechanism by introducing a special DNS domain '.local.' It discovers services using the regular DNS message format via IP multicast without DNS servers, thus SCs directly communicate with SPs. Unlike SLPv2 with IPv6 modification, mDNS uses one IP multicast address for all discovery messaging.

In static and/or local networks, each SDP mechanism efficiently works thanks to IPv6 multicast, however, as we mentioned above, ITS applications need to discover services according to geographical position in VANET as quickly as possible without unnecessary bandwidth consumption.

B. IPv6 GeoNetworking

The GeoNet project has developed a reference specification of IPv6 operated over GeoNetworking, which conforms to the C2CNet specification [START_REF]CAR 2 CAR communication consortium manifesto, overview of the C2C-CC system, version 1.1[END_REF], [START_REF]D1.2 Final GeoNet Architecture Design[END_REF]. C2CNet, specified by the CAR 2 CAR Communication Consortium 2 , is a communication layer dedicated to car-to-car communications and is located between the network layer and the link layer. It supports geographical addressing and routing by means of encapsulation of IPv6 packet within a C2CNet packet containing GeoDestination (coordinates of the geographic area where the packet should be distributed).

Although the C2CNet layer can exchange packets without IP, the GeoNet project has defined how to transmit IPv6 packet over C2CNet ("IPv6 over C2CNet") so that IPv6 and GeoNetworking can be combined. This combination allows to distribute IPv6 multicast packets to a given GeoDestination. This is performed transparently to the upper layers; In IPv6 GeoNetworking-enabled VANETs, each MR is assigned a C2CNet identifier. When a node sends out an IPv6 packet with destination node's IPv6 address, the C2CNet layer encapsulates the IPv6 packet within a C2C packet, which includes the C2CNet identifier of the IP next hop node. The C2CNet layer thereby makes the routing decision with the C2CNet identifier and nodes' geographical location. IPv6 GeoNetworking has four types of geographical routing mechanisms: GeoUnicast, GeoBroadcast/TopoBroadCast, and GeoAnycast. Depending on the mechanisms, several types of the geographical destinations (GeoDestination) can be specified with geographical coordinates and descriptions of a shape, such as a circle area with a particular radius of a geographical position. These geographical routing mechanisms are mapped to IPv6 unicast, multicast, and anycast so that upper layer entities i.e. applications/services can transparently use these mechanisms without any interaction with the C2CNet layer. It means that the users only need to support the regular IPv6 stack. In the GeoNet project, IPv6 GeoNetworking has been implemented in Linux using TUN virtual interface. Routers at first receive regular IPv6 packets on their ingress (egress) interface and pass the packets to the userland C2CNet module via the virtual interface. Then subsequent communication is performed in the C2CNet layer [START_REF] Tsukada | Experimental evaluation for IPv6 over VANET geographic routing[END_REF], [START_REF] Noguchi | Real-vehicle integration of driver support application with IPv6 GeoNetworking[END_REF]. 2 The CAR 2 CAR Communication Consortium. http://www.car-to-car.org/ In this section, we propose a location-aware service discovery mechanism. Our solution consists of application layer service discovery components and the IPv6 GeoNetworking components in the network layer. We use SLPv2's service discovery components because of its ability to handle multiple IPv6 multicast groups, as mentioned in Section II. The IPv6 GeoNetworking components constructs and maintains VANETs. The descriptions of these components are described below.

A. Assumptions and system requirements

The proposed mechanism aims at discovering services for ITS applications in VANETs described in Section II. We assume that each attached host has a global IPv6 address configured from a network prefix assigned by its router. VANETs are made of vehicle and roadside ITS stations routers with IPv6 GeoNetworking capabilities. Multi-hop routing is performed at the C2CNet layer transparently from the IP layer. The routers are therefore one IP hop neighbors from the IPv6 point of view. Each router can get its current geographical position via embedded GPS. A service is basically identified with a service type and optional service specific attributes. It means that there may be multiple services that operate an identical service type with different service attributes.

The design principles are as follows:

• Discover services according to geographical position in addition to the services type and attributes: when SCs try to discover SPs, each SC shall specify a GeoDestination within which SPs can be discovered. The size of the GeoDestination is not dependent on the wireless communication range of the sender but just dependent on application/services' requirements.

• Specify GeoDestination for each service: each service shall be able to use a service-specific geographical range separately.

• Avoid unnecessary bandwidth usage: the service discovery mechanism should not send discovery messages to unnecessarily large number of nodes.

B. Directory-less SLP

SLPv2 components are used with the IPv6 modification, as mentioned in Section II. SDs are not introduced since we focus on mobile services located in VANETs where such a static centralized entity is hard to be installed. Whenever a SC tries to discover a service, it issues the multicast SrvRqst message to a corresponding IPv6 multicast group calculated by the service type of the requested service. When SPs, which join the corresponding IPv6 multicast group, receive the SrvRqst message and they operate services that meet the request, they return the unicast SrvRply message to the SC. We use the sitelocal scope IPv6 multicast (i.e. FF05::1:1000/118) instead of the link-local scope because SCs and SPs are mostly out of link-local scope; they are located behind different ITS station (ITS-S) routers.

Contrary to the original SLPv2, in the proposed mechanism SCs can specify an arbitrary GeoDestination for each service discovery process as described in the subsequent section.

C. Multicast service request over GeoBroadcast

In order to deliver the multicast SrvRqst message to a subset of SPs inside a particular GeoDestination in a VANET, we extend SCs to exploit the GeoBroadcast mechanism by IPv6 GeoNetworking, which disseminates IPv6 multicast packets to all nodes located inside a GeoDestination represented by its coordinates and radius [START_REF]D2.2 Final GeoNet Specification[END_REF].

The GeoNet specification proposes several solutions to determine how to map the GeoDestination to a group of destinations. For instance, an IPv6 multicast address can be statically mapped to a corresponding GeoDestination using a configuration file that assigns a GeoDestination with a radius around the centre of the area where the packet shall be propagated (i.e. FF0E::1 corresponds to a 500m radius). It means that application/service users need to specify all possible pairs of IPv6 multicast address and radius.

However, the solution relying on the static configuration does not meet the above-mentioned requirements, because the corresponding IPv6 multicast address for each service is not statically configured but calculated using the hash function. Therefore we introduce a mechanism that specifies GeoDestination by adding an <IPv6 multicast addresses, radius> mapping into IPv6 GeoNetworking. SCs send the mapping information to their ITS-S routers.

Regarding multi-hop IPv6 multicast routing from an attached node to others in SrvRqst, the multicast packets are !"#$#%&'() !"#$#%&'*) +,"-."/01/#$ 234$51/#$%'.678#$ 9#$:%;;<=::>:><<<?>>@ A*6B%"6,.%(C(D,$ 7,E34/.%A*6B 234$51/#$%'.678#$ 9#$:%;;<=::>:><<<?>>@ 27?F7 27?F7 GH51/#$%'.67I4J 9#$:%'( GH51/#$%'.67I4J 9#$:%'( +,"GH51/#$% Fig. 4. Encapsulation of SLP messages propagated using simple IP multicast forwarding without any dedicated routing mechanism, because ITS-S routers can communicate with each other as one-hop IP neighbor thanks to IPv6 GeoNetworking. It means that while the maintenance of multicast groups in VANETs traditionally incurs some costs, the proposed mechanism does not need such overhead. Fig. 2, 3, and 4 shows the system overview, protocol stack in each system entity, and the overview of the encapsulation of the SLP messages respectively. The operation processes of the proposed mechanism are identified with three phases: (i) service activation, (ii) service discovery, and (iii) service operation. Overall processes are shown as follows:

1) In the service activation phase, when a service is activated, its SP joins an IPv6 multicast group determined with the hash function by means of MLD report to its ITS-S router. 2) In the service discovery phase, when an application requests its SC to discover services inside a particular GeoDestination, the SC calculates the corresponding IPv6 multicast address and sends the mapping information, which contains a pair of <IPv6 multicast address, radius>, to the IPv6 GeoNetworking mechanism in its ITS-S router.

3) The SC issues the multicast SrvRqst designated to the corresponding IPv6 multicast address to its ITS-S router.

The ITS-S router receives the IPv6 multicast packet through its ingress interface and forwards it to the internal C2CNet virtual interface. 4) The IPv6 GeoNetworking mechanism determines the GeoDestination by looking up the registered mapping information. Then the IPv6 multicast packets are encapsulated into the GeoBroadcast packets and sent out on the egress interface. 5) ITS-S routers located inside the GeoDestination receive the GeoBroadcast packets through egress interface. The packet is decapsulated and then the IPv6 layer checks if there are attached nodes belonging to the corresponding multicast group (i.e. a SP that operates the requested service) on their ingress interface. If there are corresponding SPs, the routers send the IPv6 multicast packets to its SPs through their ingress interface. 6) In the end of service discovery phase, SPs reply unicast SrvRply to the SC. 7) Finally, the application starts to consume the service in their communications. Fig. 5 shows the overall messaging sequence. Suppose a set of all nodes in the considered network N , a group of all nodes that join the corresponding IPv6 multicast group G mc , a group of all nodes being inside the corresponding GeoDestination G gd . Only if a node N i ∈ N fulfills (N i ∈ G mc ) ∩ (N i ∈ G gd ) can receive SrvRqst packets. Fig. 6 shows the selective propagation of multicast SrvRqst packets. Thanks to this mechanism and the SLPv2's per-service IPv6 multicast address assignment, the proposed mechanism can avoid propagating service discovery messages unnecessarily large GeoDestination.

IV. EXPERIMENTS

In order to observe the cost and performance of the proposed mechanism, we have implemented a prototype system and integrated it into our real field testbed.

A. Field evaluation setup

We implemented the system by extending OpenSLP 2.0 Beta 1 3 and CarGeo64 on Linux operating system. OpenSLP is an open-source implementation of SLP including the modification for IPv6, whereas CarGeo6 is an open-source implementation of IPv6 GeoNetworking in complying with the reference specification of the GeoNet project. Regarding the IPv6 multicast forwarding function in ITS-S router, we implemented our own multicast forwarding daemon. We performed a field evaluation at NAIST campus in Japan. As we use three sets of MRs and attached hosts, one of them (MR1, Host1) runs a SC in Host1, which moves around the other nodes (MR2, Host2, and MR3, Host3) and periodically tries to discover services with randomly selected GeoBroadcast radius. On the contrary, the others (MR2, Host2, and MR3, Host3) are stationary nodes located along a road. Host2 and Host3 operate a SP for each (SP1, SP2). The position of MR2 and Host2 is inside the direct communication range of MR1 and Host1. MR3 and Host3 are not inside the direct communication range of MR1 and Host1 but of MR2 and Host2. It means that the SC can reach SP1 via single hop whereas it can SP2 via multiple hops.

Each SP runs the same pairs of multiple services. Therefore when both SPs are inside a GeoDestination of a particular SrvRqst, the SC can receive two service information for one request. The system configuration is shown in Table I.

B. End-to-end latency

Table II shows the discovery latency between (i) SC and SP1, and (ii) SC and SP2 in the succeeded service discovery phase. The average latency is 7.86ms in the single hop case and 48.6ms in the multi hop case. It shows our proposed mechanism can discover services with fairly low latency. As several ITS related research mentioned that the acceptable latency is around 10-1000ms, our proposed service discovery mechanism meets this requirement even in the two-hop case. The evaluation shows preliminary results in which maximum hop is the two-hop case, therefore more experiments will

GeoBroadCast

GeoUnicast LS Beacon Fig. 7. Message overhead be conducted in future work. Although the system discover services rapidly, in the multi hop case, the success rate drops sharply. We need to improve it by configuring the retransmit mechanism and discovery interval.

C. Messaging overhead

Fig. 7 shows the bandwidth usage on the egress interface at each MR. In our evaluation, we do not take into account ITS station internal communications between host and MR since they are performed with Ethernet which provides enough bandwidth and stability. In the evaluation, the size of each packet is as follows: (i) GeoBroadcast: from 189 to 264 bytes, (ii) GeoUnicast: 199 bytes, (iii) LS: from 86 to 94 bytes, and (iv) Beacon: 78bytes. The size of the GeoBroadcast packet, which contains a SrvRqst message, is variable because of the SLP's retransmission algorithm.

The total size of transmitted packets during the evaluation is 525Kbytes. Considering the evaluation is performed during 720 seconds, our proposed mechanism shows it does not consume much high bandwidth.

V. CONCLUSION AND FUTURE WORK

In this paper, we presented a location-aware service discovery mechanism for ITS applications in VANETs. The proposed mechanism is a harmonization of SLPv2 and IPv6 GeoNetworking developed in the GeoNet project. We showed that the IPv6 multicast-based service discovery using GeoBroadcast efficiently discovers services offered in the VANET without unnecessarily propagating IPv6 multicast packets into the entire VANET. We also implemented the proposed mechanism into Linux using the OpenSLP and the CarGeo6 implementations. The evaluation was performed in the field testbed in our campus.

As a next step we are conducting further field evaluations with more realistic scenarios. Although the proposed mechanism discovered services via not only single hop but also multiple hops with fairly low latency and low bandwidth usage, further improvements are necessary since the discovery success rate, specifically in the multi hop case, is not enough. It is also necessary to investigate how to discover services from/to the Internet in combination with IPv6 mobility support protocols.

Fig. 1 .

 1 Fig. 1. VANET in vehicular communication systems

Fig. 2 .

 2 Fig. 2. System overview

Fig. 3 .

 3 Fig. 3. Proposed Service Discovery stack

Fig. 5 .Fig. 6 .

 56 Fig. 5. Messaging sequence. LS is the abbreviation of Location Service, control messages of IPv6 GeoNetworking.

  We integrated the system into our field testbed facilities including three sets of MRs and attached hosts, which can be capable of testing multi-hop communication in a VANET. MRs are equipped with one Ethernet port as an ingress interface, and one wireless 802.11 b/g card used as an egress interface. Ubuntu 10.10 (kernel 2.6.35.11) is installed on all nodes. MRs can get current geographical position through GPS receiver connected via their USB port. In order to get coordinates, gpsd-2.96 5 is installed as a local TCP server. While routers run CarGeo6 and the IPv6 multicast forwarding daemon so that they operate IPv6 GeoNetworking and IPv6 multicast forwarding, attached hosts are conventional PCs that only support OpenSLP and legacy IPv6 multicast with MLD multicast capabilities. Applications and services only need to manipulate a set of OpenSLP functions.

		TABLE I
		SYSTEM CONFIGURATION
	Entity	Parameter	Configuration
	all Hosts	Number of services	100
	Host1	Service discovery frequency	1Hz
		Radius of GeoBroadcast	Random (50m-200m)
	all MRs	GPS position update frequency	1Hz
	MR1, Host1	Driving speed	0-20km/h
		Distance from SP1(Single hop)	10m -100m
		Distance from SP2(Multi hop)	120m -200m

The OpenSLP project. http://www.openslp.org/

The CarGeo6 project. http://www.cargeo6.org/

gpsd -a GPS service daemon. http://gpsd.berlios.de/

ACKNOWLEDGMENT

The authors would like to thank the Tunisian developers from ESPRIT and all the people involved in the CarGeo6 implementation for their effort in the development and support of the GeoNetworking layer and for their collaboration with the IMARA project-team (INRIA).