Seamless internet 3G and opportunistic WLAN vehicular connectivity

Abstract

Most of the cellular network operators are nowadays striving to solve the problem caused by the increasing demand of mobile data users. In the near future, vehicles will be equipped not only with cellular connectivity, but also with dedicated short-range wireless devices, used to connect via single or multiple hops to fixed road side units attached to the infrastructure network to gain Internet access. Taking this hybrid-connectivity scenario, we propose S eamless I nternet 3G and Opportunistic WL AN V ehicular I nternet Co nnectivity (SILVIO), a solution for providing Internet connectivity in multi-hop vehicular ad hoc networks. Vehicles use the cellular network to assure always-on connectivity, while they opportunistically select to offload some non-critical flows to the multi-hop wireless local area network (WLAN). The advantages of this approach are twofold: the users can benefit from a higher bandwidth, while the operators can alleviate their overloaded cellular networks. SILVIO makes use of existing standard mobility mechanisms integrated, enhanced and extended to provide a seamless connectivity experience without introducing much complexity nor signalling overhead. One of the main contributions of this article is the proposal and analysis of different handover strategies between 3G and multi-hop WLAN networks for the vehicular scenario. A trace-driven simulator was developed to evaluate the performance improvements provided by SILVIO. Real traffic traces from the city of Madrid were used to feed the simulator which considers large vehicles as obstacles, as well. The obtained results show that using SILVIO the cellular network can be offloaded by a factor up to 80%.

1 Introduction

Internet connectivity is today a need for many users. The Internet has evolved in just a few years from an experimental infrastructure that allowed a small number of academic institutions to exchange data into what was going to become the most essential tool for private companies and public institutions to develop their activity, as well as for users to access to news, play games, talk to friends across the world, share information, etc. Providing Internet connectivity anywhere, anytime and in the best possible conditions (both from the user and provider point of view) is no longer an academic exercise without no strong real demand to answer to, but a critical research and engineering problem. It involves not only academia, but also companies and governments, and with quite a big economical footprint.

Nowadays users may enjoy Internet connectivity from a quite broad number of scenarios thanks to the popularity of WLAN-based access, e.g., at work, home, school, airports, coffee shops, etc. Moreover, in the recent years, cellular-based connectivity (e.g., 3G) has also become quite popular and affordable, being available almost anywhere within populated areas. Within this new picture of different and cheap connectivity options available, the list of devices from our daily life that are connected to the Internet is no longer restricted to our PC and laptop, being now very common to find that it also includes phones, TVs, gaming consoles, video players, hard drives, or even our home appliances.

This article focuses on one particular scenario where Internet connectivity has not yet been fully integrated and exploited: vehicular environments. So far most efforts have been oriented to safety services and traffic efficiency, while Internet communications have been considered to be of a much lower priority. This situation is reflected on the work performed by the main standardization bodies working on vehicular networks (e.g., ETSI TC ITS, ISO TC204, IEEE 1609). Motivated by the goal of reducing the number of accidents and their consequences these bodies have specified communication architectures that will allow cars to cooperatively exchange safety critical information among them. The ETSI has just recently finalized the standardization of the mechanisms [1] required to integrate IPv6 in the harmonized communication system for European ITS [2].

Vehicular communication scenarios can be divided into two main categories: vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I). V2V communications are mainly used for safety applications, while V2I ones are mostly used for traffic efficiency and Internet connectivity. We identify two main approaches that can be followed to enable V2I communications:

• Use of 3G: Cellular technologies such as 3G or the forthcoming enhanced Long Term Evolution (LTE) technology allow users to obtain relatively high bandwidth from mobile platforms. Using 3G to connect vehicles is the simplest approach from a deployment and solution complexity viewpoint, as it does not require any additional protocol development and reuses existing operators' communications infrastructure.

• Use of VANETs: A Vehicular ad hoc network (VANET) is a short-range multi-hop wireless network, formed by vehicles in a certain area and fixed roadside gateways placed along the roads. The use of WLAN-based VANETs is a widely considered approach to provide connectivity in vehicular environments in a cheap and scalable way.

