A Survey of Multi-Access Edge Computing and Vehicular Networking

With the introduction of 5G and the Internet of Things, Multi-access Edge Computing (MEC) has become an evolving distributed computation and storage capability at the network edge. MEC will support task offloading, mobility, resource allocation, and management of inter-server communications to improve quality of service and satisfy real-time applications that require low latency. Thus, MEC is regarded as a crucial capability that will provide computation and storage at the network edge as an extension of the more traditional cloud. By placing MEC at the network edge, a broad range of new applications and services can be offered in close proximity to users, including support for vehicular networks. This paper provides a current and comprehensive review of MEC-enabled vehicular networks. It first introduces MEC by providing a definition, architecture, applications, and challenges. The paper then investigates MEC support for vehicular network applications and services and identifies current research and future challenges.


I. INTRODUCTION
The introduction of 5G, the Internet of Things (IoT) and new applications and services are driving fundamental change to the Internet and how resources are distributed in the network. The demand for improved Quality of Service (QoS), lower energy consumption, lower latency and higher capacity has motivated the development of new technologies to fill gaps in how data is collected, processed, stored and moved around the Internet. Examples of the new technologies include Mist computing, Fog computing and Mobile Cloud Computing (MCC) [1], [2], [3]. The motivation is to distribute compute and storage capability closer to where data is generated or consumed, and this includes IoT devices, User Equipment (UE) and other systems. Cloud computing [4], [5] is defined as a service model that allows UE to connect to cloud servers that are formed into a pool of resources. More demanding tasks, which have requirements exceeding the locally available resources, can be sent to cloud servers for execution. In the case of cloud computing [4], [5] and MCC, remote The associate editor coordinating the review of this manuscript and approving it for publication was Fan-Hsun Tseng. servers, which could be a static desktop computer or a mobile device, can be integrated into the resource pool. Mobile devices rely on cellular and wireless networks to connect to the cloud servers and have a smaller array of applications and local resources that can be utilized. The implementation of MCC produces advantages [6] including: • a reduction in the UE energy consumption by offloading task related energy consumption to the cloud; • access to cloud applications; and • enhanced storage capabilities. In order to reduce the problem of high latency, the edge computing paradigm was introduced to the edge of mobile networks as it can be used to support cloud services closer to the UE. Hence, mobile edge computing can offer significantly lower latency and save energy consumption in the users' applications. The first edge computing concept, Cloudlet, was proposed in 2009 [7], and it provides robust computing and storage services by placing powerful computers in closer proximity to users. Another well-known approach is combining the computing power of several users in close proximity by an ad-hoc cloud to perform computation locally [8], [9]. Compared to Cloudlets and ad-hoc clouds, a more general concept of edge computing is Fog computing, which Cisco introduced in 2012 to enable the processing of the applications on billions of connected devices at the edge of a network [3]. Consequently, Fog computing may be considered to be one of the critical enablers of the IoT and big data applications [10]. The equipment, with storage and processing capability, can range from wireless access points, routers and switches, to base stations and resource-rich cloud platforms and data centres [11].
A new solution for better QoS, which was developed by the Industry Specification Group (ISG) within the European Telecommunications Standards Institute (ETSI) in 2014 [12], is known as Mobile Edge Computing. The Mobile Edge Computing concept is to enable seamless and efficient integration of cloud computing functionalities into the mobile network to bring computing resources close to the UE. The creation of a brand new open ecosystem has been demonstrated by the group, in which the applications can be deployed across multi-vendor Mobile Edge Computing platforms by service providers. To ensure that the standard is maintained, the infrastructure's service environment needs to be managed and overseen by telecommunication companies. Notably, several published surveys have talked about the advantages and shortcomings of Mobile Edge Computing in different use cases and scenarios, as well as its standardization. As has been evidenced, the benefits of Mobile Edge Computing include high bandwidth, access to radio network information, low latency and location awareness as the cloud services are deployed on the edge of mobile networks. Although mobile network operators are expected to deploy and manage services, third party service providers will also be allowed to join the deployment, which could bring more applications into the Mobile Edge Computing ecosystem, including intelligent videos, connected cars, Internet of Things gateways and augmented reality [13]. In 2016, the ISG presented a Mobile Edge Computing reference architecture and framework to support services, including radio network information, location awareness and application execution. Furthermore, several papers have explored how to deploy the service environment by using both models with existing technologies. Significantly, the Mobile Edge Computing was replaced with Multi-access Edge Computing (MEC) by the ETSI ISG in September 2016 in order to broaden its applicability into heterogeneous networks including fixed access technologies and WiFi [14]. Table 1 includes selected differences between cloud computing service types.
MEC is considered to have a significant role in future network designs, the 5G/6G Networks [14] and IoT [16], as it reduces UE limitations and enables real-time applications and services. Mobile Internet services are widely and frequently accessed by users today, while riding on public transportation or driving vehicles. As a result, it causes a significant increase in data transmissions in currently available networks. Some researchers have generally classified vehicular networking applications into safety-based applications, and non-safety applications [17]. Specifically, safety-based applications include applications disseminated between entities within a vehicular network, such as warnings, alerts, and messaging. On the other hand, the applications with very low latency tolerance and high-efficiency requirements are categorized as safety applications. Some applications, such as autonomous driving, require reduced latency, improved data rate transmission, and a wider variety of communication. As a result, MEC is considered to be a promising solution to satisfy the demands of vehicular networks. Notably, the ETSI MEC ISG published a white paper in December 2017 to introduce and explain how MEC can be utilized as a supporting technology to provide multiple services for connected autonomous driving [18] and also to deploy services at appropriate locations in the 5G ecosystem [19]. The ETSI has an ongoing effort to support vehicular use cases by investigating innovative mechanisms and solutions. The authors in [20] proposed an SDN-enhanced 5G-MEC architecture, including new components providing softwarized multiple access management services (S-MAMS). The proposed S-MAMS that optimizes RU is aligned with the ETSI requirements for intelligent selection and combination of the paths used for the user plane.
5G, 6G and IoT, including the Internet of vehicular networks, will add millions, if not billions, of devices to the Internet and as a result it is anticipated that there will be a significant rise in the number of applications and services being used, as well as a significant rise in the need to aggregate and process data as close to UE as possible to prevent congestion and transmission of redundant information. It is therefore a challenge to design an MEC environment to consider the various categories of service requirements, device capabilities, and wireless characteristics based on the existing heuristic algorithms and solutions. Comparisons of cloud computing and MEC and the integration of MEC with vehicular networks [21] are found in the literature, however, aspects of MEC network performance have not been fully investigated and compared with other paradigms, and recently developed technologies are only now being applied to MEC enabled vehicular networks. For example, Artificial Intelligence (AI) and Blockchain have been recognized as valuable approaches that can be considered for algorithm feasibility and parameter dimensionality challenges. Also, ML enables computer programs to analyze data and derive outcomes by learning the intricacies of the problems that are being solved. Consequently, ML can be used to progressively improve the performance of pre-determined tasks [22]. The challenges related to MEC and ML integration and utilization with the Internet of Vehicular Networks were a motivation for this paper. In this paper, MEC is reviewed, including concepts, architecture, framework, and supporting technologies. A brief comparison with other computing paradigms is provided. In addition, MEC models, and challenges, including MEC enabled vehicular networks, are presented.

