Fifth Generation (5G) wireless networks can support the demanding use cases of Vehicle Cloud Computing (VCC) systems. Various communication models determine which entities communicate with each other in a VCC architecture. They are referred to as Vehicle to Everything or V2X, where V stands for vehicle and X determines the entity that communicates with the vehicle. More specifically, the X parameter represents another vehicle in a Vehicle to Vehicle (V2V) communication, a network infrastructure in a Vehicle to Infrastructure (V2I) communication or a pedestrian in a Vehicle to Pedestrian (V2P) communication.
Vehicle to Vehicle (V2V)
V2V communications comprise a wireless network where vehicles exchange information with each other. Such information could include vehicle location, speed, direction, braking, stability loss, and any other information, including traffic or multimedia. V2V could be applied in a mesh network, meaning that every vehicle could receive and forward messages from/to other vehicles. The first V2V implementations warned the driver about traffic conditions. Still, they could not take control of the vehicle. Later implementations improve the braking or steering capabilities of the vehicles.
Vehicle to Infrastructure (V2I)
Vehicle to Infrastructure (V2I) communication is performed through the RSUs, while the information gathered by the infrastructure could include traffic or road conditions and Points of Interest (PoI). Indicatively, velocity, acceleration, and inter-vehicle distances, could be suggested by the infrastructure. The network will consider the traffic conditions and optimize traffic manipulation, fuel consumption, and driver safety.
Vehicle to Pedestrian (V2P)
In a V2P communication, information between vehicles and pedestrians is exchanged. The pedestrians could exchange road safety information with vehicles using their mobile devices to avoid accidents.
5G-VCC System architectures
5G Vehicular Cloud Computing (5G-VCC) can take advantage of the advanced heterogeneous network access technologies to support the various services required for vehicular communication. This means that each vehicle can use services with different Quality of Service (QoS) constraints. Therefore, there can be various architectures to serve the diverse user requirements and provider policies.
There are three main 5G-VCC architectures described in the research literature. These include the Vehicular Cloud (VC), the Vehicles using Cloud (VuC), and the Vehicles using Fog (VuF). Furthermore, Software Defined Vehicular (SDN-V) architectures, improving the management of the network, have been proposed. Finally, Hybrid Vehicular Architectures (HVA) combining the operating principles of multiple 5G-VCC architectures are suggested. The following paragraphs describe each one of the available architectures.
Vehicular Cloud (VC) architecture
According to the VC architecture, the Cloud consists of vehicles with computing resources. Vehicles may interact directly with each other, while data forwarding is supported by proprietary protocols such as the 802.11s. However, these Vehicle resources may also remain idle for an extended period. This may happen when vehicles are parked for many hours each day or even for many days. Furthermore, the resources may remain idle even in short periods when vehicles may remain stuck due to congested traffic roads. The resources of such vehicles could be used for constructing a cloud infrastructure. Additional resource manipulation factors arise in cases where the constructed Cloud is based on an ever-changing architecture where vehicular VMs (VVMs) are continuously added or removed.
Thus, to assure service continuity, multiple service instances should be distributed simultaneously in several VVMs. Furthermore, for the vehicle’s resources to be provided to the VC architecture, the authorization of each vehicle’s owner is required.
Vehicles using Cloud (VuC) architecture
According to the VuC architecture, the vehicles interact with a Cloud infrastructure through Macrocell/Femtocell BSs or RSUs. Compared to the VC architecture, the vehicles are considered the end-users in a VuC architecture.
Vehicles using Fog (VuF)
The VuF architecture could be considered an evolution of the VuC architecture, where the operating principles of Fog computing are applied. In more detail, the VuF architecture defines that the BSs or RSUs are equipped with additional computational and storage resources. At the same time, they are also referred to as micro-datacenter BSs (md-BSs) and micro-data center RSUs (md-RSUs), respectively. In this case, the vehicles interact with computing and storage resources characterized by proximity, low latency, and high bandwidth.
Software-Defined Vehicular Architectures (SDN-V)
Each VCC architecture could be enhanced with advanced manipulation functionalities using the Software Defined Networks (SDN) technology. More specifically, the SDN technology simplifies the network management procedures while at the same time it reduces the network equipment cost. The basic operating principles include that the network control plane and the data plane are decoupled. Moreover, the network orchestration and management are performed by SDN controllers. The interaction with network equipment from different vendors is achieved by proving Open Application Programming Interfaces (Open APIs). SDN control could be implemented either at the Cloud or the Fog infrastructure. The SDN components could be virtualized, considering the operating principles of Network Functions Virtualization (NFV) to reduce the required SDN hardware and improve the overall system sustainability. In particular, concerning the Cloud-based SDN control, the SDN controller is implemented at the Cloud infrastructure, by one or more Virtual Machines (VM). On the other hand, a Fog infrastructure implementing the SDN control is also described. Specifically, an md-RSU contains a computing device and an Open Flow (OF) Switch.
The computing device includes a VM and a lightweight hypervisor. The hypervisor is a middleware that enables VMs to share resources to their hosted services. Furthermore, some md-RSUs contain additional software, such as OF Controllers, Cloud Controllers, and RSU Cloud Resource Managers (RSU CRMs). The OF Controllers control the OF Switch rules via the control plane, while the Cloud Controllers control the hypervisors and the VMs resources. Accordingly, each RSU CRM communicates with both the OF and Cloud controllers via the data plane and distributes information about services and data flow changes. Furthermore, there is also a Software-Defined VCC architecture described. In this architecture, an SDN controller exists between the RSUs and the Cloud infrastructure, providing centralized resource manipulation functionalities for the entire architecture.
Hybrid Vehicular Architectures (HVA)
The previous main models may be combined in hybrid 5G-VCC architectures. In a 5G-VCC architecture, multiple communication models could also be used together, also known as Hybrid Vehicular Architectures (HVA). Indicatively, a hybrid 5G-VCC architecture may combine both the VuC and VuF models. Services may be offered by both Cloud and Fog infrastructures. At the same time, the Cognitive Radio Networks (CRN) communication principles are adopted. More specifically, the traffic flows generated by the Clouds are considered as primary flows, while the ones generated by the Fog are considered as secondary flows. Also, vehicles are separated into two groups, the primary vehicles which use the Cloud services and the secondary vehicles which use the Fog services. Primary vehicles have higher priority on the spectrum usage, while secondary vehicles connecting to the Fog use the remaining time and frequency holes.
Additionally, an HVA architecture is introduced, combining the design characteristics of VC, VuC, and VuF architectures. Its main advantage is that the entire computation and storage resources are virtualized. The complete virtualization provides enhanced system flexibility as well as resource sustainability. Furthermore, an HVA architecture may combine both VC and VuC architectures. More specifically, a VC provides vehicle cooperation functionalities such as Internet access via multi-hop traffic routing (mesh networking). Also, the VC collects information about its vehicles, such as fuel consumption, GPS coordinates, CO2 emissions, and traffic data. The VC evaluates this information and extracts traffic-related conclusions about its area. Subsequently, the decisions are sent to the central Cloud.
Thus, vehicles that do not belong to the VC can obtain traffic-related information concerning the VC area. Furthermore, the extended version of this architecture includes multiple VCs. Each VC evaluates traffic-related information of its geographic area. The central Cloud collects the traffic-related results from all VCs and extracts conclusions for the whole area.