Existing 3G infrastructures are already suffering from the high demand of subscribers [3, 4]. A wide adoption of 3G as default access technology for the vehicular scenario would increase even more the problems faced by mobile operators. New communication paradigms like Internet of things or cloud computing will lead to a growth of low-consuming and network-capable devices, so it is expected that such devices will become available also in the automotive world. Moreover, national projects like CoCar^a[5] or research studies like [6] envision the use of the cellular network also for V2V communications. Using the 3G network to provide connectivity for those purposes would worsen the problem that operators are trying to solve. Operators are looking for offloading techniques that would allow their 3G networks to relieve by selectively moving some traffic to WLAN access networks when available, like in this case [7].

On the other hand, the use of multi-hop networks based on short-range wireless technologies (such as WLAN) in an environment as mobile and dynamic as the vehicular one, also poses significant challenges, which have been extensively analysed by the research community in the last years [8, 9]. Besides, connectivity in VANETs depends on the traffic density [10, 11] and, therefore, it is not granted in all cases (e.g., in sparse scenarios). The use of single-hop WLAN access poses less challenges, although it presents the obstacle of the deployment effort required to equip road segments with access points connected to a network infrastructure. The use of multi-hop networks helps considerably in reducing this difficulty, as the density of access points needed is reduced, and its feasibility has been analysed and in several recent works [12, 13].

Based on the above, we propose the use of an hybrid solution, called SILVIO. In our vision, 3G and WLAN technologies can complement to each other to provide the best user experience in vehicular networks. The approach we propose is based on the opportunistic use of multi-hop VANETs when available and on relying on 3G if not. Since not all traffic has the same importance nor requirements, we propose that vehicles use 3G connectivity for critical and real-time traffic (e.g., voice), and dynamically offload the rest (e.g., web browsing, file sharing, multimedia streaming) to WLAN. SILVIO is based on integrating, enhancing and extending standard mobility management mechanisms in such a way that they result in a complete solution for the provision of Internet connectivity in the vehicular scenario, bringing a seamless experience to the user while tackling mobile operators' concerns on excessive network loads. One of the main challenges to this achievement, which actually represent a key contribution of our article, is the design and analysis of different handover strategies.

Note that we focus on suburban and inter-urban scenarios (i.e., high mobility of vehicles), where it is feasible to deploy fixed WLAN point of attachments on the road--whose effective coverage can be extended by self-forming VANETs--and where there is good and ubiquitous 3G coverage. While high mobility of vehicles has a strong impact on suburban and inter-urban scenarios, one of the main issues in the city scenario is the high vehicular density, which makes interference management and dynamic reconfiguration become critical.

The rest of the article is organized as follows. Section 2 describes in detail the proposed solution, summarizing the main technologies and protocols that are used as basic ingredients. The solution is then evaluated in Section 3 by means of extensive simulations using real traffic traces. Finally, we compare our proposal with previous work in Section 4, before concluding the article in Section 5.

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.

Figure 1

Vehicular Internet connectivity: scenario and solution overview.

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.

To achieve this seamless and transparent traffic management with mobility support, SIL-VIO makes use of the following key technologies:

• Network mobility support: Since a vehicle is equipped with more than one device demanding IP connectivity, it is desirable to adopt an approach that provides connectivity to a set of devices, without any special support required on those. Note that some of these devices could be sensors with limited capabilities and processing power. This feature is achieved using network mobility mechanisms.

• 3G offloading support: The 3G interface is responsible for providing close-to always available connectivity, while the WLAN one is opportunistically used to offload non-critical traffic from the 3G network. This is achieved using IP flow mobility mechanisms.

• VANET connectivity support: The most widely adopted approach to provide connectivity via WLAN in a vehicular scenario is the use of a multi-hop VANET. This requires specific IP address auto-configuration and routing protocols designed to operate in the vehicular environment, and enhanced for the V2I communications scenario. This is achieved using a tree-based routing protocol (TREBOL; [14]), a vehicular addressing and routing protocol specially designed to support the V2I scenario.

• Interface management support: Due to the high mobility nature of the tackled scenario, handover management is of critical importance, as the impact caused by moving traffic between the 3G and WLAN interface has to be minimal from both the application and the user perspectives. This is achieved using optimized interfaces and layer-2 handover mechanisms based on the IEEE 802.21 standard.

• Smart handover procedures: A critical part of the solution is the intelligence responsible for deciding when a flow has to be handed off to a different access network and when it has to be brought back. There are different handover-decision approaches that can be followed to maximize the overall performance (i.e., average bandwidth, end-to-end delay, etc.), while minimizing the potential side effects that handover procedures (e.g., signalling) may cause. The trade-offs of the different approaches need to be assessed in order to take the best decision. The design and analysis of the handover procedures represents one of the main novelties of this article.

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).

