Seamless internet 3G and opportunistic WLAN vehicular connectivity

2 SILVIO: enabling 3G offloading in the vehicular scenario

In this section, we present SILVIO--our solution to efficiently provide vehicles with Internet connectivity. An overview of the addressed scenario and the basics of the protocol operation are first presented, before describing the details of the main components of the solution.

2.1 Solution overview

SILVIO aims at providing Internet connectivity in a vehicular scenario like the one shown in Figure 1, in which most vehicles contain several devices demanding connectivity. We argue that vehicles need to be equipped with two different wireless communications technologies: (i) 3G, to provide close-to always available connectivity, and (ii) WLAN, to provide opportunistic access through a multi-hop VANET whenever possible. So far, most of the proposed solutions use a single technology, or at most, suggest to use one for data forwarding and the other for complementaThe use of one single technology is not suitable in real scenarios, as no one can independently meet the actual connectry signalling purposes [6]. ivity requirements posed by vehicular users (i.e., always-available connectivity, mobility support, moderate to high bandwidth) and, operators (i.e., requisites related to scalability and cost). The use of 3G allows to meet the availability and mobility requirements and partially the bandwidth one, but aggravates the scalability concern of mobile operators: 3G infrastructures are currently quite overloaded and there is no room for significant improvement using existing technologies (as the radio spectrum is limited). The use of WLAN access technologies potentially enables the provision of higher bandwidth to vehicular users, but poses important challenges in mobility management and cannot achieve the same level of connection availability. Even if a multi-hop VANET-alike scheme is used, full coverage cannot be ensured and additionally, routing in multi-hop networks poses important difficulties. Last but not least, mobility management becomes harder in this scenario, due to the frequent changes of layer-2 point of attachment.

SILVIO benefits from the simultaneous use of the two different access networks: 3G and WLAN. Since a permanent WLAN good connectivity cannot be ensured (even if a multi-hop scheme is adopted) SILVIO uses the 3G access network for critical or real-time constrained traffic (e.g., voice calls), which cannot afford any delays or interruptions. The WLAN connectivity is sensed, detected and used opportunistically for data packets of less critical applications, which can cope with some minimal delays and can also benefit from higher instantaneous available bandwidths (e.g., web browsing, file sharing, or video streaming, among others). Note that a key characteristic of our proposal is that this second category of data traffic is transparently moved from the 3G to the WLAN access--depending on the availability of WLAN connectivity--without any application support needed, thanks to the use of an Internet protocol (IP) flow mobility approach. Also, when WLAN is not available, all traffic is sent and received via the 3G interface, which generally implies that non-critical applications enjoy less bandwidth than when WLAN is also used.

We next cover each of the previous aspects in more detail, explaining the role played in SILVIO by each of the technologies, and highlighting the novel aspects of our proposal.

2.2 Basic Internet connectivity provision: network mobility

Vehicles contain several devices demanding to have Internet connectivity: internal sensors, on-board computers, infotainment back-seat boards, etc.; but also external devices, such as laptops or personal digital assistants (PDAs), carried by passengers. This basically means that a vehicle can be seen as a network (or even as a set of networks) that is moving while connected to the Internet. In SILVIO these in-vehicular networks are provided with connectivity by means of using the network mobility (NEMO) basic support protocol.

The NEMO basic support protocol [15], proposed by the Internet engineering task force (IETF^b), extends the basic end-host mobility solution, Mobile IPv6 [16], to provide network mobility support. In this solution, a mobile network (known also as Network that Moves--NEMO^c) is defined as a network whose attachment point to the Internet varies with time. The router within the NEMO that connects to the Internet is called the mobile router (MR). It is assumed that the NEMO has a Home Network, connected to the Internet, where it resides when it is not moving. Since the NEMO is part of the Home Network, the mobile network nodes (MNNs) have configured addresses belonging to one or more address blocks assigned to the Home Network: the mobile network prefixes (MNPs). These addresses remain assigned to the NEMO even when it is away from home. Of course, these addresses only have topological meaning when the NEMO is at home. Thus, when the NEMO is away from home, packets addressed to the MNNs will still be routed to the Home Network, and redirected by the home agent (HA) to the current location of the MR. When the NEMO is connected to a visited network, the MR acquires an address from the visited network, called the care-of address (CoA), where the routing architecture can deliver packets without any additional mechanism (Figure 2).

