Review ArticleChallenges of Future VANET and Cloud-Based Approaches

Rakesh Shrestha , Rojeena Bajracharya , and Seung Yeob Nam

Department of Information and Communication Engineering, Yeungnam University, 280 Daehak-Ro, Gyeongsan-si,Gyeongsangbuk-do 712-749, Republic of Korea

Correspondence should be addressed to Seung Yeob Nam; synam@ynu.ac.kr

Received 26 September 2017; Revised 25 February 2018; Accepted 25 March 2018; Published 2 May 2018

Academic Editor: Orhan Gazi

Copyright © 2018 Rakesh Shrestha et al.This is an open access article distributed under the Creative CommonsAttribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Vehicular ad hoc networks (VANETs) have been studied intensively due to their wide variety of applications and services, such aspassenger safety, enhanced traffic efficiency, and infotainment.With the evolution of technology and sudden growth in the numberof smart vehicles, traditional VANETs face several technical challenges in deployment and management due to less flexibility,scalability, poor connectivity, and inadequate intelligence. Cloud computing is considered a way to satisfy these requirementsin VANETs. However, next-generation VANETs will have special requirements of autonomous vehicles with high mobility, lowlatency, real-time applications, and connectivity, which may not be resolved by conventional cloud computing. Hence, mergingof fog computing with the conventional cloud for VANETs is discussed as a potential solution for several issues in current andfuture VANETs. In addition, fog computing can be enhanced by integrating Software-Defined Network (SDN), which providesflexibility, programmability, and global knowledge of the network. We present two example scenarios for timely dissemination ofsafety messages in future VANETs based on fog and a combination of fog and SDN. We also explained the issues that need to beresolved for the deployment of three different cloud-based approaches.

1. Introduction

Vehicular ad hoc networks (VANETs) have gained popularityin recent years. Traffic accidents, road congestion, fuel con-sumption, and environmental pollution due to the largenumber of vehicles have become serious global issues. Trafficincidents are persistent problems in both developed anddeveloping countries, which result in huge loss of life andproperty. In order to overcome these issues and make thejourney safer, efficient, hassle-free, and entertaining, Intel-ligent Transportation Systems (ITS) introduced VANETs tocreate a safer infrastructure for road transportation [1, 2].VANETs focus on road safety and efficient traffic manage-ment for public roads, while offering comfort and entertain-ment for drivers and passengers throughout their journeys[3]. Vehicular communication in VANETs can be achieved byexchanging information using Vehicle-to-Vehicle (V2V) andVehicle-to-Infrastructure (V2I) communications. Vehiclescommunicate with other vehicles through On-Board Units(OBUs) forming Mobile Ad Hoc Networks (MANETs) thatallow wireless communication in a completely distributedmanner while they can communicate with Roadside Units

(RSUs) in an infrastructure mode. The Wireless Accessin Vehicular Environment (WAVE) protocol is based onIEEE 802.11p standard and provides basic radio standard forDedicated Short-Range Communications (DSRC) operatingin 5.9GHz frequency band [4].

There are mainly two types of applications used inVANETs, safety, and nonsafety applications. Safety appli-cations in VANETs are used to send safety messages, forexample, various warning messages that assist vehicles onthe road so that proper actions can be taken to preventaccidents and save people from hazardous situations. Safetymessages include events such as road accident reports, trafficjam notifications, road construction reports, and emergencyvehicle warnings [5]. These types of safety applicationsrequire low latency and high reliability. On the other hand,nonsafety applications provide an efficient and comfortabledriving experience. Nonsafety applications are classified intotwo categories: traffic management and infotainment. Trafficmanagement applications are used to improve traffic flow andresolve congestion on the road. Infotainment applications areused for information and entertainment purposes, providingInternet access to passengers, such as data storage, video

HindawiWireless Communications and Mobile ComputingVolume 2018, Article ID 5603518, 15 pageshttps://doi.org/10.1155/2018/5603518

2 Wireless Communications and Mobile Computing

streaming, and video calling. These types of applications donot require high reliability and low latency, compared to thesafety applications. In VANETs, some critical event informa-tion (e.g., accident reports)must be disseminated quickly andreliably. Even though VANETs are feasible for disseminatingevent information, it is still a challenge to disseminate criticalmessages timely and reliably to a targeted area under adynamic vehicular environment. This is due to the limitedtransmission range of DSRC, as well as the Contention-based Carrier-Sense Multiple Access with Collision Avoid-ance (CSMA/CA) scheme in the IEEE 802.11p protocol [6].The critical messages face delays due to MAC contention,which is not suitable for VANETs. Failure in timely and accu-rate dissemination of such time-critical information mightlead to collateral damage to neighboring vehicles. Recently,researchers have studied the feasibility of cellular networksfor supporting VANET services while providing wide cover-age and high data rate services to vehicular users [7]. How-ever, a single wireless communications technology, such aseither DSRC or a cellular network, may not fully support ITSservices in an environment with heavy loads, high mobility,and a dynamic network topology.Thus, by integrating cellularnetworks and IEEE 802.11p, a heterogeneous vehicular adhoc network could be a possible platform that can meetseveral demanding communication requirements. It can dealwith seamless data connectivity between spatially separatedvehicles in VANETs [8].

The traditional centralized VANET technology may notbe efficient in handling massive amounts of traffic datagenerated by smart vehicles such as video and sensor data.In order to collect and process large amount of instantaneoustraffic information, additional servers are required in dis-tributed areas. VANETs using cloud computing might be anappropriate solution for these types of situations. Recently,cloud computing has been adopted by variousmobile devicesto handle complex computations that can be hardly accomp-lished locally [9]. A lot of research has been done in VANETsintegrated with cloud computing to extend the capabilitiesof VANETs even further [10–12]. In general, uploading toand downloading from the cloud by the vehicles consumetime and energy [10]. As the density of the vehicles increasesin urban areas, the existing cloud computing paradigmcan barely satisfy the requirements of location awareness,mobility support, and latency.

A solution based on edge cloud computing has beenproposed with the concept of fog computing to overcomeissues between the vehicular nodes and the main cloud [13].The transmission delays in messages can be satisfied by fogcomputing. In addition, the safety messages can be sent todesired locations that are in different geographic areas withthe help of geo-distributed fog servers with low latency. Fogcomputing extends the cloud computing paradigm to theedge of the network [14]. Fog computing is a lightweightversion of cloud computing at the proximity of the vehicularnodes, with functions similar to the cloud. Fog computinghas a multitiered architecture, with vehicular nodes at theedge of the network. The fog platform is located betweenvehicular nodes and the datacenters of the conventional cloudenvironments. The main motivation for implementing fog

computing in VANETs is to leverage the advantages of fogcomputing in the distributed cloud environment. Fog com-puting provides very low latency between the vehicles and thecloud. In addition, fog computing can support vehicles withhighmobility. Along with the evolution of 5G technology, fogcomputing integratedwith Software-DefinedNetwork (SDN)plays an important role in enhancing the performance of theVANETs [15]. The centralized and systematic paradigm ofSDN provides scalability, flexibility, and programmability toVANET.The basic feature of SDN is separation of the controlplane for network control and the data plane for the forward-ing function [16]. By introducing the SDN controller alongwith fog computing, the system can manage geographicallydistributed fog devices and can manage heterogeneous net-works by providing programmability, flexibility, and globalinformation about the network. Due to the open, reconfig-urable interface and flexibility of SDN, it provides intelligencethat can be applied in VANETs efficiently. On the other hand,the decentralized paradigm of fog computing reduces latencyand optimizes resource utilization in future VANETs.

The rest of this paper is organized as follows. In Section 2,we investigate several key challenges and requirements offuture VANETs. In Section 3, we introduce a brief overviewof emerging technologies that act as a key enabler for futureVANETs. We present a comparative study on edge basedcloud computing and SDN in VANETs. Section 4 presentstwo examples of safety message dissemination in fog inte-grated with SDN in future VANETs. Section 5 discusses thedeployment issues of cloud-based approaches in terms of net-working and computing infrastructure followed by conclu-sion in Section 6. We summarize the definitions of acronymsused in this paper in “Summary of acronyms” for reference.

