IPv6 address autoconfiguration in geonetworking-enabled VANETs: characterization and evaluation of the ETSI solution

Vehicular networks architectures typically allow for two types of communications: vehicle-to-vehicle (V2V) and infrastructure-to-vehicle (I2V). V2V communications are mainly used by safety applications (e.g., cooperative collision warning, pre-crash sensing/warning, hazardous location, cooperative awareness) while I2V communications are typically used by traffic efficiency applications (e.g., traffic Signal Phase and Timing--SPAT, recommended speed and route guidance). There is, however, increasing interest in also supporting Internet communications from and to vehicles. By allowing classical and new IP services to be accessible from vehicles, users would see an additional benefit in the installation of a communication system in their cars, and this would help increasing user acceptance and in turn facilitate initial deployment and market penetration.

Car manufacturers as well as public authorities are working together for the definition of communications standards in the vehicular environment. Because of the growing interest, vehicular networking has become a hot research topic in the last few years, due to its potential applicability to increase road safety and driving comfort. In particular, the use of vehicular ad hoc networks (VANETs) is being considered as the base candidate technology for these cooperative systems that are expected to significantly reduce the number of traffic accidents, improve the efficiency and comfort of road transport, and also enhance the passengers' communications experience. Although many applications of vehicular communications were already identified in the 80 s, large-scale deployment of such systems has finally become possible due to the availability of new technologies, such as devices based on the IEEE 802.11 standard family, which seem to offer an affordable compromise between performance and system complexity. The primary advantage of deploying this kind of self-organized network is the fact that timely critical applications, such as safety-of-life applications, can be implemented by letting vehicles directly communicate to each other, instead of relying on centralized entities.

Working groups and standardization bodies such as IEEE 1609,^a ISO TC204,^b ETSI TC ITS^c and the Car-to-Car Communications Consortium^d (C2C-CC) have been working on providing vehicles with connectivity, both among them and to the Internet. So far, priority has been given to those capabilities required to enable safety applications, but there is an increasing interest in also enabling Internet access from the vehicles. The Internet connectivity capability is seen by consumers as a very valuable feature in a mobile phone, a television, or any electronic equipment-- and thus has an impact on the user's decision when choosing what to buy--and so is expected to be the case in the near future for cars. The deployment effort required to equip roads segments with wireless attachment points connected to a network infrastructure is often regarded as a major obstacle. The use of multi-hop networks considerably aids in reducing this difficulty, as the density of needed access points is reduced. This, however, brings the challenge of how to smoothly interconnect vehicular networks to the Internet.

The European Telecommunications Standards Institute (ETSI) TC ITS is the technical committee that received a standardization mandate from the European Commission for the development of short-range Intelligent Transport Systems (ITS) communication protocols. Recently, the ETSI has finalized the standardization of the mechanisms [1] required to integrate IPv6 in the harmonized communication system for European ITS [2]. The ETSI TC ITS architecture benefits from geographical location awareness of cars (it is assumed that all vehicles know its geographical location, by means of using a GPS or similar device) to extend the concept of IPv6 link to a specific geographical area. This article first presents the geographical location aware vehicular architecture standardized by ETSI, commonly referred to as geonetworking, and then describes in detail how IPv6 datagram transmission and standard IPv6 stateless address autoconfiguration mechanisms are performed on top of the ETSI geonetworking protocol stack (Section 2). Since the ETSI geonetwork-ing architecture is based on the use of a vehicular ad hoc network (VANET), we identify in this article the range of conditions in which multi-hop connectivity to the Internet from vehicles is effective, considering the vehicular density, the coverage radius of the wireless technology, and the distance between attachment points in the infrastructure (Section 3). These conditions define the main target scenarios in which vehicles can use IPv6 to communicate, and therefore the scenarios in which address auto-configuration mechanisms for vehicular networks must work. Next, the article includes a rigorous analysis of the ETSI stateless IPv6 address autoconfiguration mechanism, based on the identified target scenarios. An analytical model (Section 4) and a simulation-based evaluation of its performance are provided, which helps us derive configuration guidelines of the solution depending on the scenario where it is deployed and the traffic conditions (Section 5). Finally, we conclude the paper by summarizing the main conclusions of our in-depth analysis, highlighting the situations in which additional extensions to the base solution defined by ETSI may be required, and briefly discussing the associated trade-offs (Section 6).

The main purpose of an IP address auto-configuration protocol is to provide each node with a valid IP address as soon as possible. In the followings we derive an analytical expression of the time required by the ETSI SLAAC solution to configure an address.

