Abstract—Vehicular networks arose to support safety relatedapplications and to improve the traffic flow in the roads; however,nowadays they are also used to provide Internet access andentertainment to the vehicles’ users. Intrinsic characteristics ofthese networks are the constant mobility and high dynamics.Furthermore, being based on vehicles, the number of networknodes tends to increase in a fast pace. All these characteristicscombined with the fact that a vehicle does not always have directcommunication with the core network, turns crucial the use ofall available technologies and networks in the range of a vehicle,including multi-hop communications.
This paper proposes an uplink manager for vehicular net-works that offers multihoming, traffic differentiation and load-balancing, taking into account context-information to increase thenetwork performance. The proposed uplink manager providessimultaneous connectivity and traffic in multiple networks andtechnologies, and also enables the support of vehicles with singleand multi-hop connections available simultaneously. To providesuch functionalities, several extensions have been performed tothe control messages used in the mobility protocol to carry usefulinformation needed to perform the uplink manager decisions. Theproposed uplink manager has been tested in real networks andwith real equipments. The obtained results show that it fulfilsall proposed requirements, both in terms of load-balancing andtraffic differentiation, without incurring any performance dropin terms of packet losses or delay.
I. INTRODUCTION
Nowadays vehicles may be used to give support to safetyvehicular applications and to provide Internet to the usersthrough a vehicular network. They can connect to other vehi-cles or to the infrastructure and provide an Internet connection.The equipment placed inside the vehicles may have multiplenetwork interfaces of diverse technologies, such as IEEE802.11 p (WAVE), IEEE 802.11 a/g/n (Wi-Fi) and cellular.
With the widespread availability of technologies and net-works and the need to transmit more information in the sameperiod of time, the integration of multihoming can be seen asa great advantage. It provides a better use of the availableresources allowing the vehicles to be connected to morethan one access network simultaneously and, consequently,enables the ability to send/receive traffic through differentnetworks/technologies. With the adoption of this concept invehicles and networks, a set of advantages can be brought forthe communication process: the increase of reliability, Quality-of-Service (QoS) and available resources; the capability to
perform load-balancing; the decrease of economic costs dueto a better resource management [1].
Vehicular Ad-Hoc Networks (VANETs) have gained greaterfocus and developments in the recent years. A real vehicularnetwork has been co-deployed by our group in the city of Porto[2] which is supported by a fiber infrastructure network of thePorto Digital [3]. This testbed interconnects more than 600 ve-hicles (public buses, garbage trucks, and municipality vehicles)in order to provide a set of services regarding Internet accessto users inside the buses, and delay-tolerant communicationsto transport non-urgent information (sensors and logs). Thisdeployment enables the vehicles mobility between the differentavailable networks [4]. The integration of multihoming (use ofseveral access networks at the same time) [1] in the VANETsmobility protocol [4] would provide to VANETs the capabilityto take advantage of the available networks, simultaneouslyand in an optimized way, for both downlink and uplink traffic.In our first architecture for mutihoming in vehicular networks[6], the uplink traffic was routed through a single connection,only assuming the technology and the signal quality.
The work proposed in this paper provides multihomingfor uplink traffic in vehicular networks, and will consideras basis the Network Proxy Mobile IPv6 (N-PMIPv6) [5]extended for VANETs in [4] and the downlink multihomingextension proposed in [6]. The uplink multihoming aims atdifferentiating the uplink traffic and creating an algorithmresponsible for optimal routing through the available technolo-gies and networks, taking into account the network throughputand the traffic of the services. In a network perspective, itbecomes possible to perform a better resources management,where the network load can be distributed based on a setof information related with the networks in the range ofa specific vehicle. This work focuses on providing thesefunctionalities in two main cases, in single-hop and multi-hop,and it extends the control messages of the mobility protocol tocarry the required information for the optimization algorithm.The proposed approach is implemented and evaluated in areal environment with real on-board and road-side units. Theobtained results of the real tests with vehicles accessing theInternet through the different networks and technologies showthat the traffic differentiation and load balancing through theavailable technologies and networks is optimized according
to the network throughput. Moreover, the solution has beenevaluated both in single and multi-hop scenarios without anyperformance drawback in terms of delay or packet losses.
This paper is organized as follows. Section II presents therelated work in vehicular multihoming approaches. SectionIII presents the base work that supports the uplink managerintegration. Section IV presents the uplink manager opti-mization, while section V describes the work-flow of theintegrated uplink connection manager. Section VI depicts theimplemented testbeds and analyses and discusses the obtainedresults. Finally, section VII concludes the paper and introducesthe future work.
II. RELATED WORK
Mobility and multihoming are topics widely discussed inthe scientific community. However, the integration of theseare mainly theoretical and tested by simulation. Furthermore,the study of these concepts in vehicular environments is evenmore restricted. To overcome limitations/constrains such aslink failure and bandwidth limitations, and also improve thenetworks’ performance, some authors already identified thatmultihoming support is a requirement in the future [7]-[8].
With the increasing interest in vehicular networks, severalworks have studied what would be the challenges and require-ments of a robust vehicular network. In [9], it is referred thatmultihoming will have a key role in this type of networks:multihoming could be used for session continuity, verticalhandovers and load balancing mechanisms. In [10] the authorspropose CoMoRoHo, where multihoming is used in vehicularnetworks to reduce both the latency and the amount ofpacket losses. In [11] the authors propose a mobility managerbased on MIPv4/6 [12]-[13], focused in network selection andimproved vertical and horizontal handovers, using a metric thatcombines the delay and the jitter. Moreover, the frequency ofthe control messages (Binding Updates) are changed in realtime, depending on the speed of the vehicle, in order to reactquicker to network changes. However, only one technology ata time is used. Later, in [14], it is proposed QUVoD, a VANETthat uses multihoming features in a peer-to-peer network.By employing a video segment seeking scheme and, throughthe download of video segments, the authors concluded (bysimulation) that the use of both 4G and VANET networks atthe same time increase the data rate and the reliability.
As we can observe, multihoming is mainly used to improvethe handover mechanism and networks’ robustness. However,the proposals are not addressing vehicular networks or arebased on simulations.
In the previous work, [6], the authors proposed multihomingto work with N-PMIPv6 [5] extensions. In this framework, it isproposed a multihoming system that is able to divide downlinkflows through the available resources, in an optimized way,improving the network performance in terms of throughput,delay and packet loss. In this paper we will address uplinkmultihoming.
III. MOBILITY AND MULTIHOMING BASE WORK
In a vehicular environment we aim to have the follow-ing functionalities: mobility will allow the vehicles to roamthrough different networks guaranteeing the sessions continu-ity; multihoming will enable the use of several access networksat the same time and for the same or different data sessions.This section presents an overview of the mobility protocol andhow the uplink traffic is managed, since this is used as basisfor this work.
Fig. 1: Mobility and multihoming scenario
A. N-PMIPv6 with MH support
The basis for our mobility support in VANETs is the N-PMIPv6 protocol. This is based on PMIPv6 [15] and providessupport for full-network mobility. The version of N-PMIPv6used in our approach is a version extended to vehicularnetworks [4].
N-PMIPv6 protocol assumes three different entities in itsarchitecture: the Local Mobility Anchor (LMA), which isresponsible to maintain the end-devices accessible to othernodes and is topologically the anchor point for its homenetwork prefix; the Mobile Access Gateway (MAG), whichis responsible to manage the end-devices mobility-relatedsignalling, and is in the access link where end-devices areattached and the mobile MAG (mMAG), that is a MAG withmobility functionalities. In a VANET point-of-view, the LMAis placed in a machine at the core network; the MAGs areplaced in the Road Side Units (RSUs), which work as Pointsof Access (PoAs) assuming different technologies; and themMAGs are placed in the On-Board Units (OBUs), whichare entities in the vehicles that make the bridge between theRSUs and the end-user’s terminals.
B. Uplink and IPv4 communication
To provide IPv4 Internet support and IPv4 communicationto the users inside the vehicles, it is required the use of IPv4-over-IPv6 tunnels, since all the VANET architecture is based inthe IPv6 protocol. Fig. 2 presents the tunnel creation process.
Whenever a mMAG connects to a network, an IPv4-over-IPv6 tunnel for each technology between the LMA and themMAG is created.
To manage the selection of the available networks, a connec-tion manager runs in the mMAG. This manager is responsible
231
Fig. 2: IPv4 over IPv6 tunnel creation
for selecting, from the available networks, the ones that aresuitable to send the traffic in multihoming and perform all therequired configurations. The connection manager is designedto support one Wi-Fi and multiple WAVE connections atthe same time. This is because the mMAG devices onlyhave one Wi-Fi interface and, consequently, multiple Wi-Ficonnections would required the use of a virtual interface foreach connection, which would reduce the communicationsperformance. Regarding to the WAVE technology, due to itsbroadcast nature, it is able to use one physical interface tocommunicate with multiple WAVE networks.
Assuming the current uplink process without multihoming,the connection manager will first check if there are any WAVEconnections, and if so, a default route will be configuredto the WAVE IPv4-over-IPv6 tunnel, assuming the one thatpresents the best signal quality. If there is no available WAVEconnection, it will check if there is any Wi-Fi connection,and again, a default route will be configured to the Wi-Ficonnection.
IV. UPLINK MANAGER OPTIMIZATION
Fig. 3 illustrates one of the scenarios for the uplink mul-tihoming: a mMAG (OBU in the vehicle) disseminates anIPv4 network that is used by a user that connects to thatnetwork to access the Internet, and by a data collection unitthat aggregates information from sensors that aim to send thecollected data to the cloud. Having this scenario as an example,the aim of this work is to be able to send this traffic throughdifferent networks simultaneously, e.g. the Internet accessthrough a low-delay network and the sensors’ informationthrough a lower-quality network in vehicular environments.
Knowing that the WAVE technology has been developedspecifically for vehicular environments, and the fact that, when
Fig. 3: Scenario for Uplink Multihoming
the mMAG provides the IPv4 network to the user, it must usea virtual Wi-Fi interface that reduces drastically the availablebandwidth in Wi-Fi networks, WAVE technology will be usedto route the users traffic (highest priority), and Wi-Fi will beused to route the sensors’ traffic (lowest priority).
A. Traffic Differentiation
The first step required in the support of multihoming ca-pabilities is to differentiate the traffic, and then be able toroute it through the available technologies at the same time.The traffic is then differentiated by the destination port of thepackets that arrive at the mMAG. Using the above example,the sensors’ traffic will be marked using iptables (based onthe destination port) and then routed to the IPv4-over-IPv6Wi-Fi tunnel using iprules. On the other hand, to route theusers’ traffic to the IPv4-over-IPv6 WAVE tunnel, a defaultroute will be used. Then, it is used an iprule that forces allthe traffic that traverses the tunnels to be forwarded to theIPv6 addresses of the next-hop networks.
One important aspect to keep in mind is the fact that thesensors are special nodes spread through the city, that buildtheir own packets and that can adopt a pre-defined port value.
B. Network connectivity
When a packet is forwarded to an IPv4-over-IPv6 tunnel,an extra IPv6 header is added to the packet: the sourceaddress depends of the technology (TECH), where 1 is forWAVE and 0 for Wi-Fi and, also depends of the uniquenumber that identifies the OBUs (BOARDID). For example,2001:200:TECH:BOARDID; the destination address is equalto the LMA address.
The LMA needs to have available information about theOBUs to dynamically create the IPv4-over-IPv6 tunnels. Toovercome this problem, the OBU information (the BOARDID)
232
is sent from the OBU to the RSU using the reserved field ofthe Router Solicitation (RS) message, and then from the RSUto the LMA using the reserved field of the Proxy-bindingUpdate (PBU) message. These changes allow the dynamicroute management and tunnel creation.
C. Uplink traffic management based on networks achievedthroughput
To create a truly smart uplink management mechanism, theOBU needs to know the achieved throughput (AT ) of eachRSU. The only way for the OBU to know that value is byreceiving this information from the RSUs. We developed analgorithm on RSUs that analyses the incoming interface inreal-time, and calculates the average of the input and the outputtraffic, analysing the respective interface information. Then,the equation presented in expression (1) is used at each RSU todetermine AT . Here, C is the maximum achieved throughputthat a RSU can achieve without any traffic, Ps is the amountof packets per second (input and output), and S is the meanpacket size.
AT = C − (Psin ∗ Sin + Psout ∗ Sout) (1)
Now, the information must be sent to the OBU and, in orderto keep a low overhead, it is used the Router Advertisement(RA) message already present in the N-PMIPv6 protocol.However, there is no available field with enough space to carrythe AT value. Therefore, the AT value is converted in a valuebetween 0 and 31 and is sent in the 5 reserved bits of the RAmessage. To obtain this value, it is used expression (2), wherethe Max is the maximum values that can be achieved with 5bits (31) and the MaxAT is the maximum value of the ATof all RSUs.
RSUAT =AT ∗ Max
MaxAT(2)
The metric that is sent in the RA message contains a valuethat establishes a relationship between all the RSUs ATs,enabling the connection manager to route the uplink trafficaccording to that information.
D. Uplink traffic impact on the achieved throughput
As explained in the previous subsection, the OBU receivesthe information about each RSU AT , and it aims to determinethe best traffic to send in each technology and network.However,if the OBU is already sending traffic to the RSU,the AT value of the respective RSU will be affected, i.e, theAT value that the OBU receives from the RSUs is affected bythe amount of traffic that it sends in the uplink. This makesthe AT comparison unfair: AT values affected by the currentuplink traffic that can be moved, and AT values that are notaffected by the current uplink traffic. To design a truly efficientand fair load-balancing mechanism, the AT value used in thedecision process must be processed at the connection manager,in order for the OBU to use a value that is not affected by itsown uplink traffic.
Fig. 4: Multi-hop and multihoming
The solution proposed is to calculate the amount of trafficthat the OBU is sending in the uplink (OBU load), and add thisvalue to the AT value that corresponds to the connection thatis being used to route the uplink traffic, expression (3). In thisway, the value used in the decision process will not be affectedby the uplink traffic introduced by the OBU under analysis.Finally, the connection manager will search for the highestAT ′ value associated to each available WAVE connection,and will configure an iprule to route all the WAVE trafficthrough that network, as explained in subsection IV-A. Forthe connections that are not being used by the uplink traffic,AT ′ becomes equal to AT .
AT ′ = AT +OBU load (3)
E. Multi-hop support
To enable multihoming to the uplink traffic both in singleand multi-hop is not trivial. The problem is the following: inthese scenarios it is needed to use IPv4-over-IPv6 tunnels toroute the IPv4 traffic; in multi-hop this particular aspect is aproblem since, when the traffic is forwarded to the OBU 1-hop away from the RSU, due to the tunnel extra header, theiptables cannot mark the traffic with the specific destinationport, and consequently, this OBU is unable to differentiate thetraffic.
The proposed solution for this problem is illustrated in Fig.4. Instead of using tunnels to route the traffic, the multi-hop OBU (mMAG 2) will send the traffic directly to thesingle-hop OBU (mMAG 1) through the WAVE interface(multi-hop communications are only performed through theWAVE technology). As observed in the fig, and consideringthese values just as examples, all OBUs/RSUs IPv4 WAVEinterfaces’ addresses are equal to 172.16.X.Y, where X and Y
233
represent the first and the last numbers of the OBUs/RSUs ID,respectively. To support this solution, it is necessary to ensurethat the multi-hop OBU knows the IPv4 address of the single-hop OBU WAVE interface. This is necessary to enable thetraffic forwarding through the next-hop OBU. The mMAG hasto know if it is in single-hop or multi-hop, which is necessaryto identify if the traffic should be forwarded through the WAVEor tunnel interface.
To obtain the required information, a multi-hop flag andOBU ID is introduced in the code field of the RA message.Thus, whenever a multi-hop OBU connects to a single-hopOBU, using the RS message, the single-hop OBU answerswith a RA that contains its own ID and a multi-hop flag setto 1. In this case, if a node is trying to connect to an OBU, itcan only mean that the node is in multi-hop.
V. UPLINK MANAGER PROCESSES
Depending of the OBU available connections, single-hopand/or multi-hop, the uplink manager assumes different be-haviours. These are presented through subsection V-A andV-B, respectively.
A. Single-hop behavior
In the classification process, the users’ traffic is consideredas the most high-priority and the sensors’ traffic is consideredthe less-priority one. The traffic differentiation is performedwhen the OBU has at least a WAVE and a Wi-Fi connection.Then, due to the different networks characteristics, the users’traffic is sent through the best WAVE network, and thesensors’ traffic through the Wi-Fi network. If the OBU is onlyconnected to several WAVE networks or to a Wi-Fi network,all the traffic is sent through the best WAVE network orthrough the Wi-Fi network, respectively. Algorithm 1 presentsthe uplink manager behaviour in single-hop scenarios. Noticethat the support of another type of traffic just requires anotherrule and classification process in the OBUs.
Algorithm 1: Single-hop Uplink ManagerInput : Packet to be analysedOutput: mark/decision
1 if OBU has at least an WAVE and a Wi-Fi connectionthen
2 if is the traffic from sensors then3 Return the mark of the Wi-Fi connection;4 else5 Assume the best WAVE connection to send the
users’ traffic;6 else7 if OBU only has WAVE connections then8 Assume the best WAVE connection to send all
traffic;9 else
10 Assume the Wi-Fi connection to send all traffic.
Fig. 5: Single-hop testbeds
B. Multi-hop behavior
Since it is possible to have both single-hop and multi-hop connections, the connection manager must be prepared tohandle these types of scenarios. In these scenarios differentdecisions can be taken: if the multi-hop OBU has single-hop WAVE connections, the multi-hop connections will beignored, and the traffic will be routed assuming the single-hop behaviour, as in Algorithm 1; if there are no single-hop connections, it means that only multi-hop connections areavailable and all the traffic will be routed through the bestnext-hop WAVE interface. The sensors’ traffic will be routedthrough Wi-Fi, if it is available, considering always single-hopWi-Fi; if it is not available, it will be routed through WAVEwith the same conditions as the users’ traffic.
As can be concluded, the single-hop connections havepriority over the multi-hop ones. In multi-hop, the communi-cation between OBUs is performed using a WAVE connection.Consequently, the same interface is responsible for receivingand forwarding the packets, which significantly reduces theavailable bandwidth due to the shared medium.
VI. EVALUATION
This section presents and discusses the real tests of mul-tihoming in vehicles and road-side units to evaluate the pro-posed uplink manager. Subsection VI-A describes the equip-ment and the testbed scenarios, and subsection VI-B presentsthe obtained results.
such as routing, connection manager, mobility and multihom-ing; two computers are used as the LMA and as a User.
The OBU/mMAG will use a virtual interface to be con-nected to a Wi-Fi RSU and share a Wi-Fi IPv4 networksimultaneously.
Each test is repeated three times with the same conditions.The User will send traffic to the LMA using the D-ITG [16]traffic generator tool. Both sensor’s and user’s traffic will beprovided through the generated traffic with ports 3004 and3005, respectively. Table I presents the characteristics of thetestbed equipment.
Fig. 5.a) illustrates the first single-hop testbed. At thebeginning, the mMAG1 is connected to one WAVE MAG.Then, after approximately 26 seconds, the mMAG1 will move,and will find and connect to a suitable network provided bya Wi-Fi MAG. Fig. 5b) depicts the second single-hop testbed.In this case, the mMAG is connected to one Wi-Fi MAG andtwo WAVE MAGs during all the experiment.
Fig. 6: Multi-hop testbeds
Regarding to the multi-hop configurations, it is presentedin Fig. 6.a) a scenario where mMAG1 is connected to aWAVE MAG and a Wi-Fi MAG, and mMAG2 is connectedto mMAG1 using the WAVE interface. This configuration willremain unchanged until the end of the test. Finally, in Fig. 6.b)the mMAG2 is initially only connected to mMAG1, and thenit will move and connect to a suitable WAVE MAG with asingle-hop connection.
B. Results
This subsection presents and discusses the obtained results.
(a) Traffic sent by the Wi-Fi MAG
(b) Traffic sent by the WAVE MAG
Fig. 7: Throughput in the IPv6 tunnels - Traffic differentiation
The first test aims to validate both the mobility and thetraffic differentiation functionalities. The testbed of Fig. 5.a)will be used and two UDP flows of 3 and 1 Mbps will besent from the User to the LMA with a destination port of3005 (simulating users’ traffic) and 3004 (simulating sensorstraffic), respectively.
The best way to show the amount of traffic that is beingrouted through each technology is to analyse the traffic travers-ing each IPv6 tunnel. In Fig. 7 the plot with the blue line (Fig.7a) presents the throughput in the IPv6 tunnel between theWi-Fi MAG and the LMA. The green plot (Fig. 7b) presentsthe throughput in the IPv6 tunnel between the WAVE MAGand the LMA. As expected, when the mMAG only has oneconnection available, all uplink traffic is routed through thisconnection. When the mMAG connects to the WAVE MAG,the traffic is splitted according to the traffic type. The delay isapproximately 2 milliseconds in both paths before and duringthe traffic split, and the average packet loss is 0.037%. Theseresults show that it is possible to route different types of trafficthrough different routes, and change the routes of the trafficin multihoming, without increasing the packet losses and thedelay.
The testbed in Fig. 5.b) is used to evaluate the load-balancing mechanism. Two UDP flows of 3 and 1 Mbps will besent from the User to the LMA with a destination port of 3005and 3004, respectively. After approximately 41 seconds, theLMA will send 4 Mbps to the MAG 2 (MAG that was routingthe mMAG uplink traffic), until the end of the experiment.Fig. 8 illustrates the throughput in all tunnels that connectthe MAGs to the LMA. The results show that, initially, theusers’ traffic is being routed through the WAVE connection
235
(Fig. 8a), and the sensors traffic is routed through the Wi-Ficonnection (Fig. 8c). Then, after approximately 43 seconds,the connection manager detects that the RSU responsible forrouting the traffic has a load increase and decides to movethe mMAG traffic to the other available WAVE RSU (Fig.8b). During this experiment, the average packets’ delay is 1.9milliseconds, and the average packet loss is 0.012%. Again, thetraffic movement from one MAG to another in multihomingdid not affect the network performance.
(a) Traffic sent by the single-hop WAVE MAG 1
(b) Traffic sent by the single-hop WAVE MAG 2
(c) Traffic sent by the single-hop WAVE MAG
Fig. 8: Throughput in the IPv6 tunnels - Load-balancing
The multi-hop multihoming approach is evaluated with thetestbed of Fig. 6.a), where the User sends an UDP flow of2 Mbps with a destination port of 3005 and another UDPflow of 1 Mbps with destination port of 3004. Fig. 9 depictsthe throughput of the single-hop tunnels, which shows that thethroughput is maintained stable and with the envisioned trafficvalues even in multi-hop scenarios. The average packet’s delayis 10 milliseconds (it is similar to the multi-hop cases withoutmultihoming) and the average packet loss is 0.012%, whichshows the seamless functionality of the proposed multihomingapproach in multi-hop scenarios.
Finally, the authors test how the mMAG behaves when ithas available both a single and a multi-hop connection usingthe testbed of Fig. 6.b). In this test, the User will send anUDP flow of 2 Mbps with a destination port of 3005 and an
UDP flow of 1 Mbps with a destination port of 3004. Afterapproximately 29 seconds, the mMAG will connect to a single-hop WAVE MAG.
Fig. 10 shows the throughput of the tunnel created betweenthe LMA and the WAVE MAG2 (Fig. (10a)), and the through-put of the tunnel created between the LMA and the WAVEMAG1 (Fig. 10b). Before the time at 29 seconds all traffic isreaching the LMA through the IPv6 tunnel between the LMAand the MAG 1: the traffic is being routed by the tunnel thatconnects the LMA and mMAG1, as expected, because it isthe only available connection. Then, the connection managerdetects the presence of MAG2 and all traffic changes fromLMA-WAVE MAG1 tunnel to LMA-WAVE MAG2 tunnel,since the single-hop connection has priority over multi-hopconnections. During this test, the average packet loss is 0.00%and the average delay is 7 milliseconds. Again, there is noimpact on the performance of the flow packets.
(a) Traffic sent by the Wi-Fi MAG
(b) Traffic sent by the WAVE MAG
Fig. 9: Throughput in the IPv6 tunnels - Multi-hop analysis
VII. CONCLUSION
This paper proposed the implementation of an uplinkconnection manager in multihoming scenarios that providessimultaneous connections and traffic through the availabletechnologies and networks while the vehicle moves in the road.This connection manager can differentiate the incoming trafficbased on the destination port, and route through heteroge-neous networks (WAVE and Wi-Fi) simultaneously. Moreover,this connection manager has the capability to perform load-balancing in an optimized way, while supporting both single-and multi-hop communications.
The performance tests in real vehicle scenarios have shownthat the proposed uplink multihoming connects the severaluplink routes and updates them in real-time, based on theavailable technologies and networks and the load of each
236
(a) Traffic sent by the multi-hop WAVE MAG
(b) Traffic sent by the single-hop WAVE MAG
Fig. 10: Throughput in the IPv6 tunnels - Multi-hop andsingle-hop connections
connection, without any performance drop both in single-hopand multi-hop scenarios.
As future work, the proposed approach will be extended tomore types of traffic, will integrate with the real services ports,and will be deployed in the real large-scale vehicular networkavailable in the city of Porto.
ACKNOWLEDGMENTS
This work was supported in part by the PortugueseFoundation for Science and Technology through Pest-OE/EEI/LA008/13 under Grant UID/EEA/50008/2013, inpart by the IT Internal Project SmartCityMules, in partby the CMU-Portugal Program through S2MovingCity:Sensing and Serving a Moving City under Grant CMU-PERI/TIC/0010/2014, and in part by the Project MobiWise:from mobile sensing to mobility advising under Grant P2020SAICTPAC/0011/2015.
REFERENCES
[1] CAPELA, Nelson; SARGENTO, Susana. An intelligent and optimizedmultihoming approach in real and heterogeneous environments. WirelessNetworks, Springer, 21.6:1935-1955, January 2015.
[2] Future Cities, Porto Living Lab: an ecosystem for future smart cities, con-sulted on November 10, 2016. [Online]. Available: http: //futurecities.up.pt/site/
[3] Porto Digital, consulted on November 10, 2016. [Online]. Available: https://portodigital. pt/index .php
[4] LOPES, Diogo; SARGENTO, Susana. Network Mobility for VehicularNetworks. International Symposium on Computer and Communications(ISCC), IEEE, Madeira, Portugal, June 2014
[5] Soto, I., Bernardos, C. J., Calderon, M., Banchs, A., Azcorra, A. (2009).Nemo-enabled localized mobility support for internet access in automo-tive scenarios. IEEE Communications Magazine, 47(5).
[6] CAPELA, Nelson; OLIVEIRA, Marco; MARTINS, Andre; CASTRO,Francsico; SARGENTO, Susana. Multihoming for Seamless Handoverin Real Vehicular Networks, December 2016. [Online]. Available: http://nap. av. it. pt/mulhomingglobal. html.
[7] Grassi, G., Pesavento, D., Pau, G., Vuyyuru, R., Wakikawa, R., Zhang,L. (2014, April). VANET via named data networking. In Computer Com-munications Workshops (INFOCOM WKSHPS), 2014 IEEE Conferenceon (pp. 410-415). IEEE.
[8] Khaled, Y., Tsukada, M., Santa, J., Ernst, T. (2009, April). On the designof efficient vehicular applications. In Vehicular Technology Conference,2009. VTC Spring 2009. IEEE 69th (pp. 1-5). IEEE.
[9] Zhu, K., Niyato, D., Wang, P., Hossain, E., In Kim, D. (2011). Mobilityand handoff management in vehicular networks: a survey. Wirelesscommunications and mobile computing, 11(4), 459-476.
[10] KAFLE, Ved P.; KAMIOKA, Eiji; YAMADA, Shigeki. Comoroho:cooperative mobile router-based handover scheme for long-vehicularmultihomed networks. IEICE Transactions on Communications, E89-B(10): 27742785, 2006.
[11] Andersson, K., Ahlund, C., Gukhool, B. S., Cherkaoui, S. (2008,October). Mobility management for highly mobile users and vehicularnetworks in heterogeneous environments. In Local Computer Networks,2008. LCN 2008. 33rd IEEE Conference on (pp. 593-599). IEEE.
[12] PERKINS, Charles. IP mobility support for IPv4. RFC 3344 (ProposedStandard), Internet Engineering Task Force, August 2002, obsoleted byRFC 5944, updated by RFCs 4636, 4721. [Online]. Available: http://www. ietf. org/ rfc/ rfc3344 .txt