II. COMPARISON BETWEEN MEC AND OTHER PARADIGMS A. SIMILARITIES AND DIFFERENCES BETWEEN THE PARADIGMS
MEC is one of the paradigms that aims to deliver cloud computing capabilities at the network edge. As shown in Table 2, it has various similarities and differences with other significant edge paradigms.
• Similarities: As mentioned, although the edge paradigms have different backgrounds, the common goal is to bring computing capabilities to the network edge to improve service provision. The paradigms support various types of multi-tenant virtualization infrastructure, such as Cloudlet, Fog node, and MEC server. The infrastructures can be accessed through mobile and broadband networks, and the provisioning of computing capabilities can be adjusted, depending on the end user requirements. Monitoring the use of various resources has been taken into consideration by all of the paradigms, even though each paradigm has specific monitoring entities. Another similarity between the paradigms is mobility support. Various strategies have been used to support user mobility by each paradigm. In the network hierarchy, the mobility management entities are located at a higher level, and the mechanisms, are exploited to support the virtual machine, container, application and service migration. Further, to complement the services, the paradigms provide hierarchical multi-tiered architectures, which are extensions of the cloud. Nevertheless, the paradigms can operate using distributed and decentralized architectures. Ultimately, the paradigms seek to create federated infrastructures, and multiple edge infrastructures can coexist and exchange services and information. Additionally, the paradigms are able to provide similar benefits derived from the proximity of the edge data centers and accessing local information. The scalability of the whole ecosystem and the availability of services to UE are also key benefits.
• Differences: Even though the paradigms have similar targets, they have taken different strategies to achieve their goals. The deployment of edge computing platforms is focused by MEC to network edge locations and mobile network infrastructure, while the deployment of Fog nodes can be extended to other locations, including access points, user-managed servers, gateways and routers. Importantly, MCC can provide a distributed deployment, in which the service provisioning process can include the devices themselves, in some use cases.
The differences between these paradigms may influence the deployment scenarios adopted by service providers. It is essential to identify that the computing paradigms have service establishment, infrastructure and standards, that permit them to collaborate and in some scenarios to integrate.
MEC and Fog computing both have an architecture that includes server placement at the network edge with the objective of decreased latency when compared to cloud computing [23], [24]. MEC servers placed adjacent to RSUs provide computing services to vehicles. Fog computing might be considered to be a superset of MEC that has intermediate layers between the fog nodes (vehicles), edge computing servers and the cloud [25].
MEC based solutions aim to deploy computing and storage resources to the network edge. The first MEC related trend is to exploit the Network Function Virtualization (NFV) principles to provide flexible managed resource virtualization. The second MEC related trend is taking advantage of the Software Defined Networking (SDN) paradigm to decouple the control and data planes to dynamically adapt to the changing user requirements, service demand and traffic patterns [26]. Compute offloading is therefore a crucial MEC use case because it enables new and innovative sophisticated applications at the UE while reducing energy consumption [27], [28]. In [29], the compute offloading decision is divided into full offloading and partial offloading, and various compute offloading algorithms were introduced. The majority of the algorithms are exploited to minimize the UE energy consumption while meeting the execution delay constraint of the offloaded application. To note, individual papers have been compared to address the compute offloading decisions in Table 1 [29]. The authors of [30] demonstrate using simulations that a 90% energy saving can be achieved by MEC computation offloading, while the execution delay could be decreased by 98%. A computing resource allocation is included in the decision process for full or partial offloading from the UE to MEC servers. Furthermore, the papers focusing on computing resource allocation can be divided into two areas: a single computing node and multiple computing nodes, which is based on the ability of the offloaded application to be parallelized or partitioned.

