Evaluating TCP performance of routing protocols for traffic exchange in street-parked vehicles based fog computing infrastructure

As most vehicles remain parked 95% of its time, this suggests that leveraging the use of On-board Units (OBUs) in parked vehicles would provide communication and computation services to other mobile and fixed nodes for delivery of services such as multimedia streaming, data storage and data processing. The nearby vehicles can form an infrastructure using IEEE 802.11p communication interface, facilitating communication, computation and storage services to the end users. We refer to this as a Vehicular Fog Computing (VFC) infrastructure. In this study, using NS-2 simulator, we investigate how six routing protocols consisting of two proactive routing protocols, Destination Sequence Destination Vector (DSDV) and Fisheye State Routing (FSR); two reactive routing protocols, Ad Hoc On-Demand Distance Vector (AODV) and Dynamic Source Routing (DSR); and two geographic routing protocols, Distance Routing Effect Algorithm for Mobility (DREAM) and Location Aided Routing (LAR) perform when forwarding TCP traffic among the parked vehicles that form a VFC infrastructure in an urban street parking scenario. In order to reflect an urban street parking scenario, we consider a traffic mobility traces that are generated using SUMO in our simulation. To the best of our knowledge, this work is the first effort to understand how vehicle density, vehicle speed and parking duration can influence TCP in an urban street parking scenario when packet forwarding decision is made using proactive, reactive and geographic routing protocols. In our performance evaluation, positive results are observed on the influence of parking duration in parked vehicles as TCP performance in all routing protocols increases with longer parking duration. However, variable speed in parked vehicles and moving vehicles in an urban street parking scenario may not have significant influence on TCP performance, especially in case of reactive and proactive routing protocols. Further, our findings reveal that vehicle density in a VFC infrastructure can noticeably influence TCP performance. Towards the end of the paper, we delineate some important future research issues in order to improve routing performance in a street-parked vehicle based VFC infrastructure.


Introduction
Vehicular Ad hoc Networks (VANETs) are seen as a key enabling technology in realizing Intelligent Transportation Systems (ITS) [38] and smart vehicles [13]. In a VANET, each vehicle acts as a node that facilitates data exchange with another vehicles (vehicle to vehicle) and nearby Road Side Units (RSUs) [14,15]. Being a subset of Mobile Ad hoc Networking (MANET), VANET makes use of vehicle mobility on the road that allows connection to be made with nearby vehicles to form a mobile network. This inter vehicle communication is possible as vehicles are equipped with On-Board Units (OBUs) which are an ITS component that allows computation of vehicles' performance and physical position associated information such as location, speed and distance away from incoming vehicle(s) [33]. This on-board computing facility in today's vehicles is spurring emerging applications such as infotainment and comfort applications (e.g. on-board Internet access, vehicle conditions for maintenance update, traffic congestion live information) [41,48].
There have been studies of VANET in cloud computing [21,39]. However, with the proliferation of stringent latency sensitive applications, the cloud cannot keep up with the latency requirement of today's applications [9]. On average, one way communication between a remote cloud server and a client could be more than 50 ms. Therefore, cloud cannot dispense services such as virtual reality, smart transportation and games that would require latency requirement approximately 10 ms [9]. Similarly, future tactile Internet applications will require the very strong latency requirement along with highly reliable network connectivity [44]. Taking the growing importance of latency requirement of applications, Cisco introduced Fog computing in which computational capability is pushed towards the network edge, enabling easy and quick computational support to the Internet of Things (IoTs).
With the technological advancements of today's OBU installed in vehicles, many researchers envision that vehicles may form a Fog computing facility for supporting different applications in the network access segment [8,19,41]. Implementation of vehicles as a fog node has developed a novel approach of Fog computing called Vehicular Fog-Computing (VFC). This will open up a new usage scenario of VANET in which nearby vehicles can form an infrastructure facilitating communication and computation services to the end users. In particular, aside from moving vehicles in street and highways, parked vehicles (non-mobile vehicles) have a lot to offer to the applications demanding intelligent analytics at the edge of the network [19]. Additionally, parked vehicles may act as RSUs and they can facilitate data traffic routing (e.g. safety messages broadcast) along with the existing dedicates RSUs in urban vehicular networks [36]. By doing so, additional expenses for deploying dedicates RSUs can be avoided successfully. Moreover, parked vehicles may collectively act as a WiFi VANET, a form of vehicular communication where the vehicles serve as WiFi access points (repeaters) to extend the connectivity of providing Internet access to nearby vehicles or users equipped with mobile phones, laptops, etc. [11].
It was estimated that there would be approximately one billion vehicles in 2020 [19]. Another study found that on average 95% of time a vehicle remains in parking position [11]. Using the underutilized vehicles' computing facilities, it is possible to reduce the requirement of the dedicated resources for Fog computing. That is to say, Fog computing service providers would require less number of fog nodes in access and edge segments if VFC is used. Parked vehicles can help other mobile nodes such as moving vehicles or nearby mobile computing devices to extend their limited capabilities in both communication and computing domains. Moreover, a VFC infrastructure where communication and data processing would be more effectively distributed to millions of parked vehicles could assist remote cloud in data aggregation, filtering, caching and analysis. The feature comparison between parked and mobile vehicles are explained in Table 1 [19,45]. Figure 1 portraits a VFC infrastructure in on-street parking urban environment supporting different applications of end users. Taking into account the computation and communication capability of future vehicles would have, one can easily surmise that VFC would open up new business models in the near future. Thus, additionally, VFC would reduce CAPEX and OPEX of both cloud and Fog-computing service providers. Nevertheless, VANET's highly dynamic topology nature with the frequent disconnection with nearby vehicles and base stations may result in not meeting the desired latency and throughput requirements for fog-based latency sensitive applications [20]. Such challenges necessitate the routing of information from a source node to a destination node by using the most suitable routing protocols. The performance of such routing protocols can be analysed by combining a mobility model for realistic vehicular movements, a communication MAC protocol and selected routing protocols in a simulated urban environment.
This paper studies and evaluates the performance of six routing protocols; Destination Sequence Destination Vector (DSDV), Fisheye State Routing (FSR), Ad Hoc On-Demand Distance Vector (AODV), Dynamic Source Routing (DSR), Distance Routing Effect Algorithm for Mobility (DREAM) and Location Aided Routing (LAR) when forwarding TCP traffic among vehicles over IEEE 802.11p communication interface in an urban street parking scenario. Our study is motivated by two facts. First, vehicles remained parked for a significant amount of time, and their powerful OBUs would contribute in amplifying edge computing capability by several folds. Second, we Parked vehicles can be utilized as a static information hub that carries and forwards information to nearby vehicles and mobile base stations and devices alike could significantly improve connectivity Localized and geographical distribution features of VFC allow faster decision making in relaying information compared to vehicular cloud computing where increasing delay is expected as frequent control information exchange occur between the vehicles and remote servers.
Parked vehicles in an idle state could compensate the disadvantages that mobile vehicles might be having as geo-locations do not disperse as much as the latter thus links forming between vehicles are sturdier and faster routing of information may be achieved.
A mobile vehicle is prone to experience obstacles such as buildings and trees throughout its journey, hence line-of-sight communication can be interrupted.
Wireless device and rechargeable vehicle battery enable parked vehicles to act as static backbones, allowing easy communication with one another and moving vehicles that are within the vicinity.