2.3 Offloading the 3G network: flow mobility

In SILVIO, mobile routers are not only equipped with a 3G interface, but also with a WLAN one, that is opportunistically used to offload part of the traffic from the 3G one. Let us consider that the WLAN interface provides intermittent connectivity to the Internet (how this connectivity is achieved is the subject of Section 2.4), these connectivity opportunities can be used to dynamically move (i.e., offload) part of the total traffic sent/received by/at the vehicle to the WLAN access, reducing in this way the load of the 3G network. We describe in Section 2.6 the design of the automatic mechanisms (the intelligence) that decide which packets are moved, when they are moved, and from which interface to which interface. Next, we explain the mechanism used by SILVIO to provide the capability of seamlessly moving traffic between interfaces, which is based on IP flow mobility extensions.

IP flow mobility refers to the movement of selected IP flows from one interface to another, of course minimizing the impact on the user experience. In order to do so, an IP mobility protocol should allow for the simultaneous use of different care-of addresses associated to the same home address. This feature must be able to selectively send packets addressed to the same node via different access networks (identified by its CoAs). Regular Mobile IPv6 and NEMO B.S. do not provide flow mobility, so to enable it, the IETF has standardized the basic components that are required. These components are: (i) multiple CoA registration support (standardized in the RFC 5648 [17]), (ii) flow bindings support (standardized in RFC 6088 [18] to allow mobile routers to bind one or more IP flows to a specific care-of address), and (iii) traffic selectors definition (standardized in RFC 6089 [19]).

So far we have described the tools required to provide in-vehicle devices with Internet connectivity using one primary access technology (e.g., 3G), and to selective and opportunistically offload part of the traffic to another secondary access technology. In SILVIO, this secondary technology is WLAN, with connectivity being provided via a multi-hop VANET. We next describe how this is done in SILVIO.

2.4 Multi-hop WLAN vehicular Internet connectivity: addressing and routing

Providing wireless connectivity in VANETs in a cheap and scalable way has been a widely researched topic in the past decade. Finally, the need to achieve a cooperative and low latency network, motivated the use of dedicated short-range communications devices for these purposes (like the IEEE 802.11p-capable ones). Vehicles travelling together form an ad hoc network, where the actual wireless coverage is extended using multiple hops. Vehicles take advantage of fixed nodes placed along the roads, called road side units (RSUs), especially for safety-related purposes. However, as RSUs are connected to the infrastructure network, they can also be used to provide vehicles with Internet connectivity using a multi-hop wireless path.

Mobility management is also an important feature, which we have intentionally not included in the previous list, because SILVIO handles mobility in an integrated way, not limited to the access technology used (VANET in this case). Therefore, in this subsection, we focus on the IP address configuration of the WLAN interface, and how packets are routed within the VANET. This is a problem that has been quite heavily investigated in the past, but that still poses many interesting research challenges. SILVIO adopts an approach based on the use of TREBOL [14], a routing protocol for VANETs, specifically designed for V2I communications.

TREBOL is a tree-based routing protocol that can be used, without any additional control message overhead, also for auto-configuring valid IPv6 addresses. Data paths follow a tree built using the TREBOL protocol. The tree is composed by a set of nodes chosen using geographic criteria, like relative distance and speed (all vehicles are assumed to have a global positioning system (GPS) receiver). However, the forwarding decision is topological (i.e., address based), and therefore avoids the extensive beaconing load and the use of a location service, typical drawbacks of geographic routing protocols. The tree built by TREBOL is anchored at the RSU, which plays a fundamental role as it is the relay to the Internet, and all the data traffic has to pass through it.

In TREBOL, the tree used to forward data packets from the vehicles to the Internet is called Upstream tree. It is built and subsequently updated using periodical configuration messages (CM) sent by the RSU. Upon the reception of a CM each node learns about its parent and uses it as next hop to the RSU. The RSU is assumed to act as relay (forwarding packet to/from the Internet) just for vehicles placed in a limited geographical area (Figure 3). Therefore, the CMs are distributed just within the area controlled by the RSU that is broad-casting them. The tree used to forward data packets from the Internet to the vehicles is called Downstream tree. Unlike the upstream one, the downstream tree follows a reactive approach: each node learns about its children (i.e., the nodes that are using it as next hop to the RSU) on a per data packet basis, as an additional task in the forwarding process.

