Network Slicing on 5G Vehicular Cloud Computing Systems

Abstract

Fifth generation Vehicular Cloud Computing (5G-VCC) systems support various services with strict Quality of Service (QoS) constraints. Network access technologies such as Long-Term Evolution Advanced Pro with Full Dimensional Multiple-Input Multiple-Output (LTE-A Pro FD-MIMO) and LTE Vehicle to Everything (LTE-V2X) undertake the service of an increasing number of vehicular users, since each vehicle could serve multiple passenger with multiple services. Therefore, the design of efficient resource allocation schemes for 5G-VCC infrastructures is needed. This paper describes a network slicing scheme for 5G-VCC systems that aims to improve the performance of modern vehicular services. The QoS that each user perceives for his services as well as the energy consumption that each access network causes to user equipment are considered. Subsequently, the satisfactory grade of the user services is estimated by taking into consideration both the perceived QoS and the energy consumption. If the estimated satisfactory grade is above a predefined service threshold, then the necessary Resource Blocks (RBs) from the current Point of Access (PoA) are allocated to support the user’s services. On the contrary, if the estimated satisfactory grade is lower than the aforementioned threshold, additional RBs from a Virtual Resource Pool (VRP) located at the Software Defined Network (SDN) controller are committed by the PoA in order to satisfy the required services. The proposed scheme uses a Management and Orchestration (MANO) entity implemented by a SDN controller, orchestrating the entire procedure avoiding situations of interference from RBs of neighboring PoAs. Performance evaluation shows that the suggested method improves the resource allocation and enhances the performance of the offered services in terms of packet transfer delay, jitter, throughput and packet loss ratio.

1. Introduction

Nowadays, 5G Network Slicing is receiving increased attention from both the research and the industrial communities. Several research challenges of the 5G Network Slicing must be addressed, including the Radio Access Network (RAN) Virtualization [1] and the End-to-End Slice Orchestration and Management [2].

RAN Virtualization is one of the most important challenges that have arisen. Many solutions allow spectrum division while providing isolation of radio resources. However, the usage of the available resources is not always efficient and reliable. Another challenge for RAN virtualization is the ability to have multiple Radio Access Technologies (RATs), namely a heterogeneous RAN, as they are essential for 5G networks.

End-to-End Slice Orchestration and Management is a great challenge for the implementation of a network slice and the transition from the description and the design of the service to the implementation and support of the service.

Regarding the network access technologies that can be used for implementing network slicing, the Long Term Evolution (LTE) has obtained increased research interest. Specifically, the LTE Advanced Pro with FD-MIMO (rel. 15) [3,4] allows the existence of up to 64-element antennas in each evolved NodeB (eNB) enhancing the capacity of the access network. In such an architecture, information is transmitted in frames of 10 ms of length and every frame is split into 10 sub-frames of 1 Time Transmission Interval (TTI) of length each. The minimum resource which can be allocated for transmission is called Resource Block (RB). RBs are allocated to users in each TTI and the number of available RBs per TTI depends on the system bandwidth. In particular, flexible component carrier bandwidths from 1.4 up to 20 MHz are allowed, while 100 RBs are available for allocation per component carrier in the case of 20MHz bandwidth. Furthermore, multiple antennas per eNB can further increase the available bandwidth, allowing the implementation of Ultra Dense Networking (UDN) [5] architectures. Additionally, the LTE Vehicle to Everything or LTE-V2X [3] technology allows the implementation of the aforementioned characteristics in Road Side Units (RSU) for supporting vehicular infrastructures.

In Fifth Generation Vehicular Cloud Computing (5G-VCC) systems, the operating principles of both Vehicular Networks and Cloud computing are combined. Vehicular users use On-Board Units (OBUs) or smart mobile devices with computational, storage and communication resources. The OBUs communicate with each other as well as with access network infrastructures consisting of LTE-A Pro FD-MIMO macrocells, LTE V2X RSUs as well as other network access technologies. In a such architecture, each Point of Access (PoA) interacts with a Cloud infrastructure which offers a variety of vehicular services with strict Quality of Service (QoS) requirements. Thus, vehicles can provide various cloud services to their passengers, while at the same time each vehicle could serve many passengers with different services and various requirements. To address this situation, efficient resource allocation mechanisms should be implemented. This paper describes a novel network slicing scheme for 5G-VCC systems. The proposed scheme aims to improve the performance of modern vehicular services such as Conversational Voice (CVo), Conversational Video (CVi), Autonomous Navigation (ANav), Route Guidance (RG), Buffered Streaming (BS) and Web Browsing (WB). The QoS that each user receives for his services as well as the energy consumption that each access network causes to user equipment are considered. Regarding these factors, the satisfaction grade of the user services is estimated. If the perceived satisfaction grade obtained from the PoA attains a predefined service threshold, then only RBs from the current PoA are allocated. On the contrary, if the estimated satisfaction grade is lower than the aforementioned threshold, then additional RBs from a Virtual Resource Pool (VRP) are committed by the PoA so as to satisfy the required user’s services. In addition, a Management and Orchestration (MANO) [6] entity is implemented by a Software Defined Network (SDN) controller providing centralized control of the entire system. Thus, the MANO entity orchestrates the entire procedure avoiding situations of interference due to the borrowing of RBs from neighboring PoAs.

The proposed approach includes the following characteristics:

• A three layer architecture is introduced allowing the optimal allocation of communication resources to both Guaranteed Bitrate (GBR) and non- Guaranteed Bitrate (non-GBR) services.
• SDN controllers maintain Virtual Resource Pools allowing their underlying PoAs to commit the necessary of communication resources to support users’ services.
• The network slicing is performed considering the satisfaction grade of the user services.
• Fuzzy logic is applied for the estimation of the satisfaction grade of the user services by taking into consideration both the Quality of Service (QoS) of user services and the energy consumption of the user equipment.

The remainder of the paper is as follows: In Section 2 the related research literature is revised, while Section 3 presents the proposed scheme for performing network slicing on 5G-VCC architectures. Section 4 presents the simulation setup and Section 5 describes the evaluation results. Finally, Section 6 concludes the discussed work.

2. State of the Art

As the International Telecommunication Union (ITU) and the Fifth Generation Public Private Partnership (5G-PPP) have specified, 5G vehicular networks support three main categories of modern communications, namely the Enhanced Mobile Broadband, the Massive Machine-type Communications and the Critical Communications (or Low Latency Communications) [7]. In order to meet the new standards and requirements, many 5G architectures have been proposed, each serving a different use case. Furthermore, according to the Next Generation Mobile Network Alliance (NGMN), network architecture should be approached with more flexible and efficient techniques such as Network Slicing.

Initially, only Core Network (CN) slicing [8] was proposed in the academic and industrial domain. Thereafter, the NGMN also supported End-to-End (E2E) slicing [9] in order to enhance both the performance of the Radio Access Network (RAN) and the Core Network (CN). Specifically, the NGMN proposes a three-layer network management architecture, which consists of the Infrastructure Resource layer, the Business Enablement layer and the Business Application layer. According to the NGMN, a Network Slice represents an instance of a service consisting of a specific structure, configuration and workflow. Each Slice employs multiple instances of logical subnetworks. Each subnetwork fulfils the diverse functions and requirements requested by the particular service. The whole process is organized by an End-to-End (E2E) MANO entity [6]. Additionally, the architecture proposal of the 5G Infrastructure Public Private Partnership (5G-PPP) describes in detail the relations among the components of the 5G network. Specifically, the proposed architecture consists of five different layers namely the Infrastructure, the Network Function, the Orchestration, the Business Function and the Service Layer. As follows, in 5G-PPP the MANO entity consists of a separate layer. Furthermore, the Business Application layer of the NGNM architecture has been replaced in the 5G-PPP by two separate layers, namely the Business Function layer and the Service layer.

In Reference [10] the guidelines of the ITU, the NGMN and the 5G-PPP are considered and a three-layer framework for Network Slicing implementation is proposed. Specifically, the framework consists of the Service, the Network Function and the Infrastructure layers. The service layer can be approached in two ways: Either it defines the service level description by a set of SLA requirements and services, or it defines a composite structure identifying the functions and RATs that should be used by the slice. The difference between the two lies in the process of the slice generation: In the first scenario, the slice implementation necessitates the application of efficient operations to meet the requirements described. In the second scenario, the slice will be implemented in a simpler way, which, however, might be less effective.

Subsequently, the Network Function layer includes both the control and the user planes of the network architecture. Specifically, it includes every operation that has to do with the configuration of the network functions and data forwarding.

The Infrastructure layer refers to the physical network that includes the Radio Access Network (RAN) and the Core Network (CN). Also, it implements functionalities for the management and the allocation of the network resources.

Furthermore, in this framework a MANO entity coexists that converts use cases and service models into network slices using the network functions. The MANO entity links the use cases and service models to infrastructure resources, while at the same time it keeps configuring and monitoring each slice during its life cycle.

In addition to the aforementioned works, several network slicing schemes have been proposed from the research literature. Each scheme applies either non-QoS aware or QoS aware strategies to perform the resource allocation.

Well known non-QoS aware algorithms for resource allocation are the Proportional Fairness (PF) [11], the Round Robin (RR) [12], the Maximum Throughput (MT) [13], the Blind Equal Throughput (BET) [13] and the Throughput to Average (TTA) [14].