2. Key Challenges and Requirements ofFuture VANETs

VANETs are one of the fundamental technologies for effi-cient, safe, informative, and entertaining transportation sys-tem [17]. These days, people spend a significant amount oftheir time in vehicles. In order tomake that timemore secure,efficient, pleasant, pollution-free, and economical, smartvehicles based on VANETs have emerged. In this context,higher safety can be provided by exchanging critical eventsreliably. Improved efficiency is achieved by reducing trafficjams and pollution and making travel time more predictable.Furthermore, VANETs can be connected to the Internetto make the journey more entertaining by offering files todownload and access to social networks [18]. VANETs usetwo types of messages: beacon messages and safety messages.Vehicles use beacons to periodically broadcast and adver-tise status information to neighboring vehicles at intervalsof 100ms. The sender reports its velocity, location, andpseudo-ID to neighboring vehicles via beacon messages [19].On the other hand, safety messages assist vehicles on theroad by delivering emergency information so that properaction can be taken to prevent accidents and to save peoplefrom life-threatening situations. Vehicles broadcast a WAVEShort Message (WSM) to neighboring vehicles when theyencounter events on the road [5]. The message payload

Wireless Communications and Mobile Computing 3

includes information about the vehicle’s position, the mes-sages sending time, the vehicle’s location, and nearby roadevents, and so forth [20, 21]. Each vehicle gathers informationabout the neighboring vehicles within communication range.We consider heterogeneous VANETs where the OBUs ofthe vehicles are equipped with IEEE 802.11p and Long-TermEvolution (LTE) cellular technologies.

VANETs use conventional cloud for information storage,retrieval, management, complicated computation and globalnetworking [22].The cloud service can be classified into threebasic distribution models in the form of layers: software as aservice (SaaS), platform as a service (PaaS) and infrastructureas a service (IaaS). Hence, consumers can rent processing,storage, and network resources on which they can deployand run required application software and system software. Inthis case, customers have virtually unlimited resources basedonly on their budget [23]. Examples of cloud computing areEC2 provided byAmazon, Azure fromMicrosoft, andGoogleApps by Google.

VANETs use RSUs as gateways that provide a virtualiza-tion layer to connect to cloud services while on the move.The vehicular nodes use cloud services to obtain traffic andmultimedia information. This is a two-tiered architecturewhere vehicles are at the edge of the network, and the cloud isat the center [23]. A VANET using the cloud can have macro-control of the geographic position of all vehicles, obtainsinstantaneous traffic flows, and determines the targeted areaand desired recipients of safety messages [24, 25].

Even though VANETs use the cloud to solve existingproblems, there are still some fundamental challenges thatneed to be resolved along with the growth in the number ofsmart vehicles. Based on the rapid progress and developmenttrend of VANETs, some key challenges and requirements offutureVANETs are identified. FutureVANETs and its applica-tions will go beyond the current trend and integrate with newemerging technologies, which introduce new functionalities.Some of the key challenges of the future VANETs are asfollows:

(i) Intermittent connectivity: the control and manage-ment of network connection among vehicles andinfrastructure is a key challenge. The intermittentconnections due to the high mobility of vehiclesor high packet loss in vehicular networks must beavoided.

(ii) Highmobility and location awareness: futureVANETsrequire high mobility and location awareness of thevehicles participating in communication. Each vehi-cle should have the correct position of other vehiclesin the network to cope with an emergency situation.

(iii) Heterogeneous vehicle management: in the future,there will be a large number of heterogeneous smartvehicles. The management of heterogeneous vehiclesand their sporadic connections is another challengeof future VANETs.

(iv) Security: there is always a risk to the privacy of user’sdata content and location. The vehicles communicat-ing within the infrastructure should allow users to

decide what information should be exchanged andwhat information should be kept private. Privacy canbe assured by examining sensitive data locally, insteadof sending it to the cloud for analysis.

(v) Support of network intelligence: one of the challengesof future VANETs is that it needs to support networkintelligence. In future VANETs, there will be a largenumber of sensors installed in vehicles, and the edgecloud collects and preprocesses the collected databefore sharing them with other parts of the network,for example, conventional cloud servers.

Considering those challenges, the major requirements offuture VANETs can be summarized as follows:

(i) Low latency and real-time application: low latencyis the fundamental requirement in future VANETsregarding real-time applications. Future VANETsshould support real-time applications, like safetymessages with very low latency.

(ii) High bandwidth: in future, infotainment and comfortapplications such as high quality video streaming willbe in high demand. In addition, traffic applicationssuch as 3D maps and navigation systems requirefrequent automatic updates.

(iii) Connectivity: to meet the high communicationrequirements, future VANETs necessitate seamlessconnectivity between connected vehicles. Connectedand driverless vehicles should maintain continuousand highly reliable communication between vehiclesand fog devices. It should be able to avoid transmis-sion failures in the communication system.

3. Emerging Technologies for Future VANET

3.1. Edge Cloud Computing. In future, there will be a massivenumber of smart devices that will be a part of the Internet ofThings (IoT) and futureVANETs.Those devices need to com-municate with each other, for example, intelligent traffic lightsystems for autonomous vehicles and Vehicles-to-Everything(V2X), including other home-and-office smart appliances.The edge cloud computing (ECC) framework interconnectsedge devices of the IoT and the conventional cloud com-puting system. The edge cloud consists of virtualized microdatacenters distributed in different geographic locations.Theactual distribution of edge clouds depends on the customers’needs and preferences, economic circumstances, latencyrequirements of the network, and so on. The edge cloudprovides typical services in close proximity (within a singlehop) to end users, such as vehicles, mobile devices, and IoTdevices. It has flexible interface technology providing highbandwidth and low latency. The IaaS in ECC may satisfy on-demand migration of application code between edge cloudsduring runtime to cope with mobility of vehicles and devices.By using an edge cloud, the computation, storage, andprocessing loads are handled in a distributedmanner, insteadof backhauling every bit of traffic into main datacenter. TheIaaS in the edge cloud can host third-party application thathelps offload computations from vehicles to the network. In

4 Wireless Communications and Mobile Computing

Fog Computing

Large

Small

High

Low

Low

High

Cloud

No.

of h

ops t

o Cl

oud

Band

wid

th

Late

ncy

Fog ComputingComg CCompuFogF utiinmpFo gng

ll

La

Figure 1: Comparison of number of hops, latency, and bandwidth from edge nodes to the cloud.

addition, vehicles can benefit from computation and storage,as well as very low delay in communications between thevehicles and the edge cloud.

Figure 1 shows latency, bandwidth, and number of hopscomparison from edge nodes to the conventional cloud. Thebasic ECC can have three-vertical-tier hierarchy. As we cansee from the hierarchy, the number of hops from the edgedevices to the cloud increases as we go up from the bottomtier to the top tier.The edge devices have to go through severalintermediate connecting devices, such as switches, routers,controllers, and servers using different communication tech-nologies. The increased number of hops degrades the systemperformance due to delays and decrease throughput in end-to-end communication. The edge cloud can bring cloud-likeservices with better performance. In ECC, there are somesimilar concepts or flavors of edge cloud that fall under thesame umbrella. In next subsection, we discuss a brief compar-ative study between three different edge cloud computing.

3.1.1. Comparative Study of Edge Cloud Computing. Thethree-edge cloud computing with similar concepts are fogcomputing, the mobile edge computing (MEC), and thecloudlets, which aims to bridge the gap between edge devices(such as VANETs and IoT devices) and conventional cloudcomputing as shown in Figure 2. We present a comparisonbetween each of those concepts and the conventional cloud.

(A) Fog Computing. A fog computing was first introduced byCisco Systems, Inc., engineers to extend the cloud computingparadigm to the edge of wireless networks for IoT devices[16]. OpenFog Consortium drives the fog computing archi-tecture. Its objective is to influence standard bodies to create