Computation
Slower moving vehicles in search of parking spaces or limited in movement due to congestion in road traffic could form VFC with nearby vehicles that aggregates computation resources found in embedded computers in each vehicle to do work offloading of computational tasks for nearby RSU, cloud servers and individual vehicle.
Creating clusters of parked vehicles in parking lots may cooperatively form a small data center that deals with various complex tasks that require high computing capability which would be impossible to perform by a single vehicle.
-Energy in vehicles are not wasted as surplus energy can be regulated for maximizing computational processes. As a result, this would satisfy the computation demands of mobile infrastructures.
Vehicles with prolonged parking duration provide a convenient means of providing a longer computation service to nearby devices such as computers, mobile devices, servers, vehicles and RSU.
need to understand TCP traffic performance when traffic is routed using different routing protocols as today's majority of Internet traffic flows use TCP [47]. At this point, we need to highlight that there are significant research efforts made to date to understand how different routing protocols perform in a VANET scenario (e.g. [1,23,28]). In those studies, simulations are conducted considering the routing protocols facilitate Vehicle to Vehicle (V2V) and Vehicle to RSU (V2R) communication. However, to understand how those routing protocols perform when vehicles form a VFC infrastructure, a simulation scenario should take into account communication among the vehicles and end users' devices aside from V2V and V2R. This is where our work goes beyond earlier efforts. To the best of our knowledge, this work is the first attempt in understanding DSDV, FSR, AODV, DSR, DREAM and LAR performance in an urban street parking scenario in which vehicles form a VFC infrastructure.
In our simulation, we use SUMO mobility trace in order to reflect the realistic representation of parked vehicles in an urban street scenario. Additionally, we consider IEEE 802.11p MAC protocol facilitates the communication among the vehicles in a VFC. The performance evaluation would be conducted by increasing vehicle density, varying average parking duration for each parked vehicle, and varying average speed of vehicles in streets where the TCP performance will then be analysed in these scenarios. The performance of each protocol is analysed using NS-2 simulator under the following QoS metrics: average end-to-end delay, Packet Delivery Ratio (PDR) and average throughput. Results from the simulation will be used to deduce the best performing routing protocol in an urban street environment.
The remainder of this paper is organized as follows. In "Related Work" section, we briefly provide an overview on IEEE 802.11p (WAVE), the different reactive routing protocols and existing research efforts investigating performance of different routing protocols in VANET. In "Simulation Setup" section, we present simulation setup for performance evaluation. "Results" and "Discussion" sections present our findings based on simulation and discussions, respectively. Finally, we conclude our work in "Conclusion" section.

Related Work
There are two alternative solutions in order to facilitate V2V and V2R communications, namely WiFi solution, which is also referred IEEE 802.11p, and long-termevolution-vehicle-to-anything (LTE-V2X) (cellular based solution) [4,17]. Both of the solutions have merits and drawbacks. As imparted in [4], LTE-V2X may outperforms in a highway scenario where a vehicle is traveling at speed of 120 km/h. Major limitations of IEEE 802.11p are high bit error and high latency when vehicle density is high (heavy traffic scenario) [5]. And, under the same traffic scenario LTE-V2X outperforms IEEE 802.11p in terms of latency and bit error. However, there are several limitations LTE-V2X interface based V2V and V2R communication: i) providing high availability and wide cellular coverage along the road may not be possible with LTE-V2X and 2) with the existing cellular infrastructure in most of the countries during peak-hours LTE-V2X is not possible to meet demand (i.e. very unlikely to meet the desired latency requirement for V2V and V2R communication). On the other hand, IEEE 802.11p communication interface already ready for large scale deployment compared to LTE-V2X and already there are large number of vehicles equipped with this interface available on the market [5]. Thus, for the real world deployment, IEEE 802.11p is ready and it has been gaining momentum [5].
In this section, first the overview of IEEE 802.11p is presented. Next, the common routing protocols used in VANET are elaborated and the most recent research work on the performance evaluation of routing protocols in VANET are investigated.