III. MEC ENABLING TECHNOLOGIES AND FRAMEWORK
Cloud computing and virtualization technologies are important aspects of MEC. In addtion, MEC services are offered utilizing SDN, NFV, and network slicing, which allow multitenancy support and flexibility.

A. CLOUD COMPUTING, VM AND CONTAINER
Cloud Computing provides significant computing resources, constant availability, and convenient accessibility while reducing the need for end users to manage, monitor and support hardware and software. It also offers a shared resource pool with dynamic scalability. There are four distinct technology models and three service models provided [31].

1) TECHNOLOGY MODELS
• Private Cloud: It is wholly owned and maintained by an enterprise. Dedicated access is provided within the corporate firewall to ensure security (e.g., Citrix, Google, and RackSpace). • Public Cloud: It is hosted by a cloud provider to allow public users access to the pool of resources, which is based on a pay-as-per-use basis (e.g. Microsoft, Dell, and Amazon).
• Hybrid Cloud: It is the combination of private and public clouds (e.g., HP, IBM, and VMWare).
• Community Cloud: It is a pool of resources comprising of an aggregation of several providers, and a specific group can share it.
• Platform-as-a-service (PaaS): Users are offered a platform for developing, running, and managing applications (e.g. Amazon Beanstalk and Azure websites).
• Software-as-a-service (SaaS): Offers accessible software, which is hosted in the cloud (e.g. Google docs and Dropbox). VMs are an abstraction of a physical hardware stack, additional binaries, a full guest operating system image, and libraries for hosting services and applications. Essentially, these services and applications are required to provide finegrained control for terminating and instantiating processes and tasks on demand without affecting the underlying hardware. By contrast, the abstraction of a container happens at the OS level to run a specific service or application by using supporting libraries, system resources, and programs. The differences between VMs and containers can be seen in Table 3.

B. NETWORK FUNCTION VIRTUALIZATION
Operators can utilize network services and functions implemented in software to decouple the capabilities from VOLUME 10, 2022 vendor hardware, e.g., firewall, caching, Domain Name Service (DNS), and Packet Data Network/Service Gateways (PDN/S-GW). Outcomes of the decoupling include an increase in open source network service and function implementations, a decrease in the time to market and the opportunity to benefit from virtualization. NFV permits network services and functions to be implemented in the cloud or in distributed platforms, depending on the network architecture and implementation demands. Capital expenditure and operational savings can be achieved when NFV is implemented. Also, NFV provides scalability, flexible control and management and improved capability to react to changes in the network [32].
There are three domains that have been defined by the NFV architecture and orchestration framework [33]: • VNFs: They are the software implementation versions of network functions.
• NFV Infrastructure (NFVI): VNFs are deployed in the network environment, offered by NFVI, containing the software and hardware components, such as storage, CPU, and virtualization layer.

• NFV Management and Orchestration (NFV MANO):
It offers the capability of organizing and managing the virtual and physical resources of the NFVI, which is responsible for managing the lifecycle of VNFs.
NFV is a key technology that is used in MEC to virtualize entities and application instances, particularly the enabling of service scalability, migration, and flexibility. In addition, NFV MANO is responsible for the service fault and life-cycle management. Specifically, there are several benefits from the dynamic aspects of NFV for MEC: • The portability of NFV allows the movement of independent service state objects between different cloud environments in different networks.
• The deployment of portable functions over geographically inter-operable distributed virtual networks.
• Virtual network resources can be partitioned into slices for applications.
• There is a pool of configurable resources that can be shared by NFV for on-demand access.

C. SOFTWARE DEFINED NETWORKING
SDN was reviewed in [34] and provides multi-tenancy support and network programmability to enable the deployment of new and innovative network services and functions. MEC was introduced to provide compute and storage capabilities at the network edge, and SDN provides a flexible and programmatic platform to control and manage the networking aspects of MEC deployments. Essentially, SDN establishes a centralized logical control capability by decoupling the control plane from the data plane while exploiting standard APIs to enable orchestration. The underlying network infrastructure is abstracted by the centralized logical control plane to provide and instantiate virtual network instances. In order to dynamically allocate and relocate the resources of MEC-related VMs, VNFs, and containers, one or more SDN controllers are utilized [14]. Therefore, SDN's flexible service chaining can be used to connect, manage and dynamically provision VNFs and MEC services. SDN controllers can be position to provide network control and management capability at the network edge to meet performance demands and provide access to third parties and application providers to assist service mobility by enhancing the network infrastructure operation.
To be able to cope with service management and network connectivity in the context of MEC platforms or over edgeto-edge diverse transport networks and between MEC edge servers through a heterogeneous radio network, an agile and simple solution has been provided by SDN. Remarkably, some of the current routing issues associated with tunneling overhead, large volumes of control signaling, dynamic resource management, and IP address translation can be overcome by SDN [35]. The advantage of SDN associated with cross-layer operations between the transport and mobile system is that it can benefit user mobility between MEC platforms, e.g., distributed mobility can exploit RAN analytics at the edge of a mobile network.

D. NETWORK SLICING
Network slicing is the term used when one network is sliced into multiple optimized instances to satisfy specific requirements or services. It was introduced as a critical technology to provide an agile networking platform for diverse service requirements. In [36], it was demonstrated that multiple self-contained, logical networks can be deployed utilizing network slicing on shared physical infrastructure. It allows customized network operation and resource isolation. In other words, network slicing provides a multi-tenant environment, supporting the dynamic assignment of network functions, applications, and Radio Access Types (RATs), as well as flexible provisioning of network resources. Network slicing includes the notion of network slice broker to complement the service exposure capability function and the network sharing management in 3GPP mobile networks, enabling resource sharing within services, applications, and virtual mobile network operators (MNOs). Notably, the capacity of the core network and the mobile backhaul can be increased by offloading traffic to storage and compute nodes at the network edge. This is one of the motivators for MEC, and why network slicing can be used to provide scalability and low latency. SDN, NFV, and network slicing combines to enable flexible service customization, provisioning and control [37].