standards so that the edge devices can interoperate securelywith other edge devices such as IoT and cloud servicesefficiently [26]. The implementation of IoT applications inthe two-tiered architecture of the conventional cloud doesnot meet requirements related to mobility, low latency, andlocation awareness of smart devices. Thus, the evolution ofthe multitiered fog computing architecture is investigated. Ingeneral, users must download their data (multimedia files,documents, etc.) from the cloud. In fog, the data will bestored in fog servers close to the users, decreasing latencyand increasing throughput. In the first tier, ITS applicationis deployed in vehicles. The second tier is the fog platform,including fog devices such as RSUs and wireless accessnetworks. The third tier is the hyperscale datacenter of theconventional cloud. Fog computing provides high band-width, low latency, location awareness, andQuality of Service(QoS) for streaming and real-time applications in vehicles[27]. Fog computing relies on resource virtualization byusing hypervisors for input/output resources and computing,virtual file systems for storage, and an SDN for networkvirtualization infrastructure [28].

(B) Mobile Edge Computing. A new Industry SpecificationGroup (ISG) within ETSI launched mobile edge computing:ETSI is developing a system architecture and is workingtowards standardization of several APIs essentially for MEC.Theobjective of the ISG is to create a standardized, open envi-ronment that will allow efficient and seamless integration ofapplications from service providers, vendors, and third par-ties across multivendor MEC platforms. The main purposeof MEC is to unite the telecommunications sectors and ITcloud worlds, providing IT and cloud computing capabilities

Wireless Communications and Mobile Computing 5

Edge Cloud Computing

Fog MEC Cloudlets

WSNV2XIoT IoT 5G DistributedCloud

TactileNetwork

CognitiveNetwork

Figure 2: Various types of edge cloud computing.

within the RAN. MEC servers can be deployed at multiplesites, for example, at a Radio Network Controller (RNC),at a multi-Radio Access Technology (RAT) cell aggregationsite, and at LTE macro base station (eNodeB) sites [29]. TheMEC server offers computing resources, storage capacity,connectivity, radio, and network information focusing onthe cellular network. MEC allows services and applicationsto be hosted above the network layer, that is, on top of themobile network elements.These services and applications canbenefit fromclose proximity tomobile devices, aswell as fromreceiving local radio network contextual information [30].Network operators focus on MEC to deliver a standardizededge computing architecture and industry-standardizedAPIsfor third-party applications.

(C) Cloudlets. Satyanarayanan and his team at CarnegieMellon University (CMU) developed cloudlets. The OpenEdge Computing (OEC) initiative drives the development ofsoftware ecosystems surrounding cloudlets [31]. A cloudletcan be regarded as a datacenter in a box designed withthe goal of bringing the cloud closer to mobile devices.According to Satyanarayanan, cloudlets are motivated withconsideration of end-to-end latency as well as by the role ofmobile computing in hostile environments [31]. A cloudletcan be viewed as a proxy of the real cloud and is locatedin the middle tier of the three-tier hierarchy. One of theapplications of the cloudlet is to cover the absence of thecloud by performing its essential services under hostileenvironments, such as a failure of wireless backhaul dueto Denial of Service (DoS) attacks. The cloudlets that areone wireless hop away from their associated mobile devicesserve as physically nearby representatives of the cloud. Thisapproach preserves the benefits of cloud mobile convergencewhile improving service availability [31]. CMU implementedvarious mechanisms as open source code for cloudlets. Athorough technical introduction and more information onrecent usage of cloudlets are presented elsewhere in [32, 33].Cloudlets aremore useful in hostile scenarios, where the con-nections between edge devices and cloudlets are intermittent.

(D) Comparison of Edge CloudComputingApproaches. A briefcomparison between edge cloud computing approaches (i.e.,

fog, MEC, and cloudlets) and the conventional cloud is givenin Table 1. Based on the comparison in Table 1, all three-edgecloud computing approaches share a similar vision, althoughthe motivations are different. Among them, fog computingfocuses on defining the virtual network topology for eachfog application. The inspiration for fog comes from the IoT,Wireless Sensor Networks (WSNs), and VANETs [34]. MECattempts to provide a highly distributed computing environ-ment by combining cloud computing with cellular networks.The inspiration for cloudlets comes from research intodistributed clouds, tactile, and cognitive networks. Cloudletsoffer open source code to target any industry that can benefitfrom low-latency edge cloud computing, including the IoT,tactile Internet, 5G, web content delivery, or online gaming.

Fog computing and MEC support mobility applicationson devices, whereas these applications have not been con-sidered in cloudlets yet. Fog and MEC emphasize onlineanalytics and big data analytics, as well as interaction withthe cloud,whereas cloudlets do not support big data analytics.Fog computing collects and secures data from vehicles travel-ling in a wide geographic area under different environmentalconditions supporting geomobility while it is not inherentto cloudlets. Fog computing analyzes extremely time-criticaldata andmakes a decision near the vehicles to reduce latency.Prompt action and decision on the data can make a bigdifference in avoiding disaster in hazardous locations. In caseof fog, the location of the fog server is flexible; that is, thefog server can be placed in between the end devices andthe cloud, while, in case of MEC, MEC servers are usuallycollocated with the base station (BS). In case of cloudlets, theedge servers are located at the network edge. In the VANETcombined with fog, which will be referred to as fog VANEThereafter, RSUs are used to broadcast the time-critical mes-sages to the vehicles around the event spot. In case of MEC,the interworking between MEC servers and RSUs has notbeen investigated in detail yet. MEC is based on cellularnetworks where the BS supports cell based broadcasting,that is, point-to-multipoint communication, such as evolvedMultimedia Broadcast Multicast Service (eMBMS) [35] in asingle cell. Thus, the emergency messages will be broadcastto a wide range beyond the accident area, even to the vehicleswho do not need that information due to wide coverage of

6 Wireless Communications and Mobile Computing

Table 1: Comparative study of edge clouds (i.e., fog computing, MEC, and cloudlets) and the conventional cloud.

Key featuresEdge cloud computing

Conventional cloudFog Mobile edge

computing (MEC) Cloudlets

Proposed/introduced by Cisco in Aug. 2012 ETSI in Sep. 2014 CMU team in Oct.2013 Amazon

Promoted by Cisco, Princeton,Microsoft, Intel, Dell

ETSI ISG MEC:Nokia, Huawei, IBM,Intel, NTT DoCoMo,

Vodafone

Prof. Mahadev atCMU, later supported

by Intel, Huawei,Vodafone, DeutscheTelekom, Nokia and

NTT

Microsoft,Google, Amazon

Industry organizations OpenFog Consortium ETSI MEC ISG Open EdgeComputing initiative

Open CloudConsortium

Inspiration IoT, WSN, VANETsMEC as steppingstone towards 5Gmobile networks

Distributed cloud,cognitive and tactical

network

Remote storage,computing, andapplications

Architecture framework Yes YesNot necessary, it canbe an enabler for fog

and MECYes

Geo-distributed Yes Yes Yes NoNetwork Architecture Decentralized Decentralized Decentralized CentralizedLow latency/jitter Yes Yes Yes NoGeo-mobility supportfor applicationson device

Yes Yes Not inherent, butcan be added No

Near real-timeinteraction Yes Partial Partial No

Emphasis on online dataanalytics & interactionwith cloud

Yes Yes N/A Yes

Edge server location Flexible b/w enddevice and cloud Collocated with BS Network Edge N/A

Dynamic broadcastingrange depending on themessage type

Yes Partial, not dynamic Yes N/A

Location awareness Yes Yes Yes NoMobility support Yes Yes N/A LimitedChannel Bandwidth 75MHz for 802.11p 20MHz for LTE 20MHz for 802.11n ---

Capacity 6Mbps for 802.11p150Mbps downlink &50Mbps uplink for

LTE50Mbps for 802.11n ---