WAVE Enabling Communications in a VFC Infrastructure
The IEEE 802.11p/1609 is amended based on IEEE 802.11-2007 standard. It presents Wireless Access Vehicular Environment (WAVE) operational mode in order to facilitate communication among vehicles. Besides supporting TCP/UDP, the WAVE protocol stack has WAVE-mode Short Message Protocol (WSMP) [27,49], as shown in Fig. 2. The MAC of IEEE 802.11p uses Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA), similar to IEEE 802.11. IEEE 802.11p WAVE uses Enhanced Distributed Channel Access (EDCA). In EDCA, a source node senses the channel at Arbitrary Inter-frame Spacing (AIFS) and if it is found idle, the node will start its transmission. However, if the channel is busy, the source node must perform a backoff. The backoff process is  [27] similar to Distributed Coordination Function (DCF) in IEEE 802.11. One important difference between EDCA and DCF is that the inter-frame spacing interval in EDCA can be arbitrary (AIFS), allowing EDCA to shorten the frame spacing interval for delay-critical applications such as video streaming [6]. Two types of channels are specified for dedicated shortrange communications frequency band in WAVE: CCH (control channel) and SCH (service channel). CCH is primarily used for safety applications such as congestion and accidents control in road traffic by sending out WSMP messages and SCH can be used for safety and infotainment applications such as cooperative video streaming between vehicles [7,49]. Being an extension of IEEE 802.11, IEEE 802.11p uses EDCA that also employs Request To Send (RTS)/Clear To Send (CTS) mechanisms for wireless access in VANET, facilitating a collision free means for communication among vehicles. In standard unicast communication, RTS/CTS mechanisms is used to tackle collision where the same two-way handshaking process which requires the source node to send RTS, and waits for a CTS to be issued by the destination node. Frame transmission starts between the source and destination nodes, hindering other nodes from using the channel until the destination node issues an ACK to the source node as a feedback for successfully receiving the frame. However, if there is a need for retransmission of lost frames, Congestion Window (CW) size doubles as expected in DCF/EDCA mechanisms, thereby exponentially increasing the backoff time before the channel attempts for retransmission.
In broadcast communication for transmission of safety applications in VANET, RTS/CTS mechanisms are virtually unavailable which contribute to severe limitation in broadcast communication for safety messages in IEEE 802.11p [32]. When two nodes are within the transmission range of one another, they would simultaneously broadcast their safety messages which would collide result in higher probability of transmission collision that impaired successful delivery performance of broadcast service in IEEE 802.11p. In addition, receiving (destination) nodes within the communication range of the two source nodes would not be able to receive any of the safety messages, thus ACK packets are absent. Moreover, CW size will not double when collision occurs, as collision detection is also not possible due to absence of CTS packets from receiving nodes [31].

Reactive, Proactive and Geographic-based Routing Protocols in VANET
There are various Topology-based routing protocols available in VANET and these routing protocols are grouped according to their applications and characteristics [22,26,29]. Topology-based routing can be divided into three types: (i) proactive routing protocols, (ii) reactive routing protocols and (iii) hybrid routing protocols. This paper studies TCP performance under two proactive routing protocols -DSDV and FSR; two reactive routing protocols -AODV and DSR, and two geographic routing protocols, DREAM and LAR. These protocols are discussed below. More information on different routing protocols can be found in [22,29].

AODV
AODV is a topology based on demand routing protocol that relies on link information to route packets from a source to a destination. It operates on nodes via hop pattern through two phases: • Route Discovery: in AODV, when a sender node wants to forward a message to its destination node which is not its neighbor, the sender node uses Neighbor to broadcast a Route Request (RREQ) message that contains several important information, including source and destination addresses and message life span.

DSDV
DSDV is a proactive routing protocol that implements the use of routing entry in a routing table. Unlike a reactive routing protocol, DSDV does not considers a route discovery phase as part of creating paths for routing packets. Routing information from source to destination nodes is saved and updated periodically within the routing table. Details in a routing entry may include the next hop identifier to the destination node, the expected minimum number of hops to the destination node and a sequence number created by the destination node to avoid routing loop and also, to identify stale routes. The routing table in a DSDV identified node will update its entry through two methods: time-driven and event-driven. The former is periodic as routing information is regularly updated between nodes and their neighbors. The latter updates the routing table by means of a trigger due to a significant change in metrics of a particular routing entry [2,18].

FSR
FSR is another proactive or This leads to a reduction in size of routing messages between nodes. • In addition, reduce message size results in lower routing overhead and in FSR, the messages are updated periodically thereby this avoids the problem of excessive routing overhead resulting from a link state update for each node that is released in an event-driven manner which is typically found in other Link State routing protocols [18,34].

DREAM
DREAM is a position-based routing protocol that relies on obtaining geographical data consisting of nodes (vehicles) positions or locations from either digital maps or GPS. Unlike reactive routing protocols, DREAM does not need to update routing information in the routing table through the route discovery or route maintenance phases. DREAM utilizes the support of GPS to determine the node location and distance between the node and its neighbors. Each node location is exchanged and stored within the location table. As node moves from one location to another, the nodes mobility would influence the frequency of routing update between one another. Such routing results in each node to generate a control packet called location packet which would be distributed and flooded into the network and at the same time, data packets are also disseminated to every node that is aware of its current location [46].