In Reference [15] three network slicing methods are studied. In the first one, which is called Static Allocation (SA) method, the required number of RBs is estimated for each slice considering its service constraints. Subsequently, each slice allocates its RBs to vehicular users, by applying the PF resource allocation algorithm. In the second method called Allocation of Ordered Slices (AOS) slices are prioritized. The requirements of slices with higher priority are processed first, while the PF algorithm is applied to allocate RBs to the users of each slice. Finally, the third method called Impartial Allocation (IA) is an extension of the AOS method. In this approach, each slice selects which RBs will be allocated to its users considering the channel quality of each RB. Thus, slices with higher priority allocate RBs with higher channel quality, increasing the quality of their services.

In Reference [16] the Reliable Software-Defined RAN (RSDR) scheme for network slicing which applies an improved version of the RR algorithm is proposed. A weigh for each slice is calculated in each TTI and the slices with higher weight gain priority against others to the allocation of RBs. For the allocation of RBs to the available slices, the improved version of the RR scheme is applied based on the priority weight of each slice.

Regarding the QoS aware strategies for resource allocation, several schemes have also been proposed optimizing the performance of modern network environments. Indicatively, the Modified Largest Weighted Delay First (MLWDF) [17] and the Exponential/PF (EXP/PF) [18] QoS aware algorithms extend the PF metric by taking into consideration network factors such as the head of line delay and the packet loss ratio.

In Reference [19] three types of slices are defined, namely the Fixed, the On-demand and the Dynamic slices. Firstly, dedicated communication resources are allocated to the Fixed slices considering the Service Layer Agreement (SLA) of each user. Subsequently, available communication resources are allocated to the On-demand slices based on their QoS constraints by applying an alternative version of the MLWDF algorithm where Equation (1) is used for the estimation of the scheduling metric. It has to be noted that the ${\alpha }_i$ value is determined by Equation (2) where ${\delta }_i$ is the target packet loss ratio and ${\tau }_i$ is the delay constraint. Additionally, the $D_{HOL,i}$ parameter is the Head of Line (HOL) delay observed for the ith service slice, while the $R_k^{i^{req}}$ and the ${\overline{R}}^i(t-1)$ parameters represent the required throughput and the past average throughput of the slice. Finally, the remaining resources are allocated to the Dynamic slices using Equation (3).

$$m_{i,k}^{On-demand}=a_i·D_{HOL,i}·\frac{R_k^{i^{req}}\left(t\right)}{{\overline{R}}^i(t-1)}$$

(1)

$${\alpha }_i=-\frac{log{\delta }_i}{{\tau }_i}$$

(2)

$$m_{i,k}^{Dynamic}=\frac{R_k^{i^{req}}\left(t\right)}{{\overline{R}}^i(t-1)}$$

(3)

Another QoS aware algorithm for resource allocation is called Frame Level Scheduler (FLS) [20,21]. It implements a two level QoS aware streategy. The upper level estimates the $u_i\left(z\right)$ quota of data that the ith real time flow must transmit at the zth frame to satisfy its QoS constraints using Equation (4). In this equation, $q_i\left(z\right)$ represents the queue length in the zth frame, $C_i$ the number of coefficients used and $c_i\left(y\right)$ the value of the yth coefficient. It should be noted that the coefficients are used to guarantee that the delay constraint for each real time flow is satisfied. The number $C_i$ of coefficients is estimated using Equation (5), where ${\tau }_i$ represents the target delay and $T_f$ the frame length. Additionally, the coefficient value $c_i\left(y\right)$ is determined by Equation (6). Subsequently, the lower level applies the PF algorithm to allocate network resources to real time flows for transmitting their quota of data. The remaining resources are allocated to best effort flows. Furthermore, some modifications of the FLS algorithm are proposed to further improve the performance of real-time services [22] and to support Cross Carrier (CC) scheduling [23,24].

$$u_i\left(z\right)=q_i\left(z\right)+\sum _{y=2}^{C_i}[q_i(z-y+1)-q_i(z-y+2)-u_i(z-y+1)]·c_i\left(y\right)$$

(4)

$${\tau }_i=(C_i+1)·T_f$$

(5)

