## 3 Enabling Technologies and Challenges for Futuristic Vehicular Networks
### Vehicular Edge Computing  
With the development of IoT and new wireless communication technologies, many new services and applications have been enabled into the VN. Users are demanding services with tighter requirements in terms of latency, bandwidth, computational capability; with limited onboard resources VUs alone are not capable of providing a satisfying Quality of Service (QoS). One way to solve this issue is to use cloud computing, where each VU can transmit their workloads towards the computationally rich cloud servers located deep inside networks. Thus, cloud servers perform the computation operations on behalf of the VUs and send back the results. With high computation resources, the cloud server can serve many VUs with negligible computation latency. However, with a long transmission distance between VU and cloud platforms, this approach introduces large communication delays. Furthermore, user data can be exposed over a large transitional distance can be prone to the security challenges such as third-party attacks. With limited backhaul resources, issues like network connections are likely to happen when many VUs from a giver service area request cloud computing services. Thus, providing a satisfying QoS can be challenging over the cloud computing platform. For solving cloud computing problems, the MEC approach was introduced [46]. MEC brings cloud computing services closer to the end-users by deploying several edge servers in proximity. Thus, users can transmit their workload to these servers without incurring large delays, security issues, or network congestion problems. MEC has gained lots of attention in the recent past and enabled several new latency-critical applications and services over wireless networks [47, 48]. In the vehicular scenario, the MEC framework is configured as the deployment of several RSUs along with the road networks and equipping them with the edge servers deployed in the proximity [8]. This approach is called vehicular edge computing (VEC) and has a huge potential for enabling latency-critical and data-intensive VN services [49]. Figure 1, shows the main elements of a reference VEC system which includes distributed VUs, several RSUs along with the road network, and EC servers located nearby RSU nodes. VUs can access VEC services provided by EC servers through RSU nodes with V2I communication links, while they can communicate among them through V2V communication links [50]. RSUs can also act as a gateway for uploading vehicular data to the BS and Cloud facilities. The limited available resources and RSU coverage are the main bottlenecks for reducing the performance of a VEC system. The resource limitation often increases the VEC system cost in terms of computation latency when multiple VUs request services from the same EC server. The RSU coverage limitations, along with VUs mobility, can add an extra cost in terms of handover latencies. In some works, authors have considered hybrid system models in which both VEC and Cloud computing facilities are considered together for solving the capacity and coverage issues in VEC systems [6, 51]. However, such approaches can have some serious drawbacks, such as long transmission distances for accessing cloud facilities. A VN with multiple EC layers of different air and ground networks in proximity (e.g., base station, LAPs, HAPs) can be a better approach compared with a hybrid VEC-cloud system. It can reduce the transmission latencies or network congestion caused by multiple VUs requesting cloud resources and solve the coverage and capacity problems of VEC systems alone. Within Multi-EC multi-service VN, selection of proper EC platforms and the amount to be offloaded can improve VNs performance. The offloading operations of the surrounding VUs can be useful for other vehicles for a proper offloading decision, such as selection of EC platform, and amount to be offloaded. Such network selection and computation offloading problem have been discussed in the Scenario 2 in Section 5.