Scalability High High High AverageRun experimentaltestbed Yes, at Princeton No Yes, at CMU Yes

a BS. If the BS wants to broadcast the emergency messagesonly to the vehicles near the event spot within a limited area,it needs to run searching operation to know the vehicles inthat area, which can be complex and time-consuming. Thesituation might get worse if the vehicles near the event spotare served by different mobile network operators.

3.1.2. Fog Computing for Future VANETs. Fog computingstands as a good candidate amongother edge clouds for futureVANETs based on Table 1. It complements and extends the

cloud to the edge of the network. Fog computing devices atthe edge collect data generated by vehicles. Fog computingsupports big data analytics by examining the raw data to drawconclusions about a specific information based on inferenceand enhances data processing at the edge in real time. It alsofilters the data collected locally and sends the filtered data toa higher tier, that is, the cloud, so it can retrieve the data inthe future. For example, the mining of real-time data throughedge analytics can produce more accurate reports of trafficcongestion on the road or the behavior of a crowd in a festival

Wireless Communications and Mobile Computing 7

area. When a vehicle moves far from a fog server, servicelatency increases drastically. Then, the fog can redirect theapplication in the vehicle to associate it with a new applicationinstance on a fog server that is now closer to that vehicle.The distributed fog servers can cooperate with each otherand share local information with vehicles in a VANET. Inaddition, fog can work autonomously, creating a local loopby sharing local traffic information, even when disconnectedfrom the main cloud. In fog, data privacy can be enhancedto allow users to spread personal information to differentphysical locations. Privacy can be assured by examiningsensitive data locally, instead of sending it to the cloud foranalysis. In fog computing, distributed infrastructure consistsof heterogeneous resources that are managed efficiently in adistributed manner. SDN can be used along with fog, whichprovides flexibility and programmability to heterogeneousvehicular networks.

3.2. Software-Defined Network in VANETs. SDN is an emerg-ing technology that can be used in coordination with edgecloud computing, especially fog computing, to provide cen-tralized control, flexibility, and programmability to networks[36, 37].Themost commonprotocol used for communicationbetween the SDN control plane and data plane is OpenFlow[38–40].Thus, the use ofOpenFlowwill improve themanage-ment of resources and vehicles by providing an opportunityfor new services and control functions. It separates the con-trol plane and the data plane with global information aboutthe network state.The data plane is used for data forwarding,and the control plane is used for network traffic control.

The basic SDN architecture is shown in Figure 3. It con-sists of three layers, that is, the application layer, the controllayer, and the network layer. The SDN controller interactswith the application layer using northbound interfaces. Thenorthbound interface supports application developers tomanage the network through the program. The southboundinterface interacts with the SDN controller and networkdevices of the network layer. Lin et al. [41] proposed an east-west bridge mechanism for intradomain communicationswithin an SDN. At the SDN controller, the network devicesbased on OpenFlow accept policies from the controllerwithout implementing various network protocol standards,resulting in direct control, programming, and managing ofresources in the network [42]. OpenFlow programmaticallycontrols flow and defines path from source to destination. Itincreases network efficiency and decreases the router packetprocessing overhead when defining the path. It also mini-mizes network management costs [40, 43, 44]. OpenFlowdevices use flow tables that consists of flow entries, and itdecides on how an incoming packet will be processed orforwarded. The switch makes a forwarding decision for eachincoming packet by looking into the flow table entries andsimultaneously matching the header field of the incomingpackets. If it finds a match, then a corresponding decisionwill follow. Otherwise, the packets are forwarded to the SDNcontroller for additional processing. Furthermore, the controllayer consists of amobility and routingmanager.Themobilitymanager in the control layer is responsible for collectingand maintaining the status of all the SDN switches, RSUs,

SDN AppsBusiness Apps

Cloud OrchestrationApplicationLayer

ControlLayer

Traffic Engineering

Mobility Routing

SDN Control Software

NetworkLayer

Network Devices

Router SDN Switch Other Network devices

API

OpenFlow

North-bound interface

South-bound interface

Figure 3: Basic SDN controller.

and vehicles. The vehicles may be temporarily disconnectedfrom the control plane due to the high speed of the vehicles.Route prediction can be included to estimate the possiblelocation when vehicles are disconnected. A vehicle’s futureroute can be obtained from the GPS or navigation systemused by the vehicle [45]. It can also manage event detectionand the switch-status update policy. The routing managermaintains network topology information using SDN switchstatus.Thenetwork topology for stationary data plane devicesrarely changes, whereas, for the mobile data plane, thenetwork topology is constructed using collected neighborinformation. Because of these characteristics of the SDN, itcan be used to satisfy the requirements of future VANETsystems and improve VANET services in heterogeneousenvironments [39].

3.2.1. A Comparative Study of Software-Defined Networkin VANETs. In VANETs, SDN provides synergies to solveseveral challenges and issues by improving the performanceof the vehicular networks. There are several research workbased on SDN in VANETs. We investigate different protocolsthat use SDN in VANETs and provide a brief comparativestudy of those protocols, which is given in Table 2.

The authors in [45] proposed Software-DefinedVehicularAd Hoc Networks (SDVN), which integrates heterogeneousnetworks such as V2V, V2I, and vehicle-to-cloud. It providessolution for constructing a logically centralized but physically

8 Wireless Communications and Mobile Computing

Table 2: A comparative study of software defined network in VANETs.

References Protocol Controller Simulator Remarks

[45]Software DefinedVehicular Network

(SDVN)

Open source SDNcontroller POX NS3 + SUMO

Discuss solutions to improve and mitigateheterogeneity of VANETs and providesolutions for constructing a logicallycentralized but physically distributedSDN controller to improve scalability.

[46]Optimized

Software-DefinedVehicular Ad HocNetworks (OSDVN)

---- Omnet + Veins +Sumo

Control plane optimizationSoftware-Defined Vehicular Ad HocNetworks to balance the latency

requirement and the cost on 5G networks.

[47]Software-DefinedInternet Of Vehicles

(SDIV)Floodlight Mininet

Proposed a novel rule installationmechanism aimed at reducing flow tablesize for real-time query services in SDIV

[48]SDN based Vehicle

Ad-Hoc On-DemandRouting (SVAO)

------ NS3 + SUMOSeparates network control layer and datatransfer layer of SDN to enhance the datatransmission efficiency within VANETs.

[49]Software DefinedInternet of Vehicles

(SD-IoV)

OpenFlowcontrollers -----------

Proposed a layered SD-IoV architecture,which is capable of improving resource

utilization, QoS, and networkoptimization.

[50]RSU Cloud Resource

Management(RSU-CRM)

OpenFlowcontrollers Mininet

A road side Cloud resource management(CRM) model provides multi-objectiveoptimization for minimizing control

plane overhead, VMmigration, numberof service hosts and reducing

infrastructure delays.

[51]

Software-definedTrust based Ad-HocOn-demand Distance

Vector routing(SD-TAODV)

NOS OPNETSDN based VANET focused on

on-demand distance vector routingprotocol with trust management scheme.

[52] Fog Computing basedon SDN (FSDN)

OpenFlowcontrollers -----------

By leveraging the SDN basic functionalityinto fog computing, SDN can supportservices like a resource manager and fog

orchestration models.

distributed SDNcontroller to improve scalability.The authorsemployed a trajectory-prediction-based vehicle status updatepolicy to minimize SDN management overhead. They evalu-ated their proposed protocol using the network simulatorNS-3 integrated with traffic simulator SUMO and open sourceSDN controller POX.

The authors in [46] proposed an Optimized Software-Defined Vehicular Ad Hoc Networks (OSDVN) that usedhybrid mode for the southbound communication in thecontrol plane of SDVN with low latency in 5G network.The authors optimized control plane of SDVN to balancethe latency requirement and the cost on 5G networks. Theyformulated the bandwidth-rebating problem as a two-stageStackelberg game and analyzed the game equilibrium tooptimize southbound communication between vehicles andcontrollers. They evaluated their scheme using OMNeT++and compared their scheme with other existing southboundcommunication modes. The results of their scheme showedimproved latency over other existing southbound commu-nicationmodes.However, the basic rule installation approach