Configuration messages periodically refresh the set of nodes that are in charge of forwarding data packets and are identified by an incremental sequence number. Once a node receives a CM with newer sequence number, it sets the sender of that CM as parent node. Afterwards, it starts a parent node selection process based on a backoff timer. Among all the nodes that have received the CM from the same sender, the node that has the lowest backoff timer can regenerate the CM (i.e., updating some fields but keeping the original sequence number value) and send it, becoming part of the parent nodes set. All the nodes that receive a CM with an already processed sequence number (i.e., sent by a node with a shorter backoff time) cancel their scheduled retransmission.

The tree composed by the parent nodes set has to be as stable as possible. Therefore, the backoff time is calculated using motion-related information, such as the position and the speed of the vehicles. The downstream tree is updated by the parent nodes on the reception of data packets from the children. Each node while acting as parent inspects the traffic it is forwarding and builds a table collecting information about its descendants. The forwarding state is hence updated, associating to every child node that is forwarding datagrams, the information about the original sender. As stated in the beginning of this section, VANET nodes must be configured with a valid IP address, used by the routing protocol to forward packets to the Internet. Although many different address configuration protocols for VANETs can be used to achieve this functionality, SILVIO exploits an additional feature of TREBOL. As all the nodes within a certain area receive CMs to accordingly update their next hop to the RSU, these messages can also convey IPv6 prefixes. Then, using the standard IPv6 stateless address autoconfiguration (SLAAC) [20] mechanism, vehicles can configure a valid IPv6 address, ready to be used for Internet connectivity.

SILVIO assumes the use of TREBOL as defined in [14] to enable routing and addressing within the VANET, although it is integrated with the flow handover intelligence of SILVIO to decide when to opportunistically perform traffic offloading to the WLAN-based VANET (as explained in Section 2.6). Further details about TREBOL are included in [14].

2.5 Seamless interface management: vehicular-aware IEEE 802.21

Since WLAN connectivity is intermittent, the mechanisms must efficiently detect when it is available, and also predict when it is expected to disappear (e.g., because the terminal is leaving the coverage area of its current point of attachment). This prediction should be done with enough anticipation, so the handover can be prepared and performed in such a way that packet losses are minimized.

SILVIO integrates and extends the IEEE 802.21 standard to enable an enhanced interface management, capable of providing seamless intra and inter-technology handovers. We next briefly present the IEEE 802.21 standard, before identifying the possible handover situations that may occur in our vehicular scenario, and explaining how SILVIO supports them all.

The IEEE 802.21 [21, 22] or media independent handover (MIH) technology is an enabler for the optimization of handovers between heterogeneous IEEE 802 systems as well as between 802 and cellular systems. The goal is to provide the means to facilitate and improve the intelligence behind handover procedures, allowing vendors and operators to develop their own strategy and handover policies. For this purpose, the IEEE 802.21 aims at optimizing the handover procedure between heterogeneous networks by adding a technology independent function (media independent handover function [MIHF]) which improves the communication between different entities, either locally (mobile node) or remotely (network functions).

Sharing information allows handover algorithms to guarantee seamlessness while moving across different points of attachment in the network and the use of common commands greatly simplifies the design of the algorithms.

The information exchange occurs between lower layers and higher layers, taking always the MIH Function as reference. Furthermore, information can be shared locally, within the same protocol stack, or remotely, between different network entities.

The IEEE 802.21 defines different roles according to the relationship between the network-based MIHFs and the mobile node/router. In this way, it defines the concept of point of service (PoS) and point of attachment (PoA). The former identifies a network-based MIHF that talks directly to a mobile node, while the latter corresponds to the network side end-point of an L2 link that includes the mobile node as the other endpoint.

Note that in a multi-hop VANET scenario, a vehicle can lose connectivity because of two different reasons: (i) its parent (i.e., the node that is currently using to connect to the Internet) is no longer reachable; or (ii) the chain of connected vehicles between the vehicle and the RSU becomes unconnected (i.e., one parent node becomes unreachable somewhere in the path). Note that (i) is a particular case of (ii). In this case, it is very important to predict with enough anticipation if the WLAN access is about to become unusable, so the IP mobility signalling and associated state updates are all done before the WLAN access becomes unusable (with the obvious packet losses).