LAR
LAR is another position-based or geographical routing protocol. Similar to DREAM, LAR benefits from the added support of GPS to identify nodes locations, this results in reduction of routing overhead. This is possible in LAR due to two regions: • Request Zone: this region emphasizes the local area of the present node that forwards request message to its neighbors. However, forwarding request will only be possible if the intended destination node is within the boundaries of the identified region. If the destination node is not inside or not within the region, then the request message is discarded. • Expected Zone: this region takes into account of determining the best possible position of the destination node at a particular time. This is done by taking the assumed velocity or speed at which the destination node is travelling and multiplying it by the time difference between the current time and the time at which the previous position of the destination node is updated in the routing table [40]. However, if the assumed velocity is actually larger than the average speed, therefore the best possible position of the destination node might be outside the expected zone at a particular time. In addition, having more information regarding the node mobility such as physical coordinates in terms of longitude, latitude and altitude and movement direction of the nodeprovided by GPS might yield in a smaller expected zone [24].

Performance of Different Routing Protocols in VANET
Research in VANET has generated varying quantitative results of routing protocols for the past 10 years using different performance metrics and network simulators. Below are some related research efforts in urban VANET. Authors in [28] studied the performance of AODV, AOMDV, DSR and DSDV routing protocols with IEEE 802.11p in VANET. Simulation is conducted using NS-2 and the Packet Delivery Ratio (PDR) and average endto-end delay are chosen as the performance metrics. Additionally, two factors in simulation were considered: vehicle speed and vehicle density per square meter. The paper concluded that AODV and AOMDV are best performing routing protocols in terms of PDR and DSR has average performance for both PDR and average end-toend delay, as DSDV has the lowest average end-to-end delay. However, authors did not mention the type of traffic (e.g. TCP/UDP) considered in their simulation. Therefore, one cannot comprehend how TCP or UDP traffic performances explicitly when these routing protocols are applied in VANET.
Similar to [28], authors in [23] studied those routing protocols in VANET using NS-2 on a SUMO produced scenario of Navi-Mumbai city model. The authors investigate UDP traffic performance in highly mobile scenario of vehicles in VANET. Their findings conclude that DSR gives the worst PDR performance compared to other routing protocols. In [1], authors study performance of AODV, AOMDV, DSR and DSDV routing protocols in VANET using NS-2 on a SUMO generated scenario based on city of Khartoum, Sudan. Unlike [23], their study evaluates TCP traffic performance in VANET. The study offers some important insights into the possible performance behavior of TCP under AODV, AOMDV, DSR and DSDV routing protocols. Their findings highlight that AODV and DSR result in better performance compared to DSDV. Additionally it has been concluded in this study that, with the increment of vehicle density, both PDR and throughput performance tend to decline in all these routing protocols. Despite that, authors did not consider any background traffic presence while evaluating TCP performance (UDP background traffic can have significant influence on overall TCP performance [30]).
A study was conducted in [16] to understand traffic performance in a VFC scenario. Simulation is carried out considering a highway scenario and the findings of this research efforts are similar to the conclusion drawn in [1]. Authors in [43] studied the performance of AODV and DSR in VANET for a parking lot with few parked vehicles to route UDP traffic. Random Waypoint (RWP) mobility model was used in their simulation conducted using NS-2. The simulation is conducted in terms of varying node speed and the throughput, average end-to-end delay and PDR are taken as the performance metrics. Result exhibits that AODV has the better performance for routing traffic in a parking lot. The major limitation of the findings of [43] comes from the fact that the performance evaluation is conducted based on RWP mobility model which is, arguably, not suitable for understanding actual routing performance in a vehicular mobility environment. Furthermore, the authors in [43] do not provide any findings on how vehicle density and parking duration could influence UDP traffic performance. Interested readers can refer to [42] for more discussion on why a relevant mobility model is increasingly important to understand actual performance of routing protocols in a particular scenario (e.g. a disaster area recovery or urban traffic scenario).

Simulation Setup
In this paper, we study the performance of DSDV, FSR, AODV, DSR, DREAM and LAR in an urban street environment. Our prime objective is to understand how these six routing protocols perform when parked and moving vehicles in an urban street exchange TCP traffic in order to support VFC infrastructures. To create a vehicle mobility scenario in our simulation, we consider Old Airport, Berakas, Brunei Darussalam (see Fig. 3). The area is selected since it meets the following characteristics which are generally observed in an urban street environment: (i) the area is bounded by office buildings; (ii) each road within the area has at least two lanes (one lane for going into the area and another lane for going out of the area); (iii) in certain peak hours during a weekday, the area can be seen to have high number of vehicles going in and out; and (iv) vehicles can be seen to park on the side of the roads, forming long lines of parallel parking.
There are mainly three parts that encompass our simulation procedure of this paper. First, road maps are obtained using Open Street Map (OSM), which is a map editor tool that allows extraction of real world location into OSM or osm.xml file. This is followed by importing the road map into SUMO, a microscopic traffic simulator for generating the required Tcl script and mobility trace files. Lastly, NS-2, a network simulator is used to simulate the VANET scenario for analysing the performance of the aforementioned reactive routing protocols.
For our simulation, we selected several offices located in the area. We considered the scenario where vehicles are driven by the visitors will be parked on the side of the roads, intended for short-term parking. This is One parked vehicle or end user's device is used as a source node and another parked vehicle is used as the destination node (assuming that the source node is retrieving any processed information from the destination node and/or offloading any task to the destination node for processing). Nearby parked vehicles and moving vehicles are used to route packets in a multihop manner using reactive routing protocols. A ratio of 1:4 between the total number of parked vehicles and the total number of moving vehicles is assumed in our simulation similar to [3]. The urban street area we selected in Old Airport, Berakas has 30 parking spaces allocated on the side of the road, as shown in Fig. 4. We assume that vehicles start on the edges of the network in different intervals and may either end on the edges of the network or at the current position on the roads during simulation. 1 In this simulation scenario, both mobile and parked vehicles are considered in order to reflect a scenario in which a set of mobile and stationary vehicles (fog nodes) are sharing their computing or storage resources (e.g. they may jointly process a set of tasks or share any multimedia contents).
The movement of vehicles within the simulated urban scenario is randomly generated using SUMO to emulate real world traffic. Then, the SUMO mobility traces are adopted for the simulation. Distribution of vehicles on the starting locations (source) in each scenario is made randomly according to binomial distribution. This means each vehicle has a random departure rate (starting time) and random arrival rate (ending time). There may be some vehicles having the same travel time i.e. time taken to reach ending locations (destination). However, there are also some vehicles not having the same travel time. Initial placement of vehicles is also randomly assigned by SUMO. It is assumed that each vehicle in the simulation is equipped with an OBU that facilitates on-board computation and communication with other neighboring vehicles through IEEE 802.11p, allowing the parked vehicle to act as a Fog-computing service delivery platform for clients. Average vehicle speed: a total range of 10 -110 km/h of average vehicle speed is used in the influence of average vehicle speed. In this simulation, lower speeds of 10 km/h -50 km/h with interval of 10, i.e. 10 km/h, 20 km/h, 30 km/h, 40 km/h and 50 km/h are values that are used to emulate the speed limits of on-street parking movements in cities. The lower bound, i.e. 10 km/h emulates networks with many interruptions (e.g. frequent on-street parking maneuvers affecting the traffic stream and pedestrian crossings). However, the upper bound emulates a real case where many cities worldwide have on-street parking on some roads with speed limits of 50 km/h 2 [10]. In addition, higher speeds of 70 km/h -110 km/h with interval of 20, i.e. 70 km/h, 90 km/h and 110 km/h are values that are used to emulate the speed limits of urban motorways and rural roads. The lower bound, i.e. 70 km/h emulates the minimum speed for vehicles to travel in urban motorways. While the upper bound, i.e. 110 km/h emulates the maximum speed for vehicles to travel in urban motorways and it also marks the maximum speed limit that is considered legal speeding behavior that drivers should practice on both urban motorways and rural roads [10,12,25]. Table 2 summarizes the parameters we consider in our simulation.