E. ARTIFICIAL INTELLIGENCE
AI expands technological innovation by providing improved data analysis insights, especially in time-varying and complex networks [38], [39]. Pushing the AI frontiers to the network edge under this context has given rise to an emerging discipline, namely, edge intelligence (EI). It is not the simple integration of MEC and AI, but a fully complementary and new approach to utilising AI at the network edge. However, the implementation of EI is still in its infancy. EI can enable edge equipment to perform model training and inference locally, avoiding frequent communication with cloud platforms. The methods represented by deep learning and reinforcement learning (RL) have gradually become the most popular AI techniques in EI. Reference [40] claims that the integration of MEC and AI is an inevitable trend, and the reasons for this claim are: • Lower latency and bandwidth consumption • Adapting to time-varying environments • Richer edge application scenarios • MEC is an enabler for ubiquitous AI • MEC can be popularized with AI applications AI can substantially improve the cognitive performance and intelligence of the Internet of Vehicles (IoV) to adapt to rapidly changing dynamic environments, and provide multiple task requirements for resource allocation, computing task scheduling, and vehicle trajectory prediction. On this basis, EI has exhibited fascinating potential for handling various intelligent vehicle applications by adding AI services to edge RSUs. Reference [40] has introduced a deep Q-network (DDQN)-based method to minimize the cost of communication, storage, and computation in a vehicular network. However, there are still challenges that need to be considered before EI can be deployed commercially, such as: • System dynamics and openness • Hardware and network architecture • Lightweight training models • Security and privacy F. MEC FRAMEWORK MEC provides a flexible distributed programmable ecosystem by enabling modular and open solutions at the network edge to transform the user experience. Application providers and third parties can exploit MEC to offer new and innovation applications and services that benefit from the MEC node position close to the UE. The MEC nodes can be implemented based on demand to offer scalable compute and storage. ETSI has substantially positioned MEC by providing a requirements definition, reference architecture, and contributed to standards development [41]. Figure 1 illustrates the ETSI MEC framework, which is an ecosystem structure, including the functions and entities involved. The entities can be categorized into three levels: mobile edge system level, mobile edge host level and network level. The top level of the MEC framework is the mobile edge system level, and the mobile edge system-level management plays the crucial role of facilitating access for third parties and UE by providing an abstraction of the underlying MEC system. The second level is the mobile edge host level, which consists of two main components including the mobile edge host and the mobile edge host-level management. The mobile edge host offers the mobile edge platform and virtualization infrastructure to accelerate the execution of mobile edge applications. The last level is the network level, providing connectivity to one or more external networks, e.g., transit and 3GPP mobile networks.

IV. MEC ENABLED INTERNET OF VEHICLES
With the development of intelligent vehicles and sensors, the mobility and safety of vehicles on the road have become a new challenge. IoV is a fundamental technology and platform for intelligent transportation systems [42]. It can support various communication patterns, such as vehicle to infrastructure, vehicle to sensor, and vehicle to vehicle. Roadside units (RSUs) are being deployed along key routes to provide reliable coverage and access to the increasing number of applications and services targeting intelligent transportation systems. IoVs require flexible and reliable networking, fast and optimized management and the coordination of network edge compute and storage resources. RSUs are capable of caching content before delivering it to the target vehicles, and thus play an agent role in information dissemination. However, one of the challenges for the IoV is real-time low latency communication, as a majority of vehicular applications are delay-sensitive. Therefore, MEC has been recognized as a valuable option to solve this challenge by deploying compute, storage and communication resources close to vehicles. Some research works [21], [43] have investigated the architecture, applications and technical issues of MEC-enabled vehicular networks. However, different challenges arise such as mobility management, content caching, and security and privacy.

A. MEC-ENABLED VEHICULAR NETWORK ARCHITECTURE
The architecture of the MEC-enabled vehicular network is presented in Fig. 2. There are three layers in this architecture, including the cloud layer, which includes cloud servers, the MEC layer, MEC nodes, e.g., RSUs, and the user layer, which is the vehicular terminals.  • Communications. Vehicles utilize V2V and V2R communications to exchange information with other vehicles or RSUs.
• Sensing. Vehicles have sensors that collect internal and external data, e.g., Global Positioning System (GPS), vehicular system sensors, radar, and cameras.
• Storage. Vehicular terminals have storage that can act as a proxy cache for data storage and sharing.
• Computing. Vehicular terminals are capable of carrying out computing tasks in support of local applications, services and data processing, aggregation and storage.

2) EDGE SERVERS
RSUs are usually considered to be edge servers in MEC-enabled vehicular networks, and they are often distributed along major roads. When compared with vehicles, RSUs have greater compute and storage capability and communication resources, including access to transit networks and the vehicular terminals. Typically, they are responsible for processing the data collected from vehicles and uploading a subset of the aggregated and processed data to the cloud. Also, RSUs can satisfy strict performance requirements by utilizing caching technologies and computation offloading. RSUs offer various applications and services for vehicles, such as traffic control, content delivery and video streaming, safety and enhanced path navigation.