$$c_i\left(y\right)=\left\{\begin{array}{c}y\mathrm{where}0\le y\le 1\hfill \\ c_i(y-1)/2\mathrm{where}y\ge 2\hfill \end{array}\right.$$

(6)

Finally, in [25] the Ultra Reliable Low Latency Communication for Autonomous Vehicular Networks (URLLC-AVN) scheme is proposed for performing network slicing in vehicular networks. Specifically, each RSU contains a set of RBs, which is divided into two subsets, namely the local RBs and the shared RBs. The local RBs are allocated only to vehicles that are connected to the specific RSU, while the shared RBs of each RSU are added to a virtual resource pool. The queue delay that each vehicle perceives for his services is monitored. If the estimated delay grade is lower than a predefined threshold, then only RBs from the current RSU are allocated to the vehicle. On the contrary, if the estimated delay is higher than the threshold, additional RBs from the virtual resource pool are committed in order for the available resources to be increased and thus decreasing the delay that the vehicle perceives.

In this work, design characteristics of both the FLSA-CC [23] and URLLC-AVN [25] algorithms are adopted to accomplish optimal allocation of the communication resources to user services. Furthermore, the proposed scheme implements a Fuzzy Inference System (FIS) [26] for the estimation of the satisfaction grade of each user service considering both QoS and energy aware criteria.

3. The Proposed Network Slicing Scheme

The proposed network slicing scheme aims to improve the allocation of the communication resources of the access network infrastructure to maximize the satisfaction of the QoS constraints of modern vehicular services. It consists of a three-layer stack performing the allocation of communication resources to user services. The proposed slicing scheme is deployed in a Software Defined 5G network architecture, with each network component implementing specific layers of the proposed stack. In the following subsections the proposed scheme and the network architecture are described.

3.1. The Layered Design of the Proposed Scheme

The proposed slicing scheme is based on the three-layer design of the FLSA-CC [23] scheduler presented in Figure 1. Two service groups are defined, namely the Guaranteed Bit Rate (GBR) containing services with strict QoS constraints and the non-Guaranteed Bit Rate (non-GBR) containing best effort services. The upper layer of the scheme evaluates the amount of RBs that should be committed for each GBR service to succeed its QoS constraints. Subsequently, the second layer allocates RBs obtained from the upper layer to the GBR services. Finally, the third layer has been added to allocate the remaining RBs to the non-GBR services. The following subsections describe the functionalities of each layer.

3.1.1. The Upper Layer of the Network Slicing Scheme

A set $M_u\left(t_n\right)$ of GBR services per user u require resources to satisfy their constraints during the $t_n$ TTI. For each $m_u\left(t_n\right)\in M_u\left(t_n\right)$ service, the $S_{m,u}^{estimated}\left(t_n\right)$ indicator is defined, determining the estimated satisfaction grade of user u during the upcoming $t_n$ TTI that is the next TTI for which RBs are going to be allocated.

The $S_{m,u}^{estimated}\left(t_n\right)$ value are estimated using the Mamdani Fuzzy Inference System (MFIS) system described in [27], where the $E_{m,u}^{estimated}$ and the $Q_{m,u}^{estimated}$ parameters are considered as inputs expressed as Interval Valued Octagonal Fuzzy Numbers (IVOFNs) [28]. The linguistic terms and the corresponding IVOFNs used for the representation of the $S_{m,u}^{estimated}$, the $E_{m,u}^{estimated}$ and the $Q_{m,u}^{estimated}$ values are presented in

Table 1. Linguistic terms and the corresponding interval-valued octagonal fuzzy numbers used for $M{F}_E$, $M{F}_Q$ and $M{F}_S$.

${\mathit{MF}}_{\mathit{E}}$ membership functions.
Linguistic term	Interval-valued octagonal fuzzy number
Absolute High (AH)	[(0, 0, 0, 0, 0.015, 0.047, 0.079, 0.111, 0.5, 0.5, 1), (0, 0, 0, 0, 0.012, 0.038, 0.063, 0.088, 0.4, 0.4, 0.8)]
Too High (TH)	[(0, 0.020, 0.052, 0.084, 0.115, 0.147, 0.179, 0.211, 0.5, 0.5, 1), (0.002, 0.027, 0.052, 0.078, 0.103, 0.129, 0.154, 0.179, 0.4, 0.4, 0.8)]
High (H)	[(0.088, 0.120, 0.152, 0.184, 0.215, 0.247, 0.279, 0.311, 0.5, 0.5, 1), (0.092, 0.118, 0.143, 0.169, 0.194, 0.219, 0.245, 0.270, 0.4, 0.4, 0.8)]
Less than High (LH)	[(0.188, 0.220, 0.252, 0.284, 0.315, 0.347, 0.379, 0.411, 0.5, 0.5, 1), (0.183, 0.209, 0.234, 0.260, 0.285, 0.310, 0.336, 0.361, 0.4, 0.4, 0.8)]
More than Medium (MM)	[(0.288, 0.320, 0.352, 0.384, 0.415, 0.447, 0.479, 0.511, 0.5, 0.5, 1), (0.274, 0.300, 0.325, 0.350, 0.376, 0.401, 0.427, 0.452, 0.4, 0.4, 0.8)]
Medium (M)	[(0.388, 0.420, 0.452, 0.484, 0.515, 0.547, 0.579, 0.611, 0.5, 0.5, 1), (0.365, 0.391, 0.416, 0.441, 0.467, 0.492, 0.518, 0.543, 0.4, 0.4, 0.8)]
Less than Medium (LM)	[(0.488, 0.520, 0.552, 0.584, 0.615, 0.647, 0.679, 0.711, 0.5, 0.5, 1), (0.456, 0.481, 0.507, 0.532, 0.558, 0.583, 0.608, 0.634, 0.4, 0.4, 0.8)]
More than Low (ML)	[(0.588, 0.620, 0.652, 0.684, 0.715, 0.747, 0.779, 0.811, 0.5, 0.5, 1), (0.547, 0.572, 0.598, 0.623, 0.649, 0.674, 0.699, 0.725, 0.4, 0.4, 0.8)]
Low (L)	[(0.688, 0.720, 0.752, 0.784, 0.815, 0.847, 0.879, 0.911, 0.5, 0.5, 1), (0.638, 0.663, 0.689, 0.714, 0.739, 0.765, 0.790, 0.816, 0.4, 0.4, 0.8)]
Very Low (VL)	[(0.788, 0.820, 0.852, 0.884, 0.915, 0.947, 0.979, 1, 0.5, 0.5, 1), (0.729, 0.754, 0.780, 0.805, 0.830, 0.856, 0.881, 0.907, 0.4, 0.4, 0.8)]
Absolute Low (AL)	[(0.888, 0.920, 0.952, 0.984, 1, 1, 1, 1, 0.5, 0.5, 1), (0.820, 0.845, 0.870, 0.896, 0.921, 0.947, 0.972, 0.997, 0.4, 0.4, 0.8)]
${\mathit{MF}}_{\mathit{Q}}$membership functions.
Linguistic term	Interval-valued octagonal fuzzy number
Absolutely Poor (AP)	[(0, 0, 0, 0, 0.017, 0.053, 0.089, 0.125, 0.5, 0.5, 1), (0, 0, 0, 0, 0.014, 0.042, 0.071, 0.100, 0.8)]
Very Poor (VP)	[(0, 0.035, 0.071, 0.107, 0.142, 0.178, 0.214, 0.250, 0.5, 0.5, 1), (0.025, 0.053, 0.082, 0.110, 0.139, 0.167, 0.196, 0.225, 0.4, 0.4, 0.8)]
Poor (P)	[(0.125, 0.160, 0.196, 0.232, 0.267, 0.303, 0.339, 0.375, 0.5, 0.5, 1), (0.150, 0.178, 0.207, 0.235, 0.264, 0.292, 0.321, 0.350, 0.4, 0.4, 0.8)]
Medium Poor (MP)	[(0.250, 0.285, 0.321, 0.357, 0.392, 0.428, 0.464, 0.500, 0.5, 0.5, 1), (0.275, 0.303, 0.332, 0.360, 0.389, 0.417, 0.446, 0.475, 0.4, 0.4, 0.8)]
Medium (M)	[(0.375, 0.410, 0.446, 0.482, 0.517, 0.553, 0.589, 0.625, 0.5, 0.5, 1), (0.400, 0.428, 0.457, 0.485, 0.514, 0.542, 0.571, 0.600, 0.4, 0.4, 0.8)]
Medium Good (MG)	[(0.500, 0.535, 0.571, 0.607, 0.642, 0.678, 0.714, 0.750, 0.5, 0.5, 1), (0.525, 0.553, 0.582, 0.610, 0.639, 0.667, 0.696, 0.725, 0.4, 0.4, 0.8)]
Good (G)	[(0.625, 0.660, 0.696, 0.732, 0.767, 0.803, 0.839, 0.875, 0.5, 0.5, 1), (0.650, 0.678, 0.707, 0.735, 0.764, 0.792, 0.821, 0.850, 0.4, 0.4, 0.8)]
Very Good (VG)	[(0.750, 0.785, 0.821, 0.857, 0.892, 0.928, 0.964, 1, 0.5, 0.5, 1), (0.775, 0.803, 0.832, 0.860, 0.889, 0.917, 0.946, 0.975, 0.4, 0.4, 0.8)]
Absolutely Good (AG)	[(0.875, 0.910, 0.946, 0.982, 1, 1, 1, 1, 0.5, 0.5, 1), (0.900, 0.928, 0.957, 0.985, 1, 1, 1, 1, 0.4, 0.4, 0.8)]
${\mathit{MF}}_{\mathit{S}}$membership functions.
Linguistic term	Interval-valued octagonal fuzzy number
Absolute Unsatisfactory (AU)	[(0, 0, 0, 0, 0.012, 0.038, 0.064, 0.090, 0.5, 0.5, 1), (0, 0, 0, 0, 0.010, 0.031, 0.051, 0.072, 0.4, 0.4, 0.8)]
Very Unsatisfactory (VU)	[(0, 0.025, 0.051, 0.077, 0.103, 0.129, 0.155, 0.181, 0.5, 0.5, 1), (0.018, 0.038, 0.059, 0.080, 0.101, 0.122, 0.142, 0.163, 0.4, 0.4, 0.8)]
Unsatisfactory (U)	[(0.090, 0.116, 0.142, 0.168, 0.194, 0.220, 0.246, 0.272, 0.5, 0.5, 1), (0.109, 0.129, 0.150, 0.171, 0.192, 0.212, 0.233, 0.254, 0.4, 0.4, 0.8)]
Slightly Unsatisfactory (SU)	[(0.181, 0.207, 0.233, 0.259, 0.285, 0.311, 0.337, 0.363, 0.5, 0.5, 1), (0.200, 0.220, 0.241, 0.262, 0.283, 0.303, 0.324, 0.345, 0.4, 0.4, 0.8)]
Less than Acceptable (LA)	[(0.272, 0.298, 0.324, 0.350, 0.376, 0.402, 0.428, 0.454, 0.5, 0.5, 1), (0.290, 0.311, 0.332, 0.353, 0.374, 0.394, 0.415, 0.436, 0.4, 0.4, 0.8)]
Slightly Acceptable (SA)	[(0.363, 0.389, 0.415, 0.441, 0.467, 0.493, 0.519, 0.545, 0.5, 0.5, 1), (0.381, 0.402, 0.423, 0.444, 0.464, 0.485, 0.506, 0.527, 0.4, 0.4, 0.8)]
Acceptable (A)	[(0.454, 0.480, 0.506, 0.532, 0.558, 0.584, 0.610, 0.636, 0.5, 0.5, 1), (0.472, 0.493, 0.514, 0.535, 0.555, 0.576, 0.597, 0.618, 0.4, 0.4, 0.8)]
More than Acceptable (MA)	[(0.545, 0.571, 0.597, 0.623, 0.649, 0.675, 0.701, 0.727, 0.5, 0.5, 1), (0.563, 0.584, 0.605, 0.625, 0.646, 0.667, 0.688, 0.709, 0.4, 0.4, 0.8)]
Slightly Satisfactory (SS)	[(0.636, 0.662, 0.688, 0.714, 0.740, 0.766, 0.792, 0.818, 0.5, 0.5, 1), (0.654, 0.675, 0.696, 0.716, 0.737, 0.758, 0.779, 0.800, 0.4, 0.4, 0.8)]
Satisfactory (S)	[(0.727, 0.753, 0.779, 0.805, 0.831, 0.857, 0.883, 0.909, 0.5, 0.5, 1), (0.745, 0.766, 0.787, 0.807, 0.828, 0.849, 0.870, 0.890, 0.4, 0.4, 0.8)]
Very Satisfactory (VS)	[(0.818, 0.844, 0.870, 0.896, 0.922, 0.948, 0.974, 1, 0.5, 0.5, 1), (0.836, 0.857, 0.877, 0.898, 0.919, 0.940, 0.961, 0.981, 0.4, 0.4, 0.8)]
Absolute Satisfactory (AS)	[(0.909, 0.935, 0.961, 0.987, 1, 1, 1, 1, 0.5, 0.5, 1), (0.927, 0.948, 0.968, 0.989, 1, 1, 1, 1, 0.4, 0.4, 0.8)]

. Additionally,

Table 2. The Fuzzy rule (or knowledge) base.

Rule	${\mathit{MF}}_{\mathit{E}}$	Operator	${\mathit{MF}}_{\mathit{Q}}$	${\mathit{MF}}_{\mathit{S}}$
1	AH	and	AP	AU
2	TH	and	AP	VU
3	H	and	AP	VU
4	LH	and	AP	VU
5	MM	and	AP	U
6	M	and	AP	U
7	LM	and	AP	SU
8	ML	and	AP	SU
9	L	and	AP	SU
10	VL	and	AP	LA
11	AL	and	AP	LA
12	AH	and	VP	VU
13	TH	and	VP	U
14	H	and	VP	U
15	LH	and	VP	U
16	MM	and	VP	SU
17	M	and	VP	SU
18	LM	and	VP	SU
19	ML	and	VP	LA
20	L	and	VP	LA
21	VL	and	VP	SA
22	AL	and	VP	SA
23	AH	and	P	U
24	TH	and	P	U
25	H	and	P	SU
26	LH	and	P	SU
27	MM	and	P	LA
28	M	and	P	LA
29	LM	and	P	LA
30	ML	and	P	SA
31	L	and	P	SA
32	VL	and	P	SA
33	AL	and	P	A
34	AH	and	MP	SU
35	TH	and	MP	SU
36	H	and	MP	LA
37	LH	and	MP	LA
38	MM	and	MP	LA
39	M	and	MP	SA
40	LM	and	MP	SA
41	ML	and	MP	A
42	L	and	MP	A
43	VL	and	MP	A
44	AL	and	MP	MA
45	AH	and	M	LA
46	TH	and	M	LA
47	H	and	M	SA
48	LH	and	M	SA
49	MM	and	M	SA
50	M	and	M	A
51	LM	and	M	A
52	ML	and	M	A
53	L	and	M	MA
54	VL	and	M	MA
55	AL	and	M	SS
56	AH	and	MG	SA
57	TH	and	MG	SA
58	H	and	MG	SA
59	LH	and	MG	A
60	MM	and	MG	A
61	M	and	MG	MA
62	LM	and	MG	MA
63	ML	and	MG	MA
64	L	and	MG	SS
65	VL	and	MG	SS
66	AL	and	MG	SS
67	AH	and	G	A
68	TH	and	G	A
69	H	and	G	A
70	LH	and	G	MA
71	MM	and	G	MA
72	M	and	G	MA
73	LM	and	G	SS
74	ML	and	G	SS
75	L	and	G	S
76	VL	and	G	S
77	AL	and	G	S
78	AH	and	VG	A
79	TH	and	VG	MA
80	H	and	VG	MA
81	LH	and	VG	SS
82	MM	and	VG	SS
83	M	and	VG	SS
84	LM	and	VG	S
85	ML	and	VG	S
86	L	and	VG	S
87	VL	and	VG	VS
88	AL	and	VG	VS
89	AH	and	AG	MA
90	TH	and	AG	SS
91	H	and	AG	SS
92	LH	and	AG	SS
93	MM	and	AG	S
94	M	and	AG	S
95	LM	and	AG	VS
96	ML	and	AG	VS
97	L	and	AG	VS
98	VL	and	AG	AS
99	AL	and	AG	AS

presents the knowledge base of the MFIS which consists of the fuzzy rules considered for the estimation of the $S_{m,u}^{estimated}$ parameter.

In particular, the $E_{m,u}^{estimated}$ parameter represents the communication energy consumption. It is calculated using Equation (7) [29], where ${\lambda }_b$ is the cell density in the area of the user and, thus, ${\lambda }_b·\pi ·R^2$ represents the number of PoAs connected to a user moving in an area with radius R. It has to be noted that in our case ${\lambda }_b·\pi ·R^2$ is assumed to be equal to 1. Additionally, $\zeta \left(t_n\right)\in (0,1]$ is a power amplifier parameter, $P_{tr}\left(t_n\right)$ is the transmission power of the PoA in Watts, $P_{bs}\left(t_n\right)$ is the fixed power at PoA in Watts, $P_{osc}\left(t_n\right)$ is the local oscillator power in Watts, $M\left(t_n\right)$ is the number of used antennas, $P_b\left(t_n\right)$ is the Radio Frequency (RF) chain power [30] at the base station in Watts, $C_0\left(t_n\right)$ is the energy per complex operation in Joules, $B\left(t_n\right)$ is the available bandwidth in MHz, $r_d\left(t_n\right)$ is the spectral efficiency of the downlink channel measured in bps/Hz, $P_{cod}\left(t_n\right)$ is the channel coding power measured in $\frac{Watt}{Gbit/sec}$, $P_{dec}\left(t_n\right)$ is the channel decoding power measured in $\frac{Watt}{Gbit/sec}$, and $P_d\left(t_n\right)$ is the RF chain power at user equipment measured in Watts.

$$\begin{array}{cc}\hfill E_{m,u}^{estimated}\left(t_n\right)=& {\lambda }_b·\pi ·R^2·[\zeta \left(t_n\right)·P_{tr}\left(t_n\right)+P_{bs}\left(t_n\right)+P_{osc}\left(t_n\right)+M\left(t_n\right)·\hfill \\ & (P_b\left(t_n\right)+2·C_0\left(t_n\right)·B\left(t_n\right))+B\left(t_n\right)·r_d\left(t_n\right)·\hfill \\ & P_{cod}\left(t_n\right)]+P_{dec}\left(t_n\right)·B\left(t_n\right)·r_d\left(t_n\right)+P_d\left(t_n\right)\hfill \end{array}$$

(7)

Furthermore, the $Q_{m,u}^{estimated}\left(t_n\right)$ parameter represents the estimated quality of the user’s service regarding the available RBs in the $t_n$ TTI. $Q_{m,u}^{estimated}\left(t_n\right)$ is calculated using Equation (8) which applies the Simple Additive Weighting (SAW) method described in [31]. In this equation, the $t{h}_{m,u}^{estimated}\left(t_n\right)$, the $d_{m,u}^{estimated}\left(t_n\right)$, the $j_{m,u}^{estimated}\left(t_n\right)$ and the $p{l}_{m,u}^{estimated}\left(t_n\right)$ parameters represent the throughput, the packet transfer delay, the jitter and the packet loss ratio parameter, respectively.

$$\begin{array}{cc}\hfill Q_{m,u}^{estimated}\left(t_n\right)=& w_{th}·t{h}_{m,u}^{estimated}\left(t_n\right)+w_d·\frac{1}{d_{m,u}^{estimated}\left(t_n\right)}+w_j·\frac{1}{j_{m,u}^{estimated}\left(t_n\right)}+w_{pl}·\frac{1}{p{l}_{m,u}^{estimated}\left(t_n\right)}\hfill \end{array}$$

(8)

In particular, the $t{h}_{m,u}^{estimated}\left(t_n\right)$ is estimated using Equation (9), where $\mu \left(t\right)$ represents the estimated throughput per RB and $r^{available}$ is the number of the RBs that are available for allocation.

$$\begin{array}{c}\hfill t{h}_{m,u}^{estimated}\left(t_n\right)=\mu \left(t_n\right)·r^{available}\end{array}$$

(9)

Additionally, the values of the $d_{m,u}^{estimated}\left(t_n\right)$, $j_{m,u}^{estimated}\left(t_n\right)$ and $p{l}_{m,u}^{estimated}\left(t_n\right)$ parameters are calculated using Equations (10)–(12), respectively. It has to be noted that, $p_{m,u}^{average}$ is the average packet size, $d_{m,u}^{past\_average}$ is the past average packet transfer delay and $t{h}_{m,u}^{required}$ is the required throughput of the $m^{th}$ service of user u. Additionally, the $w_{th}$, $w_d$, $w_j$ and $w_{pl}$ in (8) represent the weights of the aforementioned parameters. In this work, the considered weights are calculated using the Fuzzy Analytic Network Process (FANP) method described in [27] which in this work is implemented using IVOFNs.

$$\begin{array}{c}\hfill d_{m,u}^{estimated}\left(t_n\right)=\frac{p_{m,u}^{average}}{t{h}_{m,u}^{estimated}\left(t_n\right)}\end{array}$$

(10)

$$\begin{array}{c}\hfill j_{m,u}^{estimated}\left(t_n\right)=|d_{m,u}^{estimated}\left(t_n\right)-d_{m,u}^{past\_average}|\end{array}$$

(11)

$$\begin{array}{c}\hfill p{l}_{m,u}^{estimated}\left(t_n\right)=\frac{t{h}_{m,u}^{required}\left(t_n\right)-t{h}_{m,u}^{estimated}\left(t_n\right)}{t{h}_{m,u}^{required}\left(t_n\right)}\end{array}$$

(12)

The minimum acceptable satisfaction grades $S_{m,u}^{threshold}$ per user and service are obtained using the $E_{m,u}^{threshold}$ and the $Q_{m,u}^{threshold}$ threshold values defined in [32].

3.1.1.1. The Mamdani Satisfaction Chart

During the instantiation of the system architecture, a Mamdani satisfaction chart, which containts the $S_{m,u}^{estimated}$ values obtained for each possible $E_{m,u}^{estimated}$ and $Q_{m,u}^{estimated}$ combination, is created. Specifically, each satisfaction indicator $S_{m,u}^{estimated}$ of Figure 2 is obtained using the MFIS method, considering the $E_{m,u}^{estimated}$ and the $Q_{m,u}^{estimated}$ as input parameters. For simplicity purposes, both $E_{m,u}^{estimated}$ and $Q_{m,u}^{estimated}$ are supposed to be normalized in order to have values within the range [0, 1], while the normalization process is described in the Section 3.1.1.2. Additionally, the $M{F}_E$, $M{F}_Q$, $M{F}_S$ membership functions (MF) are defined using the Equalized Universe Method (EUM) method [27], indicating the linguistic terms and the corresponding IVOFNs for the fuzzy representation of the $E_{m,u}^{estimated}$, $Q_{m,u}^{estimated}$ and $S_{m,u}^{estimated}$ factor, respectively. Thus, for each crisp value, two membership degrees are determined in the corresponding MF, one for the upper octagon and one for the lower octagon. Table 1 represents the linguistic terms and the corresponding IVOFNs of $M{F}_E$, $M{F}_Q$ and $M{F}_S$ membership functions, which are equally distributed inside the domain [$U_{min},U_{max}$] = [0, 1], as described in [27]. Furthermore, Table 2 presents the considered fuzzy rule base which is used from the MFIS for producing the satisfaction chart.

Indicatively, when the $E_{m,u}^{estimated}$ and $Q_{m,u}^{estimated}$ values are too low, the produced $S_{m,u}^{estimated}$ value is too low as well. On the contrary, when the $E_{m,u}^{estimated}$ and $Q_{m,u}^{estimated}$ values are close to 1, the produced $S_{m,u}^{estimated}$ value is also high, indicating that the user is fully satisfied. Furthermore, when only one of the $E_{m,u}^{estimated}$ or the $Q_{m,u}^{estimated}$ values is close to 0, the user satisfaction is in low levels.

3.1.1.2. Performing Lookup at the Satisfaction Indicators Chart and Normalization of the Input Values

At this point it has to be noted that since the user’s satisfaction is obtained at the Fog by performing a lookup at the satisfaction indicators chart, the overhead introduced is minimal. Additionally, the method does not impose any significant overhead at the user equipment due to monitoring of the $E_{m,u}^{estimated}$ and $Q_{m,u}^{estimated}$ parameters. In addition, for performing the aforementioned lookup at the chart, the values of both the $E_{m,u}^{estimated}$ and the $Q_{m,u}^{estimated}$ parameters are normalized in order to be within the range [0, 1]. The normalization of the values is performed using Equations (13) and (14) for the $E_{m,u}^{estimated}$ and $Q_{m,u}^{estimated}$ parameters, respectively. In these formulas, the $E_{max}$ and the $Q_{max}$ parameters represent the maximum values that have been observed for the E and the Q parameters from the instantiation of the system and up to the current time point, while at the same time $E_{min}=0$ and $Q_{min}=0$.

$$\begin{array}{c}\hfill E_{m,u}^{normalized}=\frac{E_{m,u}^{estimated}-E_{min}}{E_{max}-E_{min}}\end{array}$$

(13)

$$\begin{array}{c}\hfill Q_{m,u}^{normalized}=\frac{Q_{m,u}^{estimated}-Q_{min}}{Q_{max}-Q_{min}}\end{array}$$

(14)

3.1.2. The Middle Layer of the Network Slicing Scheme

In each TTI, the middle layer uses an improved version of the MLWDF-CC scheduler [23], called MLWDF with Energy Awareness (MLWDF-EA), to allocate to each GBR service the number of RBs estimated from the upper level. This scheduler extends the MLWDF-CC metric to take into consideration the estimated energy consumption of each RB. Specifically, for each ith GBR flow requiring RBs, the MLWDF-EA metric of the kth RB is estimated by Equation (15). The RB that maximizes the estimated value of the MLWDF-EA metric is allocated to the ith flow. It has to be noted that the ${\alpha }_i$ value is determined by Equation (2). Additionally, the $E_{i,k}^{estimated}$ factor is normalized in order to obtain values inside the range (0,1]. As follows, the use of the cross carrier QoS aware MLWDF-EA scheduler realizes improved resource distribution among the GBR services. Cross carrier scheduling is deemed necessary since both the LRBs available in each PoA and the SRBs available in the Virtual Resource Pool can belong to different carriers.

$$m_{i,k}^{MLWDF-EA}=a_i·D_{HOL,i}·m_{i,k}^{PF-CC}·\frac{1}{E_{i,k}^{estimated}}$$

(15)

3.1.3. The Lower Layer of the Network Slicing Scheme

The third layer allocates available RBs that exist to the Virtual Resource Pool to best effort flows using Equation (16) of the PF-CC [33,34] algorithm, where $d_k^i\left(t\right)$ represents the available throughput for the ith flow in the kth RB of the t TTI and ${\overline{R}}^{i,j}(t-1)$ denotes the past average throughput.

$$m_{i,k}^{PF-CC}=\frac{d_k^i\left(t\right)}{{\sum }_{j=1}^N{\overline{R}}^{i,j}(t-1)}$$

(16)

3.2. The Proposed Network Architecture

The network architecture (Figure 3) includes K Points of Access (PoAs) that provide network access to the vehicular users. Each $k\in K$ PoA ($Po{A}_k$) has a set of Resource Blocks (RBs), a Local Monitoring Module (LMM) and a Local Allocation Module (LAM). A variable $R{B}_k^{rem}\left(t_n\right)$ indicates the remaining RBs of the kth PoA during the $t_n$ Transmission Time Interval (TTI). Additionally, the RBs of the PoA are organized into two subsets, which are called Local RBs (LRBs) and Shared RBs (SRBs).

A set of SDN controllers manipulate the PoAs. In particular, each SDN controller maintains a Virtual Resource Pool where the SRBs of its underlying PoAs are stored. Additionally, each SDN controller includes its Allocation Module (AM). Furthermore, a centralized SDN controller with a MANO entity orchestrates the entire network slicing procedure maintaining the necessary frequency reuse factor. Specifically, during the instantiation of the system, each PoA communicates with the MANO entity to identify which subset of its RBs can be considered as SRB in order to be stored to the corresponding Virtual Resource Pool. Thus, the channel interference that can occur from the assignment of the SRBs with similar frequencies to neighbouring PoAs is minimized.

Based on the layered design of the proposed scheme the allocation of RBs to user services is as follows. Initially the LMM module of each PoA implements the Upper layer of the scheme to monitor the satisfaction grade $S_{m,u}^{estimated}\left(t_n\right)$ of each user service. If the estimated $S_{m,u}^{estimated}\left(t_n\right)$ is higher than the predefined $S_{m,u}^{threshold}$ threshold value, the service requirements can be satisfied from the remaining RBs that exist in the current $Po{A}_k$. Thus the LAM module of the PoA implements the Middle and the Lower layers of the slicing scheme to allocate LRBs of the $Po{A}_k$ to both GBR and non-GBR services for the next TTI. The remaining RBs $R{B}_k^{rem}\left(t_n\right)$ are sent back to the Virtual Resource Pool which is maintained from the corresponding SDN controller. However, if the estimated satisfaction grade $S_{m,u}^{estimated}\left(t_n\right)$ is lower than the predefined $S_{m,u}^{threshold}$ threshold value, the service requirements cannot be satisfied from the $R{B}_k^{rem}\left(t_n\right)$. Thus, the AM of the SDN controller implements the Middle and the Lower layers of the scheme to allocate extra RBs from the Virtual Resource Pool to the user services. Regarding the Virtual Resource Pool the algorithm prefers to allocate RBs with similar sub frequencies for each user to minimize the number of antennas required for each vehicle, which is a factor that affects the energy consumption of the system.

4. Simulation Setup

In our experiments, the 5G Vehicular Cloud Computing topology presented in Figure 4 was considered. A mobility trace indicating the map of the city of Kastoria along with road traffic data was created using the Open Street Map (OSM) software [35]. Then, the mobility trace was used as input in the Simulator of Urban Mobility (SUMO) simulator [36] allowing the production of a realistic mobility pattern for the simulated vehicles including 52,843 vehicles in total, moving inside Kastoria city in a 24 h period. The average arrival rate of vehicles was equal to 0.611608796 vehicles per second, while their average departure rate was equal to 0.61025463 vehicles per second. The network topology was built upon the map, using the Network Simulator 3 (NS3) [37]. It included a Fog infrastructure, as well as a Cloud infrastructure.

The Fog infrastructure consisted of 2 LTE-A Pro FD-MIMO Macrocell evolved-NodeBs (eNBs) with 64-element antennas each, two LTE-A Macrocell eNBs with four-element antennas each and 60 LTE-V2X RSUs with four-element antennas each. The macrocells of the access networks were located on the map, according to the Hellenic Telecommunications and Post Commission (EETT) [38] data, while the LTE-V2X RSUs were added in order for the Ultra Dense Network (UDN) architecture to be further enhanced. Additionally, the Fog infrastructure included a set of OpenFlow SDN controllers. Each controller manipulated a subset of the aforementioned access networks. The functionality of each controller was extended by including a Virtual Resource Pool, a Monitoring Module (MM) and an Allocation Module (AM). The positions, the spectrum and the related SDN controller for each cell are presented in

Table A1. The positions and the frequencies of the available LTE-A Pro FD-MIMO Macrocells.

Network (Position)	Geographic Coordinates (Latitude, Longitude)	Number of Antennas	SDN Controller
LTE-A Pro FD-MIMO Macrocell 1 (i14)	37.987778, 23.731667	64	SDN 1
LTE-A Pro FD-MIMO Macrocell 2 (q3)	37.986389, 23.721111	64	SDN 2
Spectrum in MHz for each Antenna
Antenna Identifier	Downlink & Uplink Spectrum in MHz (LTE Band)
1	462.5–467.5 & 452.5–457.5 (31)
2	734–739 & 704–709 (17)
3	739–744 & 709–714 (17)
4	758–763 & 714–719 (28)
5	763–768 & 719–724 (28)
6	768–773 & 724–729 (28)
7	773–778 & 729–734 (28)
8	860–865 & 815–820 (18)
9	865–870 & 820–825 (18)
10	870–875 & 825–830 (18)
11	875–880 & 830–835 (19)
12	880–885 & 835–840 (19)
13	885–890 & 840–845 (19)
14	925–930 & 890–895 (8)
15	930–935 & 895–900 (8)
16	935–940 & 900–905 (8)
17	940–945 & 905–910 (8)
18	945–950 & 910–915 (8)
19	1475.9–1480.9 & 1427.9–1432.9 (11)
20	1480.9–1485.9 & 1432.9–1437.9 (11)
21	1485.9–1490.9 & 1437.9–1442.9 (11)
22	1490.9–1495.9 & 1442.9–1447.9 (11)
23	1495.9–1500.9 & 1447.9–1452.9 (11)
24	1525–1530 & 1625.5–1630.5 (24)
25	1530–1535 & 1630.5–1635.5 (24)
26	1535–1540 & 1635.5–1640.5 (24)
27	1540–1545 & 1640.5–1645.5 (24)
28	1545–1550 & 1645.5–1650.5 (24)
29	1550–1555 & 1650.5–1655.5 (24)
30	1805–1810 & 1710–1715 (3)
31	1810–1815 & 1715–1720 (3)
32	1815–1820 & 1720–1725 (3)
33	1820–1825 & 1725–1730 (3)
34	1825–1830 & 1730–1735 (3)
35	1830–1835 & 1735–1740 (3)
36	1835–1840 & 1740–1745 (3)
37	1840–1845 & 1745–1750 (3)
38	1845–1850 & 1750–1755 (3)
39	1850–1855 & 1755–1760 (3)
40	1855–1860 & 1760–1765 (3)
41	1860–1865 & 1765–1770 (3)
42	1865–1870 & 1770–1775 (3)
43	1870–1875 & 1775–1780 (3)
44	1875–1880 & 1780–1785 (3)
45	1930–1935 & 1880–1885 (2)
46	1935–1940 & 1885–1890 (2)
47	1940–1945 & 1890–1895 (2)
48	1945–1950 & 1895–1900 (2)
49	1950–1955 & 1900–1905 (2)
50	1955–1960 & 1905–1910 (2)
51	2600–2605 & 1910–1915 (15)
52	2605–2610 & 1915–1920 (15)
53	2110–2115 & 1960–1965 (1)
54	2115–2120 & 1965–1970 (1)
55	2120–2125 & 1970–1975 (1)
56	2125–2130 & 1975–1980 (1)
57	2180–2185 & 2000–2005 (23)
58	2185–2190 & 2005–2010 (23)
59	2190–2195 & 2010–2015 (23)
60	2195–2200 & 2015–2020 (23)
61	2595–2600 & 2020–2025 (16)
62	2350–2355 & 2305–2310 (30)
63	2355–2360 & 2310–2315 (30)
64	2620–2625 & 2500–2505 (7)

and

Table A2. The positions and the frequencies of the available LTE–A Macrocells and LTE V2X RSUs.

Network (Position)	Geographic Coordinates (Latitude, Longitude)	Downlink Spectrum in MHz: Antenna 1, Antenna 2, Antenna 3, Antenna 4 (LTE Band)	Uplink Spectrum in MHz: Antenna 1, Antenna 2, Antenna 3, Antenna 4 (LTE Band)	SDN Controller
LTE Macro 1 (f8)	40.524167, 21.258056	2625–2630, 2630–2635, 2635–2640, 2640–2645 (7)	2505–2510, 2510–2515, 2515–2520, 2520–2525 (7)	SDN 8
LTE Macro 2 (k19)	40.524167, 21.270556	2645–2650, 2650–2655, 2655–2660, 2660–2665 (7)	2525–2530, 2530–2535, 2535–2540, 2520–2545 (7)	SDN 9
LTE–V2X 1 (b33)	40.527296, 21.277442	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 1
LTE–V2X 2 (c12)	40.526583, 21.260826	3550–3552.5, 3552.5–3555, 3555–3557.5, 3557.5–3560 (22)	3450–3452.5, 3452.5–3455, 3455–3457.5, 3457.5–3460 (22)	SDN 1
LTE–V2X 3 (d32)	40.526032, 21.276358	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 2
LTE–V2X 4 (e12)	40.524819, 21.261104	3590–3592.5, 3592.5–3595, 3595–3597.5, 3597.5–3600 (22)	3490–3492.5, 3492.5–3495, 3495–3497.5, 3497.5–3500 (22)	SDN 1
LTE–V2X 5 (f2)	40.523786, 21.253099	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 3
LTE–V2X 6 (f31)	40.524646, 21.275628	3550–3552.5, 3552.5–3555, 3555–3557.5, 3557.5–3560 (22)	3450–3452.5, 3452.5–3455, 3455–3457.5, 3457.5–3460 (22)	SDN 2
LTE–V2X 7 (f5)	40.524328, 21.255603	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 2
LTE–V2X 8 (g12)	40.523696, 21.260837	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 2
LTE–V2X 9 (g15)	40.523305, 21.263379	3550–3552.5, 3552.5–3555, 3555–3557.5, 3557.5–3560 (22)	3450–3452.5, 3452.5–3455, 3455–3457.5, 3457.5–3460 (22)	SDN 3
LTE–V2X 10 (g9)	40.523692, 21.258844	3570–3572.5, 3572.5–3575, 3575–3577.5, 3577.5–3580 (22)	3470–3472.5, 3472.5–3475, 3475–3477.5, 3477.5–3480 (22)	SDN 1
LTE–V2X 11 (h13)	40.522762, 21.261590	3530–3532.5, 3532.5–3535, 3535–3537.5, 3537.5–3540 (22)	3430–3432.5, 3432.5–3435, 3435–3437.5, 3437.5–3440 (22)	SDN 1
LTE–V2X 12 (h17)	40.522889, 21.264763	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 3
LTE–V2X 13 (h2)	40.522746, 21.252932	3530–3532.5, 3532.5–3535, 3535–3537.5, 3537.5–3540 (22)	3430–3432.5, 3432.5–3435, 3435–3437.5, 3437.5–3440 (22)	SDN 3
LTE–V2X 14 (h30)	40.523113, 21.274598	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 3
LTE–V2X 15 (i11)	40.522163, 21.260125	3560–3562.5, 3562.5–3565, 3565–3567.5, 3567.5–3570 (22)	3460–3462.5, 3462.5–3465, 3465–3467.5, 3467.5–3470 (22)	SDN 4
LTE–V2X 16 (i19)	40.522016, 21.266329	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 4
LTE–V2X 17 (i33)	40.522453, 21.277232	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 4
LTE–V2X 18 (j22)	40.521787, 21.268839	3550–3552.5, 3552.5–3555, 3555–3557.5, 3557.5–3560 (22)	3450–3452.5, 3452.5–3455, 3455–3457.5, 3457.5–3460 (22)	SDN 4
LTE–V2X 19 (j25)	40.521608, 21.271178	3530–3532.5, 3532.5–3535, 3535–3537.5, 3537.5–3540 (22)	3430–3432.5, 3432.5–3435, 3435–3437.5, 3437.5–3440 (22)	SDN 4
LTE–V2X 20 (j28)	40.521594, 21.273391	3560–3562.5, 3562.5–3565, 3565–3567.5, 3567.5–3570 (22)	3460–3462.5, 3462.5–3465, 3465–3467.5, 3467.5–3470 (22)	SDN 5
LTE–V2X 21 (j9)	40.521637, 21.258371	3550–3552.5, 3552.5–3555, 3555–3557.5, 3557.5–3560 (22)	3450–3452.5, 3452.5–3455, 3455–3457.5, 3457.5–3460 (22)	SDN 5
LTE–V2X 22 (k11)	40.520579, 21.260202	3590–3592.5, 3592.5–3595, 3595–3597.5, 3597.5–3600 (22)	3490–3492.5, 3492.5–3495, 3495–3497.5, 3497.5–3500 (22)	SDN 2
LTE–V2X 23 (k15)	40.520582, 21.262836	3570–3572.5, 3572.5–3575, 3575–3577.5, 3577.5–3580 (22)	3470–3472.5, 3472.5–3475, 3475–3477.5, 3477.5–3480 (22)	SDN 2
LTE–V2X 24 (k16)	40.520959, 21.264330	3580–3582.5, 3582.5–3585, 3585–3587.5, 3587.5–3590 (22)	3480–3482.5, 3482.5–3485, 3485–3487.5, 3487.5–3490 (22)	SDN 1
LTE–V2X 25 (k23)	40.520580, 21.269367	3590–3592.5, 3592.5–3595, 3595–3597.5, 3597.5–3600 (22)	3490–3492.5, 3492.5–3495, 3495–3497.5, 3497.5–3500 (22)	SDN 3
LTE–V2X 26 (k7)	40.520940, 21.256585	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 4
LTE–V2X 27 (l25)	40.520507, 21.270952	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 5
LTE–V2X 28 (l30)	40.520212, 21.274900	3570–3572.5, 3572.5–3575, 3575–3577.5, 3577.5–3580 (22)	3470–3472.5, 3472.5–3475, 3475–3477.5, 3477.5–3480 (22)	SDN 3
LTE–V2X 29 (l5)	40.520316, 21.255158	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 6
LTE–V2X 30 (m17)	40.519163, 21.264467	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 5
LTE–V2X 31 (m20)	40.519652, 21.267214	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 5
LTE–V2X 32 (m22)	40.519205, 21.268504	3560–3562.5, 3562.5–3565, 3565–3567.5, 3567.5–3570 (22)	3460–3462.5, 3462.5–3465, 3465–3467.5, 3467.5–3470 (22)	SDN 6
LTE–V2X 33 (m24)	40.519181, 21.270182	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 6
LTE–V2X 34 (m27)	40.519431, 21.272556	3590–3592.5 3592.5–3595, 3595–3597.5, 3597.5–3600 (22)	3490–3492.5, 3492.5–3495, 3495–3497.5, 3497.5–3500 (22)	SDN 4
LTE–V2X 35 (m7)	40.519535, 21.256973	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 7
LTE–V2X 36 (n28)	40.518833, 21.273332	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 6
LTE–V2X 37 (n33)	40.518765, 21.277286	3580–3582.5, 3582.5–3585, 3585–3587.5, 3587.5–3590 (22)	3480–3482.5, 3482.5–3485, 3485–3487.5, 3487.5–3490 (22)	SDN 2
LTE–V2X 38 (n4)	40.518893, 21.254445	3580–3582.5, 3582.5–3585, 3585–3587.5, 3587.5–3590 (22)	3480–3482.5, 3482.5–3485, 3485–3487.5, 3487.5–3490 (22)	SDN 8
LTE–V2X 39 (o19)	40.517749, 21.266052	3590–3592.5, 3592.5–3595, 3595–3597.5, 3597.5–3600 (22)	3490–3492.5, 3492.5–3495, 3495–3497.5, 3497.5–3500 (22)	SDN 5
LTE–V2X 40 (o22)	40.517920 21.268739	3530–3532.5, 3532.5–3535, 3535–3537.5, 3537.5–3540 (22)	3430–3432.5, 3432.5–3435, 3435–3437.5, 3437.5–3440 (22)	SDN 5
LTE–V2X 41 (o26)	40.517917, 21.271664	3550–3552.5, 3552.5–3555, 3555–3557.5, 3557.5–3560 (22)	3450–3452.5, 3452.5–3455, 3455–3457.5, 3457.5–3460 (22)	SDN 6
LTE–V2X 42 (o32)	40.517755, 21.276493	3530–3532.5, 3532.5–3535, 3535–3537.5, 3537.5–3540 (22)	3430–3432.5, 3432.5–3435, 3435–3437.5, 3437.5–3440 (22)	SDN 6
LTE–V2X 43 (p24)	40.517455, 21.270338	3570–3572.5, 3572.5–3575, 3575–3577.5, 3577.5–3580 (22)	3470–3472.5, 3472.5–3475, 3475–3477.5, 3477.5–3480 (22)	SDN 6
LTE–V2X 44 (p3)	40.517490, 21.253748	3560–3562.5, 3562.5–3565, 3565–3567.5, 3567.5–3570 (22)	3460–3462.5, 3462.5–3465, 3465–3467.5, 3467.5–3470 (22)	SDN 7
LTE–V2X 45 (p30)	40.517055, 21.274813	3560–3562.5, 3562.5–3565, 3565–3567.5, 3567.5–3570 (22)	3460–3462.5, 3462.5–3465, 3465–3467.5, 3467.5–3470 (22)	SDN 8
LTE–V2X 46 (p5)	40.517527, 21.255565	3570–3572.5, 3572.5–3575, 3575–3577.5, 3577.5–3580 (22)	3470–3472.5, 3472.5–3475, 3475–3477.5, 3477.5–3480 (22)	SDN 7
LTE–V2X 47 (q23)	40.516694, 21.269523	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 7
LTE–V2X 48 (r19)	40.515949, 21.266270	3570–3572.5, 3572.5–3575, 3575–3577.5, 3577.5–3580 (22)	3470–3472.5, 3472.5–3475, 3475–3477.5, 3477.5–3480 (22)	SDN 8
LTE–V2X 49 (r2)	40.515521, 21.252794	3550–3552.5, 3552.5–3555, 3555–3557.5, 3557.5–3560 (22)	3450–3452.5, 3452.5–3455, 3455–3457.5, 3457.5–3460 (22)	SDN 7
LTE–V2X 50 (s20)	40.515218, 21.267110	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 8
LTE–V2X 51 (s24)	40.515186, 21.270210	3580–3582.5, 3582.5–3585, 3585–3587.5, 3587.5–3590 (22)	3480–3482.5, 3482.5–3485, 3485–3487.5, 3487.5–3490 (22)	SDN 9
LTE–V2X 52 (s27)	40.515476, 21.272431	3570–3572.5, 3572.5–3575, 3575–3577.5, 3577.5–3580 (22)	3470–3472.5, 3472.5–3475, 3475–3477.5, 3477.5–3480 (22)	SDN 9
LTE–V2X 53 (s30)	40.515406, 21.274918	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 7
LTE–V2X 54 (s4)	40.515366, 21.254417	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 8
LTE–V2X 55 (t1)	40.514812, 21.252504	3530–3532.5, 3532.5–3535, 3535–3537.5, 3537.5–3540 (22)	3430–3432.5, 3432.5–3435, 3435–3437.5, 3437.5–3440 (22)	SDN 7
LTE–V2X 56 (t19)	40.514485, 21.266007	3540–3542.5, 3542.5–3545, 3545–3547.5, 3547.5–3550 (22)	3440–3442.5, 3442.5–3445, 3445–3447.5, 3447.5–3450 (22)	SDN 9
LTE–V2X 57 (u21)	40.513975, 21.267817	3560–3562.5, 3562.5–3565, 3565–3567.5, 3567.5–3570 (22)	3460–3462.5, 3462.5–3465, 3465–3467.5, 3467.5–3470 (22)	SDN 9
LTE–V2X 58 (u3)	40.514014, 21.253712	3520–3522.5, 3522.5–3525, 3525–3527.5, 3527.5–3530 (22)	3420–3422.5, 3422.5–3425, 3425–3427.5, 3427.5–3430 (22)	SDN 9
LTE–V2X 59 (u32)	40.513154, 21.277329	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 8
LTE–V2X 60 (v1)	40.512886, 21.252198	3510–3512.5, 3512.5–3515, 3515–3517.5, 3517.5–3520 (22)	3410–3412.5, 3412.5–3415, 3415–3417.5, 3417.5–3420 (22)	SDN 9

(Appendix A), for the LTE Macroecell eNBs and the LTE-V2X RSUs, respectively.

The Cloud infrastructure included a set of Virtual Machines (VMs) providing services such as Conversational Voice (CVo), Conversational Video (CVi), Autonomous Navigation (ANav), Route Guidance (RG), Buffered Streaming (BS) and Web Browsing (WB).

Table 3. The 5QI value and the corresponding constraints for each service.

Service	5QI Value	Resource Type	Priority Level	Packet Delay Budget	Packet Error Rate
Conversational Voice (CVo)	1	GBR	20	100 ms	10${}^{-2}$
Conversational Video (CVi)	2	GBR	40	150 ms	10${}^{-3}$
Autonomous Navigation (ANav)	81	Delay Critical GBR	11	5 ms	10${}^{-5}$
Route Guidance (RG)	82	Delay Critical GBR	12	10 ms	10${}^{-5}$
Buffered Streaming (BS)	4	Non-GBR	50	300 ms	10${}^{-6}$
Web Browsing (WB)	6	Non-GBR	60	300 ms	10${}^{-6}$

presents the 5QI value assigned to each service, along with the corresponding constrains of each 5QI as they are defined in the 5G-PPP specifications for 5G communications [32]. Each vehicle received one flow for each service and requires RBs in each TTI to satisfy its constraints. Furthermore, an OpenFlow SDN controller provided centralized control of the entire system, while its functionality was extended with a MANO entity that orchestrated the entire functionality of the system.

Table 4. The simulation parameters.

Parameter	Value
Simulation duration	86.400 s (24 h)
Networks count	LTE-A Pro FD-MIMO Macrocell eNBs: 2
	LTE-A Single Antenna Macrocell eNBs: 2
	LTE-V2X RSUs: 60
	Total: 64
Cells radius	LTE-A Pro FD-MIMO Macrocell: 400 m
	LTE-A Single Antenna Macrocell: 400 m
	LTE-V2X cell: 100 m
Networks positions and frequencies	See Appendix A
Vehicles count	52,843
Average vehicles arrival rate	0.611608796 vehicles per second
Average vehicles departure rate	0.61025463 vehicles per second
Services	Conversational Voice (CVo) - Average datarate per flow: 200 kbps - Simulated data type: Voice over IP (VoIP) with G.729 codec - Used NS3 module: NS3 OnOffApplication [39]
	Conversational Video (CVi) - Average datarate per flow: 1.5 Mbps (according to Skype requirements for High Definition video calling [40]) - Simulated data type: Live MP4 video - Used NS3 module: NS3 UDPTraceClient [41] using MP4 video trace
	Autonomous Navigation (ANav) - Average datarate per flow: 1.0 Mbps - Simulated data type: TCP data traffic - Used NS3 module: NS3 OnOffApplication [39]
	Route Guidance (RG) - Average datarate per flow: 1.0 Mbps - Simulated data type: TCP data traffic - Used NS3 module: NS3 OnOffApplication [39]
	Buffered Streaming (BS) - Average datarate per flow: 2.0 Mbps - Simulated data type: Buffered MP4 video - Used NS3 module: NS3 UDPTraceClient [41] using MP4 video trace
	Web Browsing (WB) - Average datarate per flow: 1.0 Mbps - Simulated data type: HTTP data traffic - Used NS3 module: ThreeGppHttpClient [42]

presents the simulation parameters.

During the network slicing process, the user satisfaction $S_{m,u}^{estimated}\left(t_n\right)$ is obtained by a lookup to the MFIS Satisfaction Chart, using the estimated $E_{m,u}^{estimated}\left(t_n\right)$ and $Q_{m,u}^{estimated}\left(t_n\right)$ values. It should be noted that the services’ weights used for the $Q_{m,u}^{estimated}\left(t_n\right)$ estimation are calculated using the FANP method [27]. The criteria used include throughput, delay, jitter and packet loss. Indicativelly,

Table 5. The pairwise comparison matrices for the ANav service.

Pairwise comparisons about the Throughput criterion
	Throughput	Delay	Jitter	Packet loss
Throughput	EI	EI/MEI	SMI	EI/MEI
Delay	MEI	EI	EMI	EI
Jitter	EI/SMI	EI/EMI	EI	EI/VSMI
Packet loss	MEI	EI	VSMI	EI
Pairwise comparisons about the Delay criterion
	Delay	Jitter	Packet loss	Throughput
Delay	EI	EMI	EI	MEI
Jitter	EI/EMI	EI	EI/VSMI	EI/SMI
Packet loss	EI	VSMI	EI	MEI
Throughput	EI/MEI	SMI	EI/MEI	EI
Pairwise comparisons about the Jitter criterion
	Jitter	Packet loss	Throughput	Delay
Jitter	EI	EI/VSMI	EI/SMI	EI/EMI
Packet loss	VSMI	EI	MEI	EI
Throughput	SMI	EI/MEI	EI	EI/MEI
Delay	EMI	EI	MEI	EI
Pairwise comparisons about the packet loss criterion
	Packet loss	Throughput	Delay	Jitter
Packet loss	EI	MEI	EI	VSMI
Throughput	EI/MEI	EI	EI/MEI	SMI
Delay	EI	MEI	EI	EMI
Jitter	EI/VSMI	EI/SMI	EI/EMI	EI

presents the FANP pairwise comparison matrix for the ANav service, while the estimated weights for each service are depicted in Figure 5.

5. Experimental Results and Discussion

The proposed scheme is compared with the URLLC-AVN scheme described in [25], considering parameters such as the packet transfer delay, the jitter, the throughput and the packet loss ratio. In particular,

Table 6. The average evaluation results achieved from each scheme during the 24-h simulation.

Average Delay observed during the entire simulation in ms (±variance)
Conversational Voice (CVo)		Conversational Video (CVi)		Autonomus Navigation (ANav)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
52.546875 (+7.753125 −7.546875)	80.80541667 (+11.92258333 −11.60541667)	107.0399306 (+15.79340278 −15.37326389)	128.4479167 (+18.95208333 −18.44791667)	3.834266169 (+0.565733831 −0.55068408)	4.182835821 (+0.617164179 −0.600746269)
Route Guidance (RG)		Buffered Streaming (BS)		Web Browsing (WB)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
8.133291874 (+100041459 −1.168117745)	8.714241294 (+1.285758706 −1.251554726)	157.640625 (+23.259375 −22.640625)	173.9885417 (+25.67145833 −24.98854167)	256.0900449 (+37.78527513 −36.78010457)	259.1400293 (+37.78527513 −37.21814873)
Average Jitter observed during the entire simulation in ms (±variance)
Conversational Voice (CVo)		Conversational Video (CVi)		Autonomus Navigation (ANav)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
5.735106383 (+7.764893617 −5.735106383)	8.819319149 (+11.94068085 −8.819319149)	11.68262411 (+15.81737589 −11.68262411)	14.01914894 (+18.98085106 −14.01914894 )	0.418482058 (+0.566592569 −0.418482058 )	0.456525881 (+0.618100984 −0.456525881)
Route Guidance (RG)		Buffered Streaming (BS)		Web Browsing (WB)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
0.887689214 (+1.201863025 −0.887689214)	0.951095586 (+1.287710384 −0.951095586)	17.20520833 (+23.29468085 −17.20520833)	18.989375 (+25.71042553 −18.989375)	27.95035197 (+37.84263012 −27.95035197)	28.28323542 (+38.29332876 −28.28323542)
Average Throughput observed during the entire simulation in bps (±variance)
Conversational Voice (CVo)		Conversational Video (CVi)		Autonomus Navigation (ANav)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
199,664.5833 (+335.4166667 −344.5833333)	194,103.519 (+828.4182086 −851.0582093)	1,499,748.438 (+251.5625 −258.4375)	1,464,749.842 (+4974.928457 −5110.889235)	999,998.3229 (+1.677083333 −1.722916667)	999,530.8795 (+67.35273344 −69.19342926)
Route Guidance (RG)		Buffered Streaming (BS)		Web Browsing (WB)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
999,998.3229 (+1.677083333 −1.722916667)	999,214.2695 (+112.7829572 −115.8652244)	1,999,999.665 (+0.335416666 −0.344583333)	1,962,289.212 (+5340.845557 −5486.806553)	999,999.8323 (+0.167708333 −0.172291667)	994,216.2201 (+827.1481562 −849.7534474)
Average Packet Loss Ratio observed during the entire simulation (±variance)
Conversational Voice (CVo)		Conversational Video (CVi)		Autonomus Navigation (ANav)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
0.001677083 (+0.001722917 −0.001677083)	0.029482405 (+0.004255291 −0.004142091)	0.000167708 (+0.000172292 −0.000167708)	0.023500105 (+0.003407259 −0.003316619)	0.0000017 (+0.00000172 −0.00000168)	0.000469121 (+0.000069 −0.000067)
Route Guidance (RG)		Buffered Streaming (BS)		Web Browsing (WB)
Proposed	URLLC-AVN	Proposed	URLLC-AVN	Proposed	URLLC-AVN
0.0000017 (+0.00000172 −0.00000168)	0.00078573 (+0.000115865 −0.000112783)	0.000000168 (+0.000000172 −0.000000168)	0.018855394 (+0.002743403 −0.002670423)	0.000000168 (+0.000000172 −0.000000168)	0.00578378 (+0.000849753 −0.000827148)

presents the average evaluation results achieved from each scheme during the 24-h simulation, indicating that the proposed scheme achieves improved system performance in all cases. Furthermore, Figure 6 presents the average packet transfer delay achieved from each scheme for every moment during the 24-h simulation. As can be observed both schemes satisfied the delay constraint defined from the 5G-PPP specifications for each service. However, the proposed scheme achieved lower delay values in all cases. Indicatively, for the CVo service slice, the packet transfer delays observed in the case of the proposed scheme were approximately 20 ms lower than the ones observed in the case of the URLLC-AVN scheme. Furthermore, in Figure 7 and Figure 8 the two schemes are compared considering the jitter and the throughput factors, respectively. Similar to the packet transfer delay results, the proposed scheme achieved better results ensuring higher service quality in all cases. In particular, the proposed scheme attained up to 10 ms lower jitter and up to 50 kbps higher throughput in some cases. Similarly, in Figure 9 the two schemes are compared considering the Packet Loss Ratio (PLR) factor, which is a very critical parameter for the considered services. As it is observed, the proposed scheme satisfied the PLR constraint for the entire services, for every moment of the simulation, while at the same time the URLLC-AVN scheme did not satisfy this constraint in any case. Thus, in cases where the URLLC-AVN scheme was used, critical information may have been lost leading to undesirable situations in some cases (e.g., road accident in case of ANav services).

Both schemes were capable of using shared communication resources to satisfy the requirements of user services. As a result, in most cases plenty of SRBs were available for allocation from each corresponding Virtual Resource Pool. Figure 10 presents the average saturation level observed in each Virtual Resource Pool during the simulation. In particular, the saturation levels in the Virtual Resource Pools maintained in SDN Controller 1 and SDN Controller 2 were low, since both controllers manipulated LTE-A Pro FD-MIMO Macrocells with plenty of resources, along with the other cells. Additionally, the rest Virtual Resource Pools obtained approximately from 45% and up to 65% average saturation. It has to be noted that in all cases the proposed scheme resulted in slightly higher saturation of communication resources in each Virtual Resource Pool, since it committed additional resources considering more parameters in comparison with the ones considered from the URLLC-AVN, including the throughput, the delay, the jitter and the packet loss ratio. On the contrary, the URLLC-AVN scheme committed additional resources considering only the delay factor. Thus, the URLLC-AVN scheme stopped the commitment of additional resources when the delay factor was satisfied. However, the satisfaction of the packet transfer delay did not impose the satisfaction of the additional parameters considered in the proposed scheme. As a result, the proposed scheme enhanced the resource allocation in all cases. Finally, both schemes were compared considering the total energy consumption observed for each scheme during the 24 h simulation. Specifically, Figure 11 shows that the proposed scheme achieved up to 100 Joules lower energy consumption during the simulation. This energy reduction can be explained since the proposed scheme took into consideration the energy consumption factor to perform the resource allocation.

6. Conclusions

In this paper a network slicing scheme for 5G-VCC systems is described. The proposed scheme improves the performance of modern vehicular services. Specifically, the QoS that each user perceives for his services as well as the energy consumption that each access network causes to user equipment are considered. Subsequently, the satisfaction grade of the user services is estimated by taking into consideration both the QoS and the energy consumption factors. If the estimated satisfaction grade is lower than a predefined threshold, additional RBs from the neighbouring PoAs are committed in order for the available resources to be increased. The orchestration of the entire procedure is performed by a MANO entity which is implemented by a centralized SDN controller. Performance evaluation showed that the proposed scheme outperforms existing solutions in terms of packet transfer delay, jitter, throughput and packet loss ratio. Future work includes the deployment of Unmanned Aerial Vehicles (UAVs) to operate as aerial relays to offload part of the RSUs tasks. Additionally, in order to further improve the proposed network slicing architecture, the design recommendations and specifications of the upcoming Sixth Generation (6G) wireless networks as well as their novel services will be studied.