Results
Many existing research works (e.g. [30,37,42]) consider UDP traffic evaluating TCP traffic. This is because in a real network it is very unlikely that a network would serve only TCP traffic at a given time. In our simulation, UDP background connections are considered besides TCP traffic for evaluating DSDV, FSR, AODV, DSR, DREAM and LAR. Intermediate nodes (nearby vehicles either parked or moving within the transmission range of the nodes) between the source-destination pair would be used to forward these traffic via a peer-to-peer manner and routing packets are done in a multihop manner. The TCP performance through various vehicle density, street parking duration and average vehicle speed are observed. In this section, results are presented in the forms of average throughput, average end-to-end delay and PDR.

Influence of Vehicle Density on TCP Performance
To see whether vehicle density has influence on TCP throughput performance, 30 UDP (background) and 30 TCP flows are considered. It is assumed that the vehicles' parking duration is 30 minutes with speed of 50 km/h. Figure 5a shows the average throughput of TCP under increasing vehicle density. It can be observed that throughput in DSDV has a steep increase as vehicles density increases. While its counterpart, throughput in FSR also follows similar pattern albeit only slight increase. This pattern of slight increase in throughput as vehicles density increases is also seen in AODV, DSR and DREAM. However, throughput in LAR decreases as vehicles density increases. At lower vehicle density, throughput in DSDV, FSR, AODV, DSR, and DREAM increases between 20 to 30 vehicles. However, at 30 vehicles, throughput in all routing protocols started to decrease and identical pattern in throughput is observed for all routing protocols under increasing vehicle density. Between 30 to 120 vehicles, throughput in DSDV and FSR gradually decreases. Similar pattern of decrease in throughput is observed in AODV and DSR between 30 to 80 vehicles, but between 80 to 120 vehicles, throughput in AODV and DSR increases. However, throughput increases in DREAM between 30 to 50 vehicles but throughput in DREAM decreases between 50 to 120. It can be seen that AODV having the highest throughput in both lower vehicle density and higher vehicle density. FSR has the second highest throughput in lower vehicle density but it has the third highest throughput in higher vehicle density, behind AODV and DREAM. DREAM has a lower throughput although DREAM has the highest throughput at 50 vehicles, but throughput gradually decreases beyond 50 vehicles and it can be deduced that throughput in DREAM continue to decrease beyond the upper limit of 120 vehicles. DSR has the fourth highest throughput, followed by LAR and DSDV. Moreover, DSDV has the lowest throughput at 20 vehicles and similar pattern is seen at 120 vehicles. However, LAR has not shown any increase in throughput either at lower vehicle density or at higher vehicle density, albeit LAR has a slightly higher throughput than DSDV at 120 vehicles. It can be deduced that beyond 120 vehicles, throughput in LAR would continue to decrease and experiences a much lower throughput than DSDV. Thereby, AODV has the highest throughput followed by FSR, DREAM, DSR, DSDV and LAR under increasing vehicle density.
The given throughput in Fig. 5a are further supported by the results in Fig. 5b that shows the average end-to-end delay of TCP under increasing vehicle density. It can be observed at lower vehicle density i.e. 20 vehicles, all routing protocols have higher delay where DSDV has the highest delay and this is followed by LAR, DSR, DREAM and FSR. AODV has the lowest delay at lower vehicle density.  Fig. 5a and b are also supported by the results in Fig. 5c that shows the PDR of TCP under increasing vehicle density. The figure shows that similar pattern of increasing PDR as vehicle density increases for all routing protocols except for PDR in LAR that gradually decreases as vehicle density increases. At lower vehicle density, AODV has the highest PDR and this is followed by DSR, FSR, LAR and DREAM. DSDV has the lowest PDR. In comparison, DSDV has the lowest throughput and highest delay while AODV has the highest throughput and lowest delay at lower vehicle density. Therefore, lower PDR results in lower throughput and higher delay. Similar patterns of steep increase in PDR is observed in DSDV and slight increase in PDR for other routing protocols under increasing vehicle density, hence an increase in PDR imparts an increase in throughput and a decrease in delay. However, at higher vehicle density, AODV has the highest PDR and this is followed by DSR, FSR, DREAM, and DSDV. LAR has the lowest PDR at higher vehicle density. In summary, AODV has the highest PDR followed by DSR, FSR, DREAM, DSDV and LAR under increasing vehicle density.
Initially, between 20 to 30 vehicles, all routing protocols except LAR experiences an increase in both throughput and PDR as well a decrease in delay because increasing vehicle density attributes to increasing number of neighboring nodes to form paths in order to forward packets. As a result, this increases the availability and probability of alternative paths to route packets, thereby decreasing the probability of forwarding packets via congested paths. In addition, DSDV experiences a steep increase in throughput because at lower vehicle density, DSDV does not require much network resources to maintain its routing table as the routing entries are lower due to lesser number of neighboring nodes. This results in very low routing overhead, thus exponentially increases the number of successful routing at a much lower delay.
However, beyond 30 vehicles, all routing protocols except LAR experiences a gradual decrease in both throughput and PDR with an increase in delay. In the case of DSDV and FSR, both being proactive routing protocols are significantly affected at higher vehicle density because there is an exponential increase in vehicles to maintain their routing tables i.e. high channel occupancy, which overtime consume a lot of network resources thereby causing higher routing overhead and slower delivery of packets between neighboring nodes. However, FSR still has higher throughput compared to DSDV as FSR employs its technique of assigning different time intervals to update its routing entries and there is no need for triggering an untimely update to the routing table. In the case of AODV and DSR, both being reactive routing protocols, at higher vehicle density, there is a frequent increase in route discovery operations to establish routing with newer neighboring nodes, thus imparting a higher routing overhead. Similarly, DREAM floods the network frequently as there are more vehicles in the network, i.e. increasing routing updates as vehicles pass one another, imparting a higher routing overhead. This deduction is also adopted for LAR, where increasing vehicle density cause throughput and PDR to gradually decrease leading to a gradual increase in delay as more vehicles impart frequent routing updates. However, delay in LAR is considerably higher than DREAM due to more vehicles are considered when forwarding request message to its destination node, thereby imparting a higher probability of frequent request messages. Between 80 to 120 vehicles, both AODV and DSR attain a slight increase in throughput and PDR because considering the locations of neighboring nodes, where these nodes might be located in an area that is not within the radius of the transmission range of the source node. Concurrently, the source node is also not located within the radius of the transmission range of the neighboring nodes. Thus, these results in a reduction in the total RTS/CTS packets present in the wireless channel as the source node do not need to communicate with the neighboring nodes. Hence, the source node does not need to initiate frequent random backoff, resulting in lower delay, higher transmission rate and increased throughput.