Link Down and Link Going Down messages are triggered in SILVIO as follows: when a node detects that its parent node is going to become unreachable imminently, it advertises that event to all nodes (if any) in the VANET that are sending traffic which is traversing that parent node, so they can all move the traffic to their 3G interface. Note that a vehicle obtains information about all the nodes that are sending traffic in the VANET as part of regular TREBOL operation.

Existing IEEE 802.21 procedures and messages cannot be used to inform about a future potential change of point of attachment and IP address. SILVIO defines a new Link Going Up message that is sent when this event is predicted, allowing the mobile router to perform the required mobility signalling of a subsequent change of area in advance. SILVIO generates Link Going Up messages by overhearing CM messages from neighbouring areas (in a way similar to what is reported in [11]). When a node receives a CM that has been generated in a different area, it has to filter it to preserve the logical division in areas. However, the information contained in the message can be used to learn the IPv6 address of RSU on the neighbouring area, as well of the IPv6 prefixes that should be used for address configuration purposes there.

2.6 Opportunistic WLAN use: smart vehicular handover management

In order to design a flow handover mechanism suitable for multi-hop wireless VANETs, a careful evaluation of many aspects--such as the vehicle mobility and the presence of two-way vehicular traffic--needs to be conducted. From the point of view of complexity, the simplest technique consists in not fully exploiting the multi-hop nature of VANETs and only use WLAN connectivity when the vehicle is directly connected to the RSU (i.e., 1-hop reachability). Taking this as starting point, more complex and performance appealing approaches can be devised. Another aspect that needs to be taken into account is the cost associated to a flow handover. Since WLAN and 3G connectivity might exhibit disparate round-trip times, transmission control protocol (TCP) connections can be affected as a result of a flow handover. Additionally, too aggressive handover approaches, may lead to handovers to WLAN when the quality and stability of the connectivity are not yet good enough, causing the so-called ping-pong effects (i.e., sequence of handovers back and forth between WLAN and 3G). Another issue to be considered is related to the actual deployment of RSUs, which are usually placed alongside the roads. Given a fixed installation point, vehicles can get closer or go away to/from the RSU. However, while vehicles approaching to the RSU would take advantage of better wireless condition and even use a higher data rate [24], vehicles moving away would face the opposite.

Algorithm 1 S-direct pseudo code.