3) CLOUD SERVERS
Cloud servers, in contrast, have considerably more storage and computation resources available and data centres are positioned to provide coverage to a much wider area than an edge server. They are deployed in a remote cloud, and they are responsible for receiving the uploaded information from edge servers and mobile nodes, processing the information with a global view of the covered area, and sending responses to the processed information back to the edge servers. In addition, the cloud paradigm supports making optimal decisions by providing centralized control and global level management.

B. MEC ENABLED VEHICULAR NETWORK TECHNOLOGIES
SDN [44], cloud technology, smart vehicles [45] and NFV are enabling technologies for MEC-enabled vehicular networks.
They're integrated with MEC enabled vehicular networks to sustain diverse application services, simplify network management, reduce cost, and decrease network load and delay by processing tasks locally. The implementation of MEC-enabled vehicular networks can provide benefits, including lower response times, rich services, alleviating the tremendous bandwidth stress from back-haul networks, as well as close-proximity storage, and services. MEC enabled vehicular networks enable diverse applications, including:

1) ENTERTAINMENT
With the advantages of smart vehicles, drivers can spend more time focused on entertainment applications than complex driving operations [46]. The storage and computation resources and capabilities in MEC enabled vehicular networks benefits entertainment applications by significantly improving the QoS, and by caching popular entertainment content.

2) ROAD SAFETY
The RSUs (MEC servers) are deployed along major roads, which places the edge servers in close proximity to vehicles thereby reducing latency and permitting sensor data to be received and analysed in near real-time. Safety related information can be passed to surrounding vehicles to avoid potential accidents.

3) PATH NAVIGATION
The MEC storage and computation resources can be used to enhance path navigation by collecting, storing and processing data from vehicles within range and through aggregated and processed data received from neighbor RSUs [47].

4) TRAFFIC CONTROL
The RSUs along the major roads collect data from vehicles and sensors within its region and use this information to identify traffic status and assist with traffic control by providing updates to traffic control systems and vehicles. The information provided by the RSUs reduces traffic congestion and improves traffic flow [48].

5) LOW LATENCY SERVICES
The demands of high reliability and ultra-low latency services can be met by MEC enabled vehicular networks, such as autonomous driving [49]. The robust computation and storage resources of the MEC enabled vehicular network can support task execution for autonomous driving systems by providing updates on the surrounding environment, traffic status, and congestion.

6) INTENSIVE COMPUTATION SERVICES
Intensive computation services can leverage the computation offloading possible with MEC enabled vehicular networks. Augmented Reality (AR) and facial recognition are two standard appliciatons that benefit from MEC supported intensive computation services. The services can be transferred to from the cloud to edge servers with available computation resources.

7) DATA MINING AND AGGREGATION
MEC enabled vehicular networks are anticipated to generate a significant amount of data and as the network matures the data generation growth could be exponential. The data can be received from vehicles [50] or generated by road side sensors. By deeply exploiting the data generated in MEC-enabled vehicular networks by using data mining, AI, ML and aggregation, the data efficiency, and network performance can be significantly enhanced.

8) BLOCKCHAIN BASED MEC FOR VEHICULAR NETWORKS
MEC provides ultra-low latency, high bandwidth, and near real-time access to computing services, however, it still faces challenges [51], [52] such as the fairness of resource sharing, and the continuity and seamless handover of end-users. Recent advances in blockchain technology provide a useful approach to improving security. Due to blockchain's secure and decentralized nature, it can help establish a credible and stable MEC framework for vehicular networks. The authors in [53] have proposed alliance blockchain technology that permits anonymous and traceable vehicle-to-vehicle (V2V) data sharing, which can effectively prevent second hand data sharing. Reference [54] designed an attribute based encryption algorithm using blockchain, which can be maintained in a RSU. This approach can provide safe access to different types of announcement messages according to different vehicle attributes. In [55], a new integrated framework, BMEC-FV, was proposed to enable dynamic orchestration of secure connected vehicle communication. The authors formulated a vehicle trustworthiness value, the number of generated blocks, the block size, and the primary node performance as a joint optimization problem, and used dueling deep Q-learning with a pruning compression method to obtain the optimal strategy.

9) SPACE-AIR-GROUND INTEGRATED VEHICULAR NETWORK
The authors of [56] claim that space-air-ground integrated communication has potential advantages such as enhanced coverage and broadband access. The appearance of space-airground integrated vehicular networks (SAGVN) is expected to solve some of the existing IoV challenges. However, as the number of vehicles connected to the network grows the number of challenges related to operation and performance are expected to increase. SAGVN was designed as a foundation for vehicular networking [57] and spaceair-ground integrated networks [58]. Further studies have commenced [59], [60]. However, the resource allocation problem in the SAGVN ecosystem has not been fully investigated and user association remains a challenge. Current work focuses on subchannel allocation, power allocation, and mobility management. Recently, [61] introduced an SAGVN architecture that includes edge computing and a resource optimization objective function that combines user association, subchannel and power allocation. The proposed algorithm has been tested using small cells. The architecture and algorithm are proposed for a low-complexity IoV scenario and vehicle mobility has not been fully considered.

A. APPLICATION AND STATE RELOCATION
MEC enabled IoVs pose a challenge related to application and state relocation as vehicles move around the network. Applications and state information should to be relocated from one MEC server to another as vehicles move to ensure that the MEC benefits of low latency, local computation and storage are maintained. Relocation decision making is a key aspect of MEC server deployments and policies and processes are utilized to achieve this outcome. The underlying network state, congestion, vehicle speed and the density of vehicles on major roads are factors that impact on the relocation process.