Influence of Varying Parking Duration on TCP Performance
Figure 6a delineates how parking duration of vehicles can influence TCP performance. It is assumed that there are 30 UDP (background) and 30 TCP (foreground) flows, while the total number of vehicles is 50 and vehicle speed is 50 km/h. Figure 6a shows the average throughput of TCP under varying average parking durations. It can be observed that in shorter parking durations i.e. between 10 to 30 minutes, throughput in both DSDV and FSR increases. However, in longer parking durations i.e. between 30 to 50 minutes, throughput in DSDV decreases while throughput in FSR continues to increase. Identical pattern of increase in throughput is seen in both AODV and DSR. However, throughput in both DREAM and LAR decreases under increasing parking durations. It is also worth noting that DREAM has the highest throughput in both shorter parking durations and longer parking durations despite achieving a gradual decrease in throughput as it remains static and immobile for longer period of time. In summary, DREAM has the highest throughput followed by AODV, FSR, DSR, LAR and DSDV under increasing parking durations.
Results shown in Fig. 6a is further supported by results shown in Fig. 6b that shows the average end-to-end delay under increasing parking durations. It can be seen that between 10 to 30 minutes of parking, delay in both DSDV and FSR decreases but between 30 to 50 minutes, delay in DSDV increases while delay in FSR continue to decrease. Similar pattern of decrease in delay can be seen for both AODV and DSR under increasing parking durations. However, delay in both DREAM and LAR increases for longer period of parking. As a comparison, throughput in AODV and DSR increases as delay decreases under increasing parking durations whereby throughput in DREAM and LAR decreases as delay increases under increasing parking durations. It is also worth noting that DREAM has the lowest delay at 10 minutes of parking but it loses to AODV where it attains the second lowest delay at 50 minutes of parking. In addition, LAR has the highest delay under increasing parking durations. In summary, AODV has the lowest delay followed by DREAM, FSR, DSR, DSDV and LAR under increasing parking durations. Figure 6c shows the PDR of TCP under increasing parking durations. Between 10 to 30 minutes of parking, PDR in both DSDV and FSR increases but between 30 to 50 minutes of parking, PDR in DSDV decreases and PDR in FSR continues to increase. Both AODV and DSR experience a gradual increase in PDR and both DREAM and LAR experience a gradual decrease in PDR for longer period of parking. It is seen that both AODV and DSR being reactive routing protocols exhibit similar pattern in terms of throughput, delay and PDR under increasing parking durations and alternating to the increasing pattern in throughput and PDR for both AODV and DSR, where both DREAM and LAR attain decreasing pattern in both throughput and PDR under increasing parking durations, thereby both DREAM and LAR exhibit similar pattern in both performance metrics as geographic routing protocols. Shorter parking duration shows that DREAM has the highest PDR but it falls behind AODV, DSR and FSR at longer parking durations. AODV attains the highest PDR followed by DSR, FSR, DREAM, LAR and DSDV under increasing parking durations.
Increasing pattern in both throughput and PDR along with a decrease in delay found in the two pairs of collective routing protocols i.e. DSDV and FSR as proactive routing protocols and AODV and DSR as reactive routing protocols under increasing parking durations is because parked vehicles remain static and immobile for longer period of time leading to less change in topology forming more successful routing paths with neighboring nodes. As a result, routing of packets becomes faster and more reliable with less congestion in the network. However, the decreasing pattern in both throughput and PDR with an increase in delay found in both DREAM and LAR under increasing parking durations is due to a geographic routing protocol characteristic where GPS is required to enable either DREAM or LAR to establish routing with neighboring nodes that is both effective and providing less routing overhead. However, GPS is not required or not enabled in parked vehicle as there is no need for the vehicle to move, thereby vehicle speed and vehicle mobility are negligible. This caused both DREAM and LAR to resort to increase the frequency of flooding the network for establishing routing, imparting higher routing overhead and congestion.
It can also be observed that lower throughput, lower PDR and higher delay is experienced by DSDV at higher parking duration is because longer parking duration triggers DSDV to frequently send out routing messages to maintain its routing table which overtime consumes a lot of network resources, hence imparting higher overhead compared to shorter parking durations.