of the SDN control plane is not efficient for dynamic vehi-cle due to real-time requirements by VANET. In order toovercome this issue, [45] proposed a novel rule installa-tion mechanism, which aimed at reducing flow table sizefor real-time query services in Software-Defined Internetof Vehicles (SDIV). They used compact flow table withimproved proactive rule installation to reduce the number ofrules. They substituted multicast addresses with destinationaddress and some modification in packet header withoutnetwork performance degradation. They used Mininet fortheir simulation and used flood light as SDN controller.

The authors in [48] proposed SDN based On-DemandRouting Protocol in Vehicle ad hoc networks (SVAO) thatseparates network control layer and data transfer layer of SDNto enhance the data transmission efficiency within VANETs.They proposed a two-level structure. A distributed globallevel collects all the vehicle information and centralized locallevel selects forwarding devices. They have used NS3 withSUMO to compare the performance of their proposed proto-col with other routing protocols with different vehicle density,

Wireless Communications and Mobile Computing 9

at different vehicle speeds in diverse communication ranges.On the other hand, Jiacheng et al. proposed a Software-Defined IoV (SD-IoV) architecture that is capable of improv-ing resource utilization, QoS, and network optimization inharsh VANET environments [49].The authors discussed SD-IoVmajor functions and challenges, and then they explainedin detail on how those challenges can be resolved. They gavean illustration on how functions enabled by SD-IoV solvedthe current challenges in IoV.They also provided the benefitsof SDN in SD-IoV such as vendor neutralization, networkmanagement, flexibility, and easy application deployment.They pointed out open issues of SD-IoV to shed light onfuture research.

Similarly, the authors in [50] designed RSU CloudResource Management (RSU-CRM) that contributes to theVANET cloud by increasing its advantages for serviceproviders and provides QoS for the users in the vehiclegrid. The primary demand of the vehicle grid is served byleveraging the flexibility of SDN to reconfigure the serviceshosted in the network dynamically and forwarding the dataefficiently. The CRM minimizes the infrastructure delays inthe RSU cloud and minimizes the network configurations. Italso minimizes the operational costs by reducing the numberof service replications. In addition to this, it providesmultiob-jective optimization for minimizing control plane overheadand VM migration. Zhang et al. [51] proposed a Software-Defined Trust Based Ad Hoc On-Demand Distance Vectorrouting (SD-TAODV) protocol in software-defined VANETswith trust management to ensure security and QoS. Theyused OPNETmodeler to compare their protocol with AODVprotocol, which showed better network performance thanAODV but shows higher end-to-end delay than AODV. Theauthors in [52] adopted the hybrid control mode proposed byKu et al. [42]. In their architecture, the SDN controller doesnot take full control of the system, but the task was sharedwith BS and RSUs. They assumed that SDN wireless nodesuse a cellular node for the control channel and DSRC forthe data channel. The authors used SDN wireless nodes asvehicles that act as a forwarding data plane that are operatingon OpenFlow.

4. Example Scenario of Fog for Safety MessageDissemination in VANETs

In future VANETs, fog can play an important role in the dis-semination of time-critical event messages, as it is located atthe proximity of the vehicles. Let us consider a case of usingfog in VANET environment. The main components of fogVANETs are fog servers, which are geographically distributedto control all the local activities in the region of interest.It can contribute to timely processing of data. A fog serverinterconnects with the cloud or other fog devices using wiredconnections on the Internet [53]. It helps to lower operat-ing expenses through conserving network bandwidth byprocessing the selected data locally, instead of sending themto the central cloud for analysis. We assume that fog servershave intelligence and can find an appropriate destinationof emergency messages. The fog server uses its computingresources to provide necessary location-based services and

Table 3: A table that summarizes the propagation range of a safetymessage depending on the event types.

Event type Range𝐸1(e.g., intersection accident) 𝑑

1(e.g., 10m)

𝐸2(e.g., fatal accident) 𝑑

2(e.g., 100m)

.

.

....

𝐸𝑛(e.g., road pile-up accident) 𝑑

𝑛(e.g., <10 km)

interact with vehicles and other fog devices for real-timeinformation processing.

Fog VANET can be composed of conventional cloud, fogcomputing infrastructure, and end devices (such as smartvehicles) as shown in Figure 4. The top tier is a conventionalcloud, which consists of servers or datacenters that providecomputation capability, massive data storage, and globalnetworking. Fog VANET interconnects fog devices (such asfog servers, router, switches, and RSUs) with the vehicles.Each RSU is connected to a switch, which is connected toa router. Each router is connected with fog servers, adjacentrouters, and themain cloud through Internet.The vehicles arethe end nodes located at the bottom tier of the framework. Infog infrastructure, the fog servers usually provide computingservice, and the routers and switches are the networkingdevices and the RSUs are the wireless access devices. In thisexample, we consider two types of messages, that is, safetymessages and infotainmentmessages.We investigate how thesafety messages and infotainment messages can be dissemi-nated from the vehicles to an appropriate destination. All thecommunications in fog VANET are based on IP protocol.

Let us consider an emergency situation where a vehiclebroadcasts safety messages to the neighbor vehicles andnearby RSUs, when it detects an event. Depending upon theevent types, the propagation range of a safety message can bedifferent as shown in Table 3. Some event types are advertisedto a limited range while other events are disseminated to avery wide area of several kilometers based on the severity ofthe event. Event types such as injury accidents or road pile-ups need to be disseminated to a longer distance to preventfrom further causalities. However, the propagation range ofa safety messages might be dependent on additional factors,for example, weather conditions, and, thus, a more compli-cated logic might be required to determine an appropriatepropagation range. This algorithm needs to be deployed inthe fog servers in this scenario. In this example, we consideran event type of road pile-up accident, which needs to bedisseminated to a wider area. When a vehicle detects a pile-up accident, it broadcasts that information to nearby RSUsusing broadcast IP address. Then, RSUs forward this safetymessage to the switch since this message was sent with abroadcast IP address, it reaches a router in Figure 4. Whenrouter receives the broadcast safety message, that messageneeds to be treated as an exceptional message. We can set upthe routing table of the router so that every message with abroadcast IP address is sent to the fog server.When the routerreceives the safety message with a broadcast destination IPaddress, the router will forward the safety message to the fog

10 Wireless Communications and Mobile Computing

Data Plane Backhaul CommunicationSafety messageInfotainment message

S/WS/W

S/W

Router

FOG

RSU

RSU

RSU

Fog Server

S/WS/W

S/W

Router

App. Server(e.g. infotainment Server)

FOG

Internet

RSU

Access Networks

Wireless communication

Backhaul Communication

RSU

RSU

Cloud Computing

Accident

Fog Server

FOG

Figure 4: Safety message dissemination in fog VANET.

server for further processing.Themessage flow is representedby a blue dashed line in Figure 4. The fog server examinesthe received message focusing on the event type, contents,timeliness, and priority.We assume that the fog servers have alogic such as machine-learning algorithms to decide whetherto forward the message to the central cloud or to other fogdevices. The fog server transmits the message to other fogservers geographically close to the accident area. The fogserver can also transmit the accumulated data to cloud forbig data analysis and the results can be provided to the thirdparties such as insurance company, police departments, orhospital for further processing.

Let us consider the infotainment case, where the user ofthe vehicle tries to download somemultimedia contents fromthe application server.The communication between the vehi-cle and the application server is based on IP address.The firstmessage from the vehicle, for example, http request message,can be received by an RSU and be forwarded to the router via

switch. The router forwards the infotainment message to theapplication server, based on the server IP address, which isrepresented by a green dashed line in Figure 4.