Figure 2

NEMO basic support protocol operation overview.

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.

Connecting vehicles to the Internet means to enable, at least, two major functionalities within the VANET:

• Address configuration: Vehicles need to be uniquely identified in the network, hence they must be able to auto-configure a valid IP address. This process has to be automatic, without requiring any manual intervention from the user.

• Routing capability: Nodes have to forward their data traffic to the best available gateway to the Internet (role played by RSUs). Therefore, the routing algorithm has to efficiently route IP datagrams (that would be mainly unicast), from the vehicle to the roadside gateway and vice versa.

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.

Figure 3

TREBOL area.

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.

Media independent handover (MIH) defines three main mobility services:

• The media independent event service (MIES) provides event classification, event filtering and event reporting, corresponding to dynamic changes in link characteristics, link status and link quality. This service is particularly important for SILVIO, since WLAN availability needs to be known as precisely as possible in order to benefit from it without introducing interruptions in the on-going communications.

• The media independent command service (MICS) enables MIH clients to manage and control the link behaviour related to handovers and mobility. It also provides the means to mandate actions to lower layers, in a local or in a remote protocol stack.

• The media independent information service (MIIS) provides details on the characteristics and services provided by the serving and surrounding networks. The information enables effective system access and effective handover decisions.

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.

In order to understand the role played by the IEEE 802.21 in SILVIO as well as the value added by our proposed extensions, we describe next the three potential flow handover scenarios that may arise:

• 3G-to-WLAN: In this scenario, a vehicle can only send and receive traffic via a 3G network. At a certain point, WLAN connectivity to the RSU--either single or multi-hop--becomes available. The mobile router deployed in the vehicle needs to be notified of such a WLAN availability event in order to be able to perform a flow handover, offloading part of the in-vehicle traffic from the 3G network to the VANET. IEEE 802.21 Link Up events can be used in this scenario to notify the MR about WLAN availability. Regular IEEE 802.21 Link Up events are used to inform of 1-hop radio availability with a given point of attachment. However, in order to gain Internet connectivity, a mobile router in the VANET does not only need a WLAN point of attachment within its radio coverage, but also that this PoA is either the RSU or is connected (via a multi-hop path) to the RSU. Therefore, 1-hop radio connectivity between a vehicle and another PoA is not enough to trigger a Link Up event, unless the PoA is a RSU. SILVIO benefits from the TREBOL configuration messages used to regenerate the routing tree as enablers of Link Up events. If a vehicle receives a CM message, this means that the message has been successfully forwarded from the RSU to the receiver, and that can be used as a hint that the PoA is indeed able to provide Internet connectivity.

Upon detection and flow handover decision, the mobile router configures an IPv6 address valid on the VANET and sends the required IP mobility messages (i.e., flow binding updates) to its home agent, so it can proceed to forward packets belonging to the offloaded flow(s) to the IPv6 address configured in the VANET. Note that the time required to carry out this IP mobility signalling does not cause any traffic interruption, as packets continue being forwarded via the 3G (which is always on and available) until the home agent is updated and moves the flow(s) to the new WLAN access.

• WLAN-to-3G: In this scenario, a vehicle is simultaneously connected to the Internet via 3G and WLAN, so certain flows are being sent/received via the WLAN interface. If the vehicle cannot keep connectivity via its WLAN interface, the IP flows that were using the WLAN access have to be moved back to the 3G (waiting for a future offloading opportunity). Therefore, the mobile router needs to be notified of such an event, so it can send the mobility signalling required to move the flows back to 3G. This can be done using IEEE 802.21 Link Down and Link Going Down events.

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.

SILVIO uses layer-2 measurements to predict future wireless connectivity failures, by setting a threshold on the minimum received signal strength indicator (RSSI) that can be accepted as "good radio conditions". If the RSSI sensed from its parent node falls below this threshold, then the vehicle assumes that this radio link is about to fail shortly (e.g., because the nodes are moving away) and generates the signalling required to trigger a Link Going Down event. In [23], Meireles et al. give a comprehensive evaluation of the signal strength and the packet delivery ratio between two vehicles equipped with 802.11p devices^d. In SILVIO, the threshold value used to trigger a Link Going Down event is configured according to the results reported in this evaluation report.