The address configuration time (T_conf) is the time elapsed since a vehicle enters a new geographical area (therefore loosing the connectivity to the old RSU) till the moment in which it can start using the newly configured global IPv6 address. This time depends on several factors, such as the shape and size of the areas, the configuration of the RSUs and ARs, etc.

We consider that the time between two consecutive RAs sent by an RSU (or an AR in case the RSU is working in bridge mode) follows a uniform distribution between a minimum value (MnRtr AdvInterval) and a maximum value (MaxRtr AdvInterval), which we refer to as R _m and R _M , respectively [20].

We use the following additional terminology. Let D _rsu be the distance between two adjacent RSUs, R the wireless communication range, β the vehicular density and v the speed of the vehicles.^k

In order to obtain a mathematical expression for T_conf, we first calculate the mean length of a chain of vehicles. Based on that, we are able to find out which is--on average--the length of the gap between the multi-hop chain of vehicles from the unconfigured vehicle and the RSU wireless coverage area ${\bar{D}}_{gap}$ (see Figure 8).

In order to validate the accuracy of our model and assess the performance of our solution, we performed the following experiments. We evaluated the configuration time ${\bar{T}}_{\mathsf{\text{conf}}}$ under different traffic conditions and for different deployment configuration parameters. The traffic conditions are defined by the vehicular density (β) and speed (v), while the considered deployment configuration parameters are the distance between RSUs (D _rsu ), the radio wireless coverage of each node (R), and the average time between unsolicited RAs (T_RA). The same Matlab-based simulator that was used in Section 3 to assess the effectiveness of multi-hop unicast communications in a vehicular scenario is used in these experiments. Therefore, an ideal wireless technology is assumed. In the next section we also perform an experimental evaluation based on a more complex model, and using the OMNeT++ simulator, that allows us to assess the correctness of the simplifications assumed in our mathematical model of the ETSI SLAAC configuration time, and also to derive some configuration guidelines.

The results obtained from our simulations (with a confidence interval of 95%) are shown in Figures 9, 10 and 11, in which the values calculated from our analysis are also depicted. We make use of the same three scenarios that we used in Section 3: urban, city highway, and motorway, and we also represent the results for different deployment scenarios (characterized by D _rsu and ${T_{\mathsf{\text{RA}}}}^1$). Note that the range of the average time between Router Advertisements sent by the RSU (T _ra ) depends on the traffic conditions scenario. This is so because the maximum value that could be configured in a real scenario should allow for vehicles to always have at least one configuration opportunity before changing area and that means that T_RA has to be low enough to allow that a vehicle would be configured--in the worst possible case-when it is within one single hop of the RSU (i.e., the minimum time required by a vehicle to cross the whole coverage area of the RSU should not be higher than R _M ). Note that in Figure 9 (urban scenario) we only show the case R = 150 m, as the results for R = 300 and R = 450 m are almost exactly the same (the actual difference is negligible). Similarly, for the city highway and motorway scenarios (Figures 10 and 11) we also skip (due to space constraints) depicting the results for R = 450 m, as they are equivalent to those for R = 300 m. This is due to the fact that in the studied scenarios, the vehicular density proves to be enough to ensure multi-hop connectivity in most of the situations, and therefore ${\bar{T}}_{\mathsf{\text{conf}}}\simeq {\bar{T}}_{\mathsf{\text{RA}}}^{\mathsf{\text{unsol}}}$. These are reasonable scenarios in terms of vehicular density, and they are actually the ones in which it makes sense to enable Internet multi-hop communications, as the probability of having multi-hop connectivity to the RSU is high enough, and the configuration time is short enough to support classical IP communications (e.g., infotainment, non-safety). We also analyze later in the paper sparser scenarios, in which the vehicular density is much lower.

From Figures 9, 10, and 11 we can derive different conclusions. First of all, results show that our mathematical analysis perfectly matches our model of the ETSI SLAAC solution configuration time, assuming the simplifications that we have described in this section, namely: constant and homogeneous speed, perfect collision-free wireless medium, exponential inter-vehicle spacing. Another important conclusion is that in most of the scenarios, the IP address auto-configuration time can be kept very low by properly configuring the time interval between Router Advertisements, without using too aggressive values. Besides, in these scenarios the value of the wireless coverage technology (R)--which depends on the particular access technology, transceiver performance, antenna, and channel conditions--and the distance D_RSU between deployed RSUs do not seem to have a noticeable impact on the resulting configuration time. Nevertheless, we should not forget that shorter values of R combined with larger values of D_RSU would lead to longer multi-hop paths, in terms of number of traversed nodes, and therefore lower effective bandwidths. Only for R = 150 m and in the motorway scenario (this behavior starts to be noticeable in the city highway scenario), the distance between RSUs has an impact on the configuration time, as the chances to have multi-hop connectivity between an unconfigured node that just enters into an area and the RSU decrease with the distance between them (D_RSU). In the motorway scenario, as we could anticipate from the results shown in Figure 4, configuration times are higher--though still reasonable--as the probability of having a multi-hop chain between the unconfigured node and the RSU is lower.

