1. Introduction
If the city is rapidly moving toward a Smart City, the traditional transportation systems are rapidly converging into an Intelligent Transportation System (ITS) mainly through the integration of innovative technologies, e.g., Internet of Things (IoT), and wireless technologies (e.g., 5G) [
1]. With new connected vehicles, having different communication and computing technologies, Vehicular Networks (VNs) are radically moving toward the Internet of Vehicles (IoVs) paradigm, where new applications and services are growing. With the integration of modernized technologies such as IoT and various new communication modes, including Vehicle-to-Vehicle (V2V), Vehicle-to-Road Side Units (V2R), Vehicle-to-Infrastructure of Cellular Networks (V2I), Vehicle-to-Sensors(V2S), and Vehicle-to-Person (V2P), IoV can expand the traditional Vehicular Ad hoc Networks (VANETs) capability by adding several new services and applications. IoV is able to support various functions, including intelligent traffic management, traffic safety enhancements, dynamic information services, intelligent vehicle control for improving the overall road experience of users [
2,
3,
4,
5]. However, vehicle onboard computation capacity is falling short when new latency-critical and data-intensive applications are considered; hence, new challenges are arising in VNs. The Cloud computing facilities are able to reduce the computation burden of new services; therefore, Vehicular Users (VUs) can transmit the portion/complete task to the cloud servers having enormous computation and communication power. In general, the cloud facilities are located far from the users, in the core network, and introduce some drawbacks, e.g., huge transmission costs, backhaul link congestions, data security threats due to long-distance communications. Such issues can be addressed by integrating the Edge Computing (EC) facilities into VNs, bringing cloud computing resources in the proximity of end-users [
6,
7].
In the case of VNs, EC facilities can be integrated through the deployment of several EC servers alongside the road network co-located with Roadside Units (RSUs). Such an approach is known as Vehicular Edge Computing (VEC) and has achieved lots of success by enabling new latency-critical services into VNs [
8]. However, the limited capacity and coverage of EC servers/RSUs is the main bottleneck while exploiting VEC advantages. VEC-based VN can also be complemented by adding additional EC servers located on the terrestrial cellular base stations (i.e., 5G-gNB). Such ground-based multi EC platforms can compliment VUs by providing additional services and reducing the overall burden of the VEC servers.
However, in recent times, Terrestrial Networks (TNs) are becoming more and more used, with many new users requesting services with specific demands. Limited coverage into rural and remote areas, unreliable service during natural disasters like tsunamis and earthquakes, new security challenges, poor link budget with additional interferences are some of the main challenges that need to be considered while utilizing TN-based EC platforms into VNs. In addition, VUs are not the only user group requesting services from the TN-based EC platforms. With the presence of different users, the dynamically changing resources of EC servers with vehicular mobility adds additional challenges while integrating the TN-based EC services into VNs. With this limitation, integrating TN-based EC platforms into VN alone can not be a sufficient solution for the new futuristic vehicular services and applications, which will have more stringent requirements in terms of latency and computation resources.
Encouraged by the new technological developments and the additional interest shown by several tech giants (i.e., Facebook, Google, etc.), the Non-Terrestrial Networks (NTN), including space and air networks are growing these days mainly for providing global connectivity [
9]. Several new platforms such as new satellite constellations, unmanned aerial vehicles (UAVs) swarms, small fueled aircraft, balloons have been deployed at different heights from the ground users to achieve the global connectivity challenge [
10]. Better connectivity, scalability, reliability are some of the advantages of NTN based communication platforms. With the addition of modern communication technologies, such as multi-beam antennas, the NTN platforms can also provide EC-based services with an onboard computing server [
11,
12,
13]. Such NTN-based EC platforms can complement the VNs for solving several problems, including RSUs’ limited capacity and coverage. However, the higher transmission delay, introduced by space networking platforms (i.e., satellite constellations), is a major challenge while considering NTN platforms for serving latency-critical VNs. Compared with space networks, new aerial platforms such as Low Altitude and High Altitude Platforms (LAPs and HAPs) have a considerable advantage with reduced transmission distances, low deployment time and costs, and reduced communication channel losses. Therefore LAPs and HAPs can be excellent solutions for complimenting the VN for providing new innovative and intelligent services to the end-users.
Every connected vehicle in a VN is equipped with several sensors, able to generate tones of data (i.e., big data) in real-time. These data can be analyzed and exploited for improving the quality of VNs services and applications [
14]. Recently machine learning (ML) techniques are used for solving challenging problems over wireless networks [
15,
16]. With new hardware technologies and the availability of a large amount of data through IoT devices, ML research is grown fast. Several new ML tools and techniques have been developed and utilized for solving real-world problems on a daily basis. The use of new innovative ML-based solutions for analyzing the vehicular data for improving the vehicular environment can be beneficial [
17]. However, proper infrastructures with communication and computing resources are required, for embedding the ML-based solutions into VNs, failure of which can introduce higher process costs (i.e., cost induced by ML model training, inference, etc). With limited resources and dynamic movements in VNs, it is challenging to implement ML techniques. The EC resources can be exploited for integrating the ML-based solution techniques into VNs.
Traditional ML approaches such as centralized ML require VUs to transmit their data to the centralized, more powerful servers [
18]. However, such an approach can introduce higher costs in terms of communication latencies and energy requirements. With resource limitations and critical service requirements performing centralized ML over VN can be challenging. On the other hand, new learning approaches such as Federated Learning (FL), VUs are able to perform the training operations by themselves [
19]. In each FL round, VUs perform the training operations to learn local ML model parameters, to be then sent towards the centralized server. After receiving all VUs parameters from its coverage area, the server is able to perform an averaging operation for creating a global model to be broadcast back to the VUs. Thus, the VUs can reduce the data communication cost by performing local training operations and also exploit the presence of other VUs, by learning experiences/data through the averaging. For these reasons, recently, FL-based solutions are preferred for VN application when solving challenging problems [
19,
20,
21]. For benefiting from the collaborative learning into FL, a server platform with better coverage characteristics and channel conditions is required. NTN platforms, such as HAPs, can assist VN in implementing an efficient FL process with their better coverage characteristics, moderate transmission distances, and better channel conditions. FL and other ML techniques will be described in more detail in
Section 3.
Therefore, there is clear scope for integrating NTN layers, especially air network-based EC platforms, with ground-based EC resources, into VNs. Such an approach can solve the limited capacity and coverage problem of conventional ground-based EC platforms and can provide more intelligent services and applications with stringent requirements. Therefore, we aim to provide a novel multiple EC platforms-enabled VN architecture by integrating ground and aerial network-based EC resources. Different enabling technologies, corresponding challenges, and opportunities are discussed in detail. We further analyze several vehicular scenarios and the benefits of using the proposed VN architecture for solving the challenges associated with them. In the following, we list the main contributions of this work:
In
Section 2, a review of the technological background is given by resuming the most important technical reports, projects, and papers addressing scenarios similar to the one we consider.
In
Section 3, we first describe the main enabling technologies that can be crucial for shaping the next generation VNs. In particular, we focus on ML, VEC, and network softwarization technologies, their characteristics, corresponding benefits, and challenges while used in vehicular environments.
In
Section 4, for efficient utilization of the previously introduced key technologies over the vehicular environment, we provide a joint air-ground network-based VN architecture (for better clarity, in the following the term air-ground refers to the architecture while T-NTN to the terrestrial and non-terrestrial network issues and deployment). We highlight the important characteristics of individual layers of the proposed architecture, including capacity, coverage, and applications. With multiple EC platforms, the proposed architecture can be useful for implementing various intelligent vehicular services and applications that can ease the vehicular experience.
In
Section 5, we further describe three main VN scenarios including the implementation of an efficient ML platform for VN services and applications, enabling the computation offloading based EC services in VN, and a network function placement for the network slicing-based vehicular services. Important challenges, and the solution methodologies that can be used while considering the proposed network architecture over these important vehicular scenarios, are analyzed.
In
Section 6, we summarize the important characteristics, challenges, and proposed solutions for the scenarios discussed in the previous section.
In
Section 7, we conclude our work by highlighting the proposed solutions and possible future research directions that can be followed.
2. Scenario Background
The Smart City vision can be achieved through a proper integration of several key technologies (e.g., ML, EC). In [
22], the authors have surveyed different EC technologies that can be useful for realizing the Smart City vision. Various Smart City scenarios and corresponding challenges are reported. Furthermore, in [
23], the influence of big data and ML technologies in Smart City developments is presented. Developing a proper ITS is a key to creating sustainable Smart City environments. Different technologies are merging with the goal of forming sustainable, safe, and intelligent VNs for serving VUs. In [
24], the authors surveyed several ML-based solutions employed in VNs communication and networking parts. Differently, the importance of a network softwerization technology in the VN and corresponding challenges is surveyed in [
25]. In [
26], the authors have proposed a software-defined collaborative EC platform for the vehicular scenario. They have mainly focused on ground-based EC technologies, including mobile edge computing (MEC), fog computing, cloudlet, etc. However, limited capacity and coverage issues of ground-based EC platforms limit the performance of traditional VNs.
Recently, the importance of NTN platforms in wireless communication is highlighted in different projects and research works. Several ongoing projects including EdgeSAT [
27], SATis5 [
28], Expanse [
29] are aimed at integration (with terrestrial networks (TNs)), softwarization, and expansion of EC facilities over NTN platforms. Several study items such as IoT over NTN, new radio (NR) over NTN, satellite components in 5G architecture, and unmanned aerial systems are part of 3rd generation partnership project (3GPPs) Release 17 studies, which will be finalized at the end of the first quarter of 2022 [
30]. It is also expected that 3GPP will reconsider many of these items in an upcoming release (i.e., Release 18) [
31].
In [
32], the authors presented the new opportunities and challenges ahead for integrating the NTN technologies into upcoming 6G networks. The work in [
33] analyzes the importance and challenges of integrating NTN networks into VN. A space-air-ground integrated VN architecture for supporting different vehicular services in diverse scenarios is proposed. Furthermore, in [
34], the authors have presented a space-air ground integrated VN architecture highlighting the key features of each platform layer. It is possible to enable several EC services over different NTN layers by deploying proper computing resources. In [
12], authors proposed EC-enabled UAV platforms for improving computation performance and reducing the execution latency of MEC systems. Recently in [
35], authors studied the energy performance of an offloading strategy designed over EC-enabled satellites and HAP networks for ground-based users. In [
36], the importance of the UAV-assisted VEC system and corresponding implementation issues are highlighted.
3. Enabling Technologies and Challenges for Futuristic Vehicular Networks
A suitable VN architecture able to serve users with new innovative services and applications has to exploit together several key technologies. However, with limited EC capacities and coverage restrictions, it is challenging to integrate these high-level technologies into the vehicular environment. Here, we introduce the main technologies for designing futuristic VNs and corresponding challenges.
3.1. Network Softwarization
Network softwarization is a key trend that uses Software-Defined Networking (SDN), Network Function Virtualization (NFV), and network slicing techniques for providing additional programmability, flexibility, and modularity in different parts of the wireless communication networks [
37]. Network softwarization allows a flexible deployment and control of different vehicular services once adapted into VNs. Here, we introduce the main technologies that allows to create a flexible and programmable VN.
3.1.1. Network Function Virtualization (NFV)
NFV is a key technological trend to tackle the flexibility and scalability problems associated with traditional hardware-based Network Functions (NFs). In the past, different NFs such as firewalls, Content Delivery Networks (CDNs), Network Address Translation (NAT) were installed as dedicated hardware-based appliances. With this, the implementation of new services and applications were restricted by the deployment of specific hardware-based elements. NFV decouples this network functions from proprietary hardware appliances and runs them as software instances in Virtual Machines (VMs)/containers as Virtual Network Functions (VNFs) [
38]. Through NFV, standard network resources such as compute, storage, and network functions can be virtualized and kept on Commercial Off-the-Shelf (COTS) hardware like x86 servers. In addition, multiple VMs/containers, through the proper assignments of virtualized resources, can run on a single server for improving server resource utilization. With the NFV technology, different network functions can be placed in different locations of the networks elements such as data centers, EC servers, etc.
In the case of a Multiple EC (Multi-EC) platforms-enabled-VN architecture, NFV can potentially bring several benefits, including reduced network cost, less time-to-market for new services, higher resource efficiency, and better scalability. However, each VNF demands specific computation resources based upon the service types. Furthermore, since VNFs can be deployed at multiple locations, it is important to find proper function placement strategies for implementing many hybrid vehicular services over a resource-constrained VN.
3.1.2. Software-Defined Networking
With the unprecedented increase in demand for heterogeneous services in VN, there is a need for a platform that can dynamically adapt the network and service according to the demand request. Software-Defined Networking (SDN) technology can create a more flexible and programmable VN for supporting the critical requirements of the services and applications [
39,
40]. The SDN forms a fully programmable wireless network by logically separating the data and control plane, where all control operations are performed through the centralized controller unit. The controller can have a global view of network topology, traffic load, network states, and link failures. In the case of an EC-enabled VN, having different EC layers of heterogeneous hardware having a proper centralized controller assisted by the individual layers local controller can be useful for providing flexible VN services. In the past several studies have shown the importance of SDN-based VNs, where SDN technology is integrated into VN to manage different parts with improved performance in terms of network flexibility, throughput, and flexible deployments of new services and applications. However, various issues need to be handled carefully during the integration of SDN into VN including, possible security attacks over the data plane, the vulnerability of a centralized controller in terms of single-point failures, issues related to the heterogeneous hardware of different EC platforms, various access network technologies, etc. Over the years, researchers have provided numerous solutions for these issues [
26,
40,
41,
42,
43]. As an example, in [
41], a 5G software-defined vehicular network having integrated SDN technology is proposed with clear separation of data, control, and application planes. In another study [
26], the authors proposed a collaborative EC-based software-defined VN with multiple EC platforms. Furthermore, in [
40], the authors have experimented with the different SDN controllers over a complete software-defined vehicular networking on hardware. Recently in [
42], the authors have proposed a novel IoV automation and orchestration system using SDN for connected autonomous vehicles. In [
43], the authors study different VN architectures and propose a localized intelligence augmented highly reconfigurable software-defined heterogeneous vehicular networking architecture for avoiding single-point failures.
3.1.3. Network Slicing
The network slicing technique takes advantage of NFV and SDN for creating multiple logical networks or network slices over a common physical infrastructure of VN [
44,
45]. Multiple network slices can be configured over the same physical infrastructure to provide different services with diverse requirements. It provides dynamic resource management by enabling efficient resource sharing by considering various key performance indicators (KPIs) for each slice and can be an efficient technology over the VN with limited resources. Inherently, the network slice contains a chain of physical and virtual network functions that can be placed at different locations based upon the service requirements. In the case of an EC-enabled VN with users requesting services with different KPIs, each slice function needs to place carefully for satisfying the user demands. The problem of network slicing and corresponding network function placement over a Multi-EC multi-service VN is discussed later in Scenario 3 in
Section 5.
3.2. 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.
Table 1 lists the advantages and disadvantage of different EC platforms in vehicular services.
3.3. Machine Learning
The traditional approaches used for solving VNs problems include convex optimization, game-theoretic approaches, and several other metaheuristics. These techniques mainly suffer from the heavy computational burden with exponentially increasing search space in large-scale scenarios; this is even more enforced when the considered VN system employs multiple EC nodes, and network softwarization solutions, enabling more flexible implementations. Heuristic approaches used for solving the VN problems with their NP-hardness are not able to adapt to the increasing complexity of the new applications.
With the addition of IoT techniques, enabling what is usually referred to as IoV [
5,
50,
52,
53], vehicles become an excellent element for training data that can be utilized for solving vehicular problems (i.e., ML-based solutions). Several complex vehicular problems such as dynamic resource allocation, traffic predictions, cooperative congestion control, content caching, computation offloading, intrusion detection, anomaly detection can be solved by using popular ML methods such as supervised learning, unsupervised learning, reinforcement learning, etc. [
24]. Among other ML techniques, Deep Reinforcement Learning (DRL) is a potential solution for many complex vehicular scenarios, which allows exploiting Deep Neural Networks (DNN) for analyzing VNs data without requiring any prior knowledge of the VN environment, which is hard to capture [
54], e.g., correct state transmission matrix over VN states for Markov Decision Processes (MDP) based solutions. ML solutions outperform the heuristic and one-shot-based optimization techniques with better long-term performance.
Different approaches are available for the integration of ML-based solutions into vehicular environments. In each of these approaches, various communication, and computation strategies can be involved during the training process of an ML model. For example, a centralized ML model training approach requires each VN to send its data towards a centralized, more powerful server. In another case, a centralized ML server can further split the training data and corresponding operations with nearby servers to reduce the required computation time. A new collaborative learning-based approach such as federated learning (FL) can allow participating VUs to train ML models locally. The powerful central server can be employed for collecting and averaging the local training ML models parameters to combine the VUs learning experience. These technologies can have certain advantages, disadvantages and can face several new challenges in vehicular environments. In the following, we describe each of these approaches in detail.
3.3.1. Centralized ML
Even though VUs are capable of training fairly complex ML algorithms by themselves, it is yet not recommended due to several reasons. First, with their limited resources, training complex ML algorithms over Vehicles Onboard Units (OBUs) will be computationally expansive and can introduce large latency and energy costs. Complex ML techniques such as DNN require a large amount of data during training, which individual VUs are not capable of providing. Furthermore, dynamic environments like VNs are continuously changing, and the surrounding environments can affect the VUs performance while performing ML model training.
In the centralized learning approach, several randomly distributed VUs transmit their raw data towards a powerful centralized server (ML-server) with rich communication and computation resources. With this approach, fairly complex ML techniques like DNN can be adapted to solve VNs problems with better performance. With these advantages, some challenges need to be considered while implementing centralized ML-based solutions over vehicular environments. Though centralized computation servers are rich with computational resources, ML model training costs can grow exponentially with the increasing complexity of ML techniques (DNN with a high number of layers), which ensures large computation delays at servers. Furthermore, the transmission of the whole dataset towards centralized servers can be challenging with VUs limited communication resources and dynamic channel environments. In the case of VNs, with changing environment dynamics and corresponding renewed datasets, it is important to update the trained ML models for a short duration of time to avoid issues like model drift. Thus, centralized ML model training approach can have several issues while considering it for solving VNs problems.
Figure 2 shows an example of a centralized ML model training over VN where centralized ML server collects training data from individual VUs for performing training operations.
3.3.2. Distributed ML
For reducing the model training cost at a centralized ML server, the workload distribution methods can be adapted, in which the main server can select a set of powerful computing servers around it and allocate the model training tasks. This approach is known as a distributed learning approach in which multiple powerful servers collaboratively perform the training process. This allows to limit the model training latency at the centralized server and allows to train fairly complex ML models with acceptable latency. However, this approach does not solve the communication overhead problem faced by the individual VUs and thus can have limited performance over VNs.
Figure 3 shows the distributed ML model training over VN. In the case of distributed learning, the centralized server employs the nearby idle server resources for reducing the overall training latency.
3.3.3. Federated ML
For overcoming the problems of the centralized and distributed approaches, the FL technique is proposed, where individual devices can perform model training by themselves exploiting local data and transmit only the ML model updates towards a centralized server In some articles, authors do not distinguish between Distributed Learning and Federated Learning. However, here we have considered these two as separate ML model training techniques with different features [
55]. The main differences between FL and distributed learning approaches are listed in
Table 2. Once receiving updates from all vehicles in the coverage area, a centralized server performs an averaging operation (i.e., Federated Averaging (FedAvg)) for creating a centralized global model, whose parameters are then transmitted back to the vehicles. The averaging process allows individual vehicles to take advantage of other vehicles’ data and learning experiences for improving their ML models while the local device training process improves the time and energy efficiency of the model training process. Thus, a single FL process communication round includes several steps, such as individual VUs performing the local training operations, the transmission of the local model parameters towards the centralized server, after receiving parameters from an individual VUs, the averaging operation performed at centralized server for creating a global model that allows VUs to take advantage of other VUs training experiences and retransmission of model parameters back to VU. Such communication rounds can be performed for creating a suitable ML model with lesser estimation errors. The complete FL process over VN is shown in
Figure 4.
Algorithm 1 lists the possible steps involved during the FL process. FL process requires several input parameters, including the number of FL devices participating
, their datasets
, and the maximum number of FL communication rounds
. It should be noted that the FL communication rounds limit can also be replaced by any other stopping criteria such as model convergence parameter, loss function value, etc. The initialization step begins the FL process by defining the initial value of a global FL model parameter and FL communication round to zero (Line 1). At the beginning of each round, local model parameters are updated by the previous rounds’ global parameter values (Line 3). Next, FL devices perform the ML model training for generating local ML model
at
iteration in parallel (Lines 4–5), where
is a learning rate. After completing the local training process, each device forwards its parameters to the FL server (Line 6), where it performs the FedAvg operation to create a new global model (Line 8) which is then used by VUs in next round of communication. FL process continues over
communication rounds.
Algorithm 1. Federated Learning. |
- Input:
- Output:
- 1:
Initialize - 2:
for
each
do - 3:
initialize - 4:
for each do in parallel - 5:
Update based upon the and the local device learning process. - 6:
send to FL Server - 7:
end for - 8:
FL server collects all the and performs averaging - 9:
- 10:
end for - 11:
return
|
In general FL based solutions can have many benefits in VN environments, including reduced communication overheads compared with centralized/distributed learning models. However, in the case of a Multi-EC enabled VN, selecting a proper FL-server, FL devices, and the proper number of FL communication rounds can be beneficial in terms of training costs. We will discuss these issues in detail in the Scenario 1 in
Section 5.
4. Multiple Edge Computing Platforms Enabled Air-Ground Network Architecture for Vehicular Scenarios
In this section, we propose a VN architecture with multiple EC layers to serve VUs with diverse service requests. We characterize different EC platform layers in detail and highlight their importance for serving VUs.
TN-based infrastructures are playing an important role in creating a fully functional intelligent VN for futuristic Smart City environments. However, they alone are not capable of providing adequate services to dynamic VUs, which often request services with extremely low latency and high reliability. TN is vulnerable to ground-based security attacks due to its fixed positions. Furthermore, in the case of natural disasters such as tsunamis, earthquakes users often fail to connect to the services of TN. Low accessibility into remote areas mainly because of the unwillingness of mobile operators to provide services into low revenue parts needs to be considered while integrating TN into VNs. NTN such as Air networks has a considerable advantage over TN in terms of availability, reliability, scalability, and low deployment costs. With these advantages, they can play an important role in complimenting TN for providing better quality services to VUs. Both TN and NTN platforms can enable EC-based services through placements of edge computing servers along with their distributed infrastructures. Therefore, a Multilayered joint T-NTN constituted by different EC platforms over TN and NTN can be utilized for providing heterogeneous services requested by VUs with demanded quality.
In
Figure 5, we propose an air–ground network having multiple EC platform layers and jointly exploiting TN and NTN for serving VUs.
Several VUs are randomly distributed in the considered service area and demand many latency-critical and data-intensive services. The proposed network architecture is constituted by several elements as shown in
Figure 5: a set of VUs, RSU, BS elements, LAPs, and HAP. For avoiding redundancies, in the following, we omit the legend from the figures. A set of RSUs is deployed alongside roads having a limited capacity EC servers for providing computation services to the VU. Each RSU can serve a limited set of VUs in its coverage range. VUs are also supported by the BS elements equipped with EC services. BS elements can sever VUs over larger coverage areas compared with RSUs and can have powerful EC servers. However, the required roundtrip time for sending and receiving back the VUs task can be much higher. Thus, RSUs and BC servers jointly forms form a multilayered TN-based EC service platform for supporting VUs. VUs are also complemented by a swarm of LAPs (i.e., UAVs) deployed on top of them. UAVs can enable limited EC services with a pre-installed EC server. UAVs can have limited coverage and flight time that often limits their service range. VUs are also covered by multiple decentralized HAPs having better coverage and computing capacity compared with UAVs. Thus, Jointly, UAVs and HAPs form a multilayered NTN based EC platform for supporting VUs with better quality services and intelligent applications. Jointly both TN and NTN based EC platforms serve VUs with their available computation and communication resources.
As shown in
Figure 6, the considered network infrastructure can be split into several layers of ground-based and areal networking infrastructures. The TN is constituted by several connected VUs in Layer 1 which can form a small vehicular cloud, RSUs equipped with the EC servers in Layer 2, and multiple BS with EC facilities in Layer 3. The NTN has two layers of LAPs and HAPs belonging to the areal networks. LAP nodes are located at a relatively low distance from the ground compared with the HAPs and have limited computation and communication resources. Though HAPs are at a long distance from the VUs layer they can serve large coverage areas. Below we describe each of these networking layers in detail.
Layer 1—Connected VUs layer
Several connected VUs having communication and computation capabilities are grouped into Layer 1. Each VU can communicate with its neighboring VUs for possible information sharing through V2V communication technologies and use V2I links for interacting with other EC layers. VUs can communicate over a limited distance to share important information for enabling several safety-related, traffic flow management services that make drivers life easy on the road. Through V2I communication, VUs can share their workloads towards EC servers in proximity for enabling latency-critical and data-intensive applications. VUs often generate different tasks requests with specific requirements of computation, communication, and storage resources. These task requests often come with additional requirements (i.e., critical latency requirements), for which VUs often need assistance from the EC platforms in the proximity.
Layer 2—RSU-Edge Computing (RSU-EC) Layer
For enabling the EC facilities into VNs, several RSUs have been deployed alongside road infrastructures. RSUs can have communication technologies installed for communicating with VUs and other higher lever networking layers (i.e., cellular BSs, cloud infrastructures, etc.). EC servers having limited computation and storage resources can be deployed alongside RSUs to integrate the EC services into VNs. Thus, RSUs equipped with EC servers and communication technologies constitute an EC layer in the proximity of VUs for providing low latency services. However, with their limited resources and coverage, RSUs can serve a limited number of VUs. Furthermore, VUs mobility often restricts them from accessing RSU services for longer periods of time.
Layer 3—5G Base Station (BS) Layer
5G base stations (5G-gNB) have integrated modern communication and computation technologies that can be exploited as an EC platform. With larger coverage areas, they can serve a higher number of VUs. However, the BS-EC platform can have additional transmission delays due to longer communication distance compared with RSUs.
Layer 4—Low Altitude Platform (LAP) Layer
LAP platforms such as UAVs equipped with EC servers can add several benefits in terms of a reduced transmission time (less than 1 msec), reduced deployment and maintenance time, line of sight communications with better channel quality, etc. They can also act as a relay node for allowing VUs to transmit their information towards higher air networking layers such as HAP with reduced latency and energy costs. With the limited size and reduced flight times, UAVs can only have limited communication and computation resources onboard.
Layer 5—High Altitude Platform (HAP) Layer
A HAP network constituted by several nodes able to communicate amongst themselves and other infrastructures is forming another EC layer in the air network. Each HAP node can have a powerful EC server and the communication resources for serving VUs under its coverage. Better coverage, additional renewable energy sources, better stability are some of the HAPs main advantages over LAPs. However, HAP performance can be reduced by longer communication distances, additional channel loss in terms of rain fading high deployments, and maintenance time and costs. The HAPs coverage area can depend upon its altitude. In general HAP platform can provide coverage between a few 10 s of Kms to up to several 100 s of Km [
56,
57].
Communication, Computation and Storage Characteristics
Each EC platform layer of the proposed network architecture can adapt different computation and communication strategies. Several virtualization techniques (i.e., Virtual Machines (VMs), containers) can be used for the efficient utilization of EC resources. Furthermore, an SDN-based centralized control approach can be applied for managing the computation and storage resources of individual EC platforms. Multiple operators based communication technologies can be adapted for enabling the communication between EC nodes of the same and distinct layers.
Table 3 lists the most important characteristics of individual EC layers considered in the proposed network architecture.
6. Discussion
In the previous section, we have discussed various vehicular scenarios that can be considered for the proposed Multi-EC enable VN architecture.
In Scenario 1, we discuss the importance of a cost-efficient FL platform over a Multi-EC enabled Vn architecture. The selection of proper FL devices having high-quality datasets and FL servers with better coverage characteristics can help to reduce the overall FL process convergence cost. We have proposed two innovative solutions, including the hierarchical FL-based and the computation offloading enabled FL platform, to address the challenges of this scenario.
In Scenario 2, we have discussed the important characteristics and corresponding challenges of the efficient computation offloading process over Multi-EC enabled VN architecture for enabling latency-critical and data-intensive applications and services. Proper EC server selection and the amount to be offloaded can reduce the overall process cost. VUs can utilize other VUs offloading experiences for making better decisions. We propose a V2V data sharing enabled ML approach and multiple edge connectivity-based solution approaches for addressing the challenges of a computation offloading problem.
In Scenario 3, we have addressed the NFP problem for the multi-service Multi-EC enabled VN architecture. Network slicing technology can realize heterogeneous vehicular services with different requirements over common VN infrastructure. Specific services are implemented as a chain of VNFs with multiple possible placement options. VNs limited resources and service requirements need to be considered during function placements over various platforms available in Multi-EC enabled VN. We propose a preference-weighted approach for the NFP problem where the preference function models the specific weighting associated with each VNF based upon its characteristics. Innovative ML-based solutions can be used for modeling the proper preference function based upon the service characteristics.
The most prominent characteristics, challenges, and the proposed solution methods for the three proposed scenarios are summarized in
Table 7.