Introduction
VFC use cases | Mobile vehicles | Parked vehicles |
---|---|---|
Communication | Mobile vehicles can be utilized as a communication hub that connects nearby vehicles together to facilitate information exchange with other base stations in order to provide better network connectivity. | 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. |
Related Work
WAVE Enabling Communications in a VFC Infrastructure
Reactive, Proactive and Geographic-based Routing Protocols in VANET
AODV
- 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. The route discovery phase enables intermediate nodes to copy the address of the source node that the RREQ message originates from and at the same time, RREQ copies the sequence identities (addresses) of the intermediate nodes. It continues to traverse the network until it reaches the destination node. The noted addresses (previous hops) in the routing table would be used to send the Route Reply (RREP) message to the source node.
- Route Maintenance: a routing table is employed in each node to maintain route for next destination hop. If there is a break on the links between the intermediate nodes, AODV issues a route error message to the source node as the route to the destination nodes become unreachable. When this happens, new route discovery operation is triggered.
DSR
- Route Discovery: this phase copies the sequence identities of intermediate nodes that RREQ has traverse and once it reaches to the destination node, the noted sequences would be used to send RREP to the source node i.e. the complete path taken by the RREQ. Note that this creates higher routing overhead compared to AODV.
- Route Maintenance: alternate routes are used when existing route to destination becomes unreachable. If there are no alternate routes available, new route discovery operation is triggered. Newly discovered routes would have their entries updated in the routing cache. This method is effective in low mobility scenario as alternate routes are tried before reinitiate route discovery phase.
DSDV
FSR
- In FSR, a routing table called link state table is implemented where it contains the updated routing information received from neighbors. Such information is updated with only nearest neighboring nodes where different time intervals are used for updating each routing entry in the link state table. 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
LAR
- 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 node – provided by GPS might yield in a smaller expected zone [24].
Performance of Different Routing Protocols in VANET
Simulation Setup
Parameters | Values | |
---|---|---|
SUMO | SUMO version | 0.31 |
Number of vehicles | 20, 30, 50, 80, 120 | |
Parking duration (seconds) | 600, 1200, 1800, 2400, 3000 (10 - 50 minutes) [10] | |
Simulation time | 3600 seconds (60 minutes) | |
Maximum speed of a vehicle | 10km/h, 20km/h, 30km/h, 40km/h, | |
50km/h, 70km/h, 90km/h, 110km/h | ||
Acceleration | 2.6 m/s2 (default) | |
Deceleration | 4.5 m/s2 (default) | |
Sigma | 0.5 (default) | |
Length of vehicle | 5 m (default) | |
Vehicle class | Passenger (default) | |
Number of parking spaces | 30 | |
Simulation area | 650 m x 750 m | |
NS-2 | NS-2 version | 2.35 |
Number of nodes | 20, 30, 50, 80, 120 | |
Pause time (seconds) | 600, 1200, 1800, 2400, 3000 (10, 20, 30, 40, 50 minutes) | |
Simulation time | 3600 seconds (60 minutes) | |
Routing protocols | DSDV, FSR, AODV, DSR, DREAM, LAR | |
Traffic type | File Transfer Protocol (FTP) and Constant Bit Rate (CBR) | |
Channel type | Wireless | |
Radio propagation model - Path Loss Exponent (γ) - Standard Deviation (σ) - Reference Distance (d0) | Nakagami 1.68 1.7 10 m | |
Mobility model | SUMO generated mobility traces | |
Simulation area | Simulation area 650 m x 750 m | |
MAC Protocol | IEEE 802.11p | |
Antenna model | Omni-antenna | |
Packet size | 512 bytes | |
TCP variant | Reno TCP | |
Maximum packet in interface queue | 50 | |
Receiver’s window size | 125 packets |
Results
Influence of Vehicle Density on TCP Performance
Influence of Varying Parking Duration on TCP Performance
Influence of Average Vehicle Speed on TCP Performance
Throughput | Delay | PDR | |
---|---|---|---|
Vehicle Density | Increasing vehicle density caused lower throughput, lower PDR and higher delay | ||
LAR is highly influenced by increasing vehicle density | |||
Highest throughput: AODV | Lowest delay: AODV | Highest PDR: AODV | |
Lowest throughput: LAR | Highest delay: LAR | Lowest PDR: LAR | |
Parking Duration | Increasing parking duration caused higher throughput, higher PDR and lower delay but DREAM | ||
and LAR (geographic routing protocols) attain lower throughput, lower PDR and higher delay | |||
AODV and DSR are highly influenced by increasing parking durations | |||
Highest throughput: DREAM | Lowest delay: AODV | Highest PDR: AODV | |
Lowest throughput: DSDV | Highest delay: LAR | Lowest PDR: DSDV | |
Vehicle Speed | Increasing vehicle speed caused lower throughput, lower PDR and higher delay | ||
LAR is highly influenced by increasing vehicle speed | |||
Highest throughput: DREAM | Lowest delay: DREAM | Highest PDR: AODV | |
Lowest throughput: LAR | Highest delay: LAR | Lowest PDR: LAR |
Discussion
- 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 table update. At different time of the day, parking duration will vary. The longer a vehicle stays, the less likely its routing table needs to be updated. To illustrate, let us consider peak hours and off-peak hours scenarios. During peak hours, vehicles are bound to have shorter parking duration. The movement implies frequent updates in the routing table. On the other hand, vehicles tend to remain inactive for a long period of time in the off-peak hour scenario. Thus, it is unnecessary to update the routing table frequently and a longer interval of update would suffice. 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].