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 CoCara[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.
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 (IETFb), 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--NEMOc) 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.
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.
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 devicesd. 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.
-
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).
-
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.
-
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.
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