A simple qualitative evaluation of the ETSI SLAAC performance can be done by comparing T_conf with the estimated permanency time of a vehicle within a geographical area. For the sake of the example, let us consider a non-extreme case, as the one of an area with a length (D_RSU) of 2,000 m and a wireless radio technology with R = 300 m, in the city highway scenario (average speed of 80 km/h). In this scenario, a vehicle spends about 90 s in the area. By choosing values of T_RA smaller than 10 s, the ETSI SLAAC solution guarantees that vehicles can have Internet connectivity for more than 80 s, as ${\bar{T}}_{\mathsf{\text{conf}}}$ is approximately 5 s. However, it is important to highlight that the configuration parameters, such as the size and shape of the geographical areas, should be chosen also taking into account the expected traffic conditions. For example, in sparse scenarios, areas should be longer than the physical radio coverage R, while in dense scenarios the opposite case is more appropriate. We derive some simple configuration guidelines in Section 5.

In addition to these experiments, we performed some simulations to validate the correctness of our mathematical analysis also in scenarios in which the vehicular density is not high enough to have multi-hop connectivity during most of the time (β = 10 veh/km, v = 100 km/h). Examples of this scenario are city highways and motorways at night, or secondary roads. Results (see Figure 12) show that our mathematical analysis also matches the simulation results in sparse scenarios (i.e., with low values of P_mhc). Regarding the time required to configure a new address, obtained results confirm what we could anticipate from Figure 6, that is, in these scenarios it takes a long time to get an address, because in many cases the vehicle is not able to receive an RA until it is within the 1-hop coverage of the RSU. This also means that during a considerable amount of the time a vehicle is visiting a geographical area, it does not benefit from having connectivity with the RSU. It can also be observed that in this kind of scenario R has a bigger impact on the performance, as higher values of R lead to higher multi-hop connectivity probabilities.

In this section we take a step further and experimentally evaluate the performance of the ETSI SLAAC solution--in terms of address configuration time-eliminating some of the simplifications assumed in the previous section. The goal is to assess if our mathematical model is still good enough when we use a simulation model that better replicates a real environment.

The obtained simulation results are shown in Figure 13 for the three scenarios we used and for different inter-RSU distances. The results obtained from our mathematical model are also depicted in the figure. Note that since we are using a realistic wireless model, the value of R is no longer a constant value. In order to select an appropriate value to be used in our mathematical model, we performed simulations with OMNeT++ aiming at finding the average wireless coverage radius resulting from the wireless layer settings used in the simulations. The resulting value is R = 225 m. From the results shown in Figure 13, we can observe that our mathematical model approximates quite well the experimental results obtained with OMNeT++.

The last simulation experiment we performed to validate our mathematical analysis is the following. Using the OMNeT++ simulator, we take the position and speed of vehicles on a real road from real traffic traces, and measure the ETSI SLAAC configuration time. The traces were taken at the 4-lane highway A6 in Spain, in the outbound direction from Madrid, and account for the traffic from 8:30 to 9:00 a.m. (which can be considered as near to rush hour). The total amount of samples is 2985. For each sample, we have a time-stamp and the speed of the vehicle. We consider that the measurement point is the border between two geographical areas and that each vehicle keeps the same speed while traversing the area. In our simulation environment, we fix the distance between two RSUs to 2,000 m. We plot in Figure 14 the results obtained from the simulation and our mathematical analysis (Equation 13). In Equation (13) we use the vehicular density calculated from the traces (β = 38.2veh/km) and the average speed (v = 95.11 km/h). As it can be observed from Figure 14, there is a small gap between the simulation results and our mathematical model, although the model still approximates the real performance. This gap is due to the fact that our model is a simplification of the real scenario, and as a result, our analysis is optimistic. Our model does not consider the non-idealities of the wireless media, assumes a perfect exponential inter-vehicle spacing and considers that all vehicles travel at the same speed. We learned from the previous experiments with OMNeT++ (Figure 13) that the deviation from considering an ideal wireless media seems to be pretty small. Therefore, we conjecture that the deviation found in Figure 14 is due to the fact that inter-vehicle spacing does not exactly follow an exponential distribution,p and also the fact that vehicles do not all travel at the same speed.