Figure 5 explains what advantage can be obtained ifSDN is used along with fog in the situation similar tothat of Figure 4. Combining SDN with fog might give anadditional benefit in future VANETs, such as low latency.TheSDN controller platform uses SDN controllers running theOpenFlow protocol and it provides fog orchestrator, network,and resource manager. In Figure 5, the red dashed linerepresents communication for the control plane and blue linerepresents communication for the data plane. Different fromthe case of Figure 4, SDN controller platform is used betweenfog and the cloud as shown in Figure 5.The fog orchestrationat the SDN controller organizes fog devices such as fogservers, routers, switches, and RSU controllers [14]. TheRSU controller in the SDN framework is an intelligent fogdevice, which runs the OpenFlow protocol. It controls and

Wireless Communications and Mobile Computing 11

S/W

S/W

Router FOG

RSU

RSU

RSU

Fog Server

S/WS/W

Router

Backhaul CommunicationInfotainment messageData Plane

Safety messageControl Plane

SDN Controller

RSU ControllerRSU Controller

Cloud Computing

App. Server(e.g. infotainment Server)

FOG

Internet

RSU

Access Networks

Wireless communication

Backhaul Communication

RSU

RSU

Accident

Fog Orchestration &Network Mgmt

S/WFog Server

Figure 5: Safety message dissemination in fog integrated with SDN in VANETs.

manages the RSUs and connects with other distributed RSUcontrollers. The fog server is responsible for forwardingthe data and storing local road and traffic information. Weassume that the SDN controller, fog devices, and distributedRSU controllers are interconnected with each other throughhigh-speed connections such as optical fiber.

Similar to the previous example without SDN framework,we assume that the vehicle detects a pile-up accident eventon the road and broadcasts safety messages to all neighborvehicles and nearbyRSUs. EachRSU sends this eventmessageto the fog server through a switch, RSU controller, and arouter. As discussed in the previous scenario, the router sendsthe safety messages to the fog server based on the broadcastIP address. The fog server decides whether to forward themessage to the central cloud through SDN controller or toother fog servers for further dissemination based on the event

type given in Table 3. The SDN controller can establish low-latency routes between relevant components in advance, forexample, between each fog server and the cloud or betweennearby fog servers.

In this case, the event type needs to be included as anadditional field in the forwarding table of the router thatis based on SDN. If the event-to-range mapping table inTable 3 can be defined clearly for all possible cases, then theroutes for each type of message can be preestablished by theSDN controller. However, if there are some exceptional cases,which cannot be covered byTable 3, then a new route needs tobe established on arrival of the first packet corresponding tothat exceptional case by interworking of SDN controller andfog servers.

All the packets that are covered by Table 3 can be handledby routers directly with low latency. If there is no rule

12 Wireless Communications and Mobile Computing

Table 4: Deployment issues for cloud-based approaches.

Deployment Issues Fog MEC Cloudlets

Networkingandcomputinginfrastructure

(i) Management of fog serverposition and interconnection(ii) Management of neighbor fogservers(iii) Wireless access(a) Wi-Fi and mobile networks(iv) Discrimination of real-timecritical message from non-real-timemessage

(i) Management of MEC serverposition and interconnection(ii) Management of neighbor MECservers(iii) Wireless access(a) mobile networks(iv) Discrimination of real-timecritical message from non-real-timemessage(v) Internetworking issues betweenexisting VANET infrastructure andMEC

(i) Management of Cloudletsserver position andinterconnection(ii) Management of neighborcloudlet servers(iii) Wireless access(a) Wi-Fi(iv) Discrimination of real-timecritical message fromnon-real-time message

matching the arriving packet in the forwarding table of therouter, then those packets can be sent to the fog server.The fogserver will find appropriated destination of the exceptionalpacket and notify the SDN controller of the routing decision.Then, the SDN controller can configure the router to handlethose packets with a reduced delay afterwards.

As compared with the previous example, this exampleshows that fog computing integrated with SDN in VANETscan be a candidate to resolve the key challenges of futureVANETs. The fog integrated with SDN provides low latencywhile increasing throughput by storing the data in thelocal fog servers that are close to the vehicular nodes. It issuitable for real-time traffic applications with low latencysuch as emergency messages. With the integration of cellularnetworks with 802.11p, it may be possible to resolve the issueof intermittent connections between V2X communication ona highway or an isolated road.

5. Deployment Issues ofCloud-Based Approaches

The three-edge cloud computing approaches, for example,fog, MEC and cloudlets, have several deployment issues interms of computing and networking infrastructures; we sum-marized them in Table 4.

One of the key issues is the management of the serverposition and the interconnection topology between them. Allthe three-edge cloud computing approaches use edge serversclose to the edge nodes. The position of each edge serverneeds to be determined considering the vehicle density ina given area, the data traffic, the communication range ofeach vehicle, and the processing burden on a server. In caseof MEC, the MEC servers are usually collocated with thebase station. The optimal position of edge servers needs tobe determined carefully considering the above factors by theInternet Service Providers (ISPs) or telecom operators, andthese positions need to be stored andmanaged systematically,for example, based on the cloud. If this information is storedin the cloud, then the cloud can have a global picture ofdistributed edge servers.

On the other hand, each edge server needs to know adja-cent edge servers. If the cloudmanages the global information

about the position of edge servers, then an edge server canobtain a list of adjacent servers from the cloud by sendinga request message containing its own network layer addressand physical location information. Once the list is obtained,this list needs to be stored in the local memory, and theconnection to those adjacent servers and the interconnectiontopology information need to be managed.

In VANETs, the messages generated by the vehicle canbe classified into two different categories: time-critical eventmessages corresponding to the types defined in Table 3and non-real-time messages corresponding to infotainmentapplications. As we discuss in Section, time-critical messagesare usually delivered to the edge server to decide whethersend it to the cloud or to adjacent edge servers. However,infotainment traffic does not need to be delivered to the edgeservers since the destinations of those messages are apparent,for example, infotainment servers. In this case, some networkdevices such as routers or switches need to discriminate thetime-critical event messages from infotainment messages tosend them to appropriate destinations. This is an importantissue that needs to be resolved by the network devices.

In terms of access network technology, the fog supportsbothWi-Fi andmobile network access mechanism. However,MEC supports mobile network and cloudlet supports Wi-Fionly [54].

In case of MEC, there is an additional internetworkingissue. Let us consider a case where we want to deploy MECin existing VANETs. Since RSU uses 802.11p protocol andMEC uses a different protocol, for example, REPLISOM [55],they cannot communicate with each other. The messagesmay not be delivered from the vehicles to the MEC. We canconsider two different approaches to this issue. If we upgradethe RSUs so that it can communicate with the MEC’s BS,the messages from the vehicles can be delivered to the MECby the relay of RSU. However, if the vehicle drives to newlocation where RSUs have not been upgraded or RSUs havenot been deployed yet, then the vehicles cannot communicatewith theMEC servers. As a second approach, we can considerupgrade of the hardware and software of each vehicle so thatit can communicate with theMEC server directly through BS.However, if vehicles can communicate directly with BS, thenthe role of existing RSUs needs to be redefined.

Wireless Communications and Mobile Computing 13

6. Conclusion

This paper presents a review of cloud-based emerging tech-nologies for future VANETs. We outlined the key challengesthat need to be resolved in future VANETs. We present abrief overview of edge cloud computing and three differentconcepts of edge cloud that fall under the same umbrella.We then compared three different types of edge cloudcomputing-based approaches: fog, mobile edge computing(MEC), and cloudlets based on key features. Although three-edge cloud computing approaches share similar vision, theirpurposes are different. We discussed a possible capabilityof fog and a combination of fog and SDN in resolving keychallenges of future VANETs through detailed examples. Wealso explained the issues that need to be resolved for thedeployment of three different cloud-based approaches.

Acronyms

VANET: Vehicular ad hoc networksSDN: Software-Defined NetworkITS: Intelligent Transportation SystemsV2V: Vehicle-to-VehicleV2I: Vehicle-to-InfrastructureRSU: Roadside UnitMANET: Mobile Ad Hoc NetworksSDN: Software-Defined NetworkDSRC: Dedicated Short-Range CommunicationsLTE: Long-Term EvolutionCSMA/CA: Carrier-Sense Multiple Access with Collision