B. COMPUTATION OFFLOADING IN MEC
Computation offloading introduces several challenges, including accurate estimation of energy consumption, selection of appropriate application and programming models, VM or container migration, and efficient management of simultaneous offloading by multiple users [62]. Computation offloading challenges include: • optimizing the decision making for computation offloading when nearby MEC resources are limited and local networks are congested.
• allocating MEC computing, storage and network slice resources with the aim to balance MEC and network load and improving QoS.
• mobility management of the applications to ensure that service continuity is maintained as the vehicles move throughout the network.
• management, distribution, and deployment of MEC resources • utilizing the computation offloading in a timely manner to ensure that service performance is not affected [29].

C. SECURITY
Another significant challenge for the establishment of any edge paradigm ecosystem is security. There are various VOLUME 10, 2022 enabling technologies at the core of all edge paradigms, such as distributed systems, networks, and virtualization platforms [63]. Protecting the building blocks and orchestrating the various security mechanisms are the key issues. The enabling technologies that have security do not necessarily indicate that the system security can be assured. MEC is a new technology that brings computing and storage capabilities to the network edge, and the security issues have not been widely studied. As a result, specific requirements should be identified to formulate the deployment of adequate security mechanisms. The security mechanisms encompass the MEC system, hosted applications and services, interfaces and interactions with upstream systems and downstream UE. The security threat classification for edge paradigms is provided in Table 4. The security threats related to the edge paradigms have increased over recent years and it is evident from the literature that there are outstanding challenges.

• Identity and authentication
Research on identity and authentication frameworks, techniques and algorithms for MEC is ongoing. The approaches being take include utilizing existing solutions, e.g., peer-to-peer computing and federated cloud computing, and the development of new solutions that satisfy the requirements for identity and authentication in the MEC ecosystem. Authentication techniques have been proposed for edge paradigms that include user authentication within a trust domain [64]. Locationspecific information has been exploited by researchers to propose various authentication schemes for edge paradigms. User mobility is another consideration for identity and authentication solutions, and the existing protocols in MCC scenarios can be utilized to implement an efficient and secure handover authentication.
• Protocol and network security Protocol and network security for MEC is based on existing standards. The protocol and network security challenges for MEC include the integration of solutions related to applications, services and end-users. Data integrity and privacy between two authenticated entities at the edge is a key concern due to the number of attack vectors available in this ecosystem. Credential, session key management, NFV and SDN integration are some of the areas of ongoing research.
• Trust management Trust management is an important security requirement for the edge paradigms. Trust management in the distributed MEC ecosystem is a complex challenge that requires a solution that harnesses the local resources to reduce the time delay that would be introduced if trust management was centralized. A selfmanaged trust management system has been proposed by Kantert et al. [65].
• Intrusion detection systems The integration of Intrusion Detection Systems (IDS) into the MEC ecosystem is a complex undertaking due to the open nature of MEC, where operators and third parties can utilise the MEC resources to offer applications and services to end-users. IDS operates effectively when it is used to monitor every aspect of a system, including infrastructure, networking, and hosted applications and services. Earlier work [66], [67] on IDS related to Cloudlets, Fog computing, Mist and data centres are candidates for an MEC ecosystem IDS solution.
• Privacy Privacy has been a particularly active area in edge paradigms in recent years. Security protocols address the privacy challenge by providing an anonymous way for users to interact with each other or other entities. There are data privacy mechanisms that have been deployed in the mobile edge computing paradigm [68]. As these mechanisms allow local devices to collaborate by requiring the physical location of the interconnected devices, they could benefit the design of privacy mechanisms for collaborative edge servers in the future. Privacy has been a focus for edge computing research, which is beneficial to enhancing the security of system operation and protecting users' personal data. Management and monitoring systems can be used to observe trust relationships between users, devices and applications and services. Also, it is possible that the privacy helper entities, which can implement a multitude of data privacy mechanisms, may be deployed in the edge servers [13], [69].

• Virtualization
The security of edge computing virtualization infrastructure has been intensively researched in recent years [67], [70]. Secure virtualization mechanisms can be exploited in the edge paradigm virtualization infrastructure. Furthermore, research studies have presented various secure computation offloading solutions in MCC [71], [72]. These solutions also can be utilized in other edge paradigms.
Essential security research in the context of edge paradigms is ongoing, e.g., usability, forensics, fault tolerance and resilience, and secure software engineering. However, the vulnerabilities to this context can be greatly decreased when developing security-aware software systems focused on the specific edge paradigm capabilities and features.

D. CHALLENGES IN MEC ENABLED VEHICULAR NETWORKS
In the area of the IoVs, there are challenges remaining:

1) HIGH MOBILITY
The network topology in MEC-enabled vehicular network environments is highly dynamic, changing as a result of the high mobility of vehicles [73]. Hence, links between V2V and V2R can be disconnected due to a variety of factors, which will lead to a deterioration in communication and service quality. Also, handovers will frequently happen when the data is switched among MEC servers by vehicles traversing the network, contributing to latency and impacts on service continuity [74]. Consequently, the user experience may be significantly degraded. Therefore, the mobility management of MEC-enabled vehicular networks will be a crucial task in future research work.

2) HARSH CHANNEL ENVIRONMENT
In practical scenarios, there are obstacles in vehicular environments, such as buildings, trees and hills, which will affect the success of data transmission [75].

3) RESOURCE MANAGEMENT
The storage and computation resources in MEC servers are limited when compared with cloud computing servers. Managing the limited resources to satisfy dynamic resource demands, complicated traffic environments, diverse application characteristics, and optimal resource allocation is clearly a big challenge [76], [77].