• WLAN-to-WLAN: Due to the logical division in areas adopted by TREBOL, not only inter-technology handovers may happen, but also intra-technology ones between different areas, causing the IP address configured on the WLAN interface to change (note that IPv6 addresses are anchored at the RSUs, and changing area implies using a different RSU). Therefore, this type of handover also needs to be predicted, to avoid packet losses.

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.

Based on the previous analysis, we can highlight that there are many different handover approaches that can be followed, from those that are very conservative and aims at limiting the number of handovers, to those that are quite greedy and target using the VANET as much as possible. In order to illustrate and analyse the impact of this range of behaviours, we consider the following four different SILVIO modes of operation:

• SILVIO direct (S-direct): This mode, detailed in Algorithm 1 and Figure 4, is the simplest solution proposed in this article. The mobile router chooses to use the VANET just when it is under direct wireless connectivity with the RSU. The high reliability of the wireless channel makes this solution the safest in terms of stability of the attempted handovers, but, on the other hand, it does not exploit the potential benefits of the multi-hop WLAN connectivity. This algorithm provides the least number of handovers (i.e., just one) and the shortest time using the VANET so it is used in comparison to other strategies to evaluate their effectiveness.

  Figure 4

  

  S-direct mode of operation.

• SILVIO conservative (S-conservative): This mode, detailed in Algorithm 2, tries to use a possible multi-hop WLAN connectivity through the VANET (i.e., not only when directly connected to the RSU). In order to mitigate the possible ping-pong effect the mobile router is allowed to perform a handover to the multi-hop WLAN just once per TREBOL area. That is, once the mobile router backs off to the 3G network, it will not try again to obtain connectivity via the WLAN interface until it changes area. Moreover, the VANET WLAN is only used if the number of hops between the mobile router and the RSU is smaller than a configurable threshold (t-hops-wlan). In Figure 5, the method of operation is detailed. When a vehicle finds a new available path through the multi-hop VANET, it performs a flow handover to WLAN (Figure 5a). However, if the WLAN connectivity cannot be maintained (e.g., due to an obstacle between two hops, as shown in Figure 5b), the mobile router switches back to the 3G interface, and keeps using it even if a new valid path is discovered (Figure 5c).

  Figure 5

  

  S-conservative.

• SILVIO persistent (S-persistent): This mode of operation is slightly more aggressive than the ones already presented before. It tries to make use of the VANET longer by allowing the mobile router to hand off between 3G and WLAN more than once per area, but only while the vehicle is getting closer to the RSU, and if the number of hops between the router and the RSU is smaller than t1-hops-wlan. The maximum number of handover attempts from 3G to WLAN is limited by a configurable threshold (t-ho-attempts). However, there is a exception: if the VANET route is shorter than t2-hops-wlan hops, then the number of 3G to WLAN handover attempts is not limited. Algorithm 3 describes the handover behaviour of this mode. As shown in Figure 6 when the mobile router finds a new path to the RSU, it hands off again the selected flow to the WLAN. When moving away, if the mobile router decides that the WLAN link does not satisfy its quality constraints, it moves the flows back to the 3G network, without looking to other possible paths in the VANET.

  Figure 6

  

  S-persistent.

• SILVIO sticky (S-sticky): This is the greediest operation mode, in which the mobile router tries to keep using the VANET even when moving away from the RSU. From a pure handover management point of view it is exactly the same as the S-persistent mode (therefore Algorithm 3 is also valid to describe the operation of this mode). The only difference (depicted in Figure 7) between S-persistent and S-sticky modes is that in the latter case the mobile router is allowed to find an alternative multi-hop path using the WLAN even if the node is moving away. This variation is only possible while the mobile router is connecting to the RSU via a multi-hop path shorter than a certain threshold (called t-multihop). Note that in the rest of SILVIO operation modes that is not allowed, and therefore if a mobile router required to change TREBOL parent when moving away from the RSU to keep its connectivity that would trigger a handoff to 3G.

  Figure 7

  

  S-sticky.

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 Performance evaluation

This section provides an experimental evaluation of SILVIO. The main aim of this evaluation is twofold: (i) to study the performance of the different modes of SILVIO (i.e., different algorithms for smart vehicular handover management) and compare them with a solution based on the sole use of 3G, and (ii) to understand the trade-offs of each of the SILVIO operating modes. We start by introducing the evaluation framework, since it is a very important piece of our work, and then we present and analyse the obtained results.

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.