AvoidanceWAVE: Wireless Access in Vehicular EnvironmentWSM: WAVE Short MessageSaaS: Software as a servicePaaS: Platform as a serviceIaaS: Infrastructure as a serviceECC: Edge cloud computingIoT: Internet of ThingsBS: Base stationMEC: Mobile edge computingQoS: Quality of ServiceISG: Industry Specification GroupRNC: Radio Network ControllerRAT: Radio Access TechnologyV2X: Vehicles-to-EverythingOEC: Open Edge ComputingeMBMS: Evolved Multimedia Broadcast Multicast

ServiceWSN: Wireless Sensor NetworkSDVN: Software-Defined Vehicular NetworkOSDVN: Optimized Software-Defined Vehicular Ad

Hoc NetworksSDIV: Software-Defined Internet of VehiclesSVAO: SDN based Vehicle Ad HocSD-IoV: Software-Defined Internet of VehiclesRSU-CRM: RSU Cloud Resource ManagementDoS: Denial of ServiceISP: Internet Service Provider.

Conflicts of Interest

The authors declare no conflicts of interest.

Acknowledgments

This researchwas supported in part by Basic Science ResearchProgram through theNational Research Foundation of Korea(NRF) funded by the Ministry of Education, Science andTechnology (2015R1D1A1A01058595). This research was sup-ported in part by the MSIP (Ministry of Science, ICT andFuture Planning), Korea, under the ITRC (Information Tech-nology Research Center) Support Program (IITP-2018-2016-0-00313) supervised by the IITP (Institute for InformationCommunications Technology Promotion).

References

[1] Intelligent transport systems (ITS), “Framework for publicmobile networks in cooperative its (c-its)s,” Tech. Rep., Euro-pean Telecommunications Standards Institute (ETSI), PaloAlto, Calif, USA, April 2012.

[2] E.Hossain, G. Chow,V. C.M. Leung et al., “Vehicular telematicsover heterogeneous wireless networks: a survey,” ComputerCommunications, vol. 33, no. 7, pp. 775–793, 2010.

[3] R. I. Meneguette, L. F. Bittencourt, and E. R. M. Madeira, “Aseamless flow mobility management architecture for vehicularcommunication networks,” Journal of Communications andNetworks, vol. 15, no. 2, pp. 207–216, 2013.

[4] Y. L. Morgan, “Notes on DSRC & WAVE standards suite: itsarchitecture, design, and characteristics,” IEEECommunicationsSurveys & Tutorials, vol. 12, no. 4, pp. 504–518, 2010.

[5] H.Hartenstein andK. P. Laberteaux,VANET:VehicularApplica-tions and Inter-Networking Technologies, Wiley Online Library,2010.

[6] B. Liu, D. Jia, J. Wang, K. Lu, and L. Wu, “Cloud-assisted safetymessage dissemination in VANET-cellular heterogeneous wire-less network,” IEEE Systems Journal, vol. PP, no. 99, pp. 1–12,2015.

[7] K. Trichias, “Modeling and evaluation of lte in intelligent trans-portation systems. dissertation,” IEEE Systems Journal, vol. PP,pp. 1–12, 2011.

[8] R. Sivaraj, A. K. Gopalakrishna, M. G. Chandra, and P. Bala-muralidhar, “QoS-enabled group communication in integratedVANET-LTE heterogeneous wireless networks,” in Proceed-ings of the 2011 IEEE 7th International Conference on Wire-less and Mobile Computing, Networking and Communications,WiMob’2011, pp. 17–24, October 2011.

[9] C.-F. Lai, H.-C. Chao, Y.-X. Lai, and J. Wan, “Cloud-assistedreal-time transrating for http live streaming,” IEEE WirelessCommunications Magazine, vol. 20, no. 3, pp. 62–70, 2013.

[10] L. Gu, D. Zeng, and S. Guo, “Vehicular cloud computing: asurvey,” in Proceedings of the IEEE Globecom Workshops (GCWkshps ’13), pp. 403–407, Atlanta, Ga, USA, December 2013.

[11] J. Wan, D. Zhang, Y. Sun, K. Lin, C. Zou, and H. Cai, “VCMIA:a novel architecture for integrating vehicular cyber-physicalsystems and mobile cloud computing,” Mobile Networks andApplications, vol. 19, no. 2, pp. 153–160, 2014.

[12] J. Wan, D. Zhang, S. Zhao, L. T. Yang, and J. Lloret, “Context-aware vehicular cyber-physical systems with cloud support:architecture, challenges, and solutions,” IEEE CommunicationsMagazine, vol. 52, no. 8, pp. 106–113, 2014.

14 Wireless Communications and Mobile Computing

[13] I. Stojmenovic, S. Wen, X. Huang, and H. Luan, “An overviewof Fog computing and its security issues,” Concurrency andComputation: Practice and Experience, vol. 28, no. 10, pp. 2991–3005, 2016.

[14] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computingand its role in the internet of things,” in Proceedings of the 1stACMMobile Cloud ComputingWorkshop, MCC 2012, pp. 13–15,ACM, New York, NY, USA, August 2012.

[15] X.Duan, Y. Liu, andX.Wang, “SDN enabled 5G-VANET:Adap-tive vehicle clustering and beamformed transmission for aggre-gated traffic,” IEEE CommunicationsMagazine, vol. 55, no. 7, pp.120–127, 2017.

[16] Open Network Foundation, “White paper: Software definednetworking: The new norm for networks,” Tech. Rep., CISCO,Palo Alto,Calif, USA, April 2012.

[17] W. He, G. Yan, and L. D. Xu, “Developing vehicular data cloudservices in the IoT environment,” IEEE Transactions on Indus-trial Informatics, vol. 10, no. 2, pp. 1587–1595, 2014.

[18] R. I. Meneguette, “A vehicular cloud-based framework for theintelligent transport management of big cities,” InternationalJournal of Distributed Sensor Networks, vol. 12, no. 5, article8198597, 2016.

[19] S. Bai, F. A. Zaid, and F. Bai, “Vehicle safety communications-applications (vsc-a) vehicle safety communications,” Tech. Rep.,The National Academy of Sciences, Engineering and Medicine,April 2011.

[20] X. Lin, X. Sun, P.-H. Ho, and X. Shen, “GSIS: a secure andprivacy-preserving protocol for vehicular communications,”IEEE Transactions on Vehicular Technology, vol. 56, no. 6, pp.3442–3456, 2007.

[21] H. Sarvada, T. R. Nikhil, and H. J. Kulkarni, “Identification ofblack spots and improvements to junctions in Bangalore city,”International Journal of Scientific Research, vol. 2, no. 8, pp. 136–139, 2013.

[22] M. Armbrust, A. Fox, R. Griffith et al., “A view of cloud com-puting,” Communications of the ACM, vol. 53, no. 4, pp. 50–58,2010.

[23] R. Hussain, J. Son, H. Eun, S. Kim, and H. Oh, “Rethinkingvehicular communications: merging VANET with cloud com-puting,” in Proceedings of the 4th IEEE International Conferenceon Cloud Computing Technology and Science (CloudCom ’12),pp. 606–609, IEEE, Taipei, Taiwan, December 2012.

[24] G. Yan, S. Olariu, and T. Hristov, “The next paradigm shift:From vehicular networks to vehicular clouds,” Mobile Ad HocNetworking: Cutting Edge Directions, vol. 56, no. 6, pp. 645–700,2013.

[25] S. Islam and J.-C. Gregoire, “Giving users an edge: A flexibleCloudmodel and its application for multimedia,” Future Gener-ation Computer Systems, vol. 28, no. 6, pp. 823–832, 2012.

[26] Openfog Consortium Architecture Working Group, “OpenFogReference Architecture for Fog Computing,” February 2017,http://www.OpenFogConsortium.org/.