4) TASK MIGRATION
Due to the limited computation capabilities of vehicles, it is necessary for computation offloading for delay-sensitive and computation-intensive tasks to MEC servers. The frequent changing topology and dynamic channel environment can lead to a crucial challenge for optimizing task migration [20], [78].

5) SECURITY AND PRIVACY
As mentioned in the previous paragraphs, security is one of the main challenges in MEC-enabled scenarios, including vehicular networks. The dynamic topology and different users accessing the same MEC server can result in privacy and security discrepancies [79], [80].

6) FEDERATED LEARNING
Federated learning (FL) is a powerful distributed AI approach that can significantly improve the performance of AI training by coordinating multiple devices with network resource savings and removing the need to share raw data. An FL process [81] has been introduced to allow the distributed mobile devices to collaborate with an MEC server. The FL process was designed to train data locally and exchange learning parameters with the aggregation server using a number of communication rounds until the global training is complete. However, challenges remain for FL systems: • The aggregation model for MEC servers cannot be fully trusted • The transmission of learning parameters to the MEC server is vulnerable to security bottlenecks, such as the information of local updates can be modified or stolen by malicious threats [82].
• A single MEC server cannot satisfy the aggregation of all updates offloaded from a large number of devices in a highly scalable edge computing network.
To provide solutions for FL based intelligent edge computing, blockchain has been considered as an attractive security tool because it hashes values under the control of a consensus mechanism [83]. This mechanism can make linked blocks immutable against modifications and alterations by enable miners to mine blocks with digital signature. The integration of blockchain and FL creates a new paradigm called FLchain to potentially transform intelligent edge networks with decentralized and secure natures [84], [85]. Research has been devoted to FL and blockchain in MEC enabled vehicular networks. An FLchain scheme is proposed in [86] for privacypreserved IoT data sharing among distributed multiple parties such as mobile devices in industrial IoT networks with a base station. Reference [87] built a knowledge sharing solution in IoV by incorporating FL with a hierarchical blockchain. Despite the huge potential of FLchain to support the applications and services in IoV, research challenges for future FLchain implementations include: • security and stability • communication and heterogeneity issues in FLchain • economic issues • latency requirements