Influence of Average Vehicle Speed on TCP Performance
In this performance evaluation, a total of eight different values of average vehicle speed are used: 10,20,30,40,50,70, 90 and 110 km/h. In total, there are 54 simulation runs to obtained the given results for six routing protocols. The assumption on TCP and UDP traffic is the same as the previous performance evaluations. There are 50 vehicles and the parking duration for each vehicle is 30 minutes. Figure 7a shows the average throughput of TCP under increasing average vehicle speed. Initially at 10 km/h, high throughput is observed in all routing protocols with DREAM attains the highest throughput. Between 10 km/h to 20 km/h, all routing protocols experience a decrease in throughput but throughput in AODV increases. However, beyond 20 km/h, throughput in DSDV, FSR, AODV, DSR and DREAM remain consistent regardless of increasing vehicle speed. In the case of LAR, between 10 km/h to 40 km/h, throughput in LAR decreases. However, LAR experience a sudden increase in throughput between 40 km/h to 50 km/h. But, beyond 50 km/h, a similar pattern is seen between 10 km/h to 40 km/h where throughput in LAR gradually decreases. As a result, DREAM attains the highest throughput followed by AODV, FSR, DSR, DSDV and LAR. Figure 7b shows the average end-to-end delay under increasing average vehicle speed. Initially at 10 km/h, low delay is observed in all routing protocols with DREAM having the lowest delay. Between 10 km/h to 20 km/h, all routing protocols experience an increase in delay but delay in AODV decreases. In comparison, all routing protocols except AODV experience a decrease in throughput in this range of vehicle speed which results in a higher delay imparts lower throughput. However, beyond 20 km/h, similar linear pattern is seen where delay for DSDV, FSR, AODV, DSR and DREAM remain consistent regardless of increasing vehicle speed. In the case of LAR, delay increases between 10 km/h to 40 km/h but a sudden  Fig. 7a and b are further supported by the results shown in Fig. 7c that shows the PDR of TCP under increasing vehicle speed. It can be seen that at 10 km/h, all routing protocols have high PDR. However, between 10 km/h to 20 km/h, a decrease in PDR for all routing protocols except AODV that has experience an increase in PDR. In comparison, all routing protocols except AODV experience a decrease in throughput as delay increases under increasing vehicle density, thereby a decrease in PDR imparts lower throughput and higher delay. However, beyond 20 km/h, similar linear pattern is seen where PDR for DSDV, FSR, AODV, DSR and DREAM remain consistent regardless of increasing vehicle speed. In the case of LAR, PDR decreases between 10 km/h to 40 km/h but a sudden increase in PDR is attain between 40 km/h to 50 km/h. In addition, LAR experience a similar pattern of a gradual decrease in PDR for speeds beyond 50 km/h. Taking into account of throughput, delay and PDR in LAR, it can be deduced that beyond the upper limit of 110 km/h, LAR would experience a continuous gradual decrease in both throughput and PDR with a gradual increase in delay. In addition, it can also be seen that LAR has the lowest PDR compared to other routing protocols under increasing vehicle speed. Moreover, DREAM falls behind AODV for attaining the highest PDR and ties with DSR. As a result, AODV attains the highest PDR followed by DREAM, DSR, FSR, DSDV and LAR.
Observation shown that as vehicle speed increases from 10 km/h to 20 km/h, DSDV, FSR, DSR and DREAM have a decrease in both throughput and PDR with an increase in delay. This is due to increasing vehicle mobility causing higher topology changes and frequent disconnection with neighboring nodes, resulting in nodes falling out of their routing range. Similar pattern is seen in LAR as speed increases from 10 km/h to 40 km/h, thereby same assumption can be said for decreasing throughput, decreasing PDR and increasing delay in LAR. However, between 10 km/h to 20 km/h, only AODV has an increase in both throughput and PDR with a decrease in delay. This phenomenon is due to at lower vehicle speed, there is lesser to none breaks in links between nodes and their neighbors that have establish routing using AODV because there is lesser to zero route error messages that are forwarded to the source node, thereby there is less chance to trigger new route discovery operations.
Increasing speed between 20 km/h to 110 km/h shows that all routing protocols except LAR exhibit linear and consistent throughput, PDR and delay. Between 40 km/h to 50 km/h, LAR experiences a sudden increase in both throughput and PDR along having a sudden decrease in delay. This may be due to the range of vehicle speeds is optimal for LAR to yield a small expected zone to determine the best possible position of destination node. Smaller expected zone equates to LAR providing fewer request message to find its destination node as there is reduction in region size to consider leading to lesser neighboring nodes to obtain their route reply messages. However, beyond 50 km/h i.e. between 50 km/h to 110 km/h, LAR experience a decrease in both throughput and PDR with an increase in delay. This phenomenon can be due to higher vehicle speed yielding larger expected zone thus LAR has to provide higher frequency of route request messages to find its destination node, resulting in consider a larger region size with considerably higher number of neighboring nodes to obtain their route reply messages. In addition, higher vehicle speed imparts highly dynamic topology, therefore causing LAR nodes to have frequent disconnections between one another. Table 3 below shows the summary of results obtained in terms of average throughput, end-to-end delay and PDR.