In this case, dynamic reconfiguration of the RSU is not possible or just very limited (e.g., configuration based on the time of the day).

This article makes a thorough analysis of the IPv6 integration in vehicular networks, paying special attention to the IPv6 address auto-configuration functionality. We consider the recently standardized mechanisms by the ETSI TC ITS, and first assess the feasibility of IPv6 multi-hop communications, by means of analysis and simulation. Then, we focus on the IPv6 address auto-configuration, explaining how IPv6 SLAAC mechanisms can be run over the ETSI TC ITS protocol stack, and characterizing the configuration time performance.

Multi-hop vehicular networks are needed to reduce the cost of fix infrastructure deployment. This article explores which are reasonable scenarios for Internet access from vehicles, considering vehicular density, the radius of coverage of the wireless technology, and the distance between access points in the infrastructure. The reasonable scenarios are characterized by a high probability of reaching the fixed infrastructure from vehicles. These are the target scenarios for address auto-configuration solutions for vehicular networks. We make the point that considering other scenarios blindly can lead to misleading results about the performance of the solutions, since when communications are not possible, a success of failure in configuring an address is basically irrelevant.

In the article we derive an analytical expression for the average time interval required by a vehicle using the ETSI SLAAC solution to configure a new address; and we validate the analytical model by means of extensive simulations using realistic wireless transmission model and real vehicular traces. Finally, the article also provides configuration guidelines that allow to make designs for achieving target address configuration delays in different scenarios. In terms of solution performance, particular focus is put on this address configuration time interval, which is a key figure of merit due to the possibly frequent subnet changes experienced by a moving vehicle. The detailed analytical characterization of the ETSI SLAAC solution allows to obtain pre-determined performance upper limits defined by the applications, facilitating a gradual and effective deployment of short-range Internet-based vehicular applications. The obtained results of our analysis show that there is room for additional extensions to the base ETSI SLAAC solution, which can reduce the IP address configuration time by introducing additional complexity (e.g., in terms of changes to the IPv6 stack or additional processing). Among the several approaches that are worth exploring, we can mention for example the use of maps with prefix information enabling ITS stations to know in advance the advertised IPv6 prefixes per GVL area, or the overhearing of prefix information of neighboring GVL areas [25]. There might be applicability scenarios that deserve a careful analysis of the trade-offs involved by implementing extensions to the base ETSI SLAAC solution.

Next steps include the implementation of the ETSI TC ITS architecture and its validation and performance evaluation in real environments, for example by means of field operational tests (FOTs) conducted in the testbed platforms currently being deployed in Europe.

^a http://www.standards.its.dot.gov/fact_sheet.asp?f=80

^b http://www.iso.org/iso/iso_technical_committee?commid=54706

^c http://www.etsi.org/website/Technologies/IntelligentTransportSystems.aspx

^dhttp://www.car-to-car.org/.

^eInternet Engineering Task Force: http://www.ietf.org/.

^f For example, 2001:DB8:1:1::/64 and 2001:DB8:1:2::/64 are non-overlapping prefixes, while 2001:DB8:1::/48 and 2001:DB8:1:2::/64 are overlapping..

^ghttp://www.geonet-project.eu/.

^hMore precisely, in this solution gateway selection is performed by the infrastructure itself and not by the nodes as in many MANET approaches..

ⁱThe code of this simulator is available at http://fourier.networks.imdea.org/people/~marco_gramaglia/sims/ETSI-SLAAC/

^jIt is also very likely that in the future, cars are equipped with a dedicated interface for safety-related communications and one (or several, but of different technologies) for IP non-safety-related communications..

^kWe consider the speed of all vehicles fixed and constant for simplicity of the model. Simulation results that we will present later show that this simplification does not affect the validity of the conclusion of our analysis..

^lR _M = 1.25T_RA and R _m = 0.75T_RA..

^mThe code of this simulator is available at http://fourier.networks.imdea.org/people/~marco_gramaglia/sims/ETSI-SLAAC/

ⁿhttp://mixim.sourceforge.net/.

^ohttp://www.omnetpp.org/.

^pWe analyzed the inter-vehicle spacing from the used traces and it is close to an exponential distribution, as suggested in [15], but with some minor deviation. As future work, we are currently modeling this inter-vehicle spacing, based on real traffic traces [26].