VI. CHALLENGES AND FUTURE WORK
Depending on the applications and services being accessed by a UE, the MEC ecosystem provides resources to support partial or full offloading of computing and storage tasks [88]. Resource constrained applications and services, latency sensitive applications and localized data aggregation and processing will benefit from the introduction of MEC servers at the network edge. MEC servers can operate individually or in concert with adjacent MEC servers to provide additional resources or to implement parallel or partitioned solutions [89].
Resource allocation for an MEC server occurs based on rules related to meeting specified outcomes. The outcomes for a particular MEC server can be influenced by the location of the MEC server and the target audience of the MEC server, e.g., vehicular networks, IoT or mobile devices. The rules are updated based on current priorities, such as supporting latency sensitive applications or data collection and VOLUME 10, 2022 aggregation. One study considered introducing buffer thresholds for each priority level to decide whether an application should be located in MEC servers or the cloud [29].
The authors of [30] focus on execution delay minimization whilst minimizing MEC power consumption. The paper assumes densely populated mobile UE, that can access MEC servers located near the eNBs. An application assignment index policy was developed to permit the eNBs to calculate its index policy based on available computing resources at the local MEC server. Subsequently, all eNBs broadcast the index policy value to adjacent eNBs and the UE are connected to an MEC server with available resources to minimize execution delay and power consumption.
Besides the general goal of the papers [90], [91], another object of [92] is minimizing communication and computing resource overloading as well as the VM or container migration cost. VM allocation in the Small Cell enhanced Node B (SCeNB) is leveraged to formulate the problem, and the problem is addressed employing Markov Decision Process (MDP) [93]. Overall, the simulations in this paper illustrate that the VM is preferred to be allocated to the closest serving SCeNB rather than UE with higher VM migration cost.
Allocating computing and storage resources in multiple MEC servers to satisfy more complex and larger tasks, than what can be achieved with a single MEC server, occurs based on rules, priorities and objectives that have been developed and applied for this scenario. Common examples of the objectives are to minimize execution and transmission delay and minimizing power consumption. A cooperative game approach is proposed in [94] to organize the MEC cluster formation to minimize execution delay while avoiding the need to utilize the cloud.
SCeNB are a recent technology that has been deployed closer to mobile users in some scenarios to offer improved services at low cost, decreased energy and high data rates [75]. Monetary incentives have been exploited to the SCeNBs in this approach if they perform the computing process for the UEs, which are attached to other SCeNBs. The clustering of SCeNBs can significantly decrease the execution delay compared to the computing in the serving SCeNB, and SCeNBs in the cluster carry out computation tasks. The only shortcoming of this proposed scheme is that it does not solve the problem of creating new coalitions and impacts on current applications and services. Notably, the authors of [94] and [95] demonstrate that a rising amount of computing SCeNBs does not reduce the execution delay in all cases. The transmission delay will become longer than the computing delay if too many SCeNBs are participating in computing tasks, which will lead to enhanced execution delay. On the other hand, an increasing number of participating SCeNBs will improve the distribution of power consumption.
The results show that it is crucial to have an SCeNB selection and cluster formation process. In the paper [96], the author demonstrated an optimal formation of the SCeNB clusters to address power consumption and execution delay of the single computing node for a single UE scenario. Compared to the single UE scenario, the multi-UE scenario has been considered in [97] and [98]. A different cluster size is assigned to each UE according to the UE's requirements and the application. In addition, [99] and [100] focus on the balance between computing and communication load to minimize overall resource utilization while satisfying the requirements of execution delay.
The approaches and solutions found in the literature for the allocation of computing resources do not adequately consider UE mobility. Therefore, it is necessary to consider the additional transmission latency associated with moving UE and handover delays. The handover procedure used in the conventional mobile cellular networks to enable UE mobility throughout the network by changing the serving eNB/SCeNB guarantees service continuity and aims to meet QoS requirements. Similarly, it is vital to ensure the service continuity for the UE that offload computing to MEC servers. Several options have been demonstrated in the literature to cope with UE mobility, which can be categorized into two different scenarios. One of the scenarios focuses on the UEs with low mobility to adapt the transmission power of the eNB/SCeNB when the MEC is processing offloaded applications [107], [108]. Another scenario is to guarantee service continuity when UE handover to a new serving eNB/SCeNB occurs. This target can be achieved by two approaches: VM migration and selection of a new communication path between the computing node and the UE. Research has focused on VM migration. However, it can be observed that research into VM migration is based on single MEC computing node scenarios. Even though this scenario is less complex, papers dealing with the allocation of computing resources assume multiple computing nodes [29] and the two research directions should converge.
The mobility of MEC-enabled IoVs leads to application and service relocation and mobility-based task migration within various MEC servers. Applications and services need to be relocated from one MEC server to another to satisfy the benefits of low latency and to ensure that computing and storage resources are available, while suitable policies make the decisions about where and when applications and services should be relocated. Thus, a very challenging problem is taking into account the difference in communication latency, the availability of resources in the target MEC server, the computational load and the performance and overhead cost of relocation with the optimization of the QoS, and the heterogeneity of applications can exacerbate the challenge. ML has been considered as a helpful technology that can be applied to the management of the MEC vehicular network to solve the low efficiency of traditional optimization methods and relocation problems [50], and various machine learning methods, including reinforcement learning (RL), deep Q-networks model [73], and traditional ML approaches [75], have been introduced to optimize the system performance.
In [109], an MEC-enabled Energy-Efficient Scheduling (MEES) method has been presented to minimize the total energy consumption of RSUs under latency constraints. MEES includes four processing phases; delay estimation, energy consumption estimation, task scheduling and processing, and results. A heuristic algorithm has been leveraged in the MEES method to decrease the energy consumption of MEC-enabled RSUs while satisfying the latency requirements of computation tasks in IoVs [109]. By evaluating the performance between MEES with two other algorithms, which are All Task Admission Algorithm (ATAA) [48] and GMCF [110], they have shown that MEES has improved performance over the other algorithms in terms of the task blocking possibility, average latency and energy consumption between RSUs. However, they have not explained clearly how the data from vehicles to RSUs can be effectively transferred. Research to enhance MEES remains future work.
While the MEC standard includes functions to relocate applications seamlessly, suitable policies are required to decide which applications should be relocated, including when and where. These decisions should take into account the availability of resources at the destination server, the computational load, the difference in communication latency, and the overhead and performance costs of relocation to optimize the QoS, not just for a single user, but on a global scale. It is a challenging problem, further exacerbated by the heterogeneity of applications, which have different performance requirements and impose different storage, computation, and communication loads [111].
Digital twin edge network (DITEN) is an emerging paradigm [112] that integrates MEC with a Digital Twin (DT) to provide service to various applications in MEC enabled scenarios. DT was driven by developments in advanced wireless communication and computation technologies [113]. DT can accurately replicate the physical object in the digital domain, and the virtual twin can constantly interact and synchronously evolve with the physical entity throughout the VOLUME 10, 2022 whole life cycle [114]. In Table 5, DTs have been divided into three types based on functionality.
DITEN has attracted attention from industry and academia as a promising technology for autonomous vehicles. A vehicular MEC system has been designed in [101] to employ AI and DT technologies for task offloading. The authors in [103] propose an adaptive DT based Vehicular network consisting of two AI empowered closed loops for VEC network management and DT construction. A DT based deep learning method has been applied by [115] to minimize the response time of the system to obtain the optimal service offloading strategy. More DT based vehicular network cases have been summarized in Table 6.
A variety of promising and useful solutions have been provided from the existing research works to highlight the challenges in vehicular networking. However, some of the solutions only consider a static environment. It is anticipated that future works are expected for heterogeneous vehicular networking.

VII. CONCLUSION
MEC has been presented in this paper as a technology that can be employed to reduce Wide Area Network latency for delay-sensitive applications and services. The definition and architecture have been introduced and discussed with their applications and challenges. The advantages and advancement of MEC and how it has been leveraged in recent research work and industry have been discussed by comparing it with other edge paradigms, such as fog computing and cloud computing. The introduction, architecture, applications, and challenges of MEC-enabled vehicular networks have been investigated as the seamless merging of MEC and vehicular networks can satisfy the increasing requirements for storage and computation resources. MEC-enabled vehicular networks deploy MEC servers closer to vehicles with resource allocation and computation offloading to provide improved application and service performance. However, various challenges remain including mobility, privacy and security. ML based optimal solutions have been discussed and provide useful technologies to improve overall performance. LING HOU received the bachelor's degree in electrical and electronic engineering from Southwest Petroleum University, China, in 2013, and the master's degree in electrical and electronic engineering from RMIT University, Melbourne, VIC, Australia, in 2018, where he is currently pursuing the Ph.D. degree with the School of Engineering. He is also an Academic Staff with the School of Engineering, RMIT University. His research interests include 5G/6G, multi-access edge computing, vehicular networks, and machine learning.