Discussion
Our current work nonetheless opens up several avenues for future research in routing performance in the Vehicular Fog Computing (VFC) research domain, specifically in increasing throughput and decreasing the delay. This would include selective hopping, fog node selection for task processing and storage, and reduction of route discovery and maintenance-related overhead as discussed further below: • Selective hops for packets forwarding in a VFC: While the increase in vehicle density would reduce the physical distance and communication delay between nodes in a VFC infrastructures, data needs to be traversed in multiple hops from the source to destination that may concurrently increase the energy consumption. Looking at the issue from another perspective, not all nodes need to participate in the communication process. Through a selective process, only several nodes are chosen to provide with the optimal route for processing. As some vehicles stay longer than others, they would have higher availability. Thus, this can be used as an attribute for the selection. For instance, a low vehicle density scenario would only have one option consisting of five hops to send data from a source to destination. In a typical high vehicle density scenario without any selective process, the same process would take more hops to achieve the same goal. However, using a selective process in the high vehicle density scenario can provide several options to choose from that would give equal or even less number of hops from that of the former scenario. Hence, finding the optimal route from the selective hopping can help in reducing the delay and simultaneously increasing the throughput in the case of high vehicle density. Additionally, a vehicle mobility prediction information based on historical and context data of the vehicle can be taken into account while deciding on the hops in a packet forwarding path between a source and destination node. • Selective vehicle for computation and storage in a VFC: Allocating a task to a fog node (vehicle) that is mobile might cause the task to be migrated as the fog node becomes unavailable. This is undesirable as the migration could produce additional overhead to complete a task, including moving task to a new fog node and reestablishing TCP sessions. If finding the optimal route is not a concern, another alternative to reduce the delay is using a selective fog node process.
Assuming that an intermediate (e.g. a broker) is present with the knowledge of all of the fog nodes' capability, this can be used to assist in the fog selection process. The intermediate can filter out the fog nodes that do not meet the requirements to process the task and only the ones that are eligible are considered to process the task. The higher capability fog node will have a greater chance to complete the task and hence reducing the delay (and increase TCP throughput). • Route discovery and maintenance-related overhead reduction: Routing table needs to be updated to give the latest and accurate information. However, frequent updates could incur overheads and increase delay. Another possible approach to reduce such overhead could be introducing a dynamic interval of routing Therefore, the update interval can be changed dynamically (short interval for peak hours and long interval for off-peak hours) depending on the situation in order to reduce the overhead and delay. • Mechanisms required in enabling VFC in real-world: Emerging technologies have played a significant role in the real-world adoption of VFC, in various levels, mainly focusing in the communication or computation aspects. Apart from using the well-known RSU to assist in the VFC, there exists other cost-effective intermediaries such as a Fog-based broker. With virtualization, vehicle resources can be pooled and centrally managed by the broker. The broker can obtain incoming tasks from the end users and schedule the tasks to the qualified vehicles that meet the task requirement for further processing. Furthermore, such broker would have trust evaluation capabilities that are essential in the VFC due to the dynamic and heterogeneous environment. Depending on the context, the trust evaluation can be derived from suitable metrics such as security, recommendation, feedback [35], for parked vehicles, or using velocity, speed and direction for mobile vehicles [45].

Conclusion
This paper has successfully conducted performance simulation and evaluation of DSDV, FSR, AODV, DSR, DREAM and LAR routing protocols under different vehicle density, parking durations and vehicle speed based on SUMO mobility traces involving parked vehicles. In the near future parked vehicles would be part of network edge computing facility (by forming VFC) in order to reduce computational and storage burden of dedicated computing facilities for edge and cloud computing. Therefore, understanding which routing protocol would be the most suitable choice for delivering traffic among the VFC nodes (vehicles) is increasingly important. This paper concludes that AODV outperforms the other routing protocols, with DREAM attaining the second-best performance in all performance metrics: throughput, average end-to-end delay and PDR. Thereby, our study nominates the use of AODV or DREAM to route packets in urban street environment. Another important findings we discovered from the simulation results is that, in most cases none of the routing protocols may ensure end-toend delay less than 40 ms. Therefore, we may surmise that VFC with IEEE 802.11p interface is not suitable for the applications that have stringent latency requirement (e.g. 10 ms). Furthermore, although VFC enables allocation and processing of tasks generated from the end users, there are still other areas of concern that need future works. These include the residual battery power of vehicles and the power needed to compute the tasks, while considering the power needed for the vehicle to commute to its next destination. Additionally, vehicle availability should be a deciding factor before a task can be allocated to the vehicles. In VFC, availability can be observed from the vehicle parking duration and vehicle processing capabilities. These are crucial as they will have an impact on the VFC performance in terms of the task completion time, as well as the overall task migration that would impose additional communication and processing overheads. Subsequently, this all in turn would deteriorate TCP performance as such migration would increase occupancy of channel and the number of times a node (a vehicle in a VFC) needs to back-off due to collision resolution.