if vehicle attached only to the 3G network then

   if (WLAN available) & (# hops = 1) then

      vehicle attaches also to WLAN

      vehicle offloads best-effort traffic to WLAN

   end if

else

 if vehicle attached to 3G and WLAN then

   if (vehicle loses Internet connectivity via WLAN) then

   vehicle moves back offloaded traffic to 3G

    end if

  end if

end if

3.1 Evaluation framework

One of the biggest challenges that we have to face when doing research in the vehicular area is that validating and evaluating the performance of the designed mechanisms is usually very hard. On one hand, it usually requires involving a relatively high number of vehicles, making experimentation with real life prototypes deployed in cars quite unfeasible. Among the several vehicular testbeds that have been deployed in the last years, we can highlight the following: Cartel and Cabernet projects at MIT [25, 26], Dome and DieselNet at Amherst [27], VanLan by Microsoft Research [28] and C-VeT at UCLA [29]. None of them meet the requirements, in terms of number of required vehicles, to evaluate the performance of SILVIO.

Algorithm 2 S-conservative pseudo code.

if vehicle attached only to the 3G network then

   if (WLAN available) & (# hops ≤ t-hops-wlan) & (# attempts < 1) & (vehicle getting closer to the RSU) then

      vehicle attaches also to WLAN

      vehicle offloads best-effort traffic to WLAN

   end if

 else

   if vehicle attached to 3G and WLAN then

      if (vehicle loses Internet connectivity via WLAN) then

        vehicle moves back offloaded traffic to 3G

    end if

   end if

end if

The previous reasoning leads us to using simulation as the only feasible tool to conduct our study on the performance of SILVIO. However, modelling the wireless environment precisely in this scenario is quite hard, and virtually impossible in practical terms. Therefore, some simplifications and assumptions need to be made, which more often than not, tend to invalidate the obtained results, as the simulation engine does not take into account aspects as important as the vehicular mobility patterns or the obstruction that vehicles themselves may represent to the wireless signal. Boban et al. [30] introduced for the first time the problem of considering other vehicles as obstruction for wireless communications. Our simulation framework takes into account the obstacles represented by large vehicles (e.g., trucks, vans) as we explain later in this section.

Algorithm 3 S-persistent and S-sticky pseudo code.

 if vehicle attached only to the 3G network then

   if (WLAN available) & (vehicle getting closer to the RSU) then

      if (# hops ≤ t1-hops-wlan) & (# attempts < t-ho-attempts) then

         vehicle attaches also to WLAN

         vehicle offloads best-effort traffic to WLAN

      else

         if (# hops ≤ t2-hops-wlan) then

            vehicle attaches also to WLAN

               vehicle offloads best-effort traffic to WLAN

         end if

      end if

   end if

else

   if vehicle attached to 3G and WLAN then

      if (vehicle loses WLAN connectivity) then

         vehicle moves back offloaded traffic to 3G

      end if

   end if

end if

In order to overcome the problem of oversimplifying the position and speed of vehicles during each simulation run, we build our simulated scenario upon realistic vehicular traces. In particular, we use SUMO^e, a microscopic road traffic simulation package that can reproduce typical behaviours of vehicular traffic, fed with real 12-h vehicular traces (Figure 8a). These traffic traces, kindly provided by the Madrid city council, were collected at a fixed measurement point placed along the M-30 orbital motorway in Madrid.

Our data set includes also the length of the vehicles (Figure 8b). This information is used to infer the type of the vehicle: short (e.g., less than 6 m) and large in other case (accounting for less than the 3% of the total). Our simulations take into account the type of vehicle, with large vehicles representing obstacles that block the wireless signal.

Our evaluation framework is based on Java simulator that merges the output coming from SUMO with the calculated RSSI values. RSSI values are calculated from [23] depending on the distance between vehicles^f. The value of the inter-vehicle distance fixes the average and the standard deviation of a Gaussian distribution from which the actual value of the RSSI is calculated. The same work [23] shows that the minimum RSSI value that provides a packet delivery ratio greater than 90% is 12, for a wireless card with an Atheros-based chip-set.

The wireless channel quality between two nodes is considered to be bad if the RSSI remains for more than 0.3 s below the reference value of 12. Additionally, if a large vehicle (i.e., longer than 6 m) appears between a vehicle and its next-hop vehicle, the channel quality is considered to be under the threshold as well. Note that this last rule is not applied for the direct connectivity between a vehicle and the RSU, as we claim that RSUs will be installed in elevated positions where the influence of large vehicles would be negligible.

For the experiments, a simulated city highway scenario is used. Road side units are deployed at different distances (denoted by D _RSU , which is the distance between two consecutive RSUs): every 1,000, 2,000 and 3,000 m. Each trace comprises 500 vehicles, while the total running time depends on the actual vehicular flow. We divided the traces into two categories (Figure 8a): high density (i.e., 500-vehicle data sets between 19 and 21 h) and low density (i.e., 500-vehicle data sets between 22 and 24 h).

3.2 Results and performance analysis

In this section, we present a performance analysis based on the results obtained with the simulator described above. Using the simulator on the previously described scenario, the following statistics can be obtained: time spent by each vehicle in 3G and WLAN, number of hops to the RSU when connected via WLAN, number of handovers per TREBOL area and signalling overhead. Note that, while the developed simulation-based framework does not completely model a vehicular network, it does cover the critical components required to evaluate the previous metrics. The goal of this analysis is not only to characterize the performance of the solution, but also to study how each of the operation modes of SILVIO behaves, as well as the impact of the different configuration parameters (i.e., the thresholds). This allows us to gain understanding on how to deploy SILVIO, depending on which is the target scenario.

While presenting the performance results, we analyse them from two different points of view: the mobile operator's and the user's. SILVIO has been designed with these two players in mind, as it is a solution that aims at providing the best possible connectivity experience to vehicular users, while being feasible and not aggravating the congestion problems that operators are already facing in their 3G networks.

where RA_H and TREBOL_H are the Router Advertisement and TREBOL headers, respectively. The hosts EUI48 addresses host_EUI48 are used as their unique identifiers. Using these values, the total overhead is 156 bytes for the low density case and 360 bytes for the high density one. The load caused by this message is for a single hop, so it has to be multiplied for the maximum depth of the tree generated by TREBOL.

Figure 9 shows the per-node control overhead of the four different SILVIO operating modes considered (S-direct, S-conservative, S-persistent and S-sticky), for different vehicular densities and deployment scenarios. As expected, the signalling overhead of S-direct is the lowest one, as it can only offload traffic when the vehicle is directly connected to the RSU. As expected, when SILVIO operates more aggressively in terms of WLAN stickiness, the generated overhead increases with the number of handovers. S-conservative is the next one after S-direct in terms of overhead, due to its limit on the number of handover attempts. Note that the average control load decreases with the size of the TREBOL area, as the handover frequency decreases too. In all cases, the overall control load is very low, and therefore it does not represent a burden on the feasibility of the solution deployment.

A performance metric that is relevant to both users and operators is the amount of time that the solution allows to effectively offload traffic from 3G to WLAN.

From the obtained results, it is worth highlighting the improvement achieved for the deployment scenario in which RSUs are installed every 1,000 m. This can be explained by the fact that S-conservative allows vehicles to try getting multi-hop connectivity through the VANET, though only once per area. This is actually the reason of this improvement not being bigger for longer D_RSU values (2,000 and 3,000 m).

Finally, results for S-sticky are presented in Table 4, showing similar results to what is obtained with S-persistent. If we look at all the results, it can be observed that increasing t-hops-WLAN improves the time exploiting WLAN connectivity. However, this improvement does not come without costs, as we explain next. Figure 10 shows the downside of increasing t-hops-WLAN. On one hand, the periods of WLAN connectivity are larger, as there are more opportunities to connect to the VANET, but on the other hand, this also causes a more intermittent connectivity, with "holes" in the WLAN multi-hop path that have to be fixed by moving to the 3G network the affected flows. Besides, these periods of time spent on the 3G while finding another offloading opportunity are on average shorter. This consecutive and frequent handoffs may have a negative impact on the user's experience. As an example, TCP RTT estimation may get affected by flow handoffs, due to the likely disparate access delays of WLAN and 3G networks.

Tree-depth	DRSU (m)	Density	Time 3G (s)	Time WLAN (s)	Offload (%)	# Handoffs	Improvement (%)
2	1000	LO	10.51 ± 0.11	29.99 ± 0.11	74.04	1.30	32.89
	1000	HI	10.15 ± 0.10	33.81 ± 0.10	76.90	1	38.15
	2000	LO	49.53 ± 0.09	32.32 ± 0.09	39.49	2.13	41.90
	2000	HI	52.40 ± 0.09	37.68 ± 0.09	41.82	1.63	50.09
	3000	LO	91.35 ± 0.09	31.85 ± 0.09	25.85	2.11	39.74
	3000	HI	98.33 ± 0.09	37.68 ± 0.09	27.70	1.49	49.12
3	1000	LO	10.46 ± 0.09	30.04 ± 0.09	74.17	1.34	33.13
	1000	HI	10.12 ± 0.10	33.84 ± 0.10	76.97	1	38.30
	2000	LO	44.16 ± 0.10	37.69 ± 0.10	46.04	3.40	65.45
	2000	HI	43.69 ± 0.08	46.39 ± 0.08	51.49	2.58	84.78
	3000	LO	85.89 ± 0.08	37.32 ± 0.08	30.29	3.46	63.74
	3000	HI	89.05 ± 0.11	46.96 ± 0.11	34.52	2.61	85.83

S-sticky gets on average better results than S-persistent due to the fact that, using this strategy, vehicles try to keep the WLAN connectivity using a multi-hop path even when they are travelling away from the RSU. We should note that staying connected using the WLAN when moving away from the RSU can, however, be a double-edged sword, as sharing the same RSU for vehicles moving in opposite direction results in an unfair usage of the WLAN resources. Since installing separate RSUs for each direction is not economically feasible, it is better, from a system point of view to deploy the S-persistent solution, which offers a very similar performance, while not suffering from the unfair WLAN sharing issue.

Based on the obtained results, it seems that the best operation mode is S-sticky using a value of t-hops-WLAN not very high (i.e., equal or less than 2) to avoid an excessive number of handovers. However, if the deployment mode does not allow to set up different RSUs for each driving direction, then S-persistent mode proves to be more appropriate. In both cases, the improvement gains in terms of amount time connecting to the VANET are around the 80%.