[27] P. Bellavista, “Mobile cloud networking: Lessons learnt, openresearch directions, and industrial innovation opportunities,” inProceedings of the 4th IEEE International Conference on MobileCloud Computing, Services, and Engineering, MobileCloud 2016,pp. 79-80, April 2016.

[28] F. Bonomi, R. Milito, P. Natarajan, and J. Zhu, “Fog Computing:A Platform for Internet of Things and Analytics,” in Studies inComputational Intelligence, vol. 546, pp. 169–186, Springer, 2014.

[29] Y. C Hu, M. Patel, D. Sabella, N. Sprecher, and V. Young,“White paper:mobile edge computing a key technology towards5G,” ETSI (European Telecommunications Standards Institute),Sophia Antipolis CEDEX, Nice, France, September 2015.

[30] Mobile Edge Computing (MEC), ETSI, and Industry Speci-fication Group (ISG), “White paper: mobile edge computing(MEC); framework and reference architecture,” ETSI (EuropeanTelecommunications Standards Institute), Sophia AntipolisCEDEX, Nice, France, 2016.

[31] M. Satyanarayanan, G. Lewis, E. Morris, S. Simanta, J. Boleng,and K. Ha, “The role of cloudlets in hostile environments,” IEEEPervasive Computing, vol. 12, no. 4, pp. 40–49, 2013.

[32] M. Satyanarayanan, R. Schuster, M. Ebling et al., “An open eco-system for mobile-cloud convergence,” IEEE CommunicationsMagazine, vol. 53, no. 3, pp. 63–70, 2015.

[33] M. Satyanarayanan, P. Bahl, R. Caceres, andN.Davies, “The casefor VM-based cloudlets in mobile computing,” IEEE PervasiveComputing, vol. 8, no. 4, pp. 14–23, 2009.

[34] Mobile Edge Computing (MEC), ETSI, and Industry Specifica-tion Group (ISG),White Paper: Fog Computing and the InternetofThings: Extend the Cloud toWhere theThings Are, CISCO, SanJose, Calif, USA.

[35] D. Lecompte and F. Gabin, “Evolved multimedia broad-cast/multicast service (eMBMS) in LTE-advanced: overviewand Rel-11 enhancements,” IEEE Communications Magazine,vol. 50, no. 11, pp. 68–74, 2012.

[36] H. Farhady, H. Lee, and A. Nakao, “Software-defined network-ing,”Computer Networks:The International Journal of Computerand Telecommunications Networking, vol. 81, no. C, pp. 79–95,2015.

[37] N. McKeown, T. Anderson, H. Balakrishnan et al., “OpenFlow:enabling innovation in campus networks,” Computer Commu-nication Review, vol. 38, no. 2, pp. 69–74, 2008.

[38] W. Stallings, “Openflow switch specification,” Tech. Rep., OpenNetworking Foundation, Menlo Park, Calif, USA, 2014.

[39] W. Stallings, “Software defined networks and openflow,” TheInternet Protocol Journal, vol. 16, no. 1, pp. 1–7, April 2010.

[40] H. Kim and N. Feamster, “Improving network managementwith software defined networking,” IEEECommunicationsMag-azine, vol. 51, no. 2, pp. 114–119, 2013.

[41] P. Lin, J. Bi, and Y. Wang, “East-West Bridge for SDN NetworkPeering,” in Communications in Computer and InformationScience, vol. 401, pp. 170–181, Springer, Berlin, Germany, 2013.

[42] I. Ku, Y. Lu,M. Gerla, F. Ongaro, R. L. Gomes, and E. Cerqueira,“Towards software-defined VANET: architecture and services,”in Proceedings of the 13th Annual Mediterranean Ad HocNetworkingWorkshop (MED-HOC-NET ’14), pp. 103–110, IEEE,Piran, Slovenia, June 2014.

[43] M. Jammal, T. Singh, A. Shami, R. Asal, and Y. Li, “Softwaredefined networking: state of the art and research challenges,”Computer Networks, vol. 72, pp. 74–98, 2014.

[44] M.-K. Shin, K.-H. Nam, and H.-J. Kim, “Software-defined net-working (SDN): A reference architecture and open APIs,” inProceedings of the 2012 International Conference on ICT Con-vergence: “Global Open Innovation Summit for Smart ICT Con-vergence”, ICTC 2012, pp. 360-361, October 2012.

[45] Z. He, J. Cao, and X. Liu, “SDVN: Enabling rapid networkinnovation for heterogeneous vehicular communication,” IEEENetwork, vol. 30, no. 4, pp. 10–15, 2016.

Wireless Communications and Mobile Computing 15

[46] H. Li, M. Dong, and K. Ota, “Control Plane Optimization inSoftware-Defined Vehicular Ad Hoc Networks,” IEEE Transac-tions on Vehicular Technology, vol. 65, no. 10, pp. 7895–7904,2016.

[47] X. Wang, C. Wang, J. Zhang, M. Zhou, and C. Jiang, “Improvedrule installation for real-time query service in software-definedinternet of vehicles,” IEEE Transactions on Intelligent Trans-portation Systems, vol. 18, no. 2, pp. 225–235, 2017.

[48] B. Dong,W.Wu, Z. Yang, and J. Li, “Software DefinedNetwork-ing Based On-Demand Routing Protocol in Vehicle Ad HocNetworks,” in Proceedings of the 12th International Conferenceon Mobile Ad-Hoc and Sensor Networks, MSN 2016, vol. 25, pp.11–18, IEEE, Hefei, China, December 2016.

[49] C. Jiacheng, Z. Haibo, Z. Ning, Y. Peng, G. Lin, and S. Xuemin,“Software defined Internet of vehicles: architecture, challengesand solutions,” Journal of Communications and InformationNet-works, vol. 1, no. 1, pp. 14–26, 2016.

[50] M. A. Salahuddin, A. Al-Fuqaha, and M. Guizani, “Software-defined networking for rsu clouds in support of the internet ofvehicles,” IEEE Internet of Things Journal, vol. 2, no. 2, pp. 133–144, 2015.

[51] D. Zhang, F. R. Yu, Z. Wei, and A. Boukerche, “Trust-basedsecure routing in software-defined vehicular ad hoc networks,”Networking and Internet Architecture, 2016.

[52] N. B. Truong, G. M. Lee, and Y. Ghamri-Doudane, “Softwaredefined networking-based vehicular Adhoc Network with FogComputing,” in Proceedings of the 14th IFIP/IEEE InternationalSymposium on Integrated Network Management/Internationalworkshop on management of the future Internet, pp. 1202–1207,Ottawa, Canada, May 2015.

[53] T. H. Luan, L. Gao, Z. Li, W. Yang, S. Guiyi, and L. Sun, “Fogcomputing: focusing on mobile users at the edge, networkingand internet architecture,”Networking and Internet Architecture,2015.

[54] K. Dolui and S. K. Datta, “Comparison of edge computingimplementations: Fog computing, cloudlet and mobile edgecomputing,” in Proceedings of the 2017 Global Internet of ThingsSummit, GIoTS 2017, pp. 1–6, Geneva, Switzerland, June 2017.

[55] S. Abdelwahab, B. Hamdaoui, M. Guizani, and T. Znati,“Replisom: disciplined tinymemory replication formassive IoTdevices in LTE edge cloud,” IEEE Internet of Things Journal, vol.3, no. 3, pp. 327–338, 2016.

International Journal of

AerospaceEngineeringHindawiwww.hindawi.com Volume 2018

RoboticsJournal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Shock and Vibration

Hindawiwww.hindawi.com Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwww.hindawi.com

Volume 2018

Hindawi Publishing Corporation http://www.hindawi.com Volume 2013Hindawiwww.hindawi.com

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwww.hindawi.com Volume 2018

International Journal of

RotatingMachinery

Hindawiwww.hindawi.com Volume 2018

Modelling &Simulationin EngineeringHindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Navigation and Observation

International Journal of

Hindawi

www.hindawi.com Volume 2018

Advances in

Multimedia

Submit your manuscripts atwww.hindawi.com