Figure 8

Vehicular traffic characteristics: (a) the vehicular flow of the used traffic traces; (b) the CDF of the vehicles length.

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.

We first start from the operator's view point. A critical performance figure of any system is the control overhead. SILVIO makes use of signalling messages to dynamically move flows between interfaces. Depending on the type of the handover, the control overhead is different:

• 3G-to-WLAN: IP mobility messages (BU/BA) are sent via the WLAN interface to inform the home agent about the flow(s) handoff(s).

• WLAN-to-3G: In this case, in addition of the IP mobility messages (sent via the 3G interface), the TREBOL parent node predicting an imminent loss of connectivity informs those nodes down in the tree that are sending traffic through it, so they can switch to 3G before the WLAN connectivity is lost.

• WLAN-to-WLAN: In this case, only IP mobility signalling is required.

We evaluate the average load (in bytes/s) generated by each vehicle while moving and crossing different TREBOL areas. Note that this load depends on the number of flow handovers performed. According to [19], the signalling used by the mobile router to inform the home agent about changes in the flow handling consists of two additional headers to the standard Binding Update message (BU_H), namely Binding Identifier Mobility Option (BIM_H) and Flow Identification Mobility Option (FIM_H). Then, a traffic selector (TSp, defined in [18]) has to be specified for each updated flow. We consider, for this evaluation, that each node performs the update for a single flow, so one IPv6 traffic selector is included in the message. The overhead injected by an update is therefore given by

$$\begin{array}{ll}\hfill O_{\mathsf{\text{NEMO}}}& =\mathsf{\text{I}}{\mathsf{\text{P}}}_{\mathsf{\text{v}}}{6}_{\mathsf{\text{H}}}+\mathsf{\text{B}}{\mathsf{\text{U}}}_{\mathsf{\text{H}}}+\mathsf{\text{BI}}{\mathsf{\text{M}}}_{\mathsf{\text{H}}}+\mathsf{\text{FI}}{\mathsf{\text{M}}}_{\mathsf{\text{H}}}+\mathsf{\text{T}}{\mathsf{\text{S}}}_{\mathsf{\text{P}}}\\ =40+8+24+8+104=184\mathsf{\text{bytes,}}\end{array}$$

(1)

where IPv6_H represents the length of the IPv6 header. The TREBOL-related signaling required to notify about a predicted loss of connectivity to the RSU depends on the number of affected nodes that need to be notified (i.e., the nodes that are sending traffic via a multi-hop path that is about to get disconnected). In order to illustrate this control overhead, we assume that on average half of the vehicles are affected when a WLAN-to-3G handover is triggered. This basically means that about 50 and 16 vehicles are affected for the case of high and low density cases, respectively (i.e., for a radio coverage of 300 m). Hence, the overhead introduced by TREBOL is given by

$$\begin{array}{ll}\hfill O_{\mathsf{\text{TREBOL}}}& =\mathsf{\text{I}}{\mathsf{\text{P}}}_{\mathsf{\text{v}}}{6}_{\mathsf{\text{H}}}+\mathsf{\text{B}}{\mathsf{\text{U}}}_{\mathsf{\text{H}}}+\mathsf{\text{TREBO}}{\mathsf{\text{L}}}_{\mathsf{\text{H}}}+\left(n_{\mathsf{\text{hosts}}}\times \mathsf{\text{hos}}{\mathsf{\text{t}}}_{\mathsf{\text{EU}}148}\right)\\ =40+16+4+\left(n_{\mathsf{\text{hosts}}}\times 6\right)\mathsf{\text{,}}\end{array}$$

(2)

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.

Figure 9

Control overhead. Low density: (a) tree-depth = 2 hops and (b) tree-depth = 3 hops. High density: (c) tree-depth = 2 hops and (d) tree-depth = 3 hops.

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.

For each of the three considered inter-RSU distances and each of the two vehicular densities, we calculate the time spent by a non-critical (i.e., one that is dynamically moved depending on the availability of WLAN connectivity) flow through the 3G and WLAN interfaces. Table 1 shows the obtained results while traversing one area for the S-direct approach, namely the time spent in 3G, the time spent in WLAN and the offloading percentage, meaning the portion of the total where offloading from 3G to WLAN is possible. Average values and 95% confidence intervals are provided. For D_RSU = 1000 m, S-direct is able to offload traffic about half of the time a vehicle spends in the area. That means that during this time the user obtains on average a higher throughput, since WLAN connectivity via one single hop to the RSU is usually faster than a 3G connection. In addition to this advantage from the user viewpoint, S-direct also benefits the mobile operator, as it helps reducing the load of its 3G network. Obtained results show that as the size of the TREBOL area increases, the benefits of offloading decrease, since nodes are only allowed to connect to WLAN when directly connected to the RSU. From this result, we can conclude that it is worth exploring how the other SILVIO operation modes perform.

Table 1 Handover strategy: S-direct

Table 2 shows the results for S-conservative, for two different values of tree-depth. This table, in addition to the results shown for S-direct, also includes the average number of handoffs from WLAN to 3G, as well as the performance improvement--in terms of WLAN usage--over S-direct. In the simulations, the value chosen for t-hops-wlan is always equal to the value used for tree-depth.

Table 2 Handover strategy: S-conservative

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).

From the obtained results, we can conclude that S-direct or S-conservative modes do not allow for fully benefiting from multi-hop WLAN connectivity through the VANET, as the time spent on WLAN per area is practically the same, regardless of the value of D_RSU. This is a expected result, since S-direct can only use the WLAN access when directly connected to the RSU, and S-conservative does not allow for more than one multi-hop WLAN connectivity attempt. Table 3 shows the results obtained with S-persistent, which is the first mode that allows for several multi-hop connectivity attempts. Note that t1-hops-wlan and t2-hops-wlan are equal to the value used for tree-depth in the simulations, and that t-ho-attempts = ∞. Results show that S-persistent is able to significantly increase the performance also when the distance between RSUs increases, at the cost of a higher number of handovers.

Table 3 Handover strategy: S-persistent

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.

Table 4 Handover strategy: S-sticky, t-multihop = 2 moving away

Figure 10

Cumulative distribution function of the time spent connected to 3G and WLAN. Time spent by a vehicle using only the 3G network in a WLAN-to-3G-to-WLAN scenario (a) t-multihop = 2 and (b) t-multihop = 3. Time spent by a vehicle using also the WLAN network in a 3G-to-WLAN-to-3G scenario (c) t-multihop = 2 and (d) t-multihop = 3.

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%.

4 Comparison with previous work

Maximizing the time vehicles are connected to Internet through an 802.11-based network is a research topic that has been explored in the last few years. In [31], Giannoulis et al. propose an enhanced handoff mechanism for 802.11 WLAN devices. Using a smarter handoff strategy oriented to frequent access point changes they get an average throughput 2.5 times greater than the default handover policy implemented in the standard driver. However, their work is focused just on improving the one-hop connectivity to the APs and, during their test drives, they experienced throughput outages depending on the physical wireless coverage. Moreover, they do not evaluate the coexistence of their proposal with standard IP mobility solutions and obviate the IP address configuration process that is, especially in vehicular environments, a crucial task.

Annese et al. propose in [32] to use a modified version of the BATMAN [33] layer-2 routing protocol for providing wireless connectivity to the infrastructure network. They were able to handoff between several APs without loss of connectivity, achieving a quite constant throughput. Despite providing layer-2 routing makes easier to solve mobility problems (i.e., just one IP address configuration process, use of the same address through different APs, etc.), on long term the flat view of the network from the layer-3 perspective can cause scalability issues.

A position-based handoff strategy was proposed by Deshpande et al. [34]. By exploiting the drivers' habit to daily drive similar routes (e.g., home to work, home to school) the authors define a handover protocol that connects to the best available AP depending on the vehicle position. Their mechanism is composed by a learning phase, where vehicles keep track of the APs signal strength for each position in their route and a handover process that selects the AP to connect to, accordingly with the measurements previously performed. In the same work, the authors propose a pre-fetch mechanism that spans the download of a user requested file over all the APs that are encountered on the route. Although the authors do not propose any IP mobility solution to be coupled with the mechanism and completely disregards the address auto-configuration tasks, this work provides a good approximation of the availability of WLAN coverage in a real scenario.

In a more recent work, Deshpande et al. [35] extended their testbed to a metro-scale WLAN network, performing long drives that lasted more than 5 h. Their throughput measurements, although do not consider at all IP mobility or addressing configuration issues, show that with a feasible APs deployment they could get good throughput values during all the drive and for a fair amount of time (the time fraction with throughput equal to zero was around 30%). The authors show also a comparison of the throughput obtained with the WLAN device to the one obtained with the 3G network. The results they show state that when both technologies are available, the throughput achieved by WLAN overcome in the 90% of the cases the one obtained with the 3G.

A similar work was developed by Balasubramanian et al. [36], where the authors tested the WLAN and 3G access in three different cities. Despite they results show that the band-width achievable using a WLAN device is not always higher than the one achievable with the 3G network, the need of offloading the 3G network still justified a mechanism for switching between the two technologies. Hence, they propose Wiffler a sub-IP layer that, based on the traffic characteristics (e.g., needed bandwidth or delay) and on the prediction of the WLAN connectivity in the near future, switches the user flows to the best interface. Results show that a considerable part of the transferred data (up to 60%, depending on the allowed delay) can be offloaded from the 3G network to the WLAN.

Different issues posed by the integration of 3G and WLAN networks have been extensively studied, such as interworking architecture, mobility management and QoS aspects [37, 38]. However, previous works assume terminals connect directly to the WLAN access points giving them access the Internet, while our work analyse the case of having WLAN multi-hop paths to the access points.

The cited works show promising results achievable from the use of WLAN access in vehicular environments. However, these works completely ignore IP mobility-related issues such as address auto-configuration or seamless handoff between APs or wireless technology. Moreover, they just consider one-hop WLAN connectivity while most of the already standardized solution for vehicular networks envision the use of multi-hop wireless communications. These two factors led us to propose a complete framework for providing seamless mobility in vehicular environments between heterogeneous technologies, namely multi-hop WLAN and 3G.

On the other hand, there also exists a considerable amount of previous work in the area of IP mobility in heterogeneous environments, even considering flow mobility [39] and offloading techniques [40]. However, most of the IP mobility works proposed so far [41] do not deal with the specifics of the vehicular scenario, and those that tackle it do not attempt to opportunistically benefit from multi-hop WLAN connectivity, enhancing in this way both users' and operators' interests, as SILVIO does. Last but not least, the level of integration of the IP mobility support (at flow level) with multi-hop addressing and routing mechanisms adopted by SILVIO, and the detailed analysis of different handover strategies, are also novel contributions of this article.

5 Conclusion

In this article, we present SILVIO--a complete framework for providing seamless Internet connectivity from vehicles in suburban and inter-urban scenarios. The solution is based on the key idea that vehicles are equipped with 3G and WLAN devices. Vehicles make use of the 3G for guaranteeing always-on connectivity, but opportunistically offload some non-critical flows if Internet connectivity through a multi-hop VANET becomes available. SILVIO builds upon a set of existing solutions, properly extended and adapted to the vehicular environment, and in particular to the vehicle-to-Internet communications scenario.

Seamless connectivity is achieved by driving the handoff mechanism between the two technologies using a vehicular-aware adaptation of the 802.21 MIH service and smart flow handoff procedures. The advantages given by opportunistically offloading the 3G network using multi-hop WLAN connectivity are twofold: cellular operators can relieve the traffic load that is currently afflicting their network, while users can benefit from the higher band-width achievable using the WLAN network and, at the same time, not eroding their available quota on the 3G network.

We have developed a trace-driven simulator to evaluate the improvement provided by SILVIO. Real traffic traces, collected at a fixed measurement point in the city of Madrid, are used to feed the simulator in which large vehicles are considered as obstacles, as well. Simulation results show that using SILVIO, the time elapsed under multi-hop wireless connectivity can increase up to 80%, introducing a control overhead on the 3G network absolutely affordable.

Future work includes performing a proof-of-concept validation, by implementing the solution and conducting tests using real vehicles.

End notes

^ahttp://www.aktiv-online.org/english/aktiv-cocar.html.

^bhttp://www.ietf.org/.

^cNEMO can mean Network Mobility or Network that Moves according to the context.

^dThese results have been confirmed by us performing similar experiments using equivalent wireless hardware and drivers.

^ehttp://sumo.sourceforge.net/.

^fThe authors of [23] kindly provided us the full experiment traces that we used to estimate

the RSSI values for a given inter-vehicle distance in both LOS and non-LOS conditions.