SlideShare a Scribd company logo
Performance Analysis and Optimization
of Next Generation Wireless Networks
Emmanouil Skondras
Three-member advisory committee
Assoc. Prof. Dimitrios D. Vergados (Supervisor)
Prof. Angelos Michalas
Prof. Christos Douligeris
Department of Informatics
School of Information and Communication Technologies
University of Piraeus
This dissertation is submitted for the degree of
Doctor of Philosophy
University of Piraeus April 2019
Performance Analysis and Optimization of Next Generation Wireless Networks
Performance Analysis and Optimization of Next Generation
Wireless Networks
PhD Thesis of Emmanouil Skondras
(Submitted at University of Piraeus, School of Information and Communication Technologies,
Department of Informatics, April 2019)
Seven-member PhD evaluation committee
1. Dimitrios D. Vergados, Associate Professor, University of Piraeus
2. Angelos Michalas, Professor, Technological Education Institution of Western Macedonia
3. Christos Douligeris, Professor, University of Piraeus
4. George Tsihrintzis, Professor, University of Piraeus
5. Konstantinos Oikonomou, Associate Professor, Ionian University
6. Ioannis Anagnostopoulos, Associate Professor, University of Thessaly
7. Stavros Kotsopoulos, Professor, University of Patras
April 22, 2019
Performance Analysis and Optimization of Next Generation Wireless Networks
I would like to thank Assoc. Prof. Dimitrios D. Vergados for his supervision, knowledge,
support and persistent encouragement during my PhD at Department of Informatics, School of
Information and Communication Technologies, University of Piraeus. I could not have
imagined having a better mentor for my PhD study. Also, I would like to thank my advisor
Prof. Angelos Michalas for his guidance and expertise. His discussion, ideas and feedback
have been invaluable and this work would not have been possible without his input.
Furthermore, I would like to express my sincere gratitude to my advisor Prof. Christos
Douligeris for the continuous support of my PhD study and the related research. His guidance
helped me in all the time of research and writing of this thesis. I would also like to thank my
family for their constant support and encouragement over the years. They have been there for
me and I am thankful for everything they helped me achieve. A special note of appreciation to
my fiancée Eirini Zoumi. I would like to express my gratitude for putting her faith in me and
supporting me in every possible way.
Performance Analysis and Optimization of Next Generation Wireless Networks
Acknowledgements
The publications made in the context of this PhD thesis have been partly supported by the
University of Piraeus Research Center (UPRC) and the Technological Educational Institute of
Western Macedonia.
Performance Analysis and Optimization of Next Generation Wireless Networks
Abstract
The Fifth Generation (5G) networks, including the 5G Vehicular Cloud Computing (5G-VCC)
systems, have evolved rapidly offering multiple services to users. The operating principles of
vehicular networks, Cloud Computing (CC), Fog Computing (FC), Mobile Edge Computing
(MEC) and Software Defined Networks (SDN) are applied to 5G infrastructures. In a 5G-VCC
system, the vehicles are equipped with On-Board Units (OBUs) which communicate with each
other as well as with Road Side Units (RSUs). Each RSU interacts with a Cloud infrastructure
which offers vehicular services with strict Quality of Service (QoS) requirements, including
Driver Assistance (DA), Passengers Entertainment and Information (PEnI) and Medical (MED)
services. Dense deployments of 5G access networks are also implemented, called Ultra Dense
Networks (UDNs), aiming to support high data rates produced by an increased number of
vehicular users. In this environment, heterogeneous technologies are used to transfer the
network services to vehicles. Optimal manipulation of the communication resources is required,
while at the same time vehicular users should always obtain connectivity to the most appropriate
network access technology, in order the constraints of the vehicular services to be satisfied. In
this thesis, existing schemes for resource allocation as well as for mobility management are
studied, while novel solutions are proposed for each topic.
Initially, the theoretical background of the 5G wireless networks and 5G-VCC systems
is described. Subsequently, the available delivery models for providing cloud services in 5G
infrastructures are mentioned, while the available 5G-VCC architectures and the communication
models are presented.
Regarding the topic of the manipulation of the available network resources in 5G-VCC
systems, the available Medium Access Control schemes (MAC schemes) are studied, while
at the same time resource scheduling algorithms implemented at the MAC layer of 5G-VCC
systems are described. Subsequently, two novel solutions are proposed to optimize the resource
allocation process in modern networks. The first one is called FLS Advanced (FLSA) and opti-
mizes the resource allocation for real-time services. Additionally, the second one is called FLS
Advanced - Cross Carrier (FLSA-CC) and is specialized for LTE-Advanced (LTE-A) access
networks where carrier aggregation is applied in order to provide widened bandwidth to the
x
users. The evaluation of the proposed algorithms is performed through extended experiments.
Simulation results show that the proposed algorithms outperform existing solutions.
The mobility management requirements arising at the 5G-VCC systems are also studied.
As a result of this study, initially three methods for calculating the significance of the criteria
affecting the mobility management are proposed, namely the Trapezoidal Fuzzy Analytical
Network Process (TF-ANP), the Trapezoidal Fuzzy Adaptive Analytical Network Process
(TF-AANP) and the Pentagonal Fuzzy Analytical Network Process (PF-ANP). Subsequently,
three network selection algorithms are proposed, namely the Trapezoidal Fuzzy TOPSIS
(TFT), the Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW) and the
Pentagonal Fuzzy TOPSIS (PFT). Following this study and regarding the research results of the
implemented algorithms, a mobility management scheme is proposed. This scheme takes into
consideration the Signal to Noise plus Interference (SINR) parameters as well as the velocity of
the vehicular users to evaluate the necessity of performing a handover. Then, it applies the PFT
algorithm to select the most appropriate network for the user. Experimental results showed that
the proposed scheme outperforms the existing solutions described in the research literature.
Περίληψη
Η μελέτη της διατριβής εντάσσεται στην ερευνητική περιοχή των ασύρματων τηλεπικοινω-
νιακών συστημάτων και ειδικότερα των δικτύων Πέμπτης Γενιάς (Fifth Generation -5G).
Τα δίκτυα 5G, συμπεριλαμβανομένων των συστημάτων 5G Vehicular Cloud Computing (5G-
VCC) , έχουν εξελιχθεί με ταχείς ρυθμούς προσφέροντας πολλαπλές σύγχρονες υπηρεσίες
στους χρήστες. Σε μία υποδομή 5G, συνηθίζεται να εφαρμόζονται οι αρχές λειτουργίας
που διέπουν τα οχηματικά δίκτυα, το Cloud Computing (CC) , το Fog Computing (FC) , το
Mobile Edge Computing (MEC) και τα Software Defined Networks (SDN) . Επιπρόσθε-
τα, σε ένα σύστημα 5G-VCC, τα οχήματα είναι εξοπλισμένα με υπολογιστικές μονάδες επί
του οχήματος (On Board Units - OBU) οι οποίες επικοινωνούν μεταξύ τους καθώς και με
υπολογιστικές μονάδες εγκατεστημένες δίπλα στο οδικό δίκτυο (Road Side Units - RSU).
Κάθε μονάδα RSU αλληλεπιδρά με μία υποδομή Cloud, η οποία προσφέρει υπηρεσίες με
αυστηρές απαιτήσεις ως προς την Ποιότητας της Υπηρεσίας (Quality of Service - QoS).
Ενδεικτικά, υπηρεσίες υποστήριξης του οδηγού (Driver Assistance - DA) , υπηρεσίες ψυχα-
γωγίας και ενημέρωσης των επιβατών (Passengers Entertainment and Information - PEnI) ,
καθώς και ιατρικές υπηρεσίες (Medical - MED) συνηθίζεται να παρέχονται στα οχήματα
από την προαναφερθείσα υποδομή Cloud. Επίσης, σε μία αρχιτεκτονική 5G, συνηθίζεται η
ανάπτυξη πυκνών υποδομών πρόσβασης στο δίκτυο, οι οποίες αναφέρονται ως Ultra Dense
Networks (UDN) . ΄Ενα UDN αναπτύσσεται με στόχο την υποστήριξη των υψηλών ρυθ-
μών δεδομένων που παράγονται από τον αυξημένο αριθμό οχηματικών χρηστών. Στο εν
λόγω περιβάλλον ασύρματης πρόσβασης χρησιμοποιούνται ετερογενείς τεχνολογίες για τη
μεταφορά των δικτυακών υπηρεσιών από το Cloud στα οχήματα.
΄Οπως γίνεται σαφές, απαιτείται βέλτιστος χειρισμός των τηλεπικοινωνιακών πόρων,
ενώ ταυτόχρονα οι χρήστες των οχημάτων θα πρέπει πάντα να αποκτούν συνδεσιμότητα με
την καταλληλότερη τεχνολογία πρόσβασης στο δίκτυο, προκειμένου να ικανοποιούνται οι
περιορισμοί των υπηρεσιών που χρησιμοποιούν.
Στο πλαίσιο της παρούσας διδακτορικής διατριβής μελετώνται τα μοντέλα κατανομής
πόρων, καθώς και τα μοντέλα διαχείρισης της κινητικότητας των χρηστών, που έχουν προ-
ταθεί από την ερευνητική κοινότητα, ενώ νέες βελτιστοποιημένες λύσεις προτείνονται για
κάθε ένα από τα εν λόγω ζητήματα. Συγκεκριμένα, αρχικά αναλύεται το θεωρητικό υ-
xii
πόβαθρο στο οποίο βασίζεται η διατριβή. Περιγράφονται οι βασικές αρχές που διέπουν τα
συστήματα 5G, και πραγματοποιείται μνεία στα συστήματα 5G Vehicular Cloud Computing
(5G-VCC). Πραγματοποιείται επίσης μία επισκόπηση των διαθέσιμων μοντέλων παροχής
υπηρεσιών υπολογιστικού νέφους, καθώς και κατηγοριοποίησή τους. Ακολούθως, πραγ-
ματοποιείται εκτενής επισκόπηση των ασύρματων δικτύων 5G, με έμφαση στα συστήματα
5G-VCC που έχουν προταθεί στην ερευνητική βιβλιογραφία, όπου αναλύονται οι αρχιτε-
κτονικές τους, τα μοντέλα επικοινωνίας μεταξύ των συστατικών τους, καθώς και οι αρχές
που εφαρμόζονται για την διάθεση των υπηρεσιών που αυτά προσφέρουν.
Στη συνέχεια, εξετάζεται ο τομέας της διαχείρισης των δικτυακών πόρων των ασύρμα-
των δικτύων επόμενης γενιάς, συμπεριλαμβανομένων των δικτύων 5G και των συστημάτων
5G-VCC. Στο πλαίσιο της μελέτης αυτής, προτείνονται δύο νέοι αλγόριθμου χρονοπρο-
γραμματισμού για ασύρματα δίκτυα 5G. Συγκεκριμένα, αρχικά προτείνεται ο αλγόριθμος
χρονοπρογραμματισμού FLS Advanced (FLSA) , ο οποίος βελτιστοποιεί την εξυπηρέτηση
υπηρεσιών πραγματικού χρόνου. Στη συνέχεια προτείνεται ο αλγόριθμος χρονοπρογραμμα-
τισμού FLS Advanced - Cross Carrier (FLSA-CC) ο οποίος αποτελεί εξέλιξη του αλγορίθμου
FLSA του οποίου η εφαρμογή εξειδικεύεται για δίκτυα LTE-Advanced (LTE-A) όπου πραγ-
ματοποιείται συνένωση πολλαπλών φερουσών συχνοτήτων (carrier aggregation) με σκοπό
τη διεύρυνση του διαθέσιμου εύρους ζώνης.
Εξετάζεται επίσης ο τομέας της διαχείρισης της κινητικότητας των χρηστών ασύρματων
δικτύων επόμενης γενιάς. Αρχικά, πραγματοποιείται μελέτη των απαιτήσεων που υπάρ-
χουν στα ασύρματα δίκτυα 5G, με έμφαση στα συστήματα 5G-VCC, ως προς τη διαχείριση
της κινητικότητας των χρηστών. Ακολούθως, προτείνεται ένα σύνολο μεθόδων για τον
υπολογισμό της σημαντικότητας των κριτηρίων που μπορεί να ληφθούν υπόψη κατά τη δι-
άρκεια της διαχείρισης της κινητικότητας των χρηστών. Οι εν λόγω μέθοδοι αναφέρονται
ως Trapezoidal Fuzzy Analytic Network Process (TF-ANP), Trapezoidal Fuzzy Adaptive
Analytic Network Process (TF-AANP) και Pentagonal Fuzzy Analytic Network Process
(PF-ANP) . Επίσης, προτείνεται ένα σύνολο αλγορίθμων που αφορούν την επιλογή του
καταλληλότερου δικτύου πρόσβασης για τον εκάστοτε χρήστη, οι οποίοι αναφέρονται ως
Trapezoidal Fuzzy TOPSIS (TFT), Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights
(TFT-ACW) και Pentagonal Fuzzy TOPSIS (PFT). Ως αποτέλεσμα της εν λόγω έρευνας,
προτείνεται ένα νέο μοντέλο, το οποίο εξειδικεύεται στη διαχείριση της κινητικότητας των
χρηστών που αλληλοεπιδρούν με συστήματα 5G-VCC. Το μοντέλο αυτό, λαμβάνει υπόψη
το Signal to Noise plus Interference (SINR) καθώς και την ταχύτητα κίνησης του χρήστη,
ώστε να αξιολογήσει την ανάγκη πραγματοποίησης διαπομπής, ενώ στη συνέχεια εφαρμόζει
τον αλγόριθμο PFT για την επιλογή του καταλληλότερου δικτύου για τον χρήστη. Το μο-
ντέλο αξιολογείται ενδελεχώς μέσω προσομοιώσεων, μέσω των οποίων αποδεικνύεται ότι
xiii
βελτιστοποιεί τη διαχείριση της κινητικότητας των χρηστών ξεπερνώντας τις υπάρχουσες
λύσεις που περιγράφονται στη βιβλιογραφία.
Performance Analysis and Optimization of Next Generation Wireless Networks
Contents
List of Figures xix
List of Tables xxiii
1 Introduction 1
1.1 Delivery Models for Cloud Services . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Software as a Service (SaaS) based Delivery Models . . . . . . . . . 4
1.1.2 Platform as a Service (PaaS) based Delivery Models . . . . . . . . . 5
1.1.3 Infrastructure as a Service (IaaS) based Delivery Models . . . . . . . 5
1.1.4 Comparison of the Delivery Models . . . . . . . . . . . . . . . . . . 5
1.2 5G Vehicular Cloud Computing Systems (5G-VCC) . . . . . . . . . . . . . . 7
1.2.1 5G-VCC Architectures . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1.1 Vehicular Cloud (VC) . . . . . . . . . . . . . . . . . . . . 7
1.2.1.2 Vehicles using Cloud (VuC) . . . . . . . . . . . . . . . . . 8
1.2.1.3 Vehicles using Fog (VuF) . . . . . . . . . . . . . . . . . . 8
1.2.1.4 Software Defined Vehicular Architectures (SDN-V) . . . . 9
1.2.1.5 Hybrid Vehicular Architectures (HVA) . . . . . . . . . . . 10
1.2.2 Communication Models for 5G-VCC Systems . . . . . . . . . . . . 11
1.2.2.1 Vehicle to Vehicle (V2V) . . . . . . . . . . . . . . . . . . 11
1.2.2.2 Vehicle to Infrastructure (V2I) . . . . . . . . . . . . . . . 12
1.2.2.3 Vehicle to Pedestrian (V2P) . . . . . . . . . . . . . . . . . 12
1.2.2.4 Hybrid Vehicular Communication (HVC) . . . . . . . . . . 12
1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Thesis Novelty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Resource Allocation - Scheduling 15
2.1 Medium Access Control (MAC) Schemes for 5G-VCC systems . . . . . . . . 15
2.1.1 Time Division Multiple Access (TDMA) based MAC Schemes . . . . 15
xvi Contents
2.1.2 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)
based MAC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Hybrid MAC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.4 Discussion on MAC Schemes for 5G-VCC Systems . . . . . . . . . 20
2.2 Overview of Downlink Packet Schedulers . . . . . . . . . . . . . . . . . . . 21
2.2.1 Non-QoS Aware Schedulers . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 QoS Aware Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 The Proposed FLS Advanced (FLSA) Scheduler . . . . . . . . . . . . . . . . 25
2.3.1 The Upper Level of the Scheduler . . . . . . . . . . . . . . . . . . . 26
2.3.2 The Middle Level of the Scheduler . . . . . . . . . . . . . . . . . . . 26
2.3.3 The Lower Level of the Scheduler . . . . . . . . . . . . . . . . . . . 26
2.3.4 Performance Evaluation of the FLSA . . . . . . . . . . . . . . . . . 26
2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler . . . . . 32
2.4.1 Simulation Environment for the FLSA-CC Evaluation . . . . . . . . 33
2.4.2 Performance Evaluation of the FLSA-CC Algorithm . . . . . . . . . 34
2.4.2.1 Real Time Services Results . . . . . . . . . . . . . . . . . 35
2.4.2.2 Best Effort Services Results . . . . . . . . . . . . . . . . . 38
3 Mobility Management 39
3.1 Related Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1 Fuzzy Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1.1 The Interval-Valued Trapezoidal Fuzzy Numbers (IVTFN) 39
3.1.1.2 The Interval-Valued Pentagonal Fuzzy Numbers (IVPFN) . 40
3.1.1.3 Creating Fuzzy Numbers: The Equalized Universe Method
(EUM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.1.4 The Mamdani Pentagonal Fuzzy Inference System (MPFIS) 41
3.1.2 Estimating the Mobility Management Criteria Importance . . . . . . 43
3.1.2.1 The Analytic Network Process (ANP) . . . . . . . . . . . 43
3.1.3 The Trapezoidal Fuzzy Analytic Network Process (TF-ANP) . . . . . 45
3.1.3.1 The Trapezoidal Fuzzy Adaptive Analytic Network Process
(TF-AANP) . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.3.2 The Pentagonal Fuzzy Analytic Network Process (PF-ANP) 49
3.1.4 Network Selection Methods . . . . . . . . . . . . . . . . . . . . . . 52
3.1.4.1 The Trapezoidal Interval-Valued Fuzzy TOPSIS (TFT) . . 52
3.1.4.2 The Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights
(TFT-ACW) . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1.4.3 The Pentagonal Fuzzy TOPSIS (PFT) . . . . . . . . . . . . 57
Contents xvii
3.1.5 Evaluation of the Proposed Methods . . . . . . . . . . . . . . . . . . 59
3.1.5.1 Network Selection using the ANP and the TFT Algorithms 59
3.1.5.1.1 Simulation Setup . . . . . . . . . . . . . . . . . 59
3.1.5.1.2 Performance Evaluation . . . . . . . . . . . . . . 61
3.1.5.1.3 Sensitivity Analysis . . . . . . . . . . . . . . . . 66
3.1.5.2 Network Selection using the TF-ANP and the TFT Algo-
rithms for supporting Medical Services . . . . . . . . . . . 75
3.1.5.2.1 Simulation Setup . . . . . . . . . . . . . . . . . 75
3.1.5.2.2 Performance Evaluation . . . . . . . . . . . . . . 75
3.1.5.3 Network Selection using the TF-AANP and the TFT-ACW
Algorithms for supporting Medical Services . . . . . . . . 79
3.1.5.3.1 Simulation Setup . . . . . . . . . . . . . . . . . 79
3.1.5.3.2 Performance Evaluation . . . . . . . . . . . . . . 83
3.2 Mobility Management Schemes for 5G Wireless Networks . . . . . . . . . . 87
3.2.1 Existing Mobility Management Schemes . . . . . . . . . . . . . . . 87
3.2.2 Taxonomy of Existing Mobility Management Schemes . . . . . . . . 100
3.2.2.1 Control Entities . . . . . . . . . . . . . . . . . . . . . . . 100
3.2.2.1.1 Vehicle Controlled Mobility Management . . . . 100
3.2.2.1.2 Network Controlled Mobility Management . . . . 100
3.2.2.1.3 Hybrid Controlled Mobility Management . . . . 101
3.2.2.1.4 Discussion on Mobility Management Control Entities101
3.2.2.2 Message Exchange Models . . . . . . . . . . . . . . . . . 103
3.2.2.2.1 Information Centric . . . . . . . . . . . . . . . . 103
3.2.2.2.2 Host Centric . . . . . . . . . . . . . . . . . . . . 103
3.2.2.2.3 Discussion on compatibility of each Mobility Man-
agement scheme with the available Message Ex-
change Models . . . . . . . . . . . . . . . . . . 104
3.2.2.3 Mobility Management Algorithm Categories . . . . . . . . 106
3.2.2.3.1 Context Aware . . . . . . . . . . . . . . . . . . . 106
3.2.2.3.2 Cost Function based . . . . . . . . . . . . . . . . 106
3.2.2.3.3 Multi Attribute Decision Making (MADM) . . . 106
3.2.2.3.4 User Centric . . . . . . . . . . . . . . . . . . . . 106
3.2.2.3.5 Fuzzy Logic based . . . . . . . . . . . . . . . . 107
3.2.2.3.6 Neural Network based . . . . . . . . . . . . . . . 107
3.2.2.3.7 MIH based . . . . . . . . . . . . . . . . . . . . . 107
3.2.2.3.8 Probabilistic . . . . . . . . . . . . . . . . . . . . 107
xviii Contents
3.2.2.3.9 Group based . . . . . . . . . . . . . . . . . . . . 107
3.2.2.3.10 Auction based . . . . . . . . . . . . . . . . . . . 107
3.2.2.3.11 Discussion on Mobility Management Algorithm
Categories . . . . . . . . . . . . . . . . . . . . . 108
3.2.3 Mobility Management on 5G-VCC Systems . . . . . . . . . . . . . . 110
3.2.3.1 Mobility Management schemes for supporting 5G-VCC Ar-
chitectures . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.2.3.2 Mobility Management schemes for supporting 5G-VCC
Communication Models . . . . . . . . . . . . . . . . . . . 113
4 A Proposed Mobility Management Approach for 5G-VCC Systems 115
4.1 Mobility Management Requirements . . . . . . . . . . . . . . . . . . . . . . 115
4.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.2.1 VHO Initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.2.1.1 Evaluation of the Satisfaction Indicators . . . . . . . . . . 117
4.2.2 Velocity Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.2.3 Network Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.4 Handover Execution . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.5 Computational Complexity of the Proposed Approach . . . . . . . . 119
4.3 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.1 Study of a Simulation Snapshot . . . . . . . . . . . . . . . . . . . . 121
4.3.1.1 VHO Initiation . . . . . . . . . . . . . . . . . . . . . . . . 121
4.3.1.2 Velocity Monitoring . . . . . . . . . . . . . . . . . . . . . 121
4.3.1.3 Network Selection . . . . . . . . . . . . . . . . . . . . . . 121
4.3.2 24 Hours Simulation Results . . . . . . . . . . . . . . . . . . . . . . 123
5 Conclusion 133
5.1 Directions for Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Bibliography 141
Appendix A The positions of the available networks 163
Appendix B The available networks per SLA 165
Appendix C The distribution of vehicles during the 24 hours simulation 171
List of Figures
1.1 The Three-Layer Stack of the 5G-VCC Systems. . . . . . . . . . . . . . . . 2
1.2 Classification of Delivery Models for Cloud Services. . . . . . . . . . . . . . 3
1.3 Classification of 5G-VCC systems. . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 The Vehicular Cloud (VC) architecture. . . . . . . . . . . . . . . . . . . . . 8
1.5 The Vehicles using Cloud (VuC) architecture. . . . . . . . . . . . . . . . . . 8
1.6 The Vehicles using Fog (VuF) architecture. . . . . . . . . . . . . . . . . . . 9
1.7 A hybrid architecture which combines the design characteristics of both VC,
VuC and VuF architectures. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 The available communication models. . . . . . . . . . . . . . . . . . . . . . 12
2.1 MAC Schemes for 5G-VCC Systems. . . . . . . . . . . . . . . . . . . . . . 15
2.2 The Three-Level Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 The Topology Simulated for the Evaluation of the FLSA Scheduler. . . . . . 27
2.4 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio using
Different Target Delays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio using
Different Target Delays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio. . . . . 29
2.7 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio. . . . 29
2.8 Evaluation of the FLSA Scheduler in terms of VoIP Throughput. . . . . . . . 30
2.9 Evaluation of the FLSA Scheduler in terms of Video Throughput. . . . . . . 30
2.10 Evaluation of the FLSA Scheduler in terms of VoIP Fairness Index. . . . . . 31
2.11 Evaluation of the FLSA Scheduler in terms of Video Fairness Index. . . . . . 31
2.12 The FLSA-CC Scheduler Design. . . . . . . . . . . . . . . . . . . . . . . . 33
2.13 The Topology Simulated for the Evaluation of the FLSA-CC Scheduler. . . . 35
2.14 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the
Real Time Flows using Different Target Delays. . . . . . . . . . . . . . . . . 36
xx List of Figures
2.15 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the
Real Time Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.16 The FLSA-CC Scheduler Evaluation in terms of the Throughput of the Real
Time Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.17 The FLSA-CC Scheduler Evaluation in terms of the Fairness Index of the Real
Time Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.18 The FLSA-CC Scheduler Evaluation in terms of the Throughput and the Fair-
ness Index of the Best Effort Flows. . . . . . . . . . . . . . . . . . . . . . . 38
3.1 The Interval-Valued Trapezoidal Fuzzy Numbers. . . . . . . . . . . . . . . . 40
3.2 The Interval-Valued Pentagonal Fuzzy Numbers. . . . . . . . . . . . . . . . 41
3.3 The ANP Network Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4 The Relations of the Criteria considered by the ANP Network Model. . . . . 60
3.5 Criteria Weights for SLA1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6 Criteria Weights for SLA2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.7 Criteria Weights for SLA3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.8 Criteria Weights for SLA4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.9 The TFT Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.10 The TFT’s Network Ranking for User 1 in case of Network Environment Changes. 68
3.11 The TFT’s Network Ranking for User 2 in case of Network Environment Changes. 68
3.12 The TFT’s Network Ranking for User 3 in case of Network Environment Changes. 71
3.13 The TFT’s Network Ranking for User 4 in case of Network Environment Changes. 71
3.14 The TFT’s Network Ranking for User 5 in case of Network Environment Changes. 72
3.15 The TFT’s Network Ranking for User 6 in case of Network Environment Changes. 72
3.16 The TFT’s Network Ranking for User 7 in case of Network Environment Changes. 73
3.17 The TFT’s Network Ranking for User 8 in case of Network Environment Changes. 73
3.18 The TFT’s Network Ranking for User 9 in case of Network Environment Changes. 74
3.19 The TF-ANP Weights per Service and Patient Health Status. . . . . . . . . . 76
3.20 The TFT Results for each Vehicle. . . . . . . . . . . . . . . . . . . . . . . . 77
3.21 The Simulated Topology for the Evaluation of the TF-ANP and the TFT
Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.22 The Importance of each Service per Patient Health Status. . . . . . . . . . . . 84
3.23 The TF-AANP Criteria Weights for the DA Services per SLA. . . . . . . . . 85
3.24 The TF-AANP Criteria Weights for the PeNI Services per SLA. . . . . . . . 85
3.25 The TF-AANP Criteria Weights for the MED Services per SLA and Patient
Health Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.26 The TF-AANP Weights for each Vehicle. . . . . . . . . . . . . . . . . . . . 86
List of Figures xxi
3.27 Classification of Mobility Management Schemes. . . . . . . . . . . . . . . . 100
4.1 The Proposed Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.2 The S Values Range as obtained using the FIS. . . . . . . . . . . . . . . . . . 125
4.3 MFSINR Membership Functions Balance. . . . . . . . . . . . . . . . . . . . . 125
4.4 MFQ Membership Functions Balance. . . . . . . . . . . . . . . . . . . . . . 125
4.5 MFS Membership Functions Balance. . . . . . . . . . . . . . . . . . . . . . 125
4.6 The Simulated Topology for the Evaluation of the proposed Mobility Manage-
ment Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.7 Criteria Weights per Service for the HO Initiation. . . . . . . . . . . . . . . . 127
4.8 The PF-ANP Network Model. . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.9 The Relations of the Criteria considered by the PF-ANP Network Model. . . 130
4.10 The Network Selection Weights per Service for SLA 1. . . . . . . . . . . . . 130
4.11 The Network Selection Weights per Service for SLA 2. . . . . . . . . . . . . 130
4.12 The Network Selection Weights per Service for SLA 3. . . . . . . . . . . . . 130
4.13 The Network Selection Weights per Service for SLA 4. . . . . . . . . . . . . 130
4.14 The PFT Ranking of each HO Scheme. . . . . . . . . . . . . . . . . . . . . . 132
4.15 The Satisfaction Grade obtained from each HO Scheme. . . . . . . . . . . . 132
4.16 The Average PFT Ranking of each HO Scheme during the 24 Hours Simulation.132
4.17 The Average Satisfaction Grade obtained from each HO Scheme during the 24
Hours Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.18 The Total HOs Count of each HO Scheme during the 24 Hours Simulation. . 132
Performance Analysis and Optimization of Next Generation Wireless Networks
List of Tables
2.1 The Characteristics of the discussed MAC Schemes. . . . . . . . . . . . . . . 22
2.2 The Parameters considered in each Scheduler in comparison with the ones
considered by the FLSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 The Simulation Parameters for the Evaluation of the FLSA Scheduler. . . . . 28
2.4 The Sub-Frequencies that are assigned to each Cell. . . . . . . . . . . . . . . 34
2.5 The Parameters considered in each Scheduler in comparison with the ones
considered by the FLSA-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.6 The Simulation Parameters for the Evaluation of the Proposed Algorithm. . . 36
3.1 The Saaty’s Nine-Point Importance Scale. . . . . . . . . . . . . . . . . . . . 43
3.2 The Linguistic Terms that are used for the Criteria Pairwise Comparisons. . . 50
3.3 QoS Class Mapping and SLAs. . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4 The ANP Supermatrix for the SLA1 VoIP Service. . . . . . . . . . . . . . . 61
3.5 The ANP Weighted Supermatrix for the SLA1 VoIP Service. . . . . . . . . . 61
3.6 The ANP Limit Supermatrix for the SLA1 VoIP Service. . . . . . . . . . . . 62
3.7 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy
Numbers used for the Evaluation of the TFT algorithm. . . . . . . . . . . . . 66
3.8 Relation of the Network QoS Characteristics and the Linguistic Terms for VoIP. 66
3.9 The Available Networks of SLA1 and SLA2. . . . . . . . . . . . . . . . . . 69
3.10 The Available Networks of SLA3 and SLA4. . . . . . . . . . . . . . . . . . 70
3.11 The Required Services per User. . . . . . . . . . . . . . . . . . . . . . . . . 70
3.12 Networks’ Classification in respect of TFT, TOPSIS (T) and FAE Results. . . 70
3.13 Linguistic Terms and the Corresponding Interval-Valued Trapezoidal Fuzzy
Numbers used for the Criteria Attributes for the Evaluation of the TFT Algo-
rithm in cases where Medical Services are used. . . . . . . . . . . . . . . . . 77
3.14 The Available Wide Coverage Networks for each Service. . . . . . . . . . . . 78
3.15 The Simulated Vehicles for the Evaluation of the TFT Algorithm. . . . . . . . 79
3.16 Networks’ Classification in respect of TFT, ANST and FAS Results. . . . . . 79
xxiv List of Tables
3.17 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy
Numbers used for the Criteria Attributes for the Evaluation of the TFT-ACW
Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.18 The Available Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.19 The Simulated Vehicles for the Evaluation of the TFT-ACW Algorithm. . . . 82
3.20 The Classification of the Networks according to TFT-ACW, TFT and FSAW
Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.21 The Mobility Management Activities of each Scheme. . . . . . . . . . . . . 99
3.22 The Control Types that each Scheme supports. . . . . . . . . . . . . . . . . . 102
3.23 The Applicability of each Scheme to the Available Message Exchange Models. 105
3.24 The Type of Algorithms used in each Scheme. . . . . . . . . . . . . . . . . . 109
3.25 The Factors considered in each Architecture. . . . . . . . . . . . . . . . . . . 111
3.26 The Applicability of each Scheme to the Available 5G-VCC Architectures. . 112
3.27 The Applicability of each Communication Model to each Architecture. . . . . 113
3.28 The Applicability of each Scheme to each Communication Model. . . . . . . 114
4.1 Linguistic Terms and the corresponding Interval-Valued Pentagonal Fuzzy
Numbers used for MFSINR, MFQ and MFS. . . . . . . . . . . . . . . . . . . . 118
4.2 The Fuzzy Rule (or Knowledge) Base. . . . . . . . . . . . . . . . . . . . . . 126
4.3 Relation of the Network QoS Characteristics and Linguistic Terms for VoIP. . 127
4.4 The Simulation Parameters for the Evaluation of the proposed Mobility Man-
agement Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.5 The available Networks for each Monitored Vehicle. . . . . . . . . . . . . . 128
4.6 The QSLA, SINRSLA and Sth,SLA thresholds per SLA. . . . . . . . . . . . . . . 129
4.7 The HO Initiation Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.8 The Monitored Vehicles Status. . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.9 The PF-ANP Initial Supermatrix for the SLA 1 NAV Service. . . . . . . . . . 131
4.10 The PF-ANP Weighted Supermatrix for the SLA 1 NAV Service. . . . . . . . 131
4.11 The PF-ANP Limit Supermatrix for the SLA 1 NAV Service. . . . . . . . . . 131
A1 The positions of the available LTE Access Networks. . . . . . . . . . . . . . 163
A2 The positions of the available WiMAX Access Networks. . . . . . . . . . . . 164
A3 The positions of the available WAVE Access Networks. . . . . . . . . . . . . 164
B1 The available LTE networks of SLA 1. . . . . . . . . . . . . . . . . . . . . . 166
B2 The available WiMAX and WAVE networks of SLA 1. . . . . . . . . . . . . 167
B3 The available LTE networks of SLA 2, SLA 3 and SLA 4. . . . . . . . . . . 168
B4 The available WiMAX and WAVE networks of SLA 2, SLA 3 and SLA 4. . . 169
List of Tables xxv
C1 Number of vehicles that start from each LTE network and their corresponding
velocities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
C2 Number of vehicles that start from each WiMAX network and their correspond-
ing velocities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
C3 Number of vehicles that start from each WAVE network and their corresponding
velocities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
C4 Vehicles count per service and SLA. . . . . . . . . . . . . . . . . . . . . . . 174
Performance Analysis and Optimization of Next Generation Wireless Networks
Chapter 1
Introduction
In a Fifth Generation Vehicular Cloud Computing (5G-VCC) system the operating principles
of vehicular networks, Cloud Computing (CC) [1] and Software Defined Networks (SDN) [2],
considered as the key enabling technologies for the 5G networks, are combined. In a typical
VCC system, vehicles are equipped with On-Board Units (OBUs) with computational, storage
and communication resources. Vehicles communicate with each other as well as with Road
Side Units (RSUs). Also, each RSU interacts with a Cloud infrastructure which offers a variety
of modern services with strict Quality of Service (QoS) requirements. Vehicles such as cars,
motorcycles, buses and trains provide a wide variety of cloud services to their passengers.
Each vehicle could serve many passengers with different services and various requirements.
Such services may include Driver Assistance (DA), Passenger Entertainment and Information
(PEnI), and Medical (MED) services. The DA services include Navigation Assistance (NAV)
[3] and Parking Assistance (PRK) [4] services. The PEnI services include Conversational
Video (CV) [5], Voice over IP (VoIP) [6], Buffered Streaming (BS) [7] and Web Browsing
(WB) [8] services. Moreover, the MED services include Live Healthcare Video (LHVideo) [9],
Medical Images (MedImages) [10], Health Monitoring (HMonitoring) [11] and Clinical Data
Transmission (CData) [12] services.
To support the communication needs of the vehicles, dense deployments of 5G networks
are implemented, called Ultra Dense Networks (UDNs) [13]. UDNs aim to support the high
data rates produced by the increased number of vehicular users. Heterogeneous network
access technologies, such as the 3GPP Long Term Evolution Advanced (LTE-A) [14], the
IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMAX) [15] or the IEEE
802.11p Wireless Access for Vehicular Environment (WAVE) [16] RSUs are used to provide
network services to vehicles. In addition, a large number of small cells, such as Femtocells,
is deployed inside the network coverage area in order to increase the overall capacity of the
network [17][18]. Network operators use the Anything as a Service (ANYaaS) [19] delivery
2 Introduction
Service Layer
Cloud & Fog services
Network Layer
Wireless communication equipment
including Road Side Units (RSUs)
and Base Stations (BSs)
Device Layer
On-Board Units (OBUs), Sensors,
Navigation devices, Smart phones,
Tablets etc.
Figure 1.1 The Three-Layer Stack of the 5G-VCC Systems.
model in order to deploy and orchestrate network management algorithms and services using
the Cloud infrastructure. Specifically, the Mobility Management as a Service (MMaaS) [20]
[21] subcategory of ANYaaS, could be applied to accomplish mobility management operations
by the Cloud infrastructure. The MMaaS model allows for each vehicular user the creation of a
Mobility Instance (MI) at the Cloud, offering mobility management services and manipulating
the user’s mobility. In this way, the user equipment resources will experience a decreased
workload and will consume less energy during the mobility management. The 5G architecture
could be improved by applying the operating principles of Fog or Mobile Edge Computing
(MEC) [22–26]. Specifically, WAVE RSUs, as well as LTE and WiMAX Base Stations
(BSs) are equipped with additional computational and storage resources and thus they are
called as micro-datacenter RSUs (md-RSUs) and micro-datacenter BSs (md-BSs), respectively.
Vehicular services are provided directly from the access network. Thus, the durability and the
response latency of the services are improved, compared with the traditional centralized cloud
server approach.
5G-VCC systems could be described considering the three-layer stack [27][28] presented
in Figure 1.1, where the Service, the Network and the Device layers are defined. The Device
layer contains the end-user equipment such as On-Board Units (OBUs), smart phones, tablets,
navigation devices and sensors. The Network layer contains the communication equipment,
such as Macrocell/Femtocell Base Stations (BSs) or Road-Side Units (RSUs), as well as in-
vehicle network devices. The Service layer contains Cloud or Fog infrastructures that offer
vehicular services.
The vehicular users should always obtain connectivity to the most appropriate network
access technology, according to the requirements of their services. In general, the mobility
management process consists of three subprocesses, namely the VHO initiation, the network
selection and the VHO execution. The VHO initiation decides when a handover must be
performed. Subsequently, the network selection deals with the selection of the most appropriate
network for the vehicle to handover. Finally, during the VHO execution two general techniques
1.1 Delivery Models for Cloud Services 3
are considered. The first one is called Soft Handover or "Connect before Break". It defines that
the OBU is firstly connected to the new network and then it is disconnected from its previous
network. The second technique is called Hard Handover or "Break before Connect". In this
case, the OBU is firstly disconnected from its previous network and then it is connected to the
next network.
1.1 Delivery Models for Cloud Services
The delivery models refer to the way in which the service is delivered to the users. The main
cloud computing delivery models are the Software as a Service (SaaS), the Platform as a
Service (PaaS) and the Infrastructure as a Service (IaaS). As presented in Figure 1.2, each one
of the main delivery models contains a variety of delivery models. These delivery models are
described in the following subsections.
Delivery Models
Software as a
Service (SaaS)
Platform as a
Service (PaaS)
Infrastructure as a
Service (IaaS)
User
Communication as
a Service (UCaaS)
Data as a Service
(DaaS)
Entertainment as a
Service (EaaS)
Information as a
Service (INaaS)
Pictures as a
Service (PICaaS)
Sensing as a Service
(SEaaS)
Warning as a
Service (WaaS)
Framework as a
Service (FaaS)
Runtime
Environment as a
Service (RaaS)
Discovery as a
Service (DISCaaS)
Network as a
Service (NaaS)
Hardware as a
Service (HaaS)
Computing as a
Service (COaaS)
Storage as a Service
(STaaS)
Figure 1.2 Classification of Delivery Models for Cloud Services.
4 Introduction
1.1.1 Software as a Service (SaaS) based Delivery Models
Software as a Service (SaaS) provides cloud services to the end-users, while at the same time it
prevents them from configuring the services’ source code or controlling the underlying cloud
infrastructure. The SaaS delivery model includes the following subcategories:
• User Communication as a Service (UCaaS): This delivery model [29] provides the
necessary applications to the users, in order to be able to communicate with each other,
by making voice or video calls, sending emails, using chat boxes etc.
• Data as a Service (DaaS): In a 5G network architecture, data sourcing and data manipu-
lation could be performed in the cloud infrastructure using the appropriate applications.
DaaS allows users to retrieve data from the cloud, in order to avoid the permanent storage
of big data sets on their devices [30].
• Entertainment as a Service (EaaS): Modern 5G network infrastructures offer media
services such as video, music or advertisements to users. EaaS defines that the provided
media services are hosted in the cloud and broadcasted to users or offered to them
on-demand [31].
• Information as a Service (INaaS): Users often need information related to events, points
of interest (POIs) or emergency situations. The INaaS delivery model provides that
information to the users. Indicatively, in [32] users share information about their location
with other users as well as with a cloud infrastructure. Then, if a user needs information
about a specific location, he/she interacts with the cloud and subscribes to the INaaS in
order to receive it.
• Pictures as a Service (PICaaS): According to the PICaaS operating principles described
in [33], users are registered to a centralized cloud manager and they periodically share
their geographical coordinates. A customer user requests multimedia material about a
specific geographic area. Thus, some users are selected according to their positions, to
take photos or videos of the given area using their cameras. Finally, such multimedia
material is sent to the consumer user.
• Sensing as a Service (SEaaS): Sensors are distributed to the countryside to collect
data about the respective environment. The sensor data are collected in the cloud and,
subsequently, they are broadcasted to the SEaaS users [34].
• Warning as a Service (WaaS): The cloud infrastructure collects information about emer-
gency situations or disasters. Subsequently, warning messages are transmitted to users
depending on their locations [35].
1.1 Delivery Models for Cloud Services 5
1.1.2 Platform as a Service (PaaS) based Delivery Models
In the Platform as a Service (PaaS) model, the users are considered as application developers.
Specifically, PaaS provides computational and storage resources to the users by hiding the
underlying hardware infrastructure from them [36]. Also, PaaS offers the necessary platform
(e.g. the underlying Operation System - OS) to users for the deployment of their applications.
The users are able to remotely develop and deploy their applications. These applications should
be compatible with the provided cloud platform. The following delivery models could be
considered as PaaS subcategories [37]:
• Framework as a Service (FaaS): FaaS provides a framework for the implementation of
user applications.
• Runtime Environment as a Service (RaaS): RaaS provides a deployment and execution
environment for the user applications.
1.1.3 Infrastructure as a Service (IaaS) based Delivery Models
Infrastructure as a Service (IaaS) refers to the provision of infrastructure from the cloud to the
users in order to be able to set up a specific platform (e.g. an OS) to deploy their applications.
The IaaS delivery model provides resources to users. Furthermore, the IaaS model includes the
following subcategories:
• Discovery as a Service (DISCaaS): This delivery model allows users to discover cloud
recourses with specific characteristics [38].
• Network as a Service (NaaS): In NaaS the users with internet access can offer this facility
to the users that do not have any access [39].
• Hardware as a Service (HaaS): In HaaS the user devices or the cloud with plenty
computational resources can offer these to the users that need more resources [40]. The
HaaS model contains two subcategories, the Computing as a Service (COaaS) [36]
and the Storage as a Service (STaaS) [41]. COaaS provides computational resources,
such as Central Processing Unit (CPU) cores to users, in order to develop and run their
applications. STaaS provides storage space to users to deploy their applications.
1.1.4 Comparison of the Delivery Models
The determination of the advantages and the disadvantages of each of the main delivery models
is necessary, in order to provide a complete view of their functionalities. SaaS is the most
6 Introduction
cost effective delivery model, due to the fact that the user leases only the software that he
uses and not the resources that host it. In addition, the SaaS services are easy in use and they
can be rapidly provided on-demand, because they are already deployed on the cloud by their
provider. Also, the user does not have to worry about the services management, as this is the
provider’s responsibility. On the other hand, the user has no control neither over the application
implementation and parameterization, nor on the data processing functionalities. Also, the user
has limited control over the application deployment and upgrade processes, while integration
with other user’s software or systems is difficult, considering the fact that the integration must
be presupported by the service provider.
PaaS is less cost effective in comparison to SaaS, while at the same time it is more cost
effective than IaaS, as the user is leasing only the software platform (e.g. an Operating System
installation) and not the entire infrastructure that hosts the platform. Unlike SaaS, a user
can deploy his own applications to run on the aforementioned platform and, thus, he has full
control over the software that he runs. Therefore, the user has also full control over the rights
of the users accessing his software as well as over the data processing functionalities of his
applications. Furthermore, the integration between user applications and external systems
can be done at the application level, since the user has full control over the source code of
his applications. Another PaaS advantage is the minimal Virtual Machine (VM) management
that is required, since such processes are handled by the infrastructure provider. However, the
lack of control over the VM could create security risks in terms of application data privacy.
Also, the provided platform is usually a shared platform and other users could be running their
applications at the same time over it, creating even more privacy risks as well as overloading
the underlying infrastructure with additional workflows.
In IaaS, the user has full control over his VM, while he can deploy and run anything he
wants inside it. Furthermore, the user has full control of data processing functionalities inside
the entire VM and not only inside his applications as it happens in PaaS. As a consequence,
IaaS simplifies ever more the integration with other systems compared with PaaS. In addition,
it is considered as the most privacy aware cloud service due to the fact that the user can deploy,
run and control his own virtual infrastructure with full control to his VMs. However, IaaS is
more expensive than SaaS and PaaS, since the user is leasing physical resources, such as CPU
cores, RAM and storage space. Also, unlike SaaS or PaaS, in IaaS the user is responsible for
the entire VM manipulation processes, which may lead to additional tasks for him. Table 1
summarizes the main delivery models’ advantages and disadvantages.
1.2 5G Vehicular Cloud Computing Systems (5G-VCC) 7
5G-VCC Systems Classification
Architectures
Communication
Models
Vehicular Cloud
(VC)
Vehicles using
Cloud (VuC)
Vehicles using Fog
(VuF)
Hybrid
Vehicular
Architectures
(HVA)
Vehicle to Vehicle
(V2V)
Vehicle to
Infrastructure
(V2I)
Vehicle to
Pedestrian (V2P)
Software Defined
Networking
Vehicular
Architectures
(SDN-V)
Hybrid
Vehicular
Communication
(HVC)
Figure 1.3 Classification of 5G-VCC systems.
1.2 5G Vehicular Cloud Computing Systems (5G-VCC)
1.2.1 5G-VCC Architectures
Three main 5G-VCC architectures are derived in the research literature, namely the Vehicular
Cloud (VC), the Vehicles using Cloud (VuC) and the Vehicles using Fog (VuF). Moreover,
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 (Figure 1.3).
1.2.1.1 Vehicular Cloud (VC)
According to the VC architecture [38, 41–46], the cloud is consisted of vehicles with computing
resources (Figure 1.4). Vehicles directly interact with each other, while data forwarding is
supported by proprietary protocols such as the 802.11s [47].
Vehicles’ resources [48] remain idle for a long period of time in vehicles parked for many
hours each day, or even for many days in some cases, as well as in vehicles that remain stuck
due to congested traffic roads. The resources of such vehicles could be used for constructing
a cloud infrastructure [49][50]. In such cases, additional resource manipulation factors are
arising, since the constructed cloud is based on an ever-changing architecture where vehicular
VMs (VVMs) [51] are continuously added or removed. Thus, in order to assure service
continuity, multiple instances of each service should be distributed simultaneously in several
VVMs [52]. Furthermore, the authorization of each vehicle’s owner is required [53], for the
vehicles’ resources to be provided to the VC architecture.
8 Introduction
Vehicular Cloud
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Figure 1.4 The Vehicular Cloud (VC) architecture.
Vehicular Environment
Cloud
RSU/BS RSU/BS
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Figure 1.5 The Vehicles using Cloud (VuC) architecture.
1.2.1.2 Vehicles using Cloud (VuC)
According to the VuC architecture [27, 28, 35, 54–60], the vehicles interact with a Cloud
infrastructure through Macrocell/Femtocell BSs or RSUs, as presented in Figure 1.5. Compared
to the VC architecture, in a VuC architecture the vehicles are considered as the end users.
1.2.1.3 Vehicles using Fog (VuF)
The VuF architecture [61] presented in Figure 1.6, could be considered as an evolution of the
aforementioned VuC architecture, where the operating principles of Fog computing [22–26]
are applied. Specifically, the VuF architecture defines that the BSs or RSUs are equipped with
additional computational and storage resources, while they are also referred as micro-datacenter
BSs (md-BSs) and micro-datacenter RSUs (md-RSUs), respectively. In this case, the vehicles
1.2 5G Vehicular Cloud Computing Systems (5G-VCC) 9
Vehicular Environment
Fog
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Figure 1.6 The Vehicles using Fog (VuF) architecture.
interact with computing and storage resources characterized by proximity, low latency and high
bandwidth.
1.2.1.4 Software Defined Vehicular Architectures (SDN-V)
Each VCC architecture could be enhanced with advanced manipulation functionalities using
the Software Defined Networks (SDN) technology [62]. More specifically, the SDN technology
simplifies the network management procedures, while at the same time it reduces the network
equipment cost. Its operating principles include:
• The network control plane and the data plane are decoupled.
• The network orchestration and management is 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 [63], considering the operating principles of Network
Functions Virtualization (NFV) [64][65], in order to reduce the required SDN hardware as
well as to improve the overall system sustainability. In particular, concerning the Cloud-
based SDN control, in [66], [67] and [68] the SDN controller is implemented at the Cloud
infrastructure, by one or more Virtual Machines (VM). On the other hand, in [69] and [70]
a Fog infrastructure implementing the SDN control is described. Specifically, an md-RSU
contains a computing device and an OpenFlow (OF) Switch. The computing device include
10 Introduction
a VM and a lightweight hypervisor. The hypervisor is a middleware which enables VMs to
share resources to their hosted services [71]. 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 OF and Cloud controllers via the data plane and disseminates
information about services and data flows changes. Furthermore, in [72], the authors describe a
Software Defined VCC architecture, where an SDN controller exists between the RSUs and the
Cloud infrastructure, providing centralized resource manipulation functionalities for the entire
architecture.
1.2.1.5 Hybrid Vehicular Architectures (HVA)
The previous main models are combined in hybrid 5G-VCC architectures. Indicatively, in [73]
a hybrid 5G-VCC architecture combining both the VuC and VuF models, is discussed. Services
are offered by both Cloud and Fog infrastructures, while the Cognitive Radio Networks (CRN)
[74] 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, in [75] and [31] an HVA
architecture (Figure 1.7) 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
resources sustainability. Also, in [76] a HVA architecture which combines both VC and VuC
architectures is described. More specifically, a VC provides vehicle cooperation functionalities
such as Internet access via multihop 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 conclusions are sent to the central cloud. Thus, vehicles that
does not belong to the VC can obtain the traffic related information concerning the VC area.
Furthermore, the extended version of this architecture includes multiple VCs could. 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.
1.2 5G Vehicular Cloud Computing Systems (5G-VCC) 11
Fog
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
Cloud
Vehicular Cloud
micro-datacenter
RSU/BS
micro-datacenter
RSU/BS
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Service Layer
Network Layer
Device Layer
Figure 1.7 A hybrid architecture which combines the design characteristics of both VC, VuC
and VuF architectures.
1.2.2 Communication Models for 5G-VCC Systems
Communication models determine which entities communicate with each other in a VCC
architecture. In general, they are referred as Vehicle to Everything or V2X, where V stands for
vehicle and X determines the entity which 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 (Figure 1.3).
1.2.2.1 Vehicle to Vehicle (V2V)
V2V communications [77–83] comprises a wireless network where vehicles exchange infor-
mation each other. Such information could include vehicle location, speed, direction, braking,
stability loss as well as any other information including traffic or multimedia. V2V could
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 condi-
tions but not took control of the vehicle, while later implementations improve the braking or
steering capabilities of the vehicles.
12 Introduction
Cloud
RSU/BSRSU/BS
Vehicular
Environment
Pedestrian
Pedestrian
Pedestrian
Vehicle to Vehicle (V2V)
Vehicle to Infrastructure (V2I)
Vehicle to Pedestrian (V2P)
Vehicle to Vehicle (V2V)
Vehicle to Infrastructure (V2I)
Vehicle to Pedestrian (V2P)
Figure 1.8 The available communication models.
1.2.2.2 Vehicle to Infrastructure (V2I)
V2I communication [84–90] is performed through the RSUs, while the information gathered
by the infrastructure could include traffic or road conditions and Points of Interest (PoI).
Indicatively, the vehicles velocities and accelerations as well as the inter-vehicle distances
could be suggested by the infrastructure considering the traffic conditions and optimizing the
traffic manipulation, the fuel consumption and the driver safety.
1.2.2.3 Vehicle to Pedestrian (V2P)
In a V2P communication [91–97] information between vehicles and pedestrians is exchanged.
The pedestrians could exchange road safety information with vehicles using their mobile
devices in order to avoid accidents.
1.2.2.4 Hybrid Vehicular Communication (HVC)
In a 5G-VCC architecture, multiple communication models could also be used together [98–
104] (Figure 1.8).
1.3 Thesis Structure
In the first chapter the fundamental operating principles of the Fifth Generation (5G) wireless
networks and 5G Vehicle Cloud Computing (5G-VCC) systems are introduced. Additionally,
the three-layer stack used to design and analyze the 5G-VCC systems is described. Subse-
quently, the theoretical background of the thesis is analyzed. Specifically, the available delivery
models for cloud services are mentioned and existing 5g-VCC architectures are presented.
Finally, the main communication models are described.
1.4 Thesis Novelty 13
The second chapter, which deals with the management of network resources in 5G-VCC
systems, firstly describes the available Medium Access Control schemes (MAC schemes).
Subsequently, existing resource scheduling algorithms implemented at the MAC layer of 5G-
VCC systems are described, while two novel solutions are proposed to optimize the resource
allocation process.
In the third chapter, the requirements of the 5G-VCC systems for the management of
mobility of vehicular users are described. Three methods for calculating the significance of the
criteria affecting the mobility management are proposed. Furthermore, three network selection
algorithms are proposed. Subsequently, the proposed algorithms are evaluated.
The fourth chapter describes a proposed scheme for performing mobility management in 5G
wireless networks. The scheme takes into consideration the Signal to Noise plus Interference
(SINR) while at the same time it performs optimized supervision of the user’s velocity, in order
to evaluate the necessity of performing a handover. Subsequently, it selects the most appropriate
network for the user. Experimental results showed that the proposed model outperforms the
existing solutions described in the research literature.
Finally, in the fifth chapter a brief review of the thesis is made. The conclusions extracted
from the performed research are mentioned, while guidance for future work is given.
1.4 Thesis Novelty
The novelty of this thesis is found in the following points:
• Medium Access Control (MAC) schemes for 5G Wireless Networks
– Study, classification and evaluation of the most used medium access mechanisms
for 5G wireless networks and specifically for 5G-VCC systems.
• 5G Wireless Network Architectures
– Study, classification and evaluation of the 5G wireless network architectures and
in particular of 5G-VCC systems, considering the applied network topologies and
communication models proposed in the research literature.
• Delivery Models for Cloud Services in 5G Wireless Networks
– Study, classification and evaluation of the most used cloud delivery models that can
be applied to 5G network architectures.
• Resource Allocation (scheduling) in 5G Wireless Networks
14 Introduction
– Two novel resource allocation (scheduling) algorithms that can be applied to 5G
Wireless Networks, including 5G-VCC systems, are proposed. The experimental
results showed that they optimize the allocation of network resources in order the
constraints of real-time services to be optimally satisfied.
• Mobility Management in 5G Wireless Networks
– Three novel methods for calculating the weights of mobility management criteria
are proposed. Experimental results showed that the proposed methods optimize the
calculation of the significance of each mobility management criterion.
– Three novel network selection algorithms for 5G wireless network, including 5G-
VCC systems, are proposed. The experimental results showed that these algorithms
select the optimal network considering the requirements of both users and network
operators.
– An integrated mobility management scheme for 5G wireless networks, including
5G-VCC systems, is proposed. Extensive experimental results demonstrated that it
optimizes the mobility management process by minimizing the number of required
handovers, while at the same time it ensures that the user is connected to the optimal
access network considering both his requirements as well as network operators
constraints.
Chapter 2
Resource Allocation - Scheduling
2.1 Medium Access Control (MAC) Schemes for 5G-VCC
systems
This section describes MAC schemes that can be applied in 5G-VCC systems. The schemes
are organized considering their underlying multiple access mechanism. Since the vehicular
environment often changes due to the high mobility of vehicles, while at the same time both
V2V and V2I communications must be supported, sometimes in an ad-hoc manner, the most
common multiple access mechanisms considered in vehicular MAC schemes include the TDMA
and the CSMA/CA. Hybrid schemes have also been proposed in the literature combining more
than one multiple access mechanism. Figure 2.1 presents the schemes that will be discussed in
the following subsections.
MAC Schemes for
5G-VCC
TDMA
based
CSMA/CA
based
Hybrid
ATSA
CAH-MAC
CBT
CESFRA
CFR-MAC
ETCM
IGPS-MAC
PTMAC UTSP
TC-MAC
VeMAC
e-VeMAC
STDMA
CA-MAC
QL-MACMMAC-CL
MQOG
ACFM
CBRC-MAC
CS-TDMA
HER-MAC
R-MAC
OBV
Figure 2.1 MAC Schemes for 5G-VCC Systems.
2.1.1 Time Division Multiple Access (TDMA) based MAC Schemes
TDMA-based MAC schemes share the medium in the field of time. In the Adaptive TDMA
Slot Assignment (ATSA) [105] scheme, for example, each vehicle selects a frame length, which
16 Resource Allocation - Scheduling
is reduced to improve channel utilization when the vehicle density becomes low, or increased
when the vehicle density becomes high to ensure that each vehicle can access the medium.
Time slots are divided in two sets, namely the Left and the Right set. A slot management
mechanism based on a binary tree model is used. The vehicles on the left sub-tree can compete
for the Left time slots, while the vehicles on the right sub-tree can compete for the Right time
slots. When a vehicle receives slot allocation information from its neighbors, it discovers which
slots are in use. Thus, the remaining slots are available to compete for.
The Cluster Based TDMA (CBT) [106] scheme provides a mechanism for intra-cluster
and inter-cluster communication to minimize the packet collisions that could occur when two
clusters are moving close to each other. In each cluster, the vehicles are synchronized in time
using their GPS devices, while one vehicle is elected as the Cluster Head (CH). A TDMA
related technique is used where each frame consists of N time slots. The CH maintains a
Slot Allocation Map (SAM) allocating time slots to vehicles. Moreover, the CH periodically
broadcasts its SAM and a beacon frame to its cluster’s vehicles. The cluster remains in the
intra-cluster communication state if the beacon frames from the CHs of the other clusters are
not received. However, if a beacon frame comes from an external CH, the two neighboring
clusters’ CHs exchange their SAMs in order to prevent inter-cluster interference. The CH that
successfully sends first its SAM is considered as the Winner, while the other is considered as
the Loser. The Loser must reschedule its own SAM.
Another TDMA-based MAC scheme is the Cross-layer Extended Sliding Frame Reservation
Aloha (CESFRA) [107]. In CESFRA safety information is disseminated up to the third hop
neighboring vehicles without any routing scheme. This scheme divides each frame into N
time slots. All the vehicles are considered to be synchronized in time using their Geographical
Positioning System (GPS) devices. When a vehicle has packets to transmit, it senses the
medium in order to find an idle time slot. Once an idle time slot is found, the vehicle starts
transmitting its packets. The time slot is also reserved by the vehicle in the subsequent frames
in order to transmit the remaining packets.
The Collision Free Reservation MAC (CFR-MAC) [108] is another mechanism that provides
TDMA based medium access. It considers the vehicles’ traffic flows as well as their velocities.
As in the ATSA, the time slots are divided into two sets, the Left and the Right set. The Left set
is assigned to vehicles that are moving to the one direction, while the Right set is assigned to
vehicles moving to the opposite. In general, when multiple vehicles are moving on the same
street with different velocities the interference levels on the wireless environment are constantly
changing leading on unpredictable changes in the medium quality. CFR-MAC addresses this
problem by dividing each slot’s set into three subsets. Each subset is associated to a specific
2.1 Medium Access Control (MAC) Schemes for 5G-VCC systems 17
velocity, namely the High, the Medium and the Low velocity. In this way the interference levels
inside each subset become less variable and the medium quality more resistant.
The Vehicular MAC (VeMAC) [109] supports broadcast services. Similar to the CBT and
CFR-MAC schemes, the two vehicles’ moving directions are considered, namely the Left and
the Right direction. A set of time slots is assigned to vehicles that move in the Left direction
and the Right direction, respectively. Using these time slots, the vehicles of each direction
communicate with each other, while the vehicles’ time synchronization is performed using
their GPS devices. Although VeMAC supports reliable transmission, it is not fully applicable
in vehicular networks with parallel transmissions. In [110] an enhanced version of VeMAC
scheme, the e-VeMAC, is proposed. The e-VeMAC scheme is based on the insight of the
one-hop neighboring vehicles in order to improve the performance of the VeMAC scheme
when parallel transmission occurs.
The Enhanced TDMA Cluster-based MAC (ETCM) [111], the Prediction-based TDMA
MAC (PTMAC) [112] and the Unified TDMA-Based Scheduling Protocol (UTSP) [113]
schemes also implement TDMA based multiple access. The ETCM scheme defines that the
vehicles are organized into clusters, while a vehicle of each cluster is defined as the CH.
Subsequently, the CH applies a TDMA based method to assign time slots to the cluster’s
vehicles.
The main operating principle of PTMAC is the packet collision prediction. PTMAC
consists of three parts, namely the collision prediction part, the collision detection part and the
collision elimination part. According to the collision prediction part, data traffic and vehicles
mobility information is used in order to predict potential future collisions. Furthermore, the
collision detection uses time slot information to detect collisions that occurred in cases where
two vehicles transmit data using the same time slot. Finally, the collision elimination part
reschedules the slots considering the information obtained from both the collision prediction
and the collision detection parts, in order to eliminate the packet collisions.
The UTSP scheme implements a centralized resource allocation mechanism for V2I commu-
nication. Initially, the RSU collects information about the channel state, the vehicles’ velocities
and the priorities of the vehicles’ services. Then, it uses a weighted function to compute a
score for each vehicle. Finally, the RSU assigns TDMA time slots to each vehicle according
to its score, where the amount of time slots assigned to each vehicle is proportional to the
corresponding vehicle’s score.
Similar to the aforementioned MAC schemes, other TDMA-based schemes are the Cooper-
ative ADHOC MAC (CAH-MAC) [114], the Improved Generalized Prime Sequence Based
MAC (IGPS-MAC) [115], the Self-organizing Time Division Multiple Access (STDMA) [116],
and the TDMA Cluster-based MAC (TC-MAC) [117].
18 Resource Allocation - Scheduling
2.1.2 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)
based MAC Schemes
The schemes of this category share the medium by applying the CSMA/CA operating principles.
The Context Aware MAC (CA-MAC) [118] considers the network load status in order
to improve the medium access performance of 802.11p MAC. More specifically, CA-MAC
consists of two parts, the Reasoning part and the Self-adaption part. Initially, the Reasoning
part obtains the network load based on context information. Thus, the network is characterized
as congested, idle or normal. Subsequently, the Self-adaption part considers the network
load and dynamically adjusts the 802.11p Contention Window [119] size, which is used for
channel reservation by the vehicles. Accordingly, if a high network load is observed, the CW
is incremented to reduce the collisions probability. On the contrary, if a low network load is
observed the CW is decreased to avoid unnecessary medium access delays. More specifically,
if the Reasoning part indicates that the network is congested, the CW will be increased by 1,
while if the Reasoning part indicates that the network status is idle, the value of CW will be
halved. The CW will remain unchanged, if the Reasoning part indicates that the network status
is normal.
Another CSMA/CA-based scheme called Multichannel MAC - Cross Layer (MMAC-CL)
[120] aims to reduce the interference between vehicles at both the MAC and the Network layers
considering two multichannel radio interfaces per vehicle. The MMAC-CL maximizes the
average Signal to Interference Ratio (SIR) between the source and the destination. Transmis-
sion channels are selected considering a SIR evaluation, in order to minimize the cochannel
interference observed by the vehicles.
The Multichannel QoS Cognitive MAC (MQOG) [121] is a multichannel scheme using
a dedicated Control Channel (CCH) for control information exchange and multiple Service
Channels (SCHs) for data transmission. Each vehicle assesses the interference level in each
channel and acquires the best one for transmission. Subsequently, each vehicle tracks its
neighbors’ communications using a Channel Neighbor State Table (CNST). The vehicles obtain
information from the CCH in order to update their CNST tables and select the appropriate
SCHs for their data transmission.
The Q-Learning MAC (QL-MAC) [122] provides a delay tolerant medium access, where
neighboring vehicles exchange positioning information. A Contention Window (CW) is defined,
while the best CW size is evaluated using a Q-Learning algorithm, in order to improve the
contention efficiency. A positive reward is awarded to each vehicle when a data frame is
successfully transferred. On the contrary, a negative reward is given when a data frame
transmission is failed. The dynamic CW size adjustment reduces the packet collisions, while at
the same time it achieves a low medium access delay. When the payload size is larger than a
2.1 Medium Access Control (MAC) Schemes for 5G-VCC systems 19
predefined threshold, the RTS/CTS mechanism is applied in order to avoid the hidden terminal
and the exposed terminal problems, otherwise the position information is utilized in order to
decide whether to start the transmission.
2.1.3 Hybrid MAC Schemes
This category includes MAC schemes that use the operating principles of more than one of
the aforementioned multiple access mechanisms. The Adaptive Collision Free MAC (ACFM)
[123] scheme combines both TDMA and FDMA. ACFM implements a time slot reservation
mechanism located at each RSU. Each frame operates in a specific frequency and contains
36 time slots that can be used for data transmission and 1 slot that is called RSU Slot (RS).
Furthermore, each RSU maintains a Slot Assignment Cycle (SAC) for the next 100ms, while
each cycle can contain from 1 and up to 5 frames according to the vehicles density. Specifically,
if the vehicle density is low, the RSU uses a few frames in order to avoid situations where a
lot of slots remain unused. On the contrary, if the vehicle density is high, the RSU uses more
frames in order to support the increased needs for resources.
Similar to the ACFM scheme, the Cluster Based RSU Centric MAC (CBRC-MAC) [124]
combines both TDMA and FDMA for providing multiple access to vehicles. Firstly, the
available spectrum is divided into a set of subfrequencies using FDMA and, subsequently, each
subfrequency is divided into a set of time slots. Thus, Resource Blocks (RBs) are created
including a specific subfrequency in the frequency domain and a specific slot in the time domain.
RSUs assign RBs to vehicles considering their communication needs.
Some schemes combine TDMA with CSMA/CA to accomplish the multiple access. In
the Hybrid Efficient and Reliable MAC (HER-MAC) [125] scheme, vehicles are synchronized
using their GPS devices. When a vehicle needs to transmit data, it uses the CSMA/CA to
perform a 3-way handshake in Wireless Access for Vehicular Environment (WAVE) [16] called
Wireless Service Announcement/Request for Service (WSA/RFS). During this handshake,
the transmitter vehicle broadcasts a WSA message in order to reserve TDMA time slots
for data transmission. When the slot reservation is complete, the transmitter vehicle sends
a RFS message to the recipient vehicle. Subsequently, the recipient vehicle responds with
an acknowledgment message (ACK) and, then, the transmitter vehicle can start the data
transmission.
The Risk-Aware MAC (R-MAC) [126] scheme divides each frame into two segments,
namely the RSU segment and the vehicle segment. RSUs broadcast control messages using the
RSU segment, while the vehicle segment is further divided into two sub-segments, namely the
CSMA/CA sub-segment and the TDMA sub-segment. The CSMA/CA sub-segment is used for
20 Resource Allocation - Scheduling
warning messages transmission (e.g. in case of an accident) while the TDMA sub-segment is
used for non-safety data transmission.
It should also be noted that in some hybrid mechanisms, the TDMA or CSMA/CA are com-
bined with the Space Division Multiple Access (SDMA) that considers the geographic position
of each vehicle. For example, the CSMA-based Self-Organizing TDMA (CS-TDMA) [127]
combines TDMA, CSMA/CA and SDMA to support both safety and non-safety applications. A
CCH channel is used for the data transmissions of the safety applications, while a SCH channel
is used for the non-safety applications. The ratio between the CCH and SCH lengths is adjusted
taking into consideration the vehicle density in each location. If the vehicles density is high,
the CCH length is increased and the SCH length is decreased in order to guarantee a maximum
delay for safety applications. On the contrary, if the vehicles density is low, the CCH length is
decreased and the SCH length is increased in order to improve the throughput for non-safety
applications.
Finally, in the OFDMA-based MAC scheme for VANETs (OBV) [128] the CSMA/CA is
combined with the OFDMA mechanism. During a resource negotiation phase, vehicles allocate
resources using CSMA/CA. Thereafter, the data transmissions are performed using OFDMA,
while at the same time the vehicles are synchronized using their GPS receivers in order to
guarantee the orthogonality between the OFDMA subcarriers.
2.1.4 Discussion on MAC Schemes for 5G-VCC Systems
Although most of the available MAC schemes have been designed for vehicular systems and
not necessarily for 5G-VCC systems, they could be easily applied to the vehicular part of a
5G-VCC architecture. The study of these schemes reveals the fact that various approaches have
been proposed to the literature.
As mentioned in the previous sections, a main factor of the discussed schemes is the
underlying multiple access protocol. The most common multiple access protocols used include
TDMA and CSMA/CA. Additionally, some schemes apply hybrid solutions by combining
more than one multiple access protocols. These schemes combine FDMA with TDMA (e.g.
ACFM and CBRC-MAC), CSMA/CA with TDMA (e.g. HER-MAC and R-MAC), OFDMA
with CSMA/CA (e.g. OBV) and so on. Furthermore, some schemes organize the vehicles into
clusters (e.g. CBRC-MAC, CBT, ETCM, IGPS-MAC, R-MAC and TC-MAC), while the rest
do not consider clusters of vehicles. In general, clustering could be considered as a useful
methodology which offers an improved use of the available spectrum. A positioning system
is also required in some cases in order to monitor the vehicles positions. The existence of a
positioning system enables the vehicles to be synchronized in time with each other using their
GPS receivers.
2.2 Overview of Downlink Packet Schedulers 21
Another important factor is the control type applied in each scheme. Some schemes apply
distributed control, while other schemes apply centralized control. Although the distributed con-
trol distributes the resource manipulation workload, the centralized control could be considered
as more appropriate in some cases, since it simplifies the manipulation of the communication
resources. In 5G-VCC architectures where a centralized Software Defined Network (SDN)
[129] controller supervises the manipulation of the entire system, centralized MAC schemes
could be easily configured considering the complete view of the system’s resources. Distributed
schemes could also be configured in 5G-VCC systems considering the operating principles of
Fog computing [130].
Cognitive Radio Networking (CRN) [74] is another factor that is proposed in 5G-VCC
systems to organize the vehicles into two groups, namely the Primary and the Secondary
vehicles. Primary vehicles obtain immediate access to network resources as determined in
their Service Level Agreements (SLAs) [131]. However, sometimes Primary vehicles do not
need the entire network resources provided according to their SLAs. In such cases, Secondary
vehicles could use the free network resources, which are also called White Spaces. Furthermore,
whenever a Primary vehicle requires the resources defined in its SLA, it immediately reserves
them, while the Secondary vehicles should obtain access to other free network resources.
Considering the CRN operating principles, some MAC schemes (e.g. MQOG) take advantage
of the free white spaces into the available spectrum in order to serve more vehicles. Finally, the
communication type (V2V or V2I) that each scheme supports is considered. Table 4.2 presents
the characteristics of the discussed MAC schemes considering the aforementioned factors.
2.2 Overview of Downlink Packet Schedulers
Several downlink packet schedulers have been proposed in the literature. They can be classified
into two groups, namely non-QoS and QoS aware, respectively. A non-QoS aware scheduler
does not take into account parameters that affect the service quality, while a QoS aware
distributes resources considering the specific constraints of each service. This section makes a
brief overview of the available scheduling strategies for LTE systems, since LTE is considered
as one of the most important network access technologies for the 5G architectures.
2.2.1 Non-QoS Aware Schedulers
In [132] the non-QoS aware schedulers Maximum Throughput (MT), Proportional Fair (PF)
and Throughput to Average (TTA) are evaluated in terms of the throughput and the fairness
index. The MT scheduler aims at the maximization of the overall system throughput and
22 Resource Allocation - Scheduling
Table 2.1 The Characteristics of the discussed MAC Schemes.
MAC Scheme
Multiple
Access
Cluster
based
Positioning
System
Required
Centralized
/Distributed
control
CRN
Support
Communication
ACFM [123]
FDMA,
TDMA
No No Centralized No V2I
ATSA [105] TDMA No No Distributed No V2V
CAH-MAC [114] TDMA No Yes Distributed No V2V
CA-MAC [118] CSMA/CA No No Distributed No V2V, V2I
CBRC-MAC [124]
FDMA,
TDMA
Yes No Centralized No V2I
CBT [106] TDMA Yes Yes Centralized No V2V
CESFRA [107] TDMA No Yes Distributed No V2V
CFR-MAC [108] TDMA No Yes Distributed No V2V
CS-TDMA [127]
CSMA/CA,
SDMA,
TDMA
No Yes Distributed No V2V
ETCM [111] TDMA Yes Yes Centralized No V2V
HER-MAC [125]
CSMA/CA,
TDMA
No Yes Distributed No V2V
IGPS-MAC [115] TDMA Yes Yes Centralized No V2V
MMAC-CL [120] CSMA/CA No Optional Distributed No V2V, V2I
MQOG [121] CSMA/CA No No Distributed Yes V2V, V2I
OBV [128]
CSMA/CA,
OFDMA
No Yes Distributed No V2V, V2I
PTMAC [112] TDMA No Yes Distributed No V2V
QL-MAC [122] CSMA/CA No Yes Distributed No V2V
R-MAC [126]
CSMA/CA,
TDMA
Yes Yes Centralized No V2V, V2I
STDMA [116] TDMA No Yes Distributed No V2V
TC-MAC [117] TDMA Yes Yes Centralized No V2V
UTSP [113] TDMA No Yes Centralized No V2I
VeMAC [109] TDMA No Yes Distributed No V2V
e-VeMAC [110] TDMA No Yes Distributed No V2V
allocates resources using the metric calculated by formula 2.1, where di
k(t) represents the
available throughput in the kth RB of the ith Transmission Time Interval (TTI). The PF aims at
fair distribution of network resources to users. Its metric is estimated using formula 2.2, where
¯Ri(t − 1) denotes the past average throughput. Finally, the TTA metric is calculated using
formula 2.3 where di(t) represents the available throughput in the ith TTI. Simulation results in
[132], [133] showed that the MT achieves higher throughput, the TTA has better performance
in terms of the fairness index while the PF provides satisfactory throughput and fairness.
mMT
i,k = di
k(t) (2.1)
mPF
i,k =
di
k(t)
¯Ri(t −1)
(2.2)
mTTA
i,k =
di
k(t)
di(t)
(2.3)
The Blind Equal Throughput (BET) non-QoS aware scheduler described in [134] distributes
equally the throughput to the users using formula 2.4. The authors of [135] compare the MT,
2.2 Overview of Downlink Packet Schedulers 23
the PF and the BET schedulers using TCP traffic in a vehicular environment. Numerical results
showed that the MT and the PF schedulers achieve similar throughputs, while their performance
is better than the one achieved by the BET algorithm.
mBET
i,k =
1
¯Ri(t −1)
(2.4)
Moreover, the authors of [136] evaluate the performance of video streaming using the MT,
the PF and the Round Robin (RR) which allocates resources sequentially to users. Simulation
results showed that the PF algorithm achieves a higher Mean Opinion Score (MOS) and
throughput for a large number of users, while the MT performs better in terms of the Freezing
Delay Ratio (FDR).
2.2.2 QoS Aware Schedulers
In [137] a QoS aware downlink scheduler is proposed which considers requirements of Guar-
anteed Bit Rate (GBR) and non - Guaranteed Bit Rate (non-GBR) bearers as well as channel
conditions for resource allocation. Scheduling is performed in two phases. At the time domain
(TD) phase a list of GBR and a list of non-GBR users requiring transmission are created and
their priorities are defined. At the frequency domain (FD) phase the allocation of users to RBs
is performed. Evaluation results showed that the suggested scheduler can handle effectively
VoIP, Video, HTTP and FTP traffic.
The authors of [138] propose a scheduling algorithm in wireless networks which uses
a utility function to perform resource allocation for both QoS aware and Best Effort (BE)
traffic. Numerical results showed that the proposed solution satisfies users with various QoS
requirements while it provides fairness to BE users.
The Modified Largest Weighted Delay First (M-LWDF) and the Exponential/PF (EXP/PF)
QoS aware schedulers are described in [139] and [140], respectively. Both algorithms extend
the PF metric by taking into consideration network factors such as delays and packet losses
that affect the service quality. Specifically, the M-LWDF metric is estimated using formula
2.5, while the EXP/PF metric is calculated by formula 2.6. The DHOL,i parameter represents
the head of line delay. Additionally, the αi value is determined by formula 2.7, where δi is
the target packet loss ratio and τi is the delay constraint. Finally, the X value is calculated
by formula 2.8, where Nrt is the number of active real time flows. Numerical results showed
that the M-LWDF scheduler performs better when the network load is low, while the EXP/PF
algorithm gives better results when the load increases.
mM−LWDF
i,k = ai ·DHOL,i ·mPF
i,k (2.5)
24 Resource Allocation - Scheduling
m
EXP/PF
i,k = exp(
ai ·DHOL,i −X
1−
√
X
)·mPF
i,k (2.6)
αi = −
logδi
τi
(2.7)
X =
1
Nrt
·
Nrt
∑
i=1
ai ·DHOL,i (2.8)
The LOG RULE and the EXP RULE schedulers presented in [141] take into account
the head of line packet delay and the channel quality reported by UEs, to support delay
sensitive flows. The LOG RULE metric is estimated using formula 2.9, where Γi
k is the spectral
efficiency for the ith user on the kth subchannel. The EXP RULE metric is estimated using
formula 2.10, where bi and c are configurable parameters. Simulation results showed that
both LOG RULE and EXP RULE could guarantee delay constraints by configuring scheduler
parameters according to the users’ target delays.
mLOGRULE
i,k = bi ·log(c+ai ·DHOL,i)·Γi
k (2.9)
mEXPRULE
i,k = bi ·exp(
ai ·DHOL,i
c+ (1/Nrt)∑j DHOL,j
)·Γi
k (2.10)
The FLS scheduler described in [142] implements a two level QoS aware strategy. The
upper level uses formula 2.11 to estimate the ui(k) quota of data that the ith real time flow must
transmit at the kth frame to satisfy its QoS constraints. In this formula, qi(k) represents the
queue length in the kth frame, Mi the number of coefficients used and ci(n) the nth coefficient
value. Coefficients are used in order to guarantee the required delay constraints for real time
flows. The number Mi of coefficients is estimated using formula 2.12, where τi represents the
target delay. Additionally, the coefficient value ci(n) is determined by formula 2.13. The lower
level uses the PF metric to allocate network resources to real time flows for transmitting their
quota of data, whereas the remaining resources are allocated to best effort flows. Simulation
results showed that the proposed model improves the performance of real time flows compared
to the EXP RULE and LOG RULE schedulers.
ui(k) = qi(k)+
Mi
∑
n=2
[qi ·(k −n+1)
−qi ·(k −n+2)−ui ·(k −n+1)]·ci(n)
(2.11)
τi = (Mi +1)·Tf (2.12)
2.3 The Proposed FLS Advanced (FLSA) Scheduler 25
Best-effort
queue
Real-time queues
YES
ui(t)
Link
Adaptation
CQI
Middle Level (M-LWDF)
Schedule RBs in TTI for ui(t)
data
ds
Upper Level (FLSA)
Compute data to be transmitted ui(t)
ds
Free RBs?
Lower Level (M-LWDF)
Schedule RBs in TTI for:
1. qi-ui(t) data for real time flows
2. Best effort flows
Figure 2.2 The Three-Level Scheduler.
ci(n) =



0 , when n = 0
1 , when n = 1
ci(n−1)/2 , when n ≥ 2
(2.13)
The work described in [133] classifies the LTE downlink schedulers into five categories
namely the channel-unaware, the channel-aware/QOS-unaware, the channel-aware/QoS-aware,
the semi-persistent for VoIP support and finally the energy aware scheduling algorithms.
Simulations that performed for the channel-aware/QoS-aware category showed that the FLS
scheduler outperforms the M-LWDF, the EXP/PF, the EXP RULE and the LOG RULE in terms
of packet losses and packet delays as the number of video flows increases.
2.3 The Proposed FLS Advanced (FLSA) Scheduler
This section describes the proposed FLSA scheduler which aims at the optimization of real
time flows in the LTE downlink. It has been built on three distinct levels as presented in Figure
2.2. The three levels cooperate to dynamically assign radio resources to users in each TTI. The
real time flows receive a higher priority than the best effort ones because of their strict service
constraints.
26 Resource Allocation - Scheduling
2.3.1 The Upper Level of the Scheduler
The upper level of FLSA uses formula 2.11 of FLS to estimate the quota ui(k) of data that
the ith real time flow should transmit in each kth TTI, to satisfy its QoS constraints. In other
words, ui(k) quota is estimated in each kth TTI of a frame, whereas in FLS it is estimated once
at the beginning of each kth frame. Performance improvement has been observed due to the
fact that in FLS, when a real time flow transmits its ui(k) quota of data, it loses the opportunity
to continue the transmission until the beginning of the next frame. By recalculating the formula
2.11 in each TTI (instead of estimating it only at the beginning of each frame), the FLSA
provides more resources to real time flows that have remaining data for transmission.
2.3.2 The Middle Level of the Scheduler
In every TTI, the middle level uses the M-LWDF scheduler to allocate resource blocks (RBs)
to real time flows for transmitting their ui(t) quota of data obtained from the upper level.
Parameters such as the signal to interference plus noise ratio (SINR), the throughput, the head
of line delay, the target delay, the target packet loss ratio and the queue length, are considered
according to formula 2.5. Moreover, the use of the QoS aware M-LWDF scheduler realizes an
improved resource distribution among the real time flows in comparison with the FLS scheduler
which at the second level uses the non-QoS aware PF algorithm.
2.3.3 The Lower Level of the Scheduler
The third level has been added to allocate the remaining RBs of each TTI to both real time
and best effort flows using the M-LWDF algorithm, in a way similar to [143]. The RBs are
allocated to real time flows for transmitting their qi −ui(t) data, where qi denotes the queue
length for the flow i, as well as to best effort flows, considering the fact that the latter have
no specific service constraints. In comparison with the FLS scheduler, which allocates the
remaining RBs only to best effort flows using the PF scheduler, this level of FLSA further
improves the resource distribution in a QoS aware manner.
2.3.4 Performance Evaluation of the FLSA
The performance of the FLSA was evaluated against the PF, M-LWDF, EXP/PF, FLS, EXP-
RULE and LOG-RULE schedulers. For the EXP-RULE metric the used parameter set is
ai ∈ [5/(0.99·τi),10/(0.99·τi)], bi = 1/E[Γi] and c = 1 as proposed in [144] for best perfor-
mance. Table 2.5 summarizes the factors considered by each scheduler for resource allocation,
demonstrating that the FLSA is the most complete strategy, since it considers the entire factors.
2.3 The Proposed FLS Advanced (FLSA) Scheduler 27
Table 2.2 The Parameters considered in each Scheduler in comparison with the ones considered
by the FLSA.
Scheduler SINR Throughput HOL
Delay
Max.
Delay
Max.
PLR
Queue
Length
PF x x
M-LWDF x x x x x
EXP/PF x x x x x
FLS x x x x
FLSA x x x x x x
EXP RULE x x x x
LOG RULE x x x x
Figure 2.3 The Topology Simulated for the Evaluation of the FLSA Scheduler.
In the simulations, an LTE network topology composed of 19 cells is considered. Each cell
contains 1 eNB with 43 dBm transmission power and 10 MHz downlink bandwidth providing
50 RBs available for allocation per TTI. The system sub-frequencies have been distributed to
cells using a reuse factor equal to 2 as presented in Figure 2.3, to avoid interference between
neighbor cells. A full bandwidth periodic Channel Quality Indication (CQI) reporting scheme
is applied and each user equipment (UE) reports its downlink Signal to Interference plus Noise
Ratio (SINR) to eNB, in every TTI. The eNB quantizes the reported SINR value and calculates
the CQI as described in [145], Then, it uses the CQI to guarantee a maximum block error
rate (BLER) less than 10% regardless of the scheduling strategy applied. A number of users,
between the range [10, 40], is moving inside the borders of each eNB according to the random
way-point mobility model. Each user receives two real time flows, including an H264 video
with bitrate equal to 440 kbps and a voice over IP (VoIP) using the G.729 codec. Furthermore,
one best effort flow is added as background traffic. Table 2.6 summarizes the simulation
parameters.
In general, QoS aware schedulers increase the packet loss ratio (PLR) as they try to
maintain the required target delay. This strategy is based on the assumption that real time
services such as VoIP and video have no advantages of receiving expired packets. Thus, since
the delay constraint is satisfied, the algorithms are evaluated in terms of PLR, so as to have a
28 Resource Allocation - Scheduling
Table 2.3 The Simulation Parameters for the Evaluation of the FLSA Scheduler.
Parameter Value
Simulation time 100 seconds
Downlink bandwidth 10 MHz
Modulation QPSK, QAM-16 and QAM-64
Number of cells 19
Cell radius 0.5 km
Number of users up to 40 users per cell
Users mobility Random way point
Traffic models
Real time traffics:
H264 video at 440 kbps,
VoIP using G.729 codec
Best effort traffic: Web
Figure 2.4 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio using Different
Target Delays.
comprehensive view about the performance improvements. Figures 2.4 and 2.5 illustrate the
impact of the target delay parameter in the PLR for VoIP and video flows, respectively, for the
case of having 20 users per cell. While the target delay increases from 50ms to 150ms, the PLR
decreases. Additionally, it may be observed that FLSA compared with FLS exhibits a lower
PLR by up to 7%.
In Figures 2.6 and 2.7, the PLR for the VOIP and video flows is presented as the number of
cell users varies from 10 to 40. The considered target delays are set to 100ms and 150ms for
VoIP and video flows respectively, as determined by the LTE QoS class specifications for these
service types [146]. As shown, FLSA results in a lower PLR than the rest of the algorithms.
FLSA shows a marginal decrease of its PLR compared to FLS for VoIP flows. Also, its PLR is
10% lower than that of FLS for video flows.
The analysis of the throughput provides an important insight on the performance of the
FLSA in comparison with the other schedulers. As presented in Figures 2.8 and 2.9 the FLSA
outperforms the rest of the schedulers, independently of the number of users for VoIP and video
2.3 The Proposed FLS Advanced (FLSA) Scheduler 29
Figure 2.5 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio using
Different Target Delays.
Figure 2.6 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio.
Figure 2.7 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio.
30 Resource Allocation - Scheduling
Figure 2.8 Evaluation of the FLSA Scheduler in terms of VoIP Throughput.
Figure 2.9 Evaluation of the FLSA Scheduler in terms of Video Throughput.
flows, respectively. This is expected due to the recalculation of formula 2.11 in each TTI by the
upper level of FLSA as well as the inclusion of the lower level in the scheduler. The FLSA
achieves higher throughputs than the rest of the algorithms providing rates of up to 330kbps for
VoIP and up to 4.7 Mbps for video services.
The proposed scheduler is also evaluated in terms of the Jain fairness index, which is
estimated using formula 2.14 where n is the number of the service flows and xi is the throughput
of the ith flow.
Jain_Fairness =
(∑n
i=1 xi)2
n·∑n
i=1 x2
i
(2.14)
Flows with the same service constraints must receive similar QoS to avoid the situation of
having a set of satisfied users against a set of dissatisfied ones of the same service type. The
maximum value of fairness is 1 while the more a scheduler accomplishes a value close to 1, the
more the resource allocation is fair. As presented in Figure 2.10 the fairness for VoIP flows is
2.3 The Proposed FLS Advanced (FLSA) Scheduler 31
Figure 2.10 Evaluation of the FLSA Scheduler in terms of VoIP Fairness Index.
Figure 2.11 Evaluation of the FLSA Scheduler in terms of Video Fairness Index.
very close to 1. Additionally, Figure 2.11 demonstrates that the FLSA scheduler improves the
fairness for the video flows compared with the rest of the schedulers.
32 Resource Allocation - Scheduling
2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-
CC) Scheduler
This section describes the proposed FLSA-CC scheduler (Fig. 2.12) which aims at the opti-
mization of system performance using carrier aggregation in the LTE downlink. The FLSA-CC
improves the FLSA scheduler in a cross carrier manner adapting the resource allocation process
at different channel conditions of the aggregated component carriers. Furthermore, due to the
fact that in the Cross Carrier Scheduling (CCS) methodology adopted by this scheduler, only
the PCC uses the PDCCH channel for transmission of scheduling information, an interference
decrement is observed resulting in better channel conditions in terms of SINR, thus increasing
the overall system capacity. The FLSA-CC has been built upon three distinct levels, which
cooperate with each other for dynamically assigning radio resources to users in each TTI.
The upper level of FLSA-CC uses the formula (2.11) of the FLS [142] to estimate the ui(x)
quota of data that the ith real time flow should transmit in each xth TTI, in order to satisfy its
QoS constraints. In other words, ui(x) quota is estimated in each xth TTI of a frame, whereas
in FLS it is estimated once, at the beginning of each frame. The FLSA-CC estimates the
coefficient value ci(n) using formula (2.15), where N represents the number of component
carriers. A performance improvement has been observed due to the fact that in FLS, when a real
time flow transmits its ui(x) quota of data, it loses the opportunity to continue the transmission
until the beginning of the next frame. By recalculating the formula (2.11) in each TTI (instead
of estimating it only at the beginning of each frame), the FLSA-CC provides more resources to
real time flows that have remaining data for transmission.
ci(n) =



n , when 0 ≤ n ≤ 1
ci(n−1)/(2·N) , when n ≥ 2
(2.15)
In each TTI, the middle level uses a cross carrier version of the MLWDF scheduler, called
MLWDF-CC, to allocate RBs to real time flows for transmitting their ui(x) quota of data which
have been calculated by the upper level. This scheduler extends the PF-CC metric [147] [148]
mPF−CC
i,k given in formula (2.16). The MLWDF-CC metric is evaluated by formula (2.17)
where the αi value is determined by formula (2.7). The use of the cross carrier QoS aware
MLWDF-CC scheduler achieves an improved resource distribution among the real time flows
in comparison with the FLS scheduler which at the second level uses the non-cross carrier
principle as well as the non-QoS aware PF algorithm.
The third level has been added to allocate the remaining RBs of each TTI to best effort
flows using formula (2.16) of the PF-CC algorithm.
mPF−CC
i,k =
di
k(t)
∑N
j=1
¯Ri,j(t −1)
(2.16)
2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler 33
Figure 2.12 The FLSA-CC Scheduler Design.
mMLWDF−CC
i,k = ai ·DHOL,i ·mPF−CC
i,k (2.17)
2.4.1 Simulation Environment for the FLSA-CC Evaluation
The simulation environment is implemented using an extended version of the Lte-Sim [145]
simulator. More specifically, the iCanCloud [149] and the OpenFlow [150] modules of the
Omnet++ [151] simulator have been configured and embedded to the Lte-Sim enabling the
ability to include a cloud infrastructure and SDN controllers to the simulated LTE topologies.
The simulation environment consists of an LTE Evolved UMTS Terrestrial Radio Access
Network (E-UTRAN) and a Cloud infrastructure. The E-UTRAN includes 7 DeNBs and 28
RNs (4 per DeNB). The transmission radius is equal to 1 kilometer for each DeNB and 100
meters for each RN. Each RN is positioned at 90% of the transmission radius of its DeNB.
Furthermore, Type-1 Outband Relaying is applied and thus two link types are defined, namely
the access link and the backhaul link. The access link is used for communication between a UE
and an RN or a DeNB using a frequency f1, while the backhaul link is used for communication
between an RN and a DeNB using a frequency f2 ̸= f1.
Inter-band Carrier Aggregation (CA) is applied in each DeNB and RN. According to this
CA configuration, two component carriers, which belong to different frequency bands, are
aggregated. Each component carrier bandwidth is equal to 20MHz and contains 100 resource
blocks. Thus, a 40MHz bandwidth is assigned to each cell (RN or DeNB) and a total of 200
RBs are available for scheduling in each TTI. Table 2.4 presents the system sub-frequencies
assigned to each cell.
34 Resource Allocation - Scheduling
Table 2.4 The Sub-Frequencies that are assigned to each Cell.
Cell Aggregated Component Carriers
DeNB0
PCC: 1805 MHz − 1825 MHz (band 3)
SCC: 760 MHz − 780 MHz (band 28)
DeNB1,3,5
PCC: 1825 MHz − 1845 MHz (band 3)
SCC: 870 MHz − 890 MHz (band 5)
DeNB2,4,6
PCC: 2110 MHz − 2130 MHz (band 1)
SCC: 940 MHz − 960 MHz (band 8)
Relay nodes
Case 1
PCC: 2620 MHz − 2640 MHz (band 7)
SCC: 780 MHz − 800 MHz (band 28)
Case 2
PCC: 2640 MHz − 2660 MHz (band 7)
SCC: 800 MHz − 820 MHz (band 20)
The 3GPP urban channel model [152] [153] is used. Since the channel between DeNB or
RN and UE encounters non-line-of-sight (NLOS) transmission, its propagation loss is estimated
using formula (2.18) and (2.19), for DeNB-UE and RN-UE communication respectively, where
d represents the distance among the nodes and fc the carrier frequency. Also, since the channel
between a DeNB and an RN encounters line-of-sight (LOS) transmission, its propagation loss
is estimated using formula (2.20).
PLNLOS
DeNB→UE = 37.6·log10(d)+58.94+21·log10(fc) (2.18)
PLNLOS
RN→UE = 36.7·log10(d)+22.7+26·log10(fc) (2.19)
PLLOS
DeNB→RN = 22·log10(d)+28+20·log10(fc) (2.20)
The Cloud contains a set of virtual machines (VMs) and implements the functionalities
of the LTE Evolved Packet Core (EPC). Additional VMs with user applications are created.
Specifically, one VM is created for each UE running three applications namely one VoIP, one
video and one best effort.
Flow forwarding as well as resource scheduling in each DeNB and RN are performed using
a centralized global controller placed into the Service Gateway (SGW) having a wide view of
the entire system. The simulated topology is presented in Figure 2.13.
2.4.2 Performance Evaluation of the FLSA-CC Algorithm
The performance of the FLSA-CC was evaluated against the PF, MLWDF, EXP/PF, FLS,
FLSA, EXP-RULE and LOG-RULE schedulers. For the EXP-RULE metric the used parameter
set is ai ∈ [5/(0.99 · τi),10/(0.99 · τi)], bi = 1/E[Γi] and c = 1 as proposed in [144] for best
performance. Table 2.5 summarizes the factors considered by each scheduler for resource
allocation, demonstrating that the FLSA-CC is the most complete strategy. Furthermore, the full
band periodic Channel Quality Indication (CQI) reporting scheme is applied. Thus, each UE
reports its downlink SINR to RN for each component carrier in every TTI. The RN quantizes
2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler 35
Figure 2.13 The Topology Simulated for the Evaluation of the FLSA-CC Scheduler.
the reported SINR value and calculates the CQI as described in [145]. Then, it uses the CQI to
guarantee a maximum BLER less than 10% regardless of the scheduling strategy applied.
Table 2.5 The Parameters considered in each Scheduler in comparison with the ones considered
by the FLSA-CC.
Scheduler SINR Throughput
HOL
Delay
Max.
Delay
Max.
PLR
Queue
Length
CCS
PF
MLWDF
EXP/PF
FLS
FLSA
FLSA-CC
EXP
RULE
LOG
RULE
A number of users move inside the borders of each RN according to the random way-point
mobility model. Each user receives two real time flows, an H264 video with bitrate equal to
440 kbps and a Voice over IP (VoIP) using the G.729 codec. Furthermore, one best effort flow
is added as background traffic. Table 2.6 summarizes the simulation parameters.
2.4.2.1 Real Time Services Results
Due to the fact that the simulation environment includes an LTE topology with RNs, a two hop
target delay for real time flows τi = τi,DeNB→RN +τi,RN→UE is considered, where τi,DeNB→RN
36 Resource Allocation - Scheduling
Table 2.6 The Simulation Parameters for the Evaluation of the Proposed Algorithm.
Parameter Value
Simulation time 100 seconds
Downlink bandwidth 2*20 = 40 MHz
Modulation QPSK, QAM-16 and QAM-64
DeNBs number / radius 7 / 1 km
Relay nodes number / radius 4 per DeNB / 100 m
Number of users up to 100 users per relay node
Users mobility Random way point
Traffic models
Real time:
H264 video at 440 kbps
VoIP using G.729 codec
Best effort: Web
Figure 2.14 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the Real
Time Flows using Different Target Delays.
represents the target delay between a DeNB and an RN, and τi,RN→UE represents the target
delay between an RN and a UE. We consider τi,DeNB→RN = τi,RN→UE. In general, QoS aware
schedulers increase the packet loss ratio (PLR) to guarantee the required τi. This strategy is
based on the assumption that real time services such as VoIP and Video can not use expired
packets. Thus, since the delay constraint is satisfied, the algorithms are evaluated in terms of
PLR, so as to have a comprehensive view about the performance improvements. Figure 2.14
illustrates the impact of the target delay parameter τi in the PLR for VoIP and video flows, for
the case of having 100 users per RN. As the target delay increases from 50ms to 150ms, the
PLR decreases. Additionally it may be observed that FLSA-CC compared with FLSA exhibits
lower PLR independently of the target delay parameter.
In Figure 2.15, the PLR for VOIP and video flows is presented while the number of
cell RN users varies from 20 to 100. In this case, the considered target delays are set to
100ms and 150ms for VoIP and video flows respectively, as determined by the LTE QoS class
specifications for these service types. As shown, FLSA-CC results in a lower PLR than the rest
2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler 37
Figure 2.15 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the Real
Time Flows.
Figure 2.16 The FLSA-CC Scheduler Evaluation in terms of the Throughput of the Real Time
Flows.
of the algorithms. Specifically, FLSA shows a marginal decrease of its PLR for VoIP flows as
well as up to a 3% lower PLR for video flows compared to FLSA.
The analysis of the throughput offered to real time services provides an important insight
on the performance of the FLSA-CC in comparison with the other schedulers. As presented in
Figure 2.16 the FLSA-CC outperforms the rest of the schedulers, independently of the number
of users for VoIP and video flows. This is expected due to the cross carrier scheduling operating
principle applied as well as due to the recalculation of formula (2.11) in each TTI by the upper
level of the FLSA-CC. More specifically, the FLSA-CC achieves higher throughputs than the
rest of the algorithms providing rates of up to 800kbps for VoIP and up to 28Mbps for video
services.
The proposed scheduler is also evaluated in terms of Jain fairness index, which is estimated
using formula 2.14. Figure 2.17 demonstrates that the FLSA-CC scheduler improves the
fairness for both VoIP and video flows.
38 Resource Allocation - Scheduling
Figure 2.17 The FLSA-CC Scheduler Evaluation in terms of the Fairness Index of the Real
Time Flows.
2.4.2.2 Best Effort Services Results
In this subsection tne FLSA-CC, FLSA and FLS schedulers, which accomplish better per-
formance for real time services are evaluated for best effort flows in terms of the throughput
and the fairness index. As presented in Figure 2.18, the FLSA-CC outperforms the other two
schedulers and provides a throughput up to 1.5Mbps for best effort flows even when the number
of users increases, while the FLSA accomplishes only a 100kbps throughput. Additionally, the
FLSA-CC scheduler significantly improves the fairness index of the best effort flows.
Figure 2.18 The FLSA-CC Scheduler Evaluation in terms of the Throughput and the Fairness
Index of the Best Effort Flows.
Chapter 3
Mobility Management
3.1 Related Methodologies
3.1.1 Fuzzy Logic
3.1.1.1 The Interval-Valued Trapezoidal Fuzzy Numbers (IVTFN)
The concept of fuzzy logic was introduced by Zadeh [154] and is used to make a decision from
indeterminate and approximate information. A fuzzy number is represented by a set of real
values representing an uncertain quantity and a convex normalized continuous function which
estimates the degree of membership for each value in the subset. Triangular or trapezoidal
fuzzy numbers are frequently used to represent uncertain information. A trapezoidal fuzzy
number can be defined as a vector x = (x1,x2,x3,x4,v ˆA) with a membership function µ(x):
µ(x) =



x−x1
x2−x1
, if x1 ≤ x < x2;
v ˆA, if x2 ≤ x ≤ x3;
x−x4
x3−x4
, if x3 < x ≤ x4;
0, otherwise.
(3.1)
where x1 < x2 < x3 < x4 and v ˆA ∈ [0,1].
An Interval-valued fuzzy number (IVFN) was introduced by Sambuc [155]. An IVFN is
defined as A = [AL,AU] consisting of the lower AL and the upper AU fuzzy numbers. IVFNs
replace the crisp membership values by intervals in [0,1]. They were proposed due to the fact
that fuzzy information can be better expressed by intervals than by single values. Liu and
Jin [156] and Cornelis et al. [157] suggest that IVFNs are useful in multiple criteria decision
making (MCDM) problems and particularly in cases where attribute values are in the form
of linguistic expressions. Therefore, Ashtiani et al. [158] propose an extension of the fuzzy
TOPSIS method using interval-valued triangular fuzzy numbers. Moreover, Liu and Jin [156]
propose a decision making method using weighted geometric aggregation operators on attribute
values expressed in the form of interval-valued trapezoidal fuzzy numbers. According to the
40 Mobility Management
definition in [158], an IVFS A is defined as follows:
A = {(x,[µL
A(x),µU
A (x)])} (3.2)
µL
A(x),µU
A (x) : X → [0,1]∀x ∈ X,µL
A(x) < µU
A (x) (3.3)
ˆµA(x) = [µL
A(x),µU
A (x)] (3.4)
A = {(x, ˆµA(x))},x ∈ (−∞,∞) (3.5)
In particular, the interval-valued trapezoidal fuzzy number defined in [159], is a general
form of fuzzy number (Figure 3.1). This number can be represented as: A = [AL,AU] =
[(xL
1,xL
2,xL
3,xL
4,vAL),(xU
1 ,xU
2 ,xU
3 ,xU
4 ,vAU ))] where: 0 ≤ xL
1 ≤ xL
2 ≤ xL
3 ≤ xL
4 ≤ 1, 0 ≤ xU
1 ≤ xU
2 ≤
xU
3 ≤ xU
4 ≤ 1, 0 ≤ vAL ≤ vAU ≤ 1 and AL ⊂ AU. The operational rules of the interval-valued
trapezoidal fuzzy numbers are defined in [159].
Figure 3.1 The Interval-Valued Trapezoidal Fuzzy Numbers.
3.1.1.2 The Interval-Valued Pentagonal Fuzzy Numbers (IVPFN)
A pentagonal fuzzy number can be defined as a vector x = (x1,x2,x3,x4,x5,v ˆA,v ˆA1,v ˆA2) with
membership function:
µ(x) =



v ˆA1 · x−x1
x2−x1
, if x1 x < x2;
v ˆA −(v ˆA −v ˆA1)· x−x2
x3−x2
, if x2 x < x3;
v ˆA, if x = x3;
v ˆA −(v ˆA −v ˆA2)· x−x3
x4−x3
, if x3 < x x4;
v ˆA2 · x−x5
x4−x5
, if x4 < x x5;
0, otherwise.
(3.6)
where x1 x2 x3 x4 x5 and v ˆA,v ˆA1,v ˆA2 ∈ [0,1].
3.1 Related Methodologies 41
The interval-valued pentagonal fuzzy number is a general IVFN case (Figure 3.2) defined
as: A = [AL,AU] = [(xL
1,xL
2,xL
3,xL
4,xL
5,vL
A,vL
A1,vL
A2),(xU
1 ,xU
2 ,xU
3 ,xU
4 ,xU
5 ,vU
A ,
vU
A1,vU
A2))] where: AL ⊂ AU, 0 xL
1 xL
2 xL
3 xL
4 xL
5 1, 0 xU
1 xU
2 xU
3 xU
4 xU
5 1,
vL
A vU
A , vL
A1 vL
A2 vL
A, vU
A1 vU
A2 vU
A and vL
A,vL
A1,vL
A2,vU
A ,vU
A1,vU
A2 ∈ [0,1]. The operational
rules of the interval-valued pentagonal fuzzy numbers are defined in [160].
U
x1
L
x2
U
x2
L
x3
L
x3
U
x4
L
x4
U
x1
U
AL
AU
0
1
1x5
L
x5
U
1
1
2
2
uL
A
uL
A uL
A
uA
UuA
UuA
,
,
Figure 3.2 The Interval-Valued Pentagonal Fuzzy Numbers.
3.1.1.3 Creating Fuzzy Numbers: The Equalized Universe Method (EUM)
The Equalized Universe Method (EUM) [161] [162] creates IVFNs with their centroids equally
spaced along a predefined domain of values. The values of the ith IVPFN are calculated using
formula 3.7, where Umin and Umax are the minimum and maximum value of the domain and c
represents the number of the IVPFNs created. The vL
A1, vU
A1, vL
A2 and vU
A2 are defined by the user.
IVPFNi =



xU
i,1 = xU
i,2 − Umax−Umin
4·(c−1) ,xL
i,1 = xU
i,1 ·(vL
A1/vU
A1)
xU
i,2 = xU
i,3 − Umax−Umin
2·(c−1) ,xL
i,2 = xU
i,2 ·(vL
A1/vU
A1)
xU,L
i,3 = Umin + Umax−Umin
c−1 ·(i−1)
xU
i,4 = xU
i,3 + Umax−Umin
2·(c−1) ,xL
i,4 = xU
i,4 ·(vL
A2/vU
A2)
xU
i,5 = xU
i,4 + Umax−Umin
4·(c−1) ,xL
i,5 = xU
i,5 ·(vL
A2/vU
A2)
(3.7)
3.1.1.4 The Mamdani Pentagonal Fuzzy Inference System (MPFIS)
Fuzzy Inference (FI) [163–165] involves the mapping of a given input to an output using fuzzy
logic. The Mamdani Pentagonal Fuzzy Inference System (MPFIS) considers two inputs (Input1
and Input2) to estimate the value of the Output. Both Input1 and Input2 have normalized values
within the range [0, 1]. Also, the MFInput1, MFInput2, MFOutput membership functions (MF) are
defined, indicating the linguistic terms and the corresponding Interval Valued Pentagonal Fuzzy
Numbers (IVPFN) for the fuzzy representation of the Input1, Input2 and Output, respectively.
42 Mobility Management
Thus, for each crisp value, two membership degrees are determined in the corresponding
MF, one for the upper pentagon and one for the lower pentagon. The MPFIS implements the
following methods:
Step 1. Membership Functions Definition: The Membership Functions (MF) for Input1, Input2
and Output parameters are defined.
Step 2. Fuzzy rule (or knowledge) base: A set R of fuzzy rules is defined, where each rule r ∈ R
is a simple if-then statement with a condition and a conclusion. The rule’s condition
consists of MFInput1 and MFInput2 membership functions, while its conclusion indicates
an MFOutput membership function.
Step 3. Fuzzification: The Input1 and Input2 crisp values are converted to degrees of member-
ship indicated as Input′
1 and Input′
2 by a lookup in MFInput1 and MFInput2 membership
functions respectively.
Step 4. Combination of the fuzzified inputs (Fuzzy Operations): A Z′
r degree is calculated
considering the rule’s condition, that indicates the strength of the r rule. Furthermore,
in case that a rule’s condition has multiple parts, the fuzzy operators ‘AND’ and ‘OR’
may be used to combine more than one conditions. The ‘Algebraic product’ and the
‘Algebraic sum’ are applied for the ‘AND’ and the ‘OR’ operators respectively. In our
study, the ‘Algebraic product’ is calculated using formula 3.8, while the ‘Algebraic sum’
is calculated using formula 3.9.
Z′
u,i,r = Input′
1ˆ·Input′
2 = Input′
1 ·Input′
2 (3.8)
Z′
u,i,r = (Input′
1 +Input′
2)−(Input′
1 ·Input′
2) (3.9)
Step 5. Implication method: The implication method estimates the consequence MFOutputc
r
of
the rule conclusion, considering both the rule conclusion MFOutputr and the rule strength
Z′
r. The MFOutputr height is trimmed with respect to the Z′
r degree, using formula 3.10,
which applies the Min method.
MFOutputc
rHeight
= min{MFOutputrHeight
,Z′
r} (3.10)
Step 6. Aggregation method: The aggregation method combines the R rules’ consequences to
calculate the OutputA fuzzy set, using formula 3.11, which applies the Max method.
OutputA
= MFOutputc
1
∪MFOutputc
2
∪...∪MFOutputc
R
(3.11)
3.1 Related Methodologies 43
Step 7. Defuzzification: During the defuzzification, the OutputA fuzzy set is transformed to the
crisp value Output. Formula 3.31 that applies the Weighted Average method is used,
where µr is the height and hr is the centroid of each rule obtained from the OutputA. Also,
symbols U and L represent the upper and the lower pentagon of each rule respectively .
Output =
R
∑
r=1
(µU
r ·hU
r + µL
r ·hL
r )
R
∑
r=1
(hU
r +hL
r )
(3.12)
3.1.2 Estimating the Mobility Management Criteria Importance
3.1.2.1 The Analytic Network Process (ANP)
The Analytic Network Process (ANP) was introduced by Saaty [166] to deal with decision
problems with criteria and alternatives that depend on each other. ANP is a generalization
of the Analytic Hierarchy Process (AHP). A decision problem that is analyzed with the ANP
can be designed either as a control-hierarchy or as a non-hierarchical network. The nodes of
the network represent the components (or clusters) of the system while the arcs denote the
interactions between them. All the interactions and the feedbacks within the clusters are called
inner dependencies, while the interactions and the feedbacks between clusters are called outer
dependencies. ANP is composed of four major steps [167]:
Step 1. Model construction and problem structuring: During this step the problem is analyzed
and decomposed into a rational system, like a network.
Step 2. Pairwise comparison matrices and priority vectors: During this step, the pairwise
comparison matrix is derived using Saaty’s nine-point importance scale based (Table
3.1).
Table 3.1 The Saaty’s Nine-Point Importance Scale.
Importance Definition
1 Equal Importance
3 Moderate Importance
5 Strong Importance
7 Very Strong Importance
9 Extreme Importance
2, 4, 6, 8 Intermediate Values
Step 3. Supermatrix formation: During this step, the supermatrix of the ANP model is con-
structed to represent the inner and the outer dependencies of the network. This is a
44 Mobility Management
partitioned matrix, where each matrix segment represents a relationship between two
clusters in the network. To construct the supermatrix the local priority vectors obtained
in Step 2 are grouped and placed in the appropriate positions in a supermatrix based on
the flow of influence from one cluster to another, or from a cluster to itself, as in the
loop. Then, the supermatrix is transformed to a stochastic one, the weighted superma-
trix. Finally, the weighted supermatrix is raised to limiting powers until all the entries
converge to calculate the overall priorities, and thus the cumulative influence of each
element on every other element with which it interacts is obtained [168]. At this point,
all the columns of the new matrix, the limit supermatrix, are the same and their values
show the global priority of each element of the network.
For example, if we assume a network with n clusters, where each cluster Ck,k =
1,2,...,n, and has mn elements, denoted as ek1,ek2,...,ekmk
, then the standard form, W,
for a supermatrix can be expressed as:
W =
C1 ... Ck ... Cn
e11 ...e1m1 ... ek1 ...ekmk
... en1 ...enmn




















































e11
C1
... W11 ... W1k ... W1n
e1m1
...
...
...
...
...
...
ek1
Ck
... Wk1 ... Wkk ... Wkn
ekmk
...
...
...
...
...
...
en1
Cn
... Wn1 ... Wnk ... Wnn
enmn
(3.13)
Step 4. Selection of the best alternatives: If the supermatrix formed in Step 3 covers the whole
network, then the priority weights of the alternatives can be found in the column of
the alternatives in the normalized supermatrix. Otherwise, additional calculations are
required in order to obtain the overall priorities of the alternatives. The alternative with
the largest overall priority should be selected, as it is the best alternative as determined
by the calculations made using matrix operations.
3.1 Related Methodologies 45
3.1.3 The Trapezoidal Fuzzy Analytic Network Process (TF-ANP)
A decision problem that is analyzed with the TF-ANP can be represented as a network of nodes.
Each node represents a component (or cluster) of the system while arcs denote interactions
between them. Interactions and feedbacks within clusters are called inner dependencies, while
interactions and feedbacks between clusters are called outer dependencies. The TF-ANP is
composed of five major steps:
Step 1. Model Construction and Problem Structuring: During this step the problem is analyzed
and decomposed into a rational system, consisting of a network of nodes.
Step 2. Pairwise comparison matrices and priority vectors: In this step, initially the fuzzy
pairwise comparison matrix ˜A is derived for each TF-ANP cluster using the linguistic
terms presented in Table 3.2, which corresponds to the nine-point importance scale
introduced in [166]. The standard form of the ˜A matrix is expressed as follows:
˜A =


















1 ... ˜a1 j ... ˜a1n
...
...
...
1/ ˜a1i ... 1 ... ˜ain
...
...
...
1/ ˜a1n ... 1/ ˜ajn ... 1
(3.14)
where n denotes the number of the cluster elements. Subsequently, the geometric mean
r ˜Ai
of each row i in ˜A is estimated according to formula 3.34, where ⊗ denotes the
multiplication operator of two fuzzy numbers as defined in [169].
r ˜Ai
= ( ˜ai1 ⊗ ˜ai2 ⊗...⊗ ˜ain)
1
n (3.15)
Then, the priority vector ˜Ωi of cluster elements is constructed as follows:
˜Ωi = [ ˜ω1 ˜ω2 ... ˜ωn ] (3.16)
where each ˜ωi = (ωU
1 ,ωU
2 ,ωU
3 ,ωU
4 ,vU
i );(ωL
1 ,ωL
2 ,ωL
3 ,ωL
4 ,vL
i ) is calculated using for-
mula 3.36. The ⊕ indicates the addition operator of two fuzzy numbers as defined in
[169].
˜ωi = r ˜Ai
/(r ˜A1
⊕r ˜A2
⊕...⊕r ˜Ai
⊕...⊕r ˜An
) (3.17)
Step 3. Construction of the Supermatrix: In this step, the fuzzy supermatrix ˜W of the TF-ANP
model is constructed. This matrix represents the inner and outer dependencies of the
TF-ANP network. It is a partitioned matrix, with each matrix segment representing the
relationship between two clusters of the network. To construct the supermatrix, the local
priority vectors ˜Ω are grouped and placed in the appropriate positions in the supermatrix
46 Mobility Management
based on the flow of influence from one cluster to another, or from a cluster to itself,
as in the loop. For example, if we assume a TF-ANP network of q clusters, Ck with
k = [1,2,...,q] and that each cluster has nq elements, denoted as ek1,ek2,...,eknk
, then
the supermatrix ˜W is expressed as:
˜W =
C1 ... Ck ... Cq
e11...e1n1 ... ek1...eknk
... eq1...eqnq




















































e11
C1
... ˜W11 ... ˜W1 j ... ˜W1q
e1n1
...
...
...
...
...
...
ek1
Ck
... ˜Wk1 ... ˜Wk j ... ˜Wkq
eknk
...
...
...
...
...
...
eq1
Cq
... ˜Wq1 ... ˜Wqj ... ˜Wqq
eqnq
(3.18)
Step 4. Construction of the Weighted Supermatrix: During this step, the supermatrix is trans-
formed to a stochastic one,the Weighted Supermatrix ˜W′ using formula 3.19.
˜W′
k,j = ˜Wk,j/q (3.19)
Step 5. Calculation of the Limited Supermatrix: In this step, initially the deffuzified Weighted
Supermatrix W is estimated using the Weighted Average method. According to this
method formula 3.20 is used, where the parameters v and d represent the height and the
centroid of each ˜W′
k,j trapezoid respectively. Subsequently, W is raised to limiting powers
until all the entries converge. By this way, the overall priorities are calculated, and thus
the cumulative influence of each element on every other interacting element is obtained
[168]. At this point, all the columns of the produced Limit Supermatrix are the same and
their values show the estimated weight for each element of the TF-ANP network.
Wk,j =
vU ·dU +vL ·dL
dU +dL
(3.20)
3.1.3.1 The Trapezoidal Fuzzy Adaptive Analytic Network Process (TF-AANP)
A decision problem that is analyzed with the TF-AANP can be represented as a network
of nodes. Each node represents a component (or cluster) of the system while arcs denote
3.1 Related Methodologies 47
interactions between them. Interactions and feedbacks within clusters are called inner depen-
dencies, while interactions and feedbacks between clusters are called outer dependencies. The
TF-AANP is composed of seven major steps:
Step 1. Estimation of the importance of each service: The fuzzy pairwise comparison matrix
˜P is derived for the services using the linguistic terms presented in Table 3.2, which
correspond to the nine-point importance scale introduced in [166]. The standard form of
the ˜P matrix is expressed as follows:
˜P =


















1 ... ˜p1 j ... ˜p1S
...
...
...
1/ ˜p1s ... 1 ... ˜psS
...
...
...
1/ ˜p1S ... 1/ ˜pjS ... 1
(3.21)
where S denotes the number of the services. Subsequently, the geometric mean r ˜Ps
of
each service (row) s in ˜P is estimated according to formula 3.22, where ⊗ denotes the
multiplication operator of two fuzzy numbers as defined in [169].
r ˜Ps
= ( ˜ps1 ⊗ ˜ps2 ⊗...⊗ ˜psS)
1
S (3.22)
Then, the priority vector ˜Ω ˜Ps
of services is constructed as follows:
˜Ω ˜Ps
= [ ˜ω ˜p1 ˜ω ˜p2 ... ˜ω ˜pS ] (3.23)
where each ˜ω ˜ps = (ωU
˜p1,ωU
˜p2,ωU
˜p3,ωU
˜p4,vU
ps);(ωL
˜p1,ωL
˜p2,ωL
˜p3,ωL
˜p4,vL
ps) is calculated us-
ing formula 3.24. The ⊕ indicates the addition operator of two fuzzy numbers as defined
in [169].
˜ω ˜ps = r ˜Ps
/(r ˜P1
⊕r ˜P2
⊕...⊕r ˜Ps
⊕...⊕r ˜PS
) (3.24)
Step 2. Model Construction and Problem Structuring for each service: During this step, for each
service s ∈ S the problem is analyzed and decomposed into a rational system, consisted
of a network of nodes.
Step 3. Pairwise comparison matrices and priority vectors: In this step, for each service s ∈ S,
the fuzzy pairwise comparison matrix ˜As is derived for each TF-AANP cluster using the
linguistic terms presented in Table 3.2. The standard form of the ˜A matrix is expressed as
follows:
˜As =


















1 ... ˜as1 j ... ˜as1n
...
...
...
1/ ˜as1i ... 1 ... ˜asin
...
...
...
1/ ˜a1sn ... 1/ ˜asjn ... 1
(3.25)
48 Mobility Management
where n denotes the number of the cluster elements. Subsequently, the geometric mean
r ˜Asi
of each row i in ˜As is estimated according to formula 3.26.
r ˜Asi = ( ˜asi1 ⊗ ˜asi2 ⊗...⊗ ˜asin)
1
n (3.26)
Then, the priority vector ˜Ωsi of the cluster elements is constructed as follows:
˜Ωsi = [ ˜ωs1 ˜ωs2 ... ˜ωsn ] (3.27)
where each ˜ωsi = (ωU
s1,ωU
s2,ωU
s3,ωU
s4,vU
si );(ωL
s1,ωL
s2,ωL
s3,ωL
s4,vL
si) is calculated using
formula 3.36. The ⊕ indicates the addition operator of two fuzzy numbers as defined in
[169].
˜ωsi = r ˜Asi
/(r ˜As1
⊕r ˜As2
⊕...⊕r ˜Asi
⊕...⊕r ˜Asn
) (3.28)
Step 4. Construction of the Supermatrices: In this step, the fuzzy supermatrix ˜Ws of the TF-
AANP model is constructed for each service representing the inner and the outer depen-
dencies of the TF-AANP network. It is a partitioned matrix, with each matrix segment
representing the relationship between two clusters of the network. To construct the
supermatrix, the local priority vectors ˜Ωs are grouped and placed in the appropriate
positions in the supermatrix based on the flow of influence from one cluster to another,
or from a cluster to itself, as in the loop. For example, if we assume that we have a
TF-AANP network of q clusters, Ck, with k = [1,2,...,q] and that each cluster has nq
elements, denoted as ek1,ek2,...,eknk
, then the supermatrix is expressed as:
˜Ws =
C1 ... Ck ... Cq
e11...e1n1 ... ek1...eknk
... eq1...eqnq




















































e11
C1
... ˜Ws11 ... ˜Ws1 j ... ˜Ws1q
e1n1
...
...
...
...
...
...
ek1
Ck
... ˜Wsk1 ... ˜Wsk j ... ˜Wskq
eknk
...
...
...
...
...
...
eq1
Cq
... ˜Wsq1 ... ˜Wsqj ... ˜Wsqq
eqnq
(3.29)
Step 5. Construction of the Weighted Supermatrices: During this step, the supermatrix of each
service is transformed to a stochastic one,the Weighted Supermatrix ˜W′
s using formula
3.1 Related Methodologies 49
3.38.
˜W′
s,k,j = ˜Ws,k,j/q (3.30)
Step 6. Calculation of the Limited Supermatrices: In this step, initially the deffuzified Weighted
Supermatrix Ws of each service is estimated by applying the Weighted Average method.
According to this method formula 3.31 is used, where the parameters vs and ds represent
the height and the centroid of each ˜W′
s,k,j trapezoid respectively. Subsequently, each
Ws is raised to limiting powers until all the entries converge. By this way the overall
priorities are calculated, and thus the cumulative influence of each element on every other
interacting element is obtained [168]. At this point, all the columns of each produced
Limit Supermatrix Ls, are the same and their values show the importance of each element
e of the TF-AANP network for the corresponding service s.
Ws,k,j =
vU
s ·dU
s +vL
s ·dL
s
dU
s +dL
s
(3.31)
Step 7. Estimation of the Criteria Weights: In this step, the weight we for each element e of the
TF-AANP network is calculated using formula 3.32 where the importance ˜ω ˜Ps of each
service s is considered.
we =
S
∑
s=1
˜ω ˜P,s ∗Ls,e (3.32)
3.1.3.2 The Pentagonal Fuzzy Analytic Network Process (PF-ANP)
The Pentagonal Fuzzy Analytic Network Process (PF-ANP) method is the IVPFN version of
the typical ANP [166] method, used for the calculation of the criteria weights. PF-ANP allows
complex relationships within and among clusters of selection criteria using a network model of
dependencies. A decision problem that is analyzed with the PF-ANP can be represented as a
network of nodes. Each node represents a component (or cluster) of the system while the arcs
denote the interactions between them. The interactions and the feedbacks within the clusters are
called inner dependencies, while the interactions and the feedbacks between clusters are called
outer dependencies. Indicatively, we could consider one cluster with network characteristics
criteria such as throughput, delay, jitter and packet loss, as well as one cluster with operator
policy criteria such as service reliability, security and price. In this situation, the PF-ANP will
consider two clusters. The PF-ANP is composed of five major steps of selection criteria:
Step 1. Model Construction and Problem Structuring: During this step the problem is analyzed
and decomposed into a rational system, consisting of a network of nodes.
Step 2. Pairwise comparison matrices and priority vectors: Initially the fuzzy pairwise compari-
son matrix ˜A is derived for each cluster using the linguistic terms presented in Table 3.2,
50 Mobility Management
which are calculated using the EUM method and correspond to the nine-point importance
scale introduced in [166]. The standard form of the ˜A matrix is expressed as follows:
˜A =


















1 ... ˜a1 j ... ˜a1n
...
...
...
1/ ˜a1i ... 1 ... ˜ain
...
...
...
1/ ˜a1n ... 1/ ˜ajn ... 1
(3.33)
where n denotes the number of the cluster elements. Subsequently, the geometric mean
Table 3.2 The Linguistic Terms that are used for the Criteria Pairwise Comparisons.
Linguistic term Interval-valued pentagonal fuzzy number
Equally Important (EI) [(0.043, 0.062, 0.1, 0.137, 0.156, 0.8, 0.6, 0.6),
(0.025, 0.05, 0.1, 0.15, 0.175, 1.0, 0.8, 0.8)]
More than Equally Important (MEI) [(0.143, 0.162, 0.2, 0.237, 0.256, 0.8, 0.6, 0.6),
(0.125, 0.15, 0.2, 0.25, 0.275, 1.0, 0.8, 0.8)]
Moderately More Important (MMI) [(0.243, 0.262, 0.3, 0.337, 0.356, 0.8, 0.6, 0.6),
(0.225, 0.25, 0.3, 0.35, 0.375, 1.0, 0.8, 0.8)]
More than Moderately More Important (MMMI) [(0.343, 0.362, 0.4, 0.437, 0.456, 0.8, 0.6, 0.6),
(0.325, 0.35, 0.4, 0.45, 0.475, 1.0, 0.8, 0.8)]
Strongly More Important (SMI) [(0.443, 0.462, 0.5, 0.537, 0.556, 0.8, 0.6, 0.6),
(0.425, 0.45, 0.5, 0.55, 0.575, 1.0, 0.8, 0.8)]
More than Strongly More Important (MSMI) [(0.543, 0.562, 0.6, 0.637, 0.656, 0.8, 0.6, 0.6),
(0.525, 0.55, 0.6, 0.65, 0.675, 1.0, 0.8, 0.8)]
Very Strongly More Important (VSMI) [(0.643, 0.662, 0.7, 0.737, 0.756, 0.8, 0.6, 0.6),
(0.625, 0.65, 0.7, 0.75, 0.775, 1.0, 0.8, 0.8)]
More than Very Strongly More Important (MVSMI) [(0.743, 0.762, 0.8, 0.837, 0.856, 0.8, 0.6, 0.6),
(0.725, 0.75, 0.8, 0.85, 0.875, 1.0, 0.8, 0.8)]
Extremely More Important (EMI) [(0.843, 0.862, 0.9, 0.937, 0.956, 0.8, 0.6, 0.6),
(0.825, 0.85, 0.9, 0.95, 0.975, 1.0, 0.8, 0.8)]
r ˜Ai
of each row i in ˜A is calculated according to formula 3.34, where ⊗ denotes the
multiplication operator of two fuzzy numbers as defined in [169].
r ˜Ai
= ( ˜ai1 ⊗ ˜ai2 ⊗...⊗ ˜ain)
1
n (3.34)
Then, the priority vector ˜Ωi of each cluster element is constructed as follows:
˜Ωi = [ ˜ω1 ˜ω2 ... ˜ωn ] (3.35)
where each ˜ωi = [(ωU
1 ,ωU
2 ,ωU
3 ,ωU
4 ,ωU
5 ,vU
i ,vU
i1,vU
i2); (ωL
1 ,
ωL
2 ,ωL
3 ,ωL
4 ,ωL
5 ,vL
i ,vL
i1,vL
i2)] is calculated using formula 3.36. The ⊕ indicates the addi-
tion operator of two fuzzy numbers as defined in [169].
˜ωi = r ˜Ai
/(r ˜A1
⊕r ˜A2
⊕...⊕r ˜Ai
⊕...⊕r ˜An
) (3.36)
Step 3. Construction of the Supermatrix: In this step, the fuzzy supermatrix ˜W of the PF-
ANP model is constructed representing the inner and outer dependencies of the PF-
ANP network. This is a partitioned matrix, with each matrix segment representing the
3.1 Related Methodologies 51
relationship between two clusters of the network. To construst the supermatrix, the local
priority vectors ˜Ω are grouped and placed in the appropriate positions in the supermatrix
based on the flow of influence from one cluster to another. For example if we assume a
network of q clusters, where each cluster Ck, k = [1,2,...,q] has nk elements, denoted
as ek1,ek2,...,eknk
, then the supermatrix is expressed as:
˜W =
C1 ... Ck ... Cq
e11...e1n1 ... ek1...eknk
... eq1...eqnq




















































e11
C1
... ˜W11 ... ˜W1 j ... ˜W1q
e1n1
...
...
...
...
...
...
ek1
Ck
... ˜Wk1 ... ˜Wk j ... ˜Wkq
eknk
...
...
...
...
...
...
eq1
Cq
... ˜Wq1 ... ˜Wqj ... ˜Wqq
eqnq
(3.37)
Step 4. Construction of the Weighted Supermatrix: During this step, the supermatrix is trans-
formed to a stochastic one,the Weighted Supermatrix ˜W′ using formula 3.38.
˜W′
k,j = ˜Wk,j/q (3.38)
Step 5. Calculation of the Limited Supermatrix: In this step, initially the deffuzified Weighted
Supermatrix W is estimated by applying the Weighted Average method using formula
3.39. The parameters v and d represent the height and the centroid of each ˜W′
k,j pentagon
respectively. Subsequently, W is raised to limiting powers until all the entries converge.
In this way the overall priorities are calculated, and thus the cumulative influence of
each element on every other interacting element is obtained [168]. At this point, all the
columns of the produced Limited Supermatrix, are the same and their values show the
global priority of each element of the network.
Wk,j =
vU ·dU +vL ·dL
dU +dL
(3.39)
52 Mobility Management
3.1.4 Network Selection Methods
3.1.4.1 The Trapezoidal Interval-Valued Fuzzy TOPSIS (TFT)
TOPSIS, introduced by Hwang and Yoon [170], is based on the concept that the best alternative
should have the shortest distance from the positive ideal solution and the longer distance
from the negative ideal solution. In the present work, network selection is performed using a
proposed fuzzy version of TOPSIS, namely the Trapezoidal interval-valued Fuzzy TOPSIS
(TFT). This method assumes that the linguistic values of the criteria attributes are represented
by interval-valued trapezoidal fuzzy numbers.
Suppose that A = {A1,A2,...,An} is the set of possible alternatives, C = {C1,C2,...,Cn} is
the set of criteria and w1,w2,...,wm are the weights of each criterion. The steps of the method
are as follows:
Step 1. Construction of the decision matrix: Each element xij of the n × m decision matrix
D is an interval-valued trapezoidal fuzzy number which expresses the performance of
alternative i for criterion j. Thus
D =
C1 ... Cm
A1 x11 ... x1m
...
...
...
...
An xn1 ... xnm
(3.40)
where: xij = (xL
ij1,xL
ij2,xL
ij3,xL
ij4,vL
ij),(xU
ij1,xU
ij2,xU
ij3,xU
ij4,vU
ij)
In case there are Q decision makers, the decision matrix and the criteria weights include
the average of the performance values and of the weights of the decision makers, re-
spectively. Hence, assuming that for the k-th decision maker xijk is the performance of
alternative i for criterion j, and wjk is the importance weight for criterion j, the average
of the performance values and weights are given by
xij =
1
Q
Q
∑
k=1
xijk =
1
Q
Q
∑
k=1
xL
ijk1,
1
Q
Q
∑
k=1
xL
ijk2,
1
Q
Q
∑
k=1
xL
ijk3,
1
Q
Q
∑
k=1
xL
ijk4,vL
ijk ,
1
Q
Q
∑
k=1
xU
ijk1,
1
Q
Q
∑
k=1
xU
ijk2,
1
Q
Q
∑
k=1
xU
ijk3,
1
Q
Q
∑
k=1
xU
ijk4,vU
ijk (3.41)
and
wj =
1
Q
Q
∑
k=1
wjk. (3.42)
Step 2. Normalization of the decision matrix: Consider that Ωb is the set of benefits attributes
and Ωc is the set of costs attributes. Then the elements of the normalized decision matrix
are computed as:
3.1 Related Methodologies 53
a)
rij =
xL
ij1
bj
,
xL
ij2
bj
,
xL
ij3
bj
,
xL
ij4
bj
,vL
ij ,
xU
ij1
bj
,
xU
ij2
bj
,
xU
ij3
bj
,
xU
ij4
bj
,vU
ij (3.43)
where bj = maxi xU
ij4 for each j ∈ Ωb and
b)
rij =
cj
xL
ij4
,
cj
xL
ij3
,
cj
xL
ij2
,
cj
xL
ij1
,vL
ij ,
cj
xU
ij4
,
cj
xU
ij3
,
cj
xU
ij2
,
cj
xU
ij1
,vU
ij (3.44)
where cj = mini xL
ij4 for each j ∈ Ωc.
Step 3. Construction of the weighted normalized decision matrix: The weighted normalized
decision matrix is constructed by multiplying each element of the normalized decision
matrix rij with the respective weight wj according to the formula
uij = rL
ij1 ·wj,rL
ij2 ·wj,rL
ij3 ·wj,rL
ij4 ·wj,vL
ij , rU
ij1 ·wj,rU
ij2 ·wj,rU
ij3 ·wj,rU
ij4 ·wj,vU
ij (3.45)
Step 4. Determination of the positive and negative ideal solution: The positive ideal solution X+
is defined as follows:
X+
= x+L
ij1 ,x+L
ij2 ,x+L
ij3 ,x+L
ij4 ,v+L
ij , x+U
ij1 ,x+U
ij2 ,x+U
ij3 ,x+U
ij4 ,v+U
ij =
i
uL
ij1,
i
uL
ij2,
i
uL
ij3,
i
uL
ij4,vL
ij ,
i
uU
ij1,
i
uU
ij2,
i
uU
ij3,
i
uU
ij4,vU
ij (3.46)
where
i
≡ maxi in case j ∈ Ωb and
i
≡ mini in case j ∈ Ωc.
The negative ideal solution X− is defined as follows:
X−
= x−L
ij1 ,x−L
ij2 ,x−L
ij3 ,x−L
ij4 ,v−L
ij , x−U
ij1 ,x−U
ij2 ,x−U
ij3 ,x−U
ij4 ,v−U
ij
=
i
uL
ij1,
i
uL
ij2,
i
uL
ij3,
i
uL
ij4,vL
ij ,
i
uU
ij1,
i
uU
ij2,
i
uU
ij3,
i
uU
ij4,vU
ij
(3.47)
where i ≡ mini in case j ∈ Ωb and i ≡ maxi in case j ∈ Ωc.
Step 5. Measurement of the distance of each alternative from the ideal solutions: The distances
d+
i1 and d+
i2 of each alternative from the positive ideal solution are evaluated as follows:
d+
i1 =
m
∑
j=1
1
4
uL
ij1 −x+L
ij1
2
+ uL
ij2 −x+L
ij2
2
+ uL
ij3 −x+L
ij3
2
+ uL
ij4 −x+L
ij4
2
1
2
(3.48)
d+
i2 =
m
∑
j=1
1
4
uU
ij1 −x+U
ij1
2
+ uU
ij2 −x+U
ij2
2
+ uU
ij3 −x+U
ij3
2
+ uU
ij4 −x+U
ij4
2
1
2
(3.49)
54 Mobility Management
Likewise, the distances d−
i1 and d−
i2 of each alternative from the negative ideal solution
are estimated as follows:
d−
i1 =
m
∑
j=1
1
4
uL
ij1 −x−L
ij1
2
+ uL
ij2 −x−L
ij2
2
+ uL
ij3 −x−L
ij3
2
+ uL
ij4 −x−L
ij4
2
1
2
(3.50)
d−
i2 =
m
∑
j=1
1
4
uU
ij1 −x−U
ij1
2
+ uU
ij2 −x−U
ij2
2
+ uU
ij3 −x−U
ij3
2
+ uU
ij4 −x−U
ij4
2
1
2
(3.51)
Consequently, similarly to [158] the distance of the alternatives from the positive and the
negative ideal solutions are expressed by intervals such as [d+
i1,d+
i2] and [d−
i1,d−
i2], instead
of single values. In this way less information is lost.
Step 6. Calculation of the relative closeness: The relative closeness of the distances from the
ideal solutions are computed as:
RCi1 =
d−
i1
d+
i1 +d−
i1
(3.52)
and
RCi2 =
d−
i2
d+
i2 +d−
i2
(3.53)
The compound relative closeness RCi is obtained from the average of the above values:
RCi =
RCi1 +RCi2
2
(3.54)
Step 7. Alternatives ranking: The alternatives are ranked according to their RCi values. The best
alternative is the one with the higher RCi value.
3.1.4.2 The Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW)
The candidate networks are ranked using the TFT-ACW algorithm, which improves the TFT
[171] by using the adaptive weights that estimated from the TF-AANP method. Thus, the
importance of the opinion of each service (decision maker) is considered, since the opinions of
some decision makers could have a higher importance than the ones of the other decision makers.
In general, similar to TFT, the TFT-ACW method is based on the concept that the best alternative
should have the shortest distance from the positive ideal solution and the longer distance from
the negative ideal solution. Also, it assumes that the linguistic values of the criteria attributes
are represented by interval-valued trapezoidal fuzzy numbers. More specifically, suppose that
AL = {AL1,AL2,...,ALz} is the set of possible alternatives, CR = {CR1,CR2,...,CRn} is the
set of criteria and w1,w2,...,wn are the importance weights of the respective criteria obtained
from the application of the TF-AANP algorithm. The steps of the method are as follows:
3.1 Related Methodologies 55
Step 1. Construction of the decision matrix: Each element ˜gie of the z×n decision matrix ˜D is
an IVTFN number expressing the performance of alternative i for criterion e. Thus,
˜D =
CR1 ... CRn
AL1 ˜g11 ... ˜g1n
...
...
...
...
ALz ˜gz1 ... ˜gzn
(3.55)
where ˜gie = (gL
ie1,gL
ie2,gL
ie3,gL
ie4,vL
ie),(gU
ie1,gU
ie2,gU
ie3,gU
ie4,vU
ie) .
In the case that there are S services (decision makers) the decision matrix include the
average of the performance values. Hence, assuming that for the sth decision maker ˜giex is
the performance of alternative i for criterion (element) e, the average of the performance
values is given by formula 3.56.
˜gie =
S
∑
s=1
( ˜gies · ˜ω ˜ps) (3.56)
Step 2. Normalization of the decision matrix: Let Γb be the set of benefit attributes and Γc the
set of cost attributes. Then, the elements of the normalized decision matrix are calculated
using either formula 3.57 or 3.58, where be = maxi gU
ie4 for each e ∈ Γb and ce = mini gL
ie4
for each e ∈ Γc.
˜g′
ie =
gL
ie1
be
,
gL
ie2
be
,
gL
ie3
be
,
gL
ie4
be
,vL
ie ,
gU
ie1
be
,
gU
ie2
be
,
gU
ie3
be
,
gU
ie4
be
,vU
ie (3.57)
˜g′
ie =
ce
gL
ie4
,
ce
gL
ie3
,
ce
gL
ie2
,
ce
gL
ie1
,vL
ie ,
ce
gU
ie4
,
ce
gU
ie3
,
ce
gU
ie2
,
ce
gU
ie1
,vU
ie (3.58)
Step 3. Construction of the weighted normalized decision matrix: The weighted normalized
decision matrix is constructed by multiplying each element of the normalized decision
matrix ˜g′
ie with the respective weight we according to the formula 3.59.
˜uie = g′L
ie1 ·we,g′L
ie2 ·we,g′L
ie3 ·we,g′L
ie4 ·we,v′L
ie ,
g′U
ie1 ·we,g′U
ie2 ·we,g′U
ie3 ·we,g′U
ie4 ·we,vU
ie
(3.59)
Step 4. Determination of the positive and negative ideal solution: The positive ideal solution
is defined in formula 3.60, where
i
≡ maxi in case e ∈ Γb and
i
≡ mini in case e ∈ Γc.
Correspondingly, the negative ideal solution is defined in formula 3.61, where i ≡ mini
56 Mobility Management
in case e ∈ Γb and i ≡ maxi in case e ∈ Γc.
˜G+
= g+L
ie1 ,g+L
ie2 ,g+L
ie3 ,g+L
ie4 ,v+L
ie , g+U
ie1 ,g+U
ie2 ,g+U
ie3 ,g+U
ie4 ,v+U
ie
=
i
uL
ie1,
i
uL
ie2,
i
uL
ie3,
i
uL
ie4,vL
ie ,
i
uU
ie1,
i
uU
ie2,
i
uU
ie3,
i
uU
ie4,vU
ie
(3.60)
˜G−
= g−L
ie1 ,g−L
ie2 ,g−L
ie3 ,g−L
ie4 ,v−L
ie , g−U
ie1 ,g−U
ie2 ,g−U
ie3 ,g−U
ie4 ,v−U
ie
=
i
uL
ie1,
i
uL
ie2,
i
uL
ie3,
i
uL
ie4,vL
ie ,
i
uU
ie1,
i
uU
ie2,
i
uU
ie3,
i
uU
ie4,vU
ie
(3.61)
Step 5. Measurement of the distance of each alternative from the ideal solutions: The distances
of each alternative from the positive ideal solution are evaluated using formulas 3.62 and
3.63.
p+
i1 =
n
∑
e=1
1
4
uL
ie1 −g+L
ie1
2
+ uL
ie2 −g+L
ie2
2
+ uL
ie3 −g+L
ie3
2
+ uL
ie4 −g+L
ie4
2
1
2
(3.62)
p+
i2 =
n
∑
e=1
1
4
uU
ie1 −g+U
ie1
2
+ uU
ie2 −g+U
ie2
2
+ uU
ie3 −g+U
ie3
2
+ uU
ie4 −g+U
ie4
2
1
2
(3.63)
Likewise, the distances of each alternative from the negative ideal solution are estimated using formulas
3.64 and 3.65.
p−
i1 =
n
∑
e=1
1
4
uL
ie1 −g−L
ie1
2
+ uL
ie2 −g−L
ie2
2
+ uL
ie3 −g−L
ie3
2
+ uL
ie4 −g−L
ie4
2
1
2
(3.64)
p−
i2 =
n
∑
e=1
1
4
uU
ie1 −g−U
ie1
2
+ uU
ie2 −g−U
ie2
2
+ uU
ie3 −g−U
ie3
2
+ uU
ie4 −g−U
ie4
2
1
2
(3.65)
Consequently, the alternative distance from the positive and from the negative ideal
solutions are expressed by intervals such as [p+
i1, p+
i2] and [p−
i1, p−
i2], instead of single
values, thus less information is lost.
Step 6. Calculation of the relative closeness: The relative closeness of the distances from the
ideal solutions are calculated using formula 3.66 and 3.67.
RCi1 =
p−
i1
p+
i1 + p−
i1
(3.66)
RCi2 =
p−
i2
p+
i2 + p−
i2
(3.67)
3.1 Related Methodologies 57
Subsequently, the compound relative closeness is obtained using formula 3.68
RCi =
RCi1 +RCi2
2
(3.68)
Step 7. Alternative networks ranking: The alternative networks are ranked according to their RCi
values. The best alternative is that with the higher RCi value.
3.1.4.3 The Pentagonal Fuzzy TOPSIS (PFT)
The Pentagonal Fuzzy TOPSIS (PFT) algorithm is an improved version of the TOPSIS using
interval-valued pentagonal fuzzy numbers. PFT assumes that the linguistic values of the criteria
attributes are represented by IVPFN numbers.
Suppose that A = {A1,A2,...,An} is the set of possible alternatives, C = {C1,C2,...,Cm} is
the set of criteria and w1,w2,...,wm are the weights of each criterion. The steps of the method
are as follows:
Step 1. Construction of the decision matrix: Each element xij of the n × m decision matrix
D is an interval-valued pentagonal fuzzy number which expresses the performance of
alternative i for criterion j. Thus
D =
C1 ... Cm
A1 x11 ... x1m
...
...
...
...
An xn1 ... xnm
(3.69)
where: xij = [(xL
ij1,xL
ij2,xL
ij3,xL
ij4,xL
ij5,vL
ij,vL
ij1,vL
ij2), (xU
ij1,xU
ij2,xU
ij3,xU
ij4,xU
ij5,vU
ij,vU
ij1,vU
ij2)]. In case there
are Q decision makers the decision matrix and the criteria weights include the average
of the performance values and of the weights respectively, of the decision makers.
Hence, assuming that for the k-th decision maker xijk is the performance of alternative
i for criterion j, and wjk is the importance weight for criterion j, the average of the
performance values and weights are given by:
xij =
1
Q
Q
∑
k=1
xijk (3.70)
and
wj =
1
Q
Q
∑
k=1
wjk. (3.71)
Step 2. Normalization of the decision matrix: Consider that Ωb is the set of benefit attributes and
Ωc is the set of cost attributes. Then, the elements of the normalized decision matrix are
58 Mobility Management
computed as:
rij = [(
xL
ij1
bj
,
xL
ij2
bj
,
xL
ij3
bj
,
xL
ij4
bj
,
xL
ij5
bj
,vL
ij,vL
ij1,vL
ij2),(
xU
ij1
bj
,
xU
ij2
bj
,
xU
ij3
bj
,
xU
ij4
bj
,
xU
ij5
bj
,vU
ij,vU
ij1,vU
ij2)] (3.72)
where bj = maxi xU
ij4 for each j ∈ Ωb, or
rij = [(
cj
xL
ij5
,
cj
xL
ij4
,
cj
xL
ij3
,
cj
xL
ij2
,
cj
xL
ij1
,vL
ij,vL
ij2,vL
ij1),(
cj
xU
ij5
,
cj
xU
ij4
,
cj
xU
ij3
,
cj
xU
ij2
,
cj
xU
ij1
,vU
ij,vU
ij2,vU
ij1)] (3.73)
where cj = mini xL
ij4 for each j ∈ Ωc.
Step 3. Construction of the weighted normalized decision matrix: The weighted normalized
decision matrix is constructed by multiplying each element of the normalized decision
matrix rij with the respective weight wj according to:
uij = [(rL
ij1 ·wj,rL
ij2 ·wj,rL
ij3 ·wj,rL
ij4 ·wj,rL
ij5 ·wj,vL
ij,vL
ij1,
vL
ij2),(rU
ij1 ·wj,rU
ij2 ·wj,rU
ij3 ·wj,rU
ij4 ·wj,rU
ij5 ·wj,vU
ij,vU
ij1,vU
ij2)] (3.74)
Step 4. Determination of the positive and negative ideal solutions: The positive ideal solution is
given by:
X+
= [(x+L
ij1 ,x+L
ij2 ,x+L
ij3 ,x+L
ij4 ,x+L
ij5 ,v+L
ij ,v+L
ij1 ,v+L
ij2 ),(x+U
ij1 ,x+U
ij2 ,x+U
ij3 ,x+U
ij4 ,x+U
ij5 ,v+U
ij ,v+U
ij1 ,v+U
ij2 )] =
[(
i
uL
ij1,
i
uL
ij2,
i
uL
ij3,
i
uL
ij4,
i
uL
ij5,vL
ij,vL
ij1,vL
ij2),(
i
uU
ij1,
i
uU
ij2,
i
uU
ij3,
i
uU
ij4,
i
uU
ij5,vU
ij,vU
ij1,vU
ij2)]
(3.75)
where
i
≡ maxi in case j ∈ Ωb and
i
≡ mini in case j ∈ Ωc.
The negative ideal solutions is given by:
X−
= [(x−L
ij1 ,x−L
ij2 ,x−L
ij3 ,x−L
ij4 ,x−L
ij5 ,v−L
ij ,v−L
ij1 ,v−L
ij2 ),(x−U
ij1 ,x−U
ij2 ,x−U
ij3 ,x−U
ij4 ,x−U
ij5 ,v−U
ij ,v−U
ij1 ,v−U
ij2 )] =
[(
i
uL
ij1,
i
uL
ij2,
i
uL
ij3,
i
uL
ij4,
i
uL
ij5,vL
ij,vL
ij1,vL
ij2),(
i
uU
ij1,
i
uU
ij2,
i
uU
ij3,
i
uU
ij4,
i
uU
ij5,vU
ij,vU
ij1,vU
ij2)]
(3.76)
where i ≡ mini in case j ∈ Ωb and i ≡ maxi in case j ∈ Ωc.
Step 5. Measurement of the distance of each alternative from the ideal solutions: The distances
of each alternative from the positive ideal solution are evaluated as follows:
d+
i1 =
m
∑
j=1
{
1
5
[(uL
ij1 −x+L
ij1 )2
+(uL
ij2 −x+L
ij2 )2
+(uL
ij3 −x+L
ij3 )2
+(uL
ij4 −x+L
ij4 )2
+(uL
ij5 −x+L
ij5 )2
]}
1
2 (3.77)
d+
i2 =
m
∑
j=1
{
1
5
[(uU
ij1 −x+U
ij1 )2
+(uU
ij2 −x+U
ij2 )2
+(uU
ij3 −x+U
ij3 )2
+(uU
ij4 −x+U
ij4 )2
+(uU
ij5 −x+U
ij5 )2
]}
1
2 (3.78)
3.1 Related Methodologies 59
Likewise the distances of each alternative from the negative ideal solution are estimated
by:
d−
i1 =
m
∑
j=1
{15[(uL
ij1 −x−L
ij1 )2
+(uL
ij2 −x−L
ij2 )2
+(uL
ij3 −x−L
ij3 )2
+(uL
ij4 −x−L
ij4 )2
+(uL
ij5 −x−L
ij5 )2
]}
1
2 (3.79)
d−
i2 =
m
∑
j=1
{
1
5
[(uU
ij1 −x−U
ij1 )2
+(uU
ij2 −x−U
ij2 )2
+(uU
ij3 −x−U
ij3 )2
+(uU
ij4 −x−U
ij4 )2
+(uU
ij5 −x−U
ij5 )2
]}
1
2 (3.80)
Consequently, similarly to [158] the distance of the alternatives from the positive and
negative ideal solutions are expressed by intervals such as [d+
i1,d+
i2] and [d−
i1,d−
i2], instead
of single values. In this way less information is lost.
Step 6. Calculation of the relative closeness: The relative closeness RCi1 and RCi2 of the dis-
tances from the ideal solutions are computed as:
RCi1 =
d−
i1
d+
i1 +d−
i1
(3.81)
and
RCi2 =
d−
i2
d+
i2 +d−
i2
(3.82)
The compound relative closeness RCi is obtained from the average of the above values
RCi =
RCi1 +RCi2
2
(3.83)
Step 7. Alternatives ranking: The alternatives are ranked according to their RCi values. The best
alternative is that with the higher RCi value.
3.1.5 Evaluation of the Proposed Methods
3.1.5.1 Network Selection using the ANP and the TFT Algorithms
3.1.5.1.1 Simulation Setup : In our experiments we consider a heterogeneous network
environment consisting of a number of LTE, WiMAX and WiFi networks. Each network can
provide at least one of the following five service types: VoIP, conversational video (CVideo),
buffered streaming (BStreaming), real time gaming (RTGaming) and web browsing. In order
to allow service continuity, QoS mapping among the QoS classes of the different access tech-
nologies is required. Table 3.3 shows this mapping relation among the different technologies.
Four SLAs are defined with SLA1 having the higher service priority and SLA 4 having the
lower service priority. SLA1 supports all the service types and it provides the best values for
the QoS and policy decision criteria. SLA2 supports a smaller number of service types, by it
does not provide support for the VoIP and real time gaming services. Additionally, it provides
60 Mobility Management
Table 3.3 QoS Class Mapping and SLAs.
LTE QCI
(Type/ Priority)
WiMAX
QoS class
IEEE 802.11e
QoS class
Required
Throughput
Required
Packet loss
Required
Delay
Required
Jitter
Services
1 (GBR/ 2)
UGS/ ertPS
(802.16e-
802.16m)
AC_VO 200 Kbps 10−2 100ms 50ms
VoIP, CVideo,
BStreaming,
RTGaming,
Web
3 (GBR/ 3) UGS AC_VO 250 Kbps 10−3 50ms 40ms
CVideo,
BStreaming,
RTGaming,
Web
2 (GBR/ 4) UGS AC_VI 8 Mbps 10−3 65ms 50ms
CVideo,
BStreaming,
Web
4 (GBR/ 5) rtPS AC_VI 8 Mbps 10−5 65ms 60ms
CVideo,
BStreaming,
Web
6 (Non-GBR/ 6) nrtPS AC_BE 2.5 Mbps 10−5 200ms N/A
BStreaming,
Web
7 (Non-GBR/ 7) nrtPS AC_BE 2 Mbps 10−5 160ms 100ms
BStreaming,
Web
8 (Non-GBR/ 8) BE AC_BE 1.5 Mbps 10−3 300ms N/A
Web
9 (Non-GBR/ 9) BE AC_BE 1.5 Mbps 10−5 300ms N/A
Network selection weights
per service & SLA
Network QoS
Characteristics
Network Policy
Characteristics
Throughput
Delay
Jitter
Packet Loss
Service Reliability
Security
Price
Goal
Criteria Groups
Criteria
Figure 3.3 The ANP Network Model.
Throughput
Delay Jitter
Packet loss
Service
Reliability
Price
Security
Figure 3.4 The Relations of the Criteria considered by the ANP Network Model.
3.1 Related Methodologies 61
slightly worse decision criteria values than those offered by SLA1. SLA3 supports only the
buffered streaming and the web browsing services and satisfactory QoS characteristics and
policies, whereas the low price SLA4 supports only the web browsing service while providing
acceptable decision criteria values.
3.1.5.1.2 Performance Evaluation : The ANP method is applied in order to estimate
the weights of network selection criteria per service type and SLA. Figure 3.3 depicts the
ANP network model. The criteria are classified into two groups namely the QoS and the
policy characteristics. The QoS characteristics group contains network performance related
criteria including throughput, delay, jitter and packet loss while the policy characteristics
group contains operator defined rules such as price, security and service reliability. Pairwise
comparison decision matrices are created based on relations among the seven selection criteria
depicted in Figure 3.4. Then, these pairwise comparison decision matrices are used to evaluate
the priority vectors of criteria and form the supermatrix per service type and SLA. Subsequently,
the weighted supermatrices and, finally, the limit supermatrices are obtained. Indicatively, for
the SLA1 VoIP service, the initial, the weighted and the limit supermatrices are presented in
Tables 3.4, 3.5 and 3.6 respectively.
Table 3.4 The ANP Supermatrix for the SLA1 VoIP Service.
Throughput Delay Jitter Packet loss Price Reliability Security
Throughput 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625
Delay 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125
Jitter 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125
Packet loss 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125
Price 0.05 0.05 0.05 0.05 0.019607 0.05 0.0625
Reliability 0.95 0.95 0.95 0.95 0.759804 0.95 0
Security 0 0 0 0 0.220588 0 0.9375
Table 3.5 The ANP Weighted Supermatrix for the SLA1 VoIP Service.
Throughput Delay Jitter Packet loss Price Reliability Security
Throughput 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
Delay 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062
Jitter 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062
Packet loss 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062
Price 0.025 0.025 0.025 0.025 0.00980392 0.025 0.03125
Reliability 0.475 0.475 0.475 0.475 0.379902 0.475 0
Security 0 0 0 0 0.110294 0 0.46875
The criteria weights per service and SLA obtained by the limit supermatrices are presented
in Figures 3.5, 3.6, 3.7 and 3.8. As illustrated, the weights are proportional to the constraints
of each service as well as to the agreements of each SLA. In particular, the weight of the price
62 Mobility Management
Table 3.6 The ANP Limit Supermatrix for the SLA1 VoIP Service.
Throughput Delay Jitter Packet loss Price Reliability Security
Throughput 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
Delay 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062
Jitter 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062
Packet loss 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062
Price 0.0246573 0.0246573 0.0246573 0.0246573 0.0246573 0.0246573 0.0246573
Reliability 0.470224 0.470224 0.470224 0.470224 0.470224 0.470224 0.470224
Security 0.0051191 0.0051191 0.0051191 0.0051191 0.0051191 0.0051191 0.0051191
criterion is low for SLA1, in which the service reliability and the network QoS characteristics
are considered as the most important factors. In SLA2 the price criterion is more important than
in SLA1, thus the respective weight is greater than that of SLA1. Consequently, the weights
of the service reliability and QoS characteristics criteria in SLA2 are lower compared to the
relative weights of SLA1. In SLA3 the weights of the price and the service reliability criteria
are balanced as they are almost of equivalent importance. Finally, in SLA4 the price is the most
important criterion resulting in a high estimated weight value.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
VoIP ConversationalVideo BufferedStreaming RealTimeGaming Web
Weight
SLA1
Throughput
Delay
Jitter
Packet Loss
Price
Reliability
Security
Figure 3.5 Criteria Weights for SLA1.
3.1 Related Methodologies 63
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
ConversationalVideo BufferedStreaming Web
Weight
SLA2
Throughput
Delay
Jitter
Packet Loss
Price
Reliability
Security
Figure 3.6 Criteria Weights for SLA2.
The ranking of the networks alternatives is performed using the TFT algorithm described
in the subsection 3.1.4.1. The weights of the network selection criteria are obtained from
Figures 3.5 - 3.8. The linguistic terms for the criteria attributes are represented by interval-
valued trapezoidal fuzzy numbers as shown in Table 3.7. The network policy specifications
are expressed directly using linguistic terms. Additionally, crisp values of network QoS
characteristics are converted into linguistic terms which correspond to specific ranges of values
per service type. Table 3.8 presents a relative example for the VoIP service, illustrating the
correspondence between ranges of network QoS characteristics values and linguistic terms.
The available - candidate networks in our simulations at the time of network selection per
service and SLA, as well as, their specifications expressed by linguistic terms are depicted in
Tables 3.9 and 3.10.
The case of having several services of different QoS constraints running at the user site is
being addressed by the TFT algorithm and network selection is performed in a way satisfying
multiple groups of criteria per user. We consider the case where nine users need to select a
network which satisfies the requirements of their services as presented in Table 3.11 and at the
same time comply with their respective SLA agreements. To achieve this goal the proposed
64 Mobility Management
0
0.1
0.2
0.3
0.4
0.5
BufferedStreaming Web
Weight
SLA3
Throughput
Delay
Jitter
Packet Loss
Price
Reliability
Security
Figure 3.7 Criteria Weights for SLA3.
TFT algorithm is applied for each user and the available networks are ranked as shown in
Figure 3.9. The positive and the negative ideal solutions are represented by unary and null
trapezoidal fuzzy numbers respectively to eliminate the ranking abnormality problem.
From the obtained results it is clear that the ranking of the network alternatives is in
accordance with the users expectations. For example, user 1 who requires increased QoS
provisioning selects LTE 1 network which guarantees the best QoS characteristics and service
reliability. As Figure 3.9 depicts, LTE 1 achieves higher ranking than the other networks,
due to the high values of the QoS characteristics and service reliability factors bearing higher
importance according to the relative ANP weights in SLA1. On the contrary, user 9 whose
prior selection criterion is the price of the service, selects the WiFi 1 network which satisfies
his requirements as expressed in his SLA agreement.
The performance of the TFT algorithm was evaluated against the original TOPSIS method,
as well as, against the method presented in [172], the Fuzzy AHP - ELECTRE (FAE) method.
The FAE method calculates the criteria weights using the Fuzzy AHP and performs the network
selection by applying the ELECTRE algorithm. We consider the scenario of the nine users of
Table 3.11. A critical weakness of TOPSIS and FAE is that they do not support users with
3.1 Related Methodologies 65
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
Web
Weight
SLA4
Throughput
Delay
Jitter
Packet Loss
Price
Reliability
Security
Figure 3.8 Criteria Weights for SLA4
more than one service. In these cases, the TOPSIS and FAE methods consider only the most
demanding service of the user. Specifically, for users 2 and 3 they applied only considering the
VoIP service and for user 7 are applied only considering the BStreaming service, whereas for
the rest users the methods are applied respectively for each single user service defined in Table
3.11.
Table 3.12 presents the network classification performed by TFT, TOPSIS and FAE.
From the analysis of the results we conclude that when a user has only one service, the
methods usually provide similar results. However, when a user requires multiple services, TFT
accomplishes more reliable results than TOPSIS and FAE, since it considers the weights of
each service. For example, the results concerning user 1 using only the VoIP service, are similar
for TFT and TOPSIS with the exception of the evaluation sequence of the WiFi 1 and WiFi
2 networks. Also, FAE accomplishes quite similar network rates with TFT and TOPSIS for
this user. Nevertheless, TFT achieves more reliable results for user 4, compared with TOPSIS
and FAE. In this case, only the RTGaming service is used and the most important criteria are
service reliability, throughput and delay. TFT selects the WiMAX2 network which provides
AG for service reliability, VG for throughput and AG for delay criterion. On the other hand,
66 Mobility Management
Table 3.7 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy Numbers
used for the Evaluation of the TFT algorithm.
Linguistic term Interval-valued trapezoidal fuzzy number
Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.0, 0.8), (0.0, 0.0, 0.0, 0.0, 1)]
Very Poor (VP) [(0.01, 0.02, 0.03, 0.07, 0.8), (0.0, 0.01, 0.05, 0.08, 1)]
Poor (P) [(0.04, 0.1, 0.18, 0.23, 0.8), (0.02, 0.08, 0.2, 0.25, 1)]
Medium Poor (MP) [(0.17, 0.22, 0.36, 0.42, 0.8), (0.14, 0.18, 0.38, 0.45, 1)]
Medium (M) [(0.32, 0.41, 0.58, 0.65, 0.8), (0.28, 0.38, 0.6, 0.7, 1)]
Medium Good (MG) [(0.58, 0.63, 0.8, 0.86, 0.8), (0.5, 0.6, 0.9, 0.92, 1)]
Good (G) [(0.72, 0.78, 0.92, 0.97, 0.8), (0.7, 0.75, 0.95, 0.98, 1)]
Very Good (VG) [(0.93, 0.98, 1, 1, 0.8), (0.9, 0.95, 1, 1, 1)]
Absolutely Good (AG) [(1, 1, 1, 1, 0.8), (1, 1, 1, 1, 1)]
Table 3.8 Relation of the Network QoS Characteristics and the Linguistic Terms for VoIP.
Linguistic term Throughput range (Kbps) Delay range (ms) Jitter range (ms) Packet loss range
AP ≤ 164 ≥ 116 ≥ 65 ≥ 0.4
VP 165 - 174 111-115 55 - 64 ≥ 0.2 - 0.4
P 175 - 184 106-110 45 - 54 >10−1
- <0.2
MP 185 - 194 100 - 105 40 - 44 10−1
M 195 - 204 95 - 99 35 - 49 10−2
MG 205 - 214 86 - 94 30 - 34 10−3
G 215 - 224 66 - 85 25 - 29 10−4
VG 225 - 239 41 - 65 20 - 24 10−5
AG ≥ 240 ≤ 40 ≤ 20 ≤ 10−6
TOPSIS selects the LTE1 network, which has similar values with the WiMAX2 for service
reliability and delay criteria but worse performance for throughout by providing G instead of
VG. Moreover, FAE does not provide a clear choice for user 4 and results to equal rankings for
both WiMAX2 and LTE1 networks. Finally, the classification of the networks obtained by the
three methods is quite different for user 7 who requests both BStreaming and web browsing
services. In this case, the TFT accomplishes more reliable results by taking into account the
weights of both services.
3.1.5.1.3 Sensitivity Analysis : In this subsection, the sensitivity of TFT is evaluated when
the number of the available access networks changes frequently. We consider three different
network configuration scenarios for the users defined in Table 3.11. In the first scenario all the
networks defined in Tables 3.9 and 3.10 are available. In the second and third scenarios the
LTE 1 and the WiFi 2 networks respectively are not reachable. The graphs of Figures 3.10-3.18
include three column types of different patern indicating the ranking of network alternatives in
each case. In the first case, user 1 selects the LTE 1 network. In the second case, the remaining
networks improve their ranking order, thus user 1 selects the WiMAX 2 network. Furthermore,
in the third case only the last rated WiFi 3 network increases its rank, since the WiFi 2 network
preceded WiFi 3 in the other two cases. Similar behavior is observed in the ranking of the
3.1 Related Methodologies 67
0
0.05
0.1
0.15
0.2
User1 User2 User3 User4 User5 User6 User7 User8 User9
NetworkScore
Trapezoidal Fuzzy Topsis Results
LTE 1
LTE 2
WiMAX 1
WiMAX 2
WiFi 1
WiFi 2
WiFi 3
Figure 3.9 The TFT Results.
network alternatives for the other users. From the aforementioned analysis we conclude that the
ranking results of the proposed method are normally adjusted with respect to the heterogeneous
network environment changes, highlighting thus the method’s sensitivity.
68 Mobility Management
0
1
2
3
4
5
6
7
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.10 The TFT’s Network Ranking for User 1 in case of Network Environment Changes.
0
1
2
3
4
5
6
7
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.11 The TFT’s Network Ranking for User 2 in case of Network Environment Changes.
3.1 Related Methodologies 69
Table 3.9 The Available Networks of SLA1 and SLA2.
SLA Service Network Throughput Delay Jitter
Packet
Loss
Price Service
Reliability
Security
SLA1
VoIP
LTE 1 MG AG VG VG VP AG VG
LTE 2 AG MG AG MG VP VG AG
WiMAX 1 M M MP AG P VG AG
WiMAX 2 G G G G P AG VG
WiFi 1 VG VG MG AG MP G G
WiFi 2 MG M MG VG MP MG MG
WiFi 3 M MP M AG MP G G
CVideo
LTE 1 MP MG VG G AP AG VG
LTE 2 AG AG AG VG AP VG AG
WiMAX 1 MP M MG AG AP VG AG
WiMAX 2 MG MG G AG VP AG VG
WiFi 1 M MG M VG P G G
WiFi 2 VG VG VG AG P MG MG
WiFi 3 G G M VG P G G
BStreaming
LTE 1 M G VG VG AP AG VG
LTE 2 VG VG AG AG AP VG AG
WiMAX 1 M MG MG VG VP VG AG
WiMAX 2 MG G MG G P AG VG
WiFi 1 VG G M AG P G G
WiFi 2 AG AG G VG P MG MG
WiFi 3 G VG VG AG MP G G
RTGaming
LTE 1 G AG AG VG VP AG VG
LTE 2 G MG VG AG VP VG AG
WiMAX 1 MP MG G AG P VG AG
WiMAX 2 VG AG AG VG VP AG VG
WiFi 1 AG VG VG VG VP G G
WiFi 2 M M MG AG MP MG MG
WiFi 3 P M M AG MP G G
Web
LTE 1 AG AG AG AG VP AG VG
LTE 2 MG M G VG MP VG AG
WiMAX 1 G M G AG P VG AG
WiMAX 2 VG G VG AG P AG VG
WiFi 1 MG MP MG VG MP G G
WiFi 2 VG G M VG MP MG MG
WiFi 3 AG VG AG AG MP G G
SLA2
CVideo
LTE 1 MG G VG AG MP G G
LTE 2 MP M MG VG M G G
WiMAX 1 M MG G AG MP MG MG
WiMAX 2 MP M M AG M MG MG
WiFi 2 G VG VG AG MG G M
WiFi 3 MP G M VG MG P M
BStreaming
LTE 1 M G G VG MP G G
LTE 2 MG MG AG G MP G G
WiMAX 1 M MG MP AG MP MG MG
WiMAX 2 G G MG VG MP MG MG
WiFi 1 G VG MG AG MP MP MP
WiFi 2 AG AG VG VG MP M M
WiFi 3 MG VG VG AG M P M
Web
LTE 2 M MP MG VG M G G
WiMAX 1 MG M G AG MG MG MG
WiMAX 2 VG G AG AG M MG MG
WiFi 1 MG MP M VG MG MP MP
WiFi 2 MG M G VG MG M M
WiFi 3 VG VG AG AG MG P M
70 Mobility Management
Table 3.10 The Available Networks of SLA3 and SLA4.
SLA Service Network Throughput Delay Jitter
Packet
Loss
Price
Service Re-
liability
Security
SLA3
BStreaming
LTE 1 M MG G VG MG MP MP
LTE 2 G G M AG MG M M
WiMAX 1 M G MP VG MG M M
WiFi 1 G G MG AG G VP P
WiFi 2 G AG G VG MG VP P
WiFi 3 MG VG MG AG G VP P
Web
LTE 1 MG MP M G G MP MP
LTE 2 M M G VG G M M
WiMAX 1 MG M M AG G M M
WiMAX 2 VP M AG AG VG P MP
WiFi 1 MG MP M AG G VP P
WiFi 2 AP AP VP G VG VP P
SLA4 Web
LTE 1 MP M M VG VG P P
LTE 2 M M G MG VG P MP
WiMAX 1 VP P M AG AG VP VP
WiMAX 2 P MP MP G VG VP P
WiFi 1 MG G M G AG AP AP
WiFi 2 AP AP VP G AG AP VP
WiFi 3 AP VP P AG AG AP VP
Table 3.11 The Required Services per User.
User SLA Required services
1 SLA1 -VoIP
2 SLA1 -VoIP,-RTGaming, -BStreaming, -Web
3 SLA1 -VoIP, -RTGaming
4 SLA1 -RTGaming
5 SLA2 -CVideo
6 SLA2 -BStreaming
7 SLA3 -BStreaming, -Web
8 SLA3 -Web
9 SLA4 -Web
Table 3.12 Networks’ Classification in respect of TFT, TOPSIS (T) and FAE Results.
User1
User2
User3
User4
User5
User6
User7
User8
User9
❵❵❵❵❵❵❵❵❵❵Networks
Method
TFT
T
FAE
TFT
T
FAE
TFT
T
FAE
TFT
T
FAE
TFT
T
FAE
TFT
T
FAE
TFT
T
FAE
TFT
T
FAE
TFT
T
FAE
LTE 1 1 1 1 2 1 1 1 1 1 2 1 1 4 2 2 4 2 5 4 2 5 2 1 4 4 6 4
LTE 2 3 3 3 3 3 3 3 3 3 4 4 2 2 3 6 1 1 4 1 3 1 3 2 5 3 3 4
WiMAX 1 5 5 5 5 5 5 5 5 5 5 5 4 3 4 3 5 4 7 2 1 4 1 3 1 6 7 3
WiMAX 2 2 2 4 1 2 4 2 2 4 1 2 1 5 5 4 2 3 2 - - - 5 5 3 5 5 4
WiFi 1 4 6 2 4 6 2 4 6 2 3 3 3 - - - 6 6 3 3 5 3 4 4 2 1 1 1
WiFi 2 6 4 6 7 4 6 6 4 6 6 7 5 1 1 1 3 5 1 5 4 2 6 6 6 7 4 4
WiFi 3 7 7 6 6 7 6 7 7 6 7 6 6 6 6 5 7 7 6 - - - - - - 2 2 2
3.1 Related Methodologies 71
0
1
2
3
4
5
6
7
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.12 The TFT’s Network Ranking for User 3 in case of Network Environment Changes.
0
1
2
3
4
5
6
7
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.13 The TFT’s Network Ranking for User 4 in case of Network Environment Changes.
72 Mobility Management
0
1
2
3
4
5
6
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.14 The TFT’s Network Ranking for User 5 in case of Network Environment Changes.
0
1
2
3
4
5
6
7
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.15 The TFT’s Network Ranking for User 6 in case of Network Environment Changes.
3.1 Related Methodologies 73
0
1
2
3
4
5
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.16 The TFT’s Network Ranking for User 7 in case of Network Environment Changes.
0
1
2
3
4
5
6
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.17 The TFT’s Network Ranking for User 8 in case of Network Environment Changes.
74 Mobility Management
0
1
2
3
4
5
6
7
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
NetworkScore
Available Networks
Scenario 1
Scenario 2
Scenario 3
Figure 3.18 The TFT’s Network Ranking for User 9 in case of Network Environment Changes.
3.1 Related Methodologies 75
3.1.5.2 Network Selection using the TF-ANP and the TFT Algorithms for supporting
Medical Services
3.1.5.2.1 Simulation Setup : We consider an heterogeneous network environment consist-
ing of a number of LTE, WAVE and WiMAX networks. Each network supports at least one
of the following medical service types: Live Video, Medical Data, Sensor Data and Clinical
Data. Also, we consider the case where 10 vehicles with patients are moving inside the network
environment and need to be connected to a network which satisfies the requirements of their
services and at the same time complies with their patient health status. The health status of each
patient is evaluated using the Manchester Triage System (MTS) [173] healthcare classification
system, which defines 5 health statuses, called Non-Urgent, Standard, Urgent, Very-Urgent and
Immediate. The Non-Urgent status has the lower risk about patient’s life, while the Immediate
status has the higher one.
3.1.5.2.2 Performance Evaluation : During the network selection process the TF-ANP
method is applied initially, in order to estimate the decision weights per service type and patient
health status, considering the ANP network model proposed in [171]. The criteria used include
throughput, delay, jitter, packet loss, service reliability, security and price. Pairwise comparison
decision matrices are created to evaluate the priority vectors of criteria and to form the fuzzy
Supermatrix per service type and patient health status. Subsequently, the fuzzy Weighted
Supermatrix and, finally, the Limit Supermatrix are obtained. Indicatively, when the patient
health status is evaluated as Non-Urgent, for the Sensor Data service the initial, the weighted
and the limit supermatrices are presented in Tables 3.4, 3.5 and 3.6 respectively. For each
health status, the criteria weights per healthcare service obtained by the corresponding Limit
Supermatrix are presented in Figure 3.19. As illustrated, the weights are proportional to the
constraints of each service as well as to the health status of each patient. In particular, the
weight of the price criterion is low for Immediate health status, resulting in a weight value
which is very close to 0. Accordingly, when the health status is evaluated as Non-Urgent, the
medical risk for the patient is very low and the price criterion becomes more important.
The ranking of the networks alternatives is performed using the TFT algorithm using the
weights of the network selection criteria obtained using the TF-ANP method. The linguistic
terms for the criteria attributes are represented by IVTFNs as shown in Table 4.1. Furthermore,
the available-candidate networks in our simulations at the time of network selection per service
as well as their specifications expressed by linguistic terms are depicted in Table 3.14.
The case of having several medical services of different QoS constraints running at the
vehicle site is also addressed. The network selection is performed in a way that satisfies
multiple groups of criteria per vehicle. The vehicles need to select a network which satisfies
76 Mobility Management
Figure 3.19 The TF-ANP Weights per Service and Patient Health Status.
3.1 Related Methodologies 77
Table 3.13 Linguistic Terms and the Corresponding Interval-Valued Trapezoidal Fuzzy Numbers
used for the Criteria Attributes for the Evaluation of the TFT Algorithm in cases where Medical
Services are used.
Linguistic term Interval-valued trapezoidal fuzzy number
Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.0, 0.9), (0.0, 0.0, 0.0, 0.0, 1.0)]
Very Poor (VP) [(0.01, 0.02, 0.03, 0.07, 0.9), (0.0, 0.01, 0.05, 0.08, 1.0)]
Poor (P) [(0.04, 0.1, 0.18, 0.23, 0.9), (0.02, 0.08, 0.2, 0.25, 1.0)]
Medium Poor (MP) [(0.17, 0.22, 0.36, 0.42, 0.9), (0.14, 0.18, 0.38, 0.45, 1.0)]
Medium (M) [(0.32, 0.41, 0.58, 0.65, 0.9), (0.28, 0.38, 0.6, 0.7, 1.0)]
Medium Good (MG) [(0.58, 0.63, 0.8, 0.86, 0.9), (0.5, 0.6, 0.9, 0.92, 1.0)]
Good (G) [(0.72, 0.78, 0.92, 0.97, 0.9), (0.7, 0.75, 0.95, 0.98, 1.0)]
Very Good (VG) [(0.93, 0.98, 1.0, 1.0, 0.9), (0.9, 0.95, 1.0, 1.0, 1.0)]
Absolutely Good (AG) [(1.0, 1.0, 1.0, 1.0, 0.9), (1.0, 1.0, 1.0, 1.0, 1.0)]
0
0,02
0,04
0,06
0,08
0,1
0,12
0,14
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
NetworkScore
Trapezoidal Fuzzy Topsis results
LTE1 LTE2 LTE3 LTE4 WAVE1 WAVE2 WAVE3 WAVE4 WiMAX1 WiMAX2
Figure 3.20 The TFT Results for each Vehicle.
the requirements of their healthcare services as presented in Table 4.8 considering the health
status of each patient. To achieve this goal the proposed TFT algorithm is applied for each
vehicle. The available networks are ranked as shown in Figure 3.20.
From the obtained results it is clear that the ranking of the network alternatives is in
accordance with the vehicles expectations. For example, vehicle 1 requiring increased QoS
provisioning selects the LTE 1 network which guarantees the best QoS characteristics and
service reliability. In particular, LTE 1 achieves higher ranking than the other networks, due
to the high values of the QoS characteristics and the service reliability factors bearing higher
importance according to the relative ANP weights for the Live Video service. On the contrary,
vehicle 4 whose prior selection criterion is the throughput of the service, selects the WAVE 1
network which satisfies his requirements considering the Clinical Data service constraints and
the Non-Urgent health status of its patient.
The performance of TFT, was evaluated against the ANST [174] and the FAS [175] methods.
A critical weakness of ANST is that it considers only the throughput criterion, while a weakness
of FAS is that it does not support vehicles with more than one service. Therefore, in the case of
FAS only the most demanding service of the vehicle is considered when more than one service
is required. Specifically, for vehicles 5, 7, 9 and 10 FAS is applied only for the Sensor Data
78 Mobility Management
Table 3.14 The Available Wide Coverage Networks for each Service.
Medical
Service
Network Throughput Delay Jitter Packet
Loss
Service
Reliability
Security Price
Live
Video
LTE1 VG AG AG VG AG VG P
LTE2 G MG VG AG VG AG AP
LTE3 AG AG MG VG AG AG VG
LTE4 MP P VG G M P MG
WAVE1 MG MG G VG MG MG AG
WAVE2 AP AP G VP AP AG M
WAVE3 MP M MG G AG G AG
WAVE4 M M VG MG MG MG G
WiMAX1 VG AG VG G AG VG MG
WiMAX2 MG M MP VG MG MG M
Medical
Images
LTE1 MG MG VG AG AG VG P
LTE2 AG AG AG MG VG AG AP
LTE3 AG VG G G AG VG VG
LTE4 M VG G M VG P MG
WAVE1 MG MG AG MG MG G AG
WAVE2 G G VG VG AG AG M
WAVE3 MG MG AG VG MP G AG
WAVE4 G G VG VG MG G G
WiMAX1 MG VP AG G VG AG MG
WiMAX2 VG AG AG VG MP G M
Sensor
Data
LTE1 MP P P VP VG G P
LTE2 M G MG MP MG G AP
LTE3 G G VG VG M G VG
LTE4 MG MP M MG M AG MG
WAVE1 MP MG VG MG AG VG AG
WAVE2 AG AG AG VG VG AG M
WAVE3 G VG AG AG VG G AG
WAVE4 MG AG G MG MG VG G
WiMAX1 MG MP VG G MG MG MG
WiMAX2 G G AG MG MG VG M
Clinical
Data
LTE1 G M VG VG AG VG P
LTE2 VG AG VG AG MG AG AP
LTE3 G G VG AG VG G VG
LTE4 AG VP P VG AP VP MG
WAVE1 VG VG AG AG VG AG AG
WAVE2 G G VG VG M G M
WAVE3 MP P P P M VG AG
WAVE4 G VG G AG MG AG G
WiMAX1 AG VG AP VG G AG MG
WiMAX2 MP MG AG MP MG G M
service. Additionally, for vehicle 6 it is applied only for the Live Video service, whereas for
vehicle 8 it is applied only for the Medical Images service.
Table 3.20 presents the network classification performed by the proposed TFT, the ANST
and the FAS algorithms, respectively. From the analysis of the results we conclude that the
proposed method achieves better performance for the entire vehicles. Indicatively, the TFT
results concerning vehicle 2 are better than the ones obtained from both ANST and FAS, due
to the fact that TFT selects the LTE 1 network which offers AG packet loss, while the ANST
selects the LTE 3 and the FAS select the WAVE that offer G and VG packet loss respectively.
Additionally, TFT provides more reliable results for vehicle 10 by taking into account the
criteria importance for the Medical Images, the Sensor Data and the Clinical Data services as
3.1 Related Methodologies 79
Table 3.15 The Simulated Vehicles for the Evaluation of the TFT Algorithm.
Vehicle Medical Services Patient Health Status
1 Live Video Very urgent
2 Medical Images Urgent
3 Sensor Data Standard
4 Clinical Data Non urgent
5 Live Video & Sensor Data Very urgent
6 Live Video & Medical Images Immediate
7 Medical Images & Sensor Data Very urgent
8 Medical Images & Clinical Data Urgent
9 Sensor Data & Clinical Data Standard
10 Medical Images & Sensor Data & Clinical Data Immediate
Table 3.16 Networks’ Classification in respect of TFT, ANST and FAS Results.
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
❵❵❵❵❵❵❵Networks
Method
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
TFT
ANST
FAS
LTE 1 1 2 1 1 8 3 3 9 7 4 8 9 2 3 7 2 3 1 2 8 7 3 8 3 4 8 7 2 8 7
LTE 2 3 4 2 3 2 10 5 7 5 2 4 4 4 7 5 3 2 2 4 5 5 1 2 10 3 2 5 4 2 5
LTE 3 2 1 4 2 1 9 1 2 1 3 5 1 1 1 1 1 1 4 1 1 1 2 1 9 1 4 1 1 1 1
LTE 4 6 9 7 6 10 2 7 4 10 6 1 6 8 9 10 5 8 7 6 10 10 6 10 2 8 1 10 6 10 10
WAVE 1 4 6 5 4 9 7 2 8 3 1 3 3 3 6 3 4 5 5 3 9 3 4 7 7 2 6 3 3 7 3
WAVE 2 10 10 10 9 5 6 8 1 4 8 6 8 10 10 4 10 9 10 8 4 4 8 5 6 9 3 4 7 4 4
WAVE 3 9 8 9 10 6 4 10 3 9 10 10 7 9 8 9 9 7 9 10 6 9 10 9 4 10 10 9 10 9 9
WAVE 4 7 7 6 5 4 1 4 6 2 5 7 2 5 4 2 7 6 6 5 2 2 5 4 1 5 5 2 5 5 2
WiMAX 1 5 3 3 8 7 5 9 5 8 7 2 10 6 2 8 6 3 3 9 7 8 7 6 5 6 7 8 8 6 8
WiMAX 2 8 5 8 7 3 8 6 3 6 9 9 5 7 5 6 8 4 8 7 3 6 9 3 8 7 9 6 9 3 6
well as the entire set of criteria, while ANST considers only the throughput criterion and FAS
takes into account only the Sensor Data service.
3.1.5.3 Network Selection using the TF-AANP and the TFT-ACW Algorithms for sup-
porting Medical Services
3.1.5.3.1 Simulation Setup : In our experiments, the 5G-VCC topology presented in
Figure 3.21 is simulated. A mobility trace indicating the map of the Syntagma square in
Athens along with road traffic data has been created using the Open Street Map (OSM)
software [176]. Then, the mobility trace has been used as input in the Simulator of Urban
Mobility (SUMO) simulator [177] allowing the production of a realistic mobility pattern for the
simulated vehicles. Furthermore, the network topology is being built upon the map, using the
Network Simulator 3 (NS3) simulator [178]. The network topology includes a heterogeneous
access network environment and a Cloud infrastructure. The access network environment
includes 1 LTE Macrocell, 4 LTE Femtocells, 1 WiMAX Macrocell and 4 WAVE RSUs. The
Cloud infrastructure includes a set of Virtual Machines (VMs) providing Driver Assistance
(DA), Passengers Entertainment and Information (PeNI) and Medical (MED) services. The
DA services include Navigation Assistance (NAV) and Parking Assistance (PRK) services.
Accordingly, the PEnI services include Conversational Video (CV), Voice over IP (VoIP),
Buffered Streaming (BS) and Web Browsing (WB) services. Finally, the MED services include
80 Mobility Management
Live Healthcare Video (LHVideo) [9], Medical Images (MedImages) [10], Health Monitoring
(HMonitoring) [11] and Clinical Data Transmission (CData) [12] services. Furthermore, a
Software Defined Network (SDN) controller provides a centralized control of the entire system.
Table 3.17 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy Numbers
used for the Criteria Attributes for the Evaluation of the TFT-ACW Algorithm.
Linguistic term Interval-valued trapezoidal fuzzy number
Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.0, 0.9), (0.0, 0.0, 0.0, 0.0, 1.0)]
Very Poor (VP) [(0.01, 0.02, 0.03, 0.07, 0.9), (0.0, 0.01, 0.05, 0.08, 1.0)]
Poor (P) [(0.04, 0.1, 0.18, 0.23, 0.9), (0.02, 0.08, 0.2, 0.25, 1.0)]
Medium Poor (MP) [(0.17, 0.22, 0.36, 0.42, 0.9), (0.14, 0.18, 0.38, 0.45, 1.0)]
Medium (M) [(0.32, 0.41, 0.58, 0.65, 0.9), (0.28, 0.38, 0.6, 0.7, 1.0)]
Medium Good (MG) [(0.58, 0.63, 0.8, 0.86, 0.9), (0.5, 0.6, 0.9, 0.92, 1.0)]
Good (G) [(0.72, 0.78, 0.92, 0.97, 0.9), (0.7, 0.75, 0.95, 0.98, 1.0)]
Very Good (VG) [(0.93, 0.98, 1.0, 1.0, 0.9), (0.9, 0.95, 1.0, 1.0, 1.0)]
Absolutely Good (AG) [(1.0, 1.0, 1.0, 1.0, 0.9), (1.0, 1.0, 1.0, 1.0, 1.0)]
3.1 Related Methodologies 81
Table 3.18 The Available Networks.
Service SLA 1 SLA 2 SLA 3 Network Throughput Delay Jitter Packet Loss Service Reliability Security Price
NavigationAssistance
(NAV)
LTE Macro G MG VG AG VG AG VG
LTE Femto 1 VG AG VG VG AG MG P
LTE Femto 2 AG G AG G VG G G
LTE Femto 3 G MG G MG G AG P
LTE Femto 4 AG AG MG AG G G AP
WiMAX Macro G AG G VG AG VG VP
WAVE 1 VG MG VG AG VG AG G
WAVE 2 MG MG VG VG G G AP
WAVE 3 MG MG G VG MG MG M
WAVE 4 M M MG VG MG MG MP
ParkingAssistance
(PRK)
LTE Macro MG M G VG VG AG MP
LTE Femto 1 AG AG AG AG AG VG G
LTE Femto 2 VG AG M VG AG G AG
LTE Femto 3 G VG MG AG VG AG MG
LTE Femto 4 MG G M G VG G G
WiMAX Macro G M M AG MG M MP
WAVE 1 M MP MG VG G G VG
WAVE 2 MG M M AG M M M
WAVE 3 AG G G AG MG MG P
WAVE 4 G M AG AG MG G G
ConversationVideo
(CV)
LTE Macro AG AG AG VG VG AG G
LTE Femto 1 MP MG VG AG AG VG AP
LTE Femto 2 G G MG VG AG MG M
LTE Femto 3 AG VG AG G VG G P
LTE Femto 4 G VG VG AG MG AG MG
WiMAX Macro MP M MG G G G MP
WAVE 1 G G VG VG G G M
WAVE 2 MG MG AG VG G MG AG
WAVE 3 MG MG G AG MG VG MP
WAVE 4 MP MP MG AG MG G P
VoiceoverIP
(VoIP)
LTE Macro VG VG AG AG VG AG AP
LTE Femto 1 M G VG VG AG VG G
LTE Femto 2 G VG MG AG VG G MG
LTE Femto 3 MG G G VG G MG MP
LTE Femto 4 VG AG VG AG VG VG P
WiMAX Macro M G MG MG G G M
WAVE 1 M MG AG AG G G VG
WAVE 2 MG M VG AG MG M M
WAVE 3 VG AG VG AG MG VG G
WAVE 4 G VG G AG MG G AG
BufferedStreaming
(BS)
LTE Macro G MG VG AG VG AG VG
LTE Femto 1 VG AG AG VG AG VG P
LTE Femto 2 AG VG VG MG MG AG G
LTE Femto 3 G MG VG G VG G M
LTE Femto 4 AG AG AG VG G G P
WiMAX Macro G AG G VG AG VG VP
WAVE 1 VG MG VG AG VG AG G
WAVE 2 MG MG VG VG G G AP
WAVE 3 MG MG G VG MG MG M
WAVE 4 M M MG VG MG MG MP
WebBrowsing
(WB)
LTE Macro MG M G VG VG AG MP
LTE Femto 1 AG AG AG AG AG VG G
LTE Femto 2 G G M G G VG G
LTE Femto 3 AG AG MG AG VG MG M
LTE Femto 4 VG G G VG MG G MG
WiMAX Macro G VG MG G M VG M
WAVE 1 M MP MG VG G G VG
WAVE 2 MG M M AG M M M
WAVE 3 AG G G AG MG MG AP
WAVE 4 G M AG AG MG G G
LiveHealthcareVideo
(LHVideo)
LTE Macro MG MG G VG MG VG MP
LTE Femto 1 MP MG VG AG AG VG AP
LTE Femto 2 G VG AG AG VG G G
LTE Femto 3 VG AG G AG G MG M
LTE Femto 4 MG G VG G AG AG G
WiMAX Macro MP M MG G G G MP
WAVE 1 G G VG VG G G M
WAVE 2 MG MG AG VG G MG AG
WAVE 3 AG AG AG AG VG AG G
WAVE 4 MP MP MG AG MG G P
MedicalImages
(MedImages)
LTE Macro M MG AG AG G AG VG
LTE Femto 1 M G VG VG AG VG G
LTE Femto 2 AG AG VG AG VG AG P
LTE Femto 3 VG MG G MG G MG MP
LTE Femto 4 G G VG G AG G MP
WiMAX Macro M G MG VG G G M
WAVE 1 VG VG AG AG VG AG AP
WAVE 2 MG M VG AG MG M M
WAVE 3 VG AG VG AG MG VG G
WAVE 4 G VG G AG MG G MP
HealthMonitoring
(HMonitoring)
LTE Macro G MG VG AG VG AG VG
LTE Femto 1 VG AG AG VG AG VG P
LTE Femto 2 AG G G G MG G VG
LTE Femto 3 VG AG MG AG MG VG G
LTE Femto 4 G VG VG G G G VG
WiMAX Macro G AG G VG AG VG VP
WAVE 1 VG MG VG AG VG AG G
WAVE 2 MG MG VG VG G G AP
WAVE 3 MG MG G VG MG MG M
WAVE 4 M M MG VG MG MG MP
ClinicalDataTransmission
(CData)
LTE Macro MG M G VG VG AG MP
LTE Femto 1 AG AG AG AG AG VG P
LTE Femto 2 AG VG MG VG VG G M
LTE Femto 3 G AG M G G MG M
LTE Femto 4 VG G G AG VG AG G
WiMAX Macro G MG VG G VG MG AG
WAVE 1 M MP MG VG G G AG
WAVE 2 MG M M AG M M M
WAVE 3 AG G G AG MG MG P
WAVE 4 G M AG AG MG G G
82 Mobility Management
Table 3.19 The Simulated Vehicles for the Evaluation of the TFT-ACW Algorithm.
Vehicle SLA Vehicular Services Patient Health Status
1 1 PRK, CV, BS, WB, LHVideo Immediate
2 1 WB, MedImages, HMonitoring Non-Urgent
3 1 NAV, VoIP, HMonitoring Standard
4 1 NAV, WB, CData Urgent
5 2 CV, LHVideo, MedImages Non-Urgent
6 2 CV, WB, MedImages Immediate
7 2 WB, HMonitoring Very urgent
8 3 WB, MedImages, CData Standard
9 3 NAV, HMonitoring, CData Urgent
10 3 WB, MedImages, HMonitoring Immediate
Table 3.20 The Classification of the Networks according to TFT-ACW, TFT and FSAW Results.
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
❵❵❵❵❵❵❵Networks
Method
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
TFT-ACW
TFT
FSAW
LTE Macro 4 3 3 2 2 2 1 1 1 2 2 1 2 2 1 2 1 1 1 2 2 1 1 2 2 3 4 3 2 3
LTE Femto 1 3 2 1 1 1 1 - - - - - - - - - - - - - - - - - - 3 1 1 2 1 1
LTE Femto 2 2 1 2 3 4 3 - - - - - - - - - - - - - - - - - - - - - - - -
LTE Femto 3 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LTE Femto 4 - - - - - - - - - 1 4 5 - - - - - - - - - - - - - - - - - -
WiMAX Macro 7 7 8 6 7 7 3 3 2 4 5 3 4 4 4 4 4 4 3 3 3 3 3 3 4 2 3 4 5 5
WAVE 1 5 4 4 4 3 4 2 2 3 3 1 2 3 3 3 1 3 3 2 1 1 2 2 1 1 4 2 1 3 2
WAVE 2 6 6 7 8 8 8 5 5 5 6 7 7 - - - - - - - - - - - - - - - - - -
WAVE 3 1 5 5 5 5 6 4 4 4 7 6 6 1 1 2 3 2 2 4 4 4 4 4 4 5 5 5 5 4 4
WAVE 4 8 8 6 7 6 5 6 6 6 5 3 4 - - - - - - - - - - - - - - - - - -
3.1 Related Methodologies 83
Vehicle 8Vehicle 8
Vehicle 7Vehicle 7
Vehicle 6Vehicle 6
Vehicle 5Vehicle 5
Vehicle 4Vehicle 4
Vehicle 3Vehicle 3
Vehicle 1Vehicle 1
Vehicle 10Vehicle 10
Vehicle 9Vehicle 9
LTE MacroLTE Macro
WAVE RSU2
WAVE RSU3
WAVE RSU4
WAVE RSU1
LTE
Femto1
LTE
Femto3
LTE
Femto2
LTE
Femto2
LTE
Femto4
WiMAX
Macro
WiMAX
Macro
Cloud
VM
Services
VM
Services VM
Services
VM
ServicesVM
Services
VM
Services
...
...
...
SDN
controller
SDN
controller
Vehicle 2Vehicle 2
Heterogeneous Access Network Environment
Figure 3.21 The Simulated Topology for the Evaluation of the TF-ANP and the TFT Algorithms.
Three Service Level Agreements (SLAs) are defined. Each SLA determines the available
networks for each service type. SLA1 supports all the available networks while SLA3 supports
only a small subset of the available networks.
Table 4.1 presents the lingustic terms and the corresponding interval-valued trapezoidal
fuzzy numbers used for the criteria attributes of the available networks, while Table 3.18
presents the corresponding specifications per service and SLA of each network, in terms of
throughput, delay, jitter, packet loss ratio, price, security and service reliability.
We consider the case where 10 vehicles with patients are moving inside the network
environment and need to be connected to a network which satisfies the requirements of their
services and at the same time complies with their patient health status, as well as with their
respective SLA agreements. The health status of each patient is evaluated using the Manchester
Triage System (MTS) [173] healthcare classification system, which defines 5 health statuses,
called Non-Urgent, Standard, Urgent, Very-Urgent and Immediate. The Non-Urgent status has
the lower risk about patient’s life, while the Immediate status has the higher one.
3.1.5.3.2 Performance Evaluation : During the network selection process initially the
relative importance ˜ω ˜ps of each service is considered with respect to the patient health status.
Figure 3.22 presents the importance of each service per patient health status, as it is obtained
84 Mobility Management
using the TF-AANP method. As it can be observed, the importance of the MED services
depends on the patient health status. Indicatively, when the patient health status becomes
immediate, the MED services obtain higher importance than the DA and the PEnI services.
Accordingly, when the patient health status becomes Non-Urgent, the relative importance of
the services is quite similar. Subsequently, the TF-AANP estimates the decision weights we
per service type and patient health status, using the ANP network model proposed in [171].
The criteria weights per SLA for the DA and the PEnI services are presented in Figures 3.23
and 3.24, respectively. Also, for each possible health status, the criteria weights per healthcare
service for the MED services are presented in Figure 3.25. As illustrated the weights are
proportional to the constraints of each service as well as to the health status of each patient.
In particular, the weight of the price criterion is low for Immediate health status, resulting in
a weight value which is very close to 0. Accordingly, when the health status is evaluated as
Non-Urgent, the medical risk for the patient is very low and the price criterion becomes more
important.
Considering the relative importance ˜ω ˜ps of each service and the criteria weights we for the
DA, PEnI and MED services, the final criteria weights are estimated for each vehicle with
respect to the health status of onboard patients, as well as to the SLA of each vehicle (Figure
3.26).
The ranking of the network alternatives is performed using the TFT-ACW algorithm using
the afforementioned criteria weights for each vehicle.
Figure 3.22 The Importance of each Service per Patient Health Status.
Subsequently, the experimental results of the TFT-ACW method are compared with the
ones obtained using the TFT [171] and the FSAW [179] algorithms (Table 3.20). When the
3.1 Related Methodologies 85
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
SLA 1 SLA 2 SLA 3 SLA 1 SLA 2 SLA 3
Navigation Assistance Parking Assistance
TF-AANPweight
Criteria Weights for Driver Assistance services per SLA
Throughput Delay Jitter Packet loss Service Reliability Security Price
Figure 3.23 The TF-AANP Criteria Weights for the DA Services per SLA.
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
SLA 1 SLA 1 SLA 2 SLA 1 SLA 2 SLA 1 SLA 2 SLA 3
VoIP Conversational Video Buffered Streaming Web
TF-AANPweight
Criteria Weights for Passengers Entertainment and Information services per SLA
Throughput Delay Jitter Packet loss Service Reliability Security Price
Figure 3.24 The TF-AANP Criteria Weights for the PeNI Services per SLA.
patient health status is Non-Urgent (vehicles 2 and 5) or Standard (vehicles 3 and 8) the results
of TFT-ACW and TFT are similar, due to the similar relative importance considered by the
TFT-ACW for each service. However, when the patient health status gets worse, the TFT-ACW
assigns higher importance to the MED services and selects the most appropriate network to
satisfy their strict constraints. Indicatively, in the case of vehicle 1, TFT-ACW selects the
WAVE 3 network, which provides VG for service reliability, as well as AG for throughput,
delay, jitter, packet loss and security, for the LHVideo medical service. On the contrary, the
results of both TFT and FSAW are negatively affected by the existence of non medical services
in the vehicle 1 ignoring the immediate health status of the patient. Specifically, TFT selects
the LTE Femto 2 network, which provides worse specifications for the LHVideo service (e.g. G
for throughput and VG for delay), while FSAW selects the LTE Femto 1 network, which also
provides worse specifications for the aforementioned medical service (e.g. MP for throughput
and MG for delay).
86 Mobility Management
Figure 3.25 The TF-AANP Criteria Weights for the MED Services per SLA and Patient Health
Status.
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
TF-AANPweight
The TF-AANP weights for each vehicle
Throughput Delay Jitter Packet loss Service Reliability Security Price
Figure 3.26 The TF-AANP Weights for each Vehicle.
3.2 Mobility Management Schemes for 5G Wireless Networks 87
3.2 Mobility Management Schemes for 5G Wireless Networks
3.2.1 Existing Mobility Management Schemes
In this section an overview of the existing mobility management schemes is presented. The
mobility management process consists of the handover (HO) initiation, the network selection
and the HO execution subprocesses. The consideration of the subprocesses that each scheme
implements provides a useful view about each scheme’s functionalities.
Some schemes implement only the HO initiation subprocess. These schemes aim at the
evaluation of the necessity to perform a handover, by avoiding either unnecessary or delayed
HOs, in order to ensure the continuity of vehicular services. Several parameters can be
considered. The most common ones include signal quality factors, criteria that affect the
vehicular services, the vehicle’s velocity, the cells’ coverage area and the operators’ policies.
Also, it should be noted that in these cases, the network selection and the HO execution must
be performed using third party algorithms.
The Street Specific Handover for Vehicular Terminals (SSHVeT) [180] algorithm considers
street aware parameters to evaluate the necessity of performing a handover. Parameters such as
vehicle velocity, road direction, Reference Signals Received Power (RSRP) [181] and radio
propagation characteristics are considered for the HO initiation. The algorithm adapts the
corresponding handover thresholds considering the obtained parameter values for each street,
in order the ping-pong effect to be minimized.
The Improved Inter-Network Handover (IINH) [182] estimates the necessity of performing
a handover considering the cell size and the vehicle velocity, which affect the time that a vehicle
will remain inside the coverage area of a cell. The vehicle makes the decision of performing a
handover considering the aforementioned parameters. It should also be noted that the cell size is
estimated considering the RSS, the path loss, the required transmission power from the vehicle
to the base station, and the geographical terrain information. The scheme is implemented in the
network layer using the functionalities offered by Mobile IP (MIP) to manipulate the vehicle
mobility.
The Decision Process for Vertical Handover in Vehicular Networks (DPVHO) [183] algo-
rithm estimates the necessity to perform a HO when the vehicle moves from an area covered by
a network to an area covered by another network. It aims at reducing the HOs failure rate and
the unnecessary HOs using a utility function based mechanism where parameters such as RSS,
vehicle trajectory, cell radius and path loss exponent of each place are considered.
The Context Aware Handover Policy (CAHP) in [184] scheme considers an LTE network
topology where both Macrocells and Femtocells exist. A load-aware algorithm is described,
which determines two handover thresholds, namely the γM
th and the γF
th, for Macrocells and
88 Mobility Management
Femtocells, respectively. Both of these thresholds are evaluated, considering the Reference
Signal Received Power (RSRP) threshold defined in LTE [14], as well as network load infor-
mation. When RSRP drops below the corresponding γth threshold, a Time-to-Trigger (TTT)
timer is activated, which is initialized to a certain value T, considering parameters such as the
cell transmission power, the distances between the available cells, the path loss, the carrier
frequency, the network traffic load and the user velocity. During the countdown, if RSRP
returns to values above the corresponding γth threshold, the timer is deactivated. Otherwise,
when the timer becomes equal to zero, the handover is initiated and the user is transferred to
the network with the highest RSRP.
The Context Aware Load Balancing (HO-CALB) [185] is another HO initiation scheme. It
considers the scenario where both WiFi and WiMAX networks coexist. A network load aware
algorithm distributes the traffic load to the WiFi and the WiMAX networks considering the
available bandwidth of each network. Each user has a set of services with strict QoS constraints.
If the observed QoS drops below a threshold, a handover policy instructs the users to perform a
handover.
Several schemes implement only the network selection subprocess. These algorithms aim
at the selection of the most appropriate access network for each vehicular user among a set
of network alternatives. Similar to the HO initiation algorithms, several parameters can be
considered, including Quality of Service (QoS) or Quality of Experience (QoE) factors, user
preferences and operators’ policies. In these cases, the HO initiation and the HO execution
must be performed using third party algorithms.
The Mobility Aware Handover in Ultra Dense Vehicular Environment (MAH-UDVE) [186]
scheme considers the direction of a vehicle’s mobility to select the most appropriate network.
The vehicle movement is statistically analyzed in order to create a set of possible next cells.
Subsequently, four different approaches can be applied to select the most appropriate cell from
the aforementioned set. The first approach selects the nearest cell, while the second approach
selects the next cell that exists in the same street in the same direction with the direction of
vehicle movement. The third approach selects the next cell that exists in the same street, but in
the opposite direction of the vehicle’s movement. Finally, the fourth approach selects the cell
with the lowest load.
The Intelligent Network Selection (INS) [187] scheme implements the network selection
process for supporting audio and video streaming vehicular services in heterogeneous network
access environments. A utility function which considers the SNR, the channel capacity and the
connection life time parameters is used. For the estimation of the connection lifetime parameter
the vehicle’s velocity and the cell radius are also considered. The candidate network which
obtains the higher score from the proposed utility function is selected.
3.2 Mobility Management Schemes for 5G Wireless Networks 89
The Technique for Order Preference by Similarity to Ideal Solution (TOPSIS) [188][189]
algorithm performs the selection of the best network access technology by considering contra-
dictory selection criteria. The main concept of the TOPSIS algorithm is that the best alternative
network should have the shortest distance from the positive ideal solution and the longest
distance from the negative ideal solution. The criteria that could be considered include the
network throughput, the delay, the jitter, the packet loss ratio, the network usage price, the
security and the service reliability. Also, the importance of these criteria can be estimated either
using the Analytic Hierarchy Process (AHP) [190] or the Analytic Network Process (ANP)
[191] method.
The Simple Additive Weighting (SAW) [188] considers multiple criteria to perform the
network selection. Firstly, the criteria weights are estimated using a method such as AHP or
ANP. Subsequently, for each network alternative, the criteria values are normalized. Then, each
value is multiplied with the corresponding weight in order the weighted criteria values to be
calculated. Finally, the weighted criteria values are summarized in order to estimate the overall
rating of the network alternative. The network with the highest rate is finally selected.
The Multiplicative Exponent Weighting (MEW) [188] method is similar to SAW. However,
in MEW the weighted criteria values are multiplied with each other to estimate the overall
rating of the network alternative.
The Gray Relational Analysis (GRA) [192] analyzes the relationship grade between the
network alternatives and the ideal solution to perform the network selection. The ideal solution
is calculated first. Subsequently, the similarity of each alternative network with the ideal
solution is estimated using the Grey Relational Coefficient (GRC) [193]. The network with the
highest similarity to the ideal solution is selected.
The concept of the Distance to Ideal Alternative (DIA)[188] algorithm is similar to the
concept of TOPSIS. Firstly, DIA estimates the positive and the negative ideal solutions. Then,
the Manhattan distance [194] of each network from the positive and from the negative solution
is calculated. The network that has the shortest distance from the positive ideal solution and the
longest distance from the negative ideal solution is selected.
The Weighted Product Method (WPM) [195] for each alternative network raises the nor-
malized criteria values to the corresponding criteria weights values. Subsequently, the method
calculates the product of the weighted values. The network with the highest product is finally
selected.
In Quantum-inspired Immune Clonal Algorithm for Network Selection (QICA-NS) [196]
two utility functions are used for network selection, one for the user and one for the network.
The user utility function considers user related parameters, such as the user preferences, his
moving velocity and his monetary budget. Accordingly, the network utility function considers
90 Mobility Management
network related parameters, such as the network load, the price and the network QoS which is
estimated using TOPSIS.
Sometimes many users have similar trajectories as they move. This situation becomes
more frequent in the case of vehicular networks, since each vehicle usually serves multiple
passengers. Consequently, many users with similar positions and requirements need to perform
a network selection, usually considering the same network alternatives. In such cases, increased
computational overhead arises from the decision process, since this process runs independently
for each user. To address this issue, algorithms for performing group handover have been
proposed in the research literature. An algorithm of this category groups users with similar
trajectories in order to perform the network selection once for the entire user group, thus
releasing usable system resources.
The Group Vertical Handover using Time Window (GVHO-TW) [197] distributes the MTs
HO requests in a time sequence. Thus, each MT performs network selection using a utility
function when its turn comes, considering the decision of all the previous MTs in order to
select the most appropriate network not only to satisfy its requirements, but also to achieve a
satisfactory load distribution to the available access networks.
Although GVHO-TW avoids the calculation of simultaneous decisions of multiple MTs, ad-
ditional handover delays occur since each MT waits for its turn in order to perform the network
selection. To address this issue, the Group Vertical Handover with Probability Distribution
(GVHO-PD) [197] scheme uses a probability distribution vector instead of a time window. This
vector contains a value for each available network, which determines the probability of the
network to be selected from the MTs, considering its performance. Subsequently, each MT
generates a random MT probability value and compares it with the values of the aforementioned
probability vector. The network with the closest probability to the random MT probability
value is selected. Thus, the MTs are distributed to the available networks.
Although the GVHO-PD scheme distributes probabilistic the workload to the available
networks, it does not optimize the entire system performance. To address this issue the Network
Assisted Group Vertical Handover (NA-GVHO) [197] scheme does not use a probability vector,
but it collects information from both the networks and the MTs. Then, each MT performs
the network selection using a Multi Attribute Decision Making (MADM) algorithm which
considers both the MT’s requirements and the current workload of each network, in order to
distribute the workload to the available networks.
In general, there is a rate of uncertainty in characterizing performance measurements as well
as rates of influence of performance metrics. Therefore, fuzzy MADM (FMADM) methods
expressing uncertain quantities by fuzzy numbers have received the interest of many researchers
in decision theory. In particular several FMADM network selection methods are suggested
3.2 Mobility Management Schemes for 5G Wireless Networks 91
utilizing linguistic variables, triangular fuzzy numbers, trapezoidal fuzzy numbers etc. to model
network attributes and their respective weights. The use of fuzzy logic for network selection
requires the definition of logic rules from specialists with thorough knowledge of the behavior
of the available access networks in various conditions.
The Trapezoidal Fuzzy TOPSIS (TFT) [171] deals with the network selection process. It
is a fuzzy version of the TOPSIS algorithm. TFT uses linguistic values for evaluating the
criteria attributes, while each linguistic value is represented by an Interval Valued Trapezoidal
Fuzzy Number (IVTFN) [198]. The criteria considered for the candidate networks ranking
include throughput, delay, jitter, packet loss, price, security and service reliability. The Analytic
Network Process (ANP) [191] is used for the estimation of the criteria weights indicating the
importance of each criterion. The network that accomplishes the higher TFT rank is selected.
The Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW) [66] is an
improved version of the TFT algorithm. It deals with the satisfaction of the constraints of
multiple vehicular services, in cases where MED services coexist with other service types
in the vehicular environment. Specifically, DA services, PEnI services and MED services
are considered that provided to vehicular users. The presence of MED services affects the
importance of other services in situations where patients with immediate health status exist
within the vehicle. The criteria used for network evaluation include throughput, delay, jitter,
packet loss, service reliability, security and price. The Trapezoidal Fuzzy Adaptive Analytic
Network Process (TF-AANP) is also proposed for the estimation of the services importance as
well as of the corresponding criteria weights, which are adapted considering the health status
of onboard patients and the Service Layer Agreement (SLA) of each vehicle.
In Intelligent Access Selection using Fuzzy Neural Network (IAS-FNN) [199] the concepts
of fuzzy logic, neural networks and utility functions are combined to perform network selection.
The proposed method makes use of a fuzzy neural network which obtains network, user
and terminal related input criteria and evaluates the performance of each access network.
The attributes of the criteria are defined through utility functions and processed through the
fuzzification, interference and defuzzification layers of the neural network.
It should also be noted that some schemes implement only the HO execution. These
algorithms determine the signaling that should be performed in order the HO to be successfully
completed. A critical parameter that should be satisfied is the HO delay which is directly
affected by the aforementioned signaling. Also, in the case of such algorithms, the HO
initiation and the network selection must be performed using third party algorithms.
In Bulk Fast PMIPv6-based Network Mobilty (BFP-NEMO) [200], one or more RSUs are
controlled by a Mobility Management Entity (MME) [201], which is called Mobile Access
Gateway (MAG). The vehicles that are inserted in a MAG domain are grouped. Then, the
92 Mobility Management
corresponding MAG pre-establishes a bidirectional tunnel between the vehicles’ group and
the candidate neighboring MAGs. Each neighboring MAG caches the data for each vehicle of
the aforementioned group. Subsequently, when a vehicle of the group is connected to the next
RSU, the corresponding MAG forwards the cached data to the vehicle.
The Enhanced Proxy Fast-handover Mobile IPv6 for Vehicular Networks (ePFMIPv6)
[202] scheme implements a proactive Layer 3 handover mechanism. The concept of Mobile
Access Gateway (MAG) is considered in this scheme as well. The issue of the simple PFMIPv6
protocol, where the next MAG waits to receive a Handover Acknowledge (HAck) [203] message
from the serving MAG (although the vehicle has arrived to it) to start the data forwarding
to vehicles, is resolved. Specifically, when the serving MAG services the vehicle, it also
establishes a tunnel with each neighboring MAG which is considered as a candidate next
MAG for the vehicle according to its RSS. When the vehicle arrives to its next MAG, its data
are immediately forwarded to it through the aforementioned tunnel, without waiting for the
HAcK message. Finally, when the HAcK message is received by the next MAG, the tunnel is
abolished and the data which follows are forwarded to the vehicle by the next MAG without the
tunnel. In this case, the "next MAG" which is now considered as the serving MAG establishes
a tunnel with each neighboring candidate next MAG and so on.
Schemes that implement more than one mobility management subprocesses have also been
proposed in the research literature. Many of these schemes implement both HO initiation and
network selection.
The Predictive Handover Mechanism for Video Streaming in Cloud Based Urban VANET
(PHMVV) [204] scheme defines a list of available networks is created for each vehicle con-
sidering its velocity, its distance from each network, as well as its moving direction. The
assumption that the vehicle knows its geographical position, as well as the positions of the
available networks, is made. Each vehicle monitors the link quality of the candidate networks,
considering their Signal to Noise Ratio (SNR), Bit Error Rate (BER) and Packet Error Rate
(PER) parameters. If a network alternative has higher link quality than the vehicle’s current
network, the vehicle performs a handover to this alternative.
Another scheme that implements both HO initiation and network selection is the Mobility
Aware Handover for Smart Cities Environment (MAH-SCE) [205]. MAH-SCE uses traffic
information that is gathered by sensors that are deployed in a Smart City [206] environment, to
perform the HO initiation and the network selection. The scheme decides when to initiate a
handover as a function of the aforementioned sensor data about the road traffic, as well as the
perceived SNR. Subsequently, the vehicles with velocity up to 16 m/s consider both Macrocells
and Femtocells as alternatives for performing a handover to them. In this case, if Femtocells
exist inside the vehicle’s area, the scheme selects the Femtocell which has the higher estimated
3.2 Mobility Management Schemes for 5G Wireless Networks 93
time that the vehicle will remain connected without a need to perform a handover to another
cell. On the contrary, if the vehicle velocity is higher than 16 m/s only the Macrocells are
considered as alternatives and the one that maximizes the time that the vehicle will remain
connected to it, is selected.
The Speed-based Vertical Handover (S-VHO) [207] scheme also implements the HO
initiation and the network selection subprocesses of the HO management. During the HO
initiation, the algorithm considers the vehicle’s velocity, the ingress time of the vehicle to the
current cell and the geographical position of the vehicle (using its GPS) to calculate the cell
crossing time. Subsequently, considering both the estimated cell crossing time and the observed
throughput, the algorithm decides when a HO must be initiated. Afterwards, the alternative
network that maximizes the throughput is selected and, then, the algorithm is deactivated for
a time period T in order the ping-pong effect to be reduced. Finally, when the algorithm is
reactivated it estimates when the next HO must be initiated.
The Media Independent Handover using Predictive Geographical Information (MIH-PGI)
[208] defines a MIH-oriented HO mechanism for ensuring the continuity of the vehicular
services and the minimal handover latency. During the HO initiation the vehicle estimates the
appropriate time to perform a handover by predicting the behavior of its current network link
quality based on the geographic information received from the Media Independent Information
Services (MIIS) component of the MIH protocol, about the network access point position
as well as the velocity of the vehicle. Subsequently, the vehicle lists the available candidate
networks, while the next network is selected considering the estimated time duration that the
vehicle will remail inside the coverage area of each candidate network. Thus, the network
which maximizes this time is selected in order to minimize the number of future handovers.
The Cognitive Vertical Handover for Vehicular Communication (CVHO) [209] scheme
considers multiple criteria to perform mobility management in a cognitive radio vehicular
environment. The handover initiation considers parameters such as the RSS, the available
bandwidth, the delay, the network load, the usage cost, the vehicle velocity and the service
type, to evaluate the necessity of performing a VHO. Subsequently, the network selection is
performed using the Analytic Hierarchy Process (AHP) [190] method using the aforementioned
criteria. An Artificial Neural Network (ANN) [210] is used to train the scheme to adapt its
handover threshold in order to take the reflex action to avoid either unnecessary handovers
or link-down situations. The ANN is trained considering the success or the failure of all the
previous handover initiation and network selection decisions.
The Auction Approach for Mobility Prediction (AAMP) [211] scheme defines a group
based HO management mechanism which aims to maximize system throughput, while at
the same time to minimize the network load when multiple vehicles perform simultaneous
94 Mobility Management
handovers. It assumed that each vehicle is equipped with a GPS device. When a vehicle reaches
the edge of its current network’s coverage, it triggers a VHO, while at the same time it reports
its position to a Vertical Handover Decision (VHD) controller, which could be considered as an
SDN controller for HO functionalities implementation. When a VHD controller receives a HO
request from a vehicle, it creates a list with the candidate networks for the vehicle considering
the vehicle’s position. Thus, considering the vehicle’s velocity and position, the VHD controller
predicts the entrance time and the exit time of the vehicle from each candidate network. When
multiple vehicles of similar positions trigger a handover, the VHD controller groups them.
Subsequently, an auction based [212] algorithm selects the most appropriate network for the
aforementioned group of vehicles in order the total throughput of the group to be maximized.
Thus, the network selection is performed once for the entire group of vehicles and not once per
vehicle, thus minimizing the network load occurring from the decision process.
The Vertical Handover for Vehicular Cloud Computing Systems (VHO-VCC) [67] scheme
takes into account the vehicle’s velocity as well as its current connection type. A two step HO
algorithm that reduces operation costs and optimizes mobility management is applied. Initially,
a HO initiation process evaluates the necessity to perform handover using a Mamdani inference
system [213] which evaluates the user satisfaction grade. When the user satisfaction drops
below a predefined threshold, which depends on the vehicle’s SLA, the network selection is
performed using TFT in order to select the most appropriate network alternative considering
both the vehicular service requirements and the operators’ policies.
The Geolocation-based Multi ACcess network Handover algorithm for vehicUlar envi-
ronments (GEO-MACHU) [214] algorithm implements three tasks, namely the Networking,
the Neighborhooding and the Decision Making task. The Networking task performs the HO
initiation considering context-aware information about the current network provided by the
Media Independent Event Service (MIES) and by the Media Independent Command Service
(MICS) [215] of the IEEE 802.21 MIH protocol (e.g. information about link-down events).
The Neighborhooding task collects information about the available networks in the vehicle’s
location using the Media Independent Information Service (MIIS) [216] of the MIH protocol
. The gathered information is considered by the Decision Making task, which performs the
network selection using the TOPSIS algorithm.
The Hybrid Communication Approach (HCA) [217] scheme defines two network interface
types, namely the IEEE 802.11p network access technology which is considered as the primary
interface, while the 3GPP LTE is considered as the secondary. By default, a vehicle is connected
to the primary interface. A QoS aware HO initiation algorithm is applied, which instructs the
vehicle to perform handover to the secondary interface when the observed packet loss of the
provided services exceeds a maximum acceptable threshold. Thereafter, a timer is activated
3.2 Mobility Management Schemes for 5G Wireless Networks 95
specifying the time interval that the user remains connected to a secondary interface. When
the timer expires and the estimated packet loss ratio of the primary interface is lower than the
maximum acceptable threshold, the vehicle performs a handover back to the primary interface.
The Velocity Aware Handover (VAH) [218] HO management scheme defines two network
tiers, namely the tier-1 consisting of Macrocells and the tier-2 consisting of Femtocells. Four
vertical handover strategies are considered, namely the Best Connected (BC), the Femto
Skipping (FS), the Femto Disregard (FD) and the Macro Skipping (MS). The BC strategy is
applied to static users and to users with Low mobility, while both Macrocells and Femtocells
are considered as alternatives. The user connects to a Macrocell if P1 ·B1 ·R−η
1 > P2 ·B2 ·R−η
2
is satisfied, or to the nearest Femtocell if P1 ·B1 ·R−η
1 < P2 ·B2 ·R−η
2 is satisfied, where P is the
transmission power, B is the bias factor, R is the user distance and η is the pathloss exponent for
each tier. The FS strategy considers users with Medium mobility. The Femtocells alternatives
are skipped to reduce the handover rate, when P1 ·B1 ·R−η
1 < P2 ·B2 ·R−η
2 . In the FD strategy,
which is applied to users with High mobility, the user always skips the available Femtocells and
connects only to the available Macrocells. Finally, in the MS strategy, for users with extremely
High mobility, the user skips the entire set of Femtocells as well as some of the Macrocells.
Similarly to the FMADM network selection algorithms, some schemes that perform both
HO initiation and network selection apply the operating principles of fuzzy logic. In these
cases, as the number of selection criteria and the available networks increases, the rules become
more complex, struggling to define effective policies either for evaluating the necessity to
perform a handover or for selective the most appropriate network for the user. Accordingly,
the use of fuzzy logic based solutions is limited to handover decision schemes with a reduced
number of selection criteria and networks.
In the Fuzzy Logic Based Vertical Handover (FLB-VHO) [219] scheme, the RSS-based
handover initiation mechanism is applied initially. Then, during the second phase, a triangular
fuzzy MADM algorithm that considers parameters such as the RSS, the delay, the network load
and the battery utilization is used.
In Fuzzy MADM for Vertical Handover (FMVHO) [220], an heterogeneous network
environment that consists of LTE and WiMAX networks is considered. Firstly, the simple RSS
based method is used for the network initiation. Thereafter, a triangular fuzzy version of the
TOPSIS method is proposed for the network selection. Network parameters such as the offered
data rate and the delay are considered during the network selection process.
Several schemes implement both the network selection and the HO execution. The Inter-
mediate Mobile Access Gateway Inter-Domain Handover (iMAG-IDH) [221] scheme deals
with the network selection and the HO execution parts of the HO management procedure,
considering the operating principles of Proxy Mobile IPv6 (PMIPv6). Concerning the network
96 Mobility Management
selection process, a location tracking mechanism is used in order to estimate the vehicle’s
moving direction. Thus, the most probable next RSU that the vehicle will pass through its
coverage area is selected. Subsequently, the scheme proactively performs a Layer 3 handover
where the appropriate signaling is exchanged in order to start the forwarding of the next data
packets. Afterwards, a Layer 2 handover is performed where the vehicle is attached to the
selected RSU.
The Hidden Markov Model - Kalman Filter (HMM-KF) [222] scheme deals with the
network selection and the HO execution subprocesses of the mobility management. The
mobility of the vehicles is modeled by tracking their movement considering information from
their GPS devices. Also, each network maintains a Hidden Markov Model (HMM) indicating
the possibilities that each vehicle connected to the network has to handover to each neighboring
network, which are estimated using the Kalman Filter (KF). Subsequently, considering the
HMM each vehicle selects its next network. Afterwards, the appropriate signaling is exchanged
between the vehicle and the selected network in order the handover to be performed. Finally,
the HMM probabilities of the previous and the new vehicle’s network are updated.
The QoS Aware Handover for Session Initiation Protocol services in Vehicular Networks
(QAH-SIP) [223] scheme is implemented in the Application Layer of the OSI stack. QAH-SIP
defines a HO execution process for supporting vehicular SIP services. Initially, the vehicle
performs the network selection considering QoS aware information (such as the maximum
acceptable delay and the packet loss, as well as the minimum required RSS) required to satisfy
the SIP service constraints. Then, it performs a pre-registration to the selected RSU where the
vehicle also sends information about its position and velocity. Then, the selected RSU reserves
the required resources in order to be available to serve the incoming vehicle. Subsequently, the
SIP signaling process [224] is performed in order the HO to be completed.
It should also be noted that some schemes implement the entire mobility management
subprocesses, including the HO initiation, network selection and HO execution.
The Vertical Handover for VANET using Multiple Parameters (VHOMP) [225] algorithm
considers multiple criteria to perform the mobility management. During the HO initiation the
Received Signal Strength (RSS) parameter is turned into account. When it becomes lower than
a predefined threshold the HO is initiated. Subsequently, the network selection is performed
considering the network bandwidth and the vehicle’s velocity. Finally, the HO is executed
using the appropriate signaling in order the vehicle to be connected to the selected network.
The Navigation Assisted Seamless Handover (NASH) [226] uses a HO initiation algorithm
which considers the vehicle velocity, as well as RSRP information, to evaluate the necessity to
perform a handover. The navigation information about the vehicle is used in order the most
probable trajectory to be estimated, while the next cell that exists in this trajectory is selected.
3.2 Mobility Management Schemes for 5G Wireless Networks 97
Finally, considering an LTE-A network infrastructure the scheme proposes the appropriate
signaling that should be performed between the current RSU/BS, the next RSU/BS the MME
and the SGW, in order seamless handover to be operated ensuring the continuity of the vehicle’s
services.
The Robust Handover in Vehicular Networks (RHVN) [227] scheme defines that in Layer 2
the HO initiation is performed when the RSS drops below a predefined threshold. Subsequently,
the vehicle selects the RSU with the higher RSS and performs the HO execution. In Layer 3
the handover occurs when a Layer 2 handover is completed. In this case, the vehicle uses its
Original Care of Address (OCoA) [228] for fast IP connectivity and then its data are forwarded
from its new RSU by applying an improved version of MIPv6 protocol, which considers the
permanent vehicle’s OCoA.
The Intelligent Handover for Vehicular Networks (IHVN) [229] scheme aims at the sat-
isfaction of the real-time services’ constraints during the vehicle’s movement across differ-
ent networks. The FMIPv6 mobility management protocol is considered, while the use of
802.21 MIH ensures the interoperability between different network access technologies. Dur-
ing the HO initiation process, when the link quality drops below a predefined threshold, a
MIH_Link_Going_Down message is transmitted to the vehicle. This message triggers the
vehicle to perform a VHO. Subsequently, a list of existing nearby networks is obtained, while
link quality information (e.g. bandwidth) is obtained from each candidate network using
MIH_MN/N2N_HO_Candidate_Query messages. Then, the link quality parameter is consid-
ered in order the network with the higher link quality to be selected. Finally, during the HO
execution the appropriate signaling is exchanged between the vehicle and the selected network,
while the HO is completed using a MIH_Link_U p message indicating that now the vehicle has
been connected to the selected network.
In the VANET Backup Communication (VANBA) [230] scheme, the concept of the Com-
munication Mediator (CM) is introduced. A CM is a vehicle that provides access to vehicular
services through V2V communication. However, in a 5G-VCC systems, the CM could also be
a RSU/BS or a pedestrian, that provides access to the services through V2I or V2P communi-
cation, respectively. Two processes for accomplishing the mobility management are defined,
namely the Link Monitoring and the HO process. The Link Monitoring process, implemented
at OSI Layers 6 and 7, monitors which CMs in the vehicle’s area are available for providing
access to vehicular applications (e.g. considering the coordinates of their positions). The HO
process, implemented at OSI Layer 3, monitors the IP reachability to the services’ providers.
When the reachability is lost or the link quality drops below a predefined QoS threshold, a
handover should be performed. Subsequently, the candidate CMs are sorted using a utility
function where the bandwidth and the monetary cost parameters are considered. Then, the first
98 Mobility Management
CM in the sorted list is selected and the HO is executed. If the HO execution fails (e.g. due to
topology changes) then the next CM in the aforementioned list is selected and so on.
In Vehicular Fast Handover for Mobile IPv6 (VFMIPv6) [231] when the vehicle approaches
the boundary of its current RSU (considering the RSS), it sends to the current RSU a request
in order handover to be initiated. Along with the request, Handover Assist Information (HAI)
is also sent from the vehicle to its current RSU, containing information about the candidate
RSUs for the vehicle, considering the RSS of each RSU. The current RSU implements a utility
function based mechanism where the HAI information is considered, in order to select the most
appropriate next RSU for the vehicle, which is the one that minimizes the handover latency,
the packet loss that occurs during the handover and the total communication overhead that
is observed due to the handover latency and the corresponding packet loss. Thereafter, the
appropriate signaling is exchanged between the current RSU, the selected next RSU, the Mobile
IPv6 (MIP) Home Agent (HA) [232][233] and the MIP Correspondent Node (CN) [232] in
order the vehicle to be connected to the selected next RSU. Table 3.21 summarizes the main
functionalities of the discussed schemes.
3.2 Mobility Management Schemes for 5G Wireless Networks 99
Table 3.21 The Mobility Management Activities of each Scheme.
Scheme VHO Initiation Network Selection VHO Execution
VHOMP [225]
SSHVeT [180]
PHMVV [204]
MAH-SCE [205]
NASH [226]
MAH-UDVE [186]
RHVN [227]
S-VHO [207]
BFP-NEMO [200]
IINH [182]
IHVN [229]
VANBA [230]
iMAG-IDH [221]
VFMIPv6 [231]
MIH-PGI [208]
CVHO [209]
DPVHO [183]
GVHO-TW [197]
GVHO-PD [197]
NA-GVHO [197]
ePFMIPv6 [202]
AAMP [211]
INS [187]
HMM-KF [222]
QAH-SIP [223]
CAHP [184]
HO-CALB [185]
TOPSIS
[188][189]
TFT [171]
TFT-ACW [66]
VHO-VCC [67]
GEO-MACHU [214]
SAW [188]
MEW [188]
GRA [192]
DIA [188]
WPM [195]
QICA-NS [196]
IAS-FNN [199]
FLB-VHO [219]
FMVHO [220]
HCA [217]
VAH [218]
100 Mobility Management
Mobility Management Schemes Classification
Message
Exchange Models
Information
Centric
Host Centric
Control Entities
Vehicle Controlled
Mobility
Management
Network
Controlled
Mobility
Management
Hybrid Controlled
Mobility
Management
Algorithm
Categories
Context aware
Cost Function
based
MADM
User Centric
Fuzzy Logic based
Neural Network
based
MIH based
Probabilistic
Group based
Auction based
Figure 3.27 Classification of Mobility Management Schemes.
3.2.2 Taxonomy of Existing Mobility Management Schemes
In this section, the schemes described in Section III are classified. Firstly, the control entities
that can implement each scheme are mentioned. Also, the OSI Layers with which each scheme
is involved are considered. Thereafter, the supported message exchange models are described
and, finally, the category of each scheme’s algorithm is determined completing an in-depth
study about each scheme’s implementation.
3.2.2.1 Control Entities
Considering the entities that control the mobility management the entire process could be
categorized as Vehicle Controlled or as Network Controlled. Furthermore, some solutions
combine both Vehicle and Network control. In these cases, the mobility management process
is called as Hybrid Controlled. The following paragraphs describe the available solutions,
considering the aforementioned control entities.
3.2.2.1.1 Vehicle Controlled Mobility Management : In the vehicle controlled mobility
management schemes the entire process is controlled by the vehicle (or user) equipment, namely
the vehicle’s OBU or the passengers’ devices.
3.2.2.1.2 Network Controlled Mobility Management : In the network controlled solu-
tions, the mobility management is performed by devices located in the network infrastructure.
3.2 Mobility Management Schemes for 5G Wireless Networks 101
Considering the underling network architecture, the mobility management task can be im-
plemented from a Mobility Management Entity (MME) or an SDN controller installed in a
Cloud or a Fog infrastructure. Alternatively, a Mobile Access Gateway (MAG) could be used,
namely a BS or a RSU enhanced with mobility management capabilities. In general, the entity
that performs the mobility management collects the necessary information for evaluating the
necessity to perform a HO initiation. Also, after each HO initiation this entity selects the most
appropriate network for the vehicle, using the methods that each mobility scheme implements
for the network selection process. Subsequently, it orchestrates the HO execution through the
appropriate signaling in order the vehicle to be connected to the selected network.
Compared to the vehicle controlled mobility management, the network controlled solutions
succeed better performance since their functionalities are implemented to the network equip-
ment. As a result, the mobility management workload is minimized for the vehicles, while at
the same time their energy requirements are decreased.
3.2.2.1.3 Hybrid Controlled Mobility Management : Hybrid controlled solutions deter-
mine that the control of the mobility management task is distributed to both the vehicle and
the network infrastructure side. Indicatively, in a hybrid controlled HO initiation algorithm,
both vehicle and network infrastructure cooperate in order the necessity of performing a han-
dover to be evaluated. Accordingly, in a hybrid controlled network selection algorithm the
aforementioned cooperation is performed in order the most appropriate network to be selected.
In both cases, several vehicle and network parameters can be considered. Indicatively, vehicles
parameters can include the perceived QoS, the signal quality, the vehicular users’ preferences
or the used services. Also, regarding the network infrastructure side, network load or operator
policy information obtained from the network infrastructure are indicative parameters that can
be considered. Finally, in a hybrid controlled HO execution algorithm both vehicle’s equipment
and network infrastructure cooperate to accomplish the handover.
3.2.2.1.4 Discussion on Mobility Management Control Entities : As it could be ob-
served in Table 3.22 some schemes support only vehicle controlled mobility management
(SSHVeT [180], DPVHO [183], CAHP [184] and HO-CALB [185]), while some other schemes
support both vehicle and network control (TFT-ACW [66], VHO-VCC [67], GVHO-TW [197],
GVHO-PD [197], NA-GVHO [197] and AAMP [211]). It should also be noted that although
some schemes have not been proposed for supporting network control, it could be performed by
implementing some of their functionalities to 5G-VCC components such as a Cloud or a Fog
infrastructure (e.g. TFT [171], VHOMP [225], PHMVV [204], MAH-SCE [205] etc.). The
implementation of such algorithms in a Cloud or a Fog infrastructure eliminates the mobility
102 Mobility Management
management workload that the vehicles OBUs undertake, while at the same time their energy
requirements are decreased. Furthermore, in cases where an SDN controller is used, the results
of these scheme can be improved since the controller supervises the manipulation of the entire
system. Finally, the BFP-NEMO [200] scheme implements only network controlled mobility
management.
Table 3.22 The Control Types that each Scheme supports.
Scheme Vehicle Controlled Network Controlled Hybrid Controlled
VHOMP [225] * *
SSHVeT [180]
PHMVV [204] * *
MAH-SCE [205] * *
NASH [226] * *
MAH-UDVE [186] * *
RHVN [227] * *
S-VHO [207] * *
BFP-NEMO [200]
IINH [182]
IHVN [229] * *
VANBA [230] * *
iMAG-IDH [221] * *
VFMIPv6 [231] * *
MIH-PGI [208] * *
CVHO [209] * *
DPVHO [183]
GVHO-TW [197]
GVHO-PD [197]
NA-GVHO [197]
ePFMIPv6 [202]
AAMP [211]
INS [187] * *
HMM-KF [222] * *
QAH-SIP [223] * *
CAHP [184]
HO-CALB [185]
TOPSIS [188][189] * *
TFT [171] * *
TFT-ACW [66]
VHO-VCC [67]
GEO-MACHU [214] * *
SAW [188] * *
MEW [188] * *
GRA [192] * *
DIA [188] * *
WPM [195] * *
QICA-NS [196] * *
IAS-FNN [199] * *
FLB-VHO [219] * *
FMVHO [220] * *
HCA [217] * *
VAH [218] * *
: Directly supported , *: Could be supported to a 5G-VCC architecture
3.2 Mobility Management Schemes for 5G Wireless Networks 103
3.2.2.2 Message Exchange Models
Message exchange models determine how the entities communicate each other in a VCC
architecture. Two models are available in VCC, the host centric and the information centric.
3.2.2.2.1 Information Centric : The information centric model proposes messages’ de-
livery considering the content semantics. The information centric model is also called as
publish-subscribe model. Considering its operating principles, two entities interact each other,
the publisher and the subscriber. Firstly, the publisher publishes the set of items. Then, the sub-
scriber expresses its interests for items through subscriptions. When an item that is contained
into the subscriber’s interests become available to the publisher, it is being sent to the subscriber.
The use of the information centric model facilitates the vehicles of obtaining easily the required
information, due to the fact that vehicles are usually interested for the information itself, ignor-
ing its origin. The authors of [42] strengthen this opinion by describing two examples. In the
first one, an autonomous vehicle travels in high speed on a highway. The vehicle must obtain
contiguous information of surrounding vehicles that exist in short distance, in order to provide
a safe course to its passengers. Using the information centric model, the vehicle regularly
expresses its interests to the surrounding vehicles. Then, it periodically receives information
about their position, speed and direction. Correspondingly, in the second example, the case of
an accident ahead is considered. More specifically, the vehicle expresses the interest for retriev-
ing information about the accident to the surrounding vehicles and RSUs. Vehicles or RSUs
that become nearest to the accident provide the required information to the vehicle. Then, the
vehicle’s driver is immediately alerted in order to be able to manipulate efficiently the situation
(e.g. by selecting an alternative route to avoid the accident area and save time). Furthermore, in
[43] the authors show that the information centric model enables the development of routing
methods with enhanced scalability characteristics. More specifically, they demonstrate that this
model provides many advantages to the routing functionality, due to the fact that it enables
the network architecture manipulation in terms of “information connectivity” considering the
context semantics, instead of considering the physical nodes connectivity.
3.2.2.2.2 Host Centric : The host centric model is also called as request-response or client-
server model [234–236], where a client machine requests to receive items offered from a host
(or server) machine. Specifically, when a client machine needs an item that belongs to this set, it
sends a request to the host machine. The host machine receives the clients request, retrieves the
required item and sends it to the client. The communication is performed using the IP protocol,
while in large scale network architectures, thousand connections could exist. Furthermore, as
described in [237], the use of the term “host centric” was started when the “information-centric”
104 Mobility Management
term was introduced. Specifically, since the “information centric” has been proposed as an
alternative message exchange model, the “host centric” term is used to represent the existing
model for messages exchange in current network infrastructures, in order the fundamental
difference between Information Centric Networking (ICN) [238] and Host Centric Networking
(HCN) [239] to be clearly identified. Specifically, in order to explain the difference between
the two models, the authors of [240] refer that in the ICN model the information itself obtains a
specific identifier (or address), while in the traditional HCN model each host machine has an IP
address assigned. Indicatively, regarding the host centric model operating principle, the authors
of [241] have proposed the implementation of a Service Oriented Architecture (SOA) [242] for
providing both information and entertainment services for vehicular clients. Specifically, each
client interacts with the implemented web services to obtain access to real time information
(e.g. about road traffic conditions) as well as to multimedia content.
3.2.2.2.3 Discussion on compatibility of each Mobility Management scheme with the
available Message Exchange Models : The rapid evolve of content distribution services has
led to host centric solutions such as overlay networks to address the increased needs for network
scalability. However, performance bottlenecks persist resulting to the network inability of
controlling the huge traffic load. In addition, the communication sessions could be interrupted
when the IP address of a client device changes. Consequently, the host centric model cannot
manipulate efficiently the increased needs for information. On the contrary, in information
centric model, network nodes are considered as content segments, rather than as IP addressed
endpoints. Thus, information centric model improves the network scalability and enhances the
mobility support as well as the multihoming functionalities.
Table 3.23 presents the applicability of each mobility management scheme to the available
message exchange models. As it could be observed, since the message exchange is performed to
Layer 3 (e.g. in IP-based host centric solutions), Layer 2 schemes (e.g. TFT [171], TFT-ACW
[66], VHO-VCC [67], VHOMP [225] etc.) and Layer 7 schemes (QAH-SIP [223]) require the
complementary use of a Layer 3 scheme (e.g. BFP-NEMO [200], IINH [182], VFMIPv6 [231]
or ePFMIPv6 [202]) in order to support either the information centric or the host centric model.
More specifically, only the Layer 3 schemes directly support the host centric model since it is
based on the IP protocol of Layer 3. Also, in some cases the information centric model could
not be directly supported, since some Layer 3 schemes support only IP based communication
(e.g. RHVN [227], BFP-NEMO [200], IINH [182], IHVN [229] etc.), requiring an IP based
architecture, while the information centric model does not use a such architecture. In such
cases, the complementary use of an additional algorithm implemented to the upper layers is
required for supporting the information centric model [243][244].
3.2 Mobility Management Schemes for 5G Wireless Networks 105
Table 3.23 The Applicability of each Scheme to the Available Message Exchange Models.
Scheme Information Centric Host Centric
VHOMP [225] * *
SSHVeT [180] * *
PHMVV [204] * *
MAH-SCE [205] * *
NASH [226] * *
MAH-UDVE [186] * *
RHVN [227] +
S-VHO [207] * *
BFP-NEMO [200] +
IINH [182] +
IHVN [229] +
VANBA [230] +
iMAG-IDH [221] +
VFMIPv6 [231] +
MIH-PGI [208] *
CVHO [209] * *
DPVHO [183] * *
GVHO-TW [197] * *
GVHO-PD [197] * *
NA-GVHO [197] * *
ePFMIPv6 [202] +
AAMP [211] * *
INS [187] * *
HMM-KF [222] * *
QAH-SIP [223] + *
CAHP [184] * *
HO-CALB [185] * *
TOPSIS [188][189] * *
TFT [171] * *
TFT-ACW [66] * *
VHO-VCC [67] * *
GEO-MACHU [214] *
SAW [188] * *
MEW [188] * *
GRA [192] * *
DIA [188] * *
WPM [195] * *
QICA-NS [196] * *
IAS-FNN [199] * *
FLB-VHO [219] * *
FMVHO [220] * *
HCA [217] * *
VAH [218] * *
* Supported using third party algorithm for Layer 3 mobility management
+ Supported using third party algorithm implemented to the Upper Layers
106 Mobility Management
3.2.2.3 Mobility Management Algorithm Categories
Several HO initiation and network selection approaches have been described considering
network and user related parameters and can be classified into the following categories:
3.2.2.3.1 Context Aware : The decision is based on signal quality parameters. In this case,
RSS, SNR or SINR are usually considered in order the signal quality of each network to be
evaluated. Context aware HO initiation is performed when the signal quality of the current
network drops below a threshold, while in case of context aware network selection the network
with the best signal quality is selected. It should be noted that although several algorithms
consider the signal quality to determine the set of network alternatives, in this category belong
only the algorithms that make the final decision (e.g. the network ranking) considering such
information.
3.2.2.3.2 Cost Function based : The cost of each network is estimated using a function.
In the case of HO initiation, if the cost of the current network exceeds a maximum acceptable
threshold, HO is initiated. Accordingly, in the case of a cost function network selection
algorithm the cost of each candidate network is calculated and the network with the lowest
cost is selected. The cost should refer to monetary cost, energy consumption aware cost,
bandwidth etc. Each HO initiation or network selection algorithm could belong to more than
one categories.
3.2.2.3.3 Multi Attribute Decision Making (MADM) : The decision is made considering
multiple and conflicting network and user criteria. In the case of HO initiation, the current
network is ranked, while HO is initiated when this rank drops below a predefined threshold.
Also, in the case of a MADM network selection algorithm the entire network alternatives are
ranked and the network with the higher rank is selected.
3.2.2.3.4 User Centric : The decision considers user preferences, which could be refer
to parameters related to QoS, QoE, monetary costs and so on. In case of HO initiation the
user satisfaction is evaluated considering his preferences. If the user satisfaction grade drops
below a threshold the HO is initiated. Accordingly, in case of user centric network selection the
utility of each network alternative is evaluated considering the user preferences and the network
with the highest utility is selected. As it could be observed, this category can be considered as
similar to the cost function based one. Specifically, the user centric schemes estimate the utility
of each network alternative which is a positive parameter, while the cost based ones estimate
3.2 Mobility Management Schemes for 5G Wireless Networks 107
the cost of each alternative which is a negative parameter. Also, the schemes of this category
are usually combined with MADM algorithms.
3.2.2.3.5 Fuzzy Logic based : They use fuzzy logic in order the decision uncertainty to be
addressed, considering the related criteria to perform HO initiation or network selection. A
fuzzy number is represented by a set of real values representing an uncertain quantity and a
convex normalized continuous function which estimates the degree of membership for each
value in the subset. Triangular, trapezoidal or pentagonal fuzzy numbers are frequently used
to represent uncertain information. These algorithms are usually combined with MADM
algorithms, while the HO initiation and the network selection are performed according to the
MADM based networks ranking.
3.2.2.3.6 Neural Network based : A neural network is constructed determining a score
for each candidate network. They are usually combined with MADM algorithms. Similar to the
previous categories HO initiation and network selection are performed considering the score of
each network.
3.2.2.3.7 MIH based : The algorithms of this category apply the operating principles of
Media Indepentent Handover (MIH) []. In some cases, they are combined with algorithms of
other categories, including context aware and MADM.
3.2.2.3.8 Probabilistic : They consider several probabilities to perform the mobility man-
agement, including probabilities about user trajectory or velocity. Indicatively, considering the
most probable user trajectory, the distribution of the signal strength of each network can be
predicted. Thus, in case of HO initiation the most appropriate time to perform a HO can be
estimated, or in case of network selection the most appropriate network for the user is selected,
considering the aforementioned prediction.
3.2.2.3.9 Group based : They consider the fact that sometimes many users with similar
trajectories and requirements need to perform a HO simultaneously. Thus, increased computa-
tion requirements for performing the mobility management arise. In this case, the algorithms
of this category group users with similar trajectories and perform the mobility management
once for the entire group, decreasing the computational requirements of the entire process.
3.2.2.3.10 Auction based : The algorithms of this category perform the network selection
using auctions. Each user makes an offer (e.g. according to his Service Level Agreement).
Subsequently, users with higher offers obtain connectivity to better networks.
108 Mobility Management
3.2.2.3.11 Discussion on Mobility Management Algorithm Categories : As presented
in table 3.24 the algorithm that each mobility management schemes combine more than one
algorithm types. Specifically, most of the schemes belong to the MADM type (e.g. TFT
[171], TFT-ACW [66], VHO-VCC [67], VHOMP [225] etc.), as well as to the context aware
type (e.g. VHO-VCC [67], VHOMP [225], SSHVeT [180], PHMVV [204] etc.). It could
be explained since the MADM algorithm could consider several (sometimes contradictory)
parameters. On the other hand, context information (e.g. signal strength) could be considered
as the most fundamental information for a mobility management scheme, since it is necessary
for determining the candidate networks for a vehicle. Furthermore, many schemes belong to
the cost function based type (e.g. VFMIPv6 [231], DPVHO [183], GVHO-TW [197], INS
[187] etc.). In addition, although user preferences could be considered as a useful factor for
performing the mobility management, only two of the discussed schemes belong to the user
centric type (VHO-VCC [67] and QICA-NS [196]),while at the same time some schemes also
belong to the fuzzy logic type (TFT [171], TFT-ACW [66], VHO-VCC [67] and IAS-FNN
[199]).Also, there are schemes that belong to the MIH based (GEO-MACHU [214], IHVN
[229] and MIH-PGI [208]), to the probabilistic (e.g. NASH [226], MAH-UDVE [186], iMAG-
IDH [221], DPVHO [183] etc.) or to the group based (BFP-NEMO [200], GVHO-TW [197],
GVHO-PD [197], NA-GVHO [197] and AAMP [211]) types. Finally, a few schemes belong to
the neural network based (CVHO [209] and IAS-FNN [199]) or to the auction based (AAMP
[211]) type.
3.2 Mobility Management Schemes for 5G Wireless Networks 109
Table 3.24 The Type of Algorithms used in each Scheme.
Scheme Cost Function
based
User
Centric
MADM Fuzzy Logic
based
Neural Net-
work based
Context
aware
MIH
based
Probabilistic Group
based
Auction
based
VHOMP [225]
SSHVeT [180]
PHMVV [204]
MAH-SCE [205]
NASH [226]
MAH-UDVE [186]
RHVN [227]
S-VHO [207]
BFP-NEMO [200]
IINH [182]
IHVN [229]
VANBA [230]
iMAG-IDH [221]
VFMIPv6 [231]
MIH-PGI [208]
CVHO [209]
DPVHO [183]
GVHO-TW [197]
GVHO-PD [197]
NA-GVHO [197]
ePFMIPv6 [202]
AAMP [211]
INS [187]
HMM-KF [222]
QAH-SIP [223]
CAHP [184]
HO-CALB [185]
TOPSIS [188][189]
TFT [171]
TFT-ACW [66]
VHO-VCC [67]
GEO-MACHU [214]
SAW [188]
MEW [188]
GRA [192]
DIA [188]
WPM [195]
QICA-NS [196]
IAS-FNN [199]
FLB-VHO [219]
FMVHO [220]
HCA [217]
VAH [218]
110 Mobility Management
3.2.3 Mobility Management on 5G-VCC Systems
In this section, the 5G-VCC architectures as well as the communication models that each
mobility management scheme supports are mentioned.
3.2.3.1 Mobility Management schemes for supporting 5G-VCC Architectures
The applicability and the performance of each mobility management scheme is affected of
factors related to the implemented 5G-VCC architecture. Table 3.25 presents the factors that
each 5G-VCC architecture satisfies, while table 3.26 presents the applicability of the discussed
mobility management schemes to each 5G-VCC architecture.
The applicability of each scheme depends on the existence of a backbone network infras-
tructure. Specifically, the VC architecture as already mentioned has no backbone network
infrastructure. It determines a complete ad-hoc topology, which consists of vehicles construct-
ing the Cloud. Thus, only the VANBA [230] and the HCA [217] schemes can be applied to
VC architectures, since in these cases the mobility management concerns the connectivity
between the participating vehicles instead of the interaction between vehicles and a network
infrastructure. This fact reinforces the need for further research since in some cases the VC
architectures could support disaster management services [245] where the availability of access
network infrastructures could be decreased. On the other hand, in the VuC, VuF, SDN-V and
HVA architectures, a communication infrastructure providing access to cloud/fog resources,
is implemented. Hence, the entire schemes can be applied to VuC, VuF, SDN-V and HVA
architectures, since they have been designed to manipulate the user mobility in relation with an
existing network infrastructure.
Furthermore, architectural factors such as the network control type applied (centralized or
decentralized) and which architectural components are virtualized, affect the performance of
each mobility management scheme.
Regarding the network control type applied, the discussed mobility management schemes
could be adapted to perform either centralized or distributed control. Centralized control is
optional in VC, SDN-V and HVA architectures. Such a configuration uses a central entity
performing the mobility management, such as a single SDN controller or a central vehicle with
increased responsibilities. Accordingly, decentralized control is performed when the network
control process is distributed to more than one control entities. Decentralized control can be
applied to the entire 5G-VCC architectures. Furthermore, both centralized and decentralized
control can be combined. For instance, in some VC architectures clustering of vehicles is
performed, where a vehicle is elected as the Cluster Head (CH) [246] implementing the
3.2 Mobility Management Schemes for 5G Wireless Networks 111
functionalities of a single SDN controller. In this case, centralized control is applied for intra-
cluster communication, while distributed control is applied for inter-cluster communication.
Finally, the considered mobility management schemes can be deployed to several virtualized
resources of a 5G-VCC architecture. Specifically, in a VC architecture virtualization of
resources is performed by the end-user devices. Also, in a VuC architecture virtualization
is applied in the Cloud, while in a VuF architecture virtualization is applied in the Fog.
Network as a Service (NaaS) [247–249] enables the configuration of network resources in
either the Cloud or the Fog. Furthermore, in HVA architectures, virtualization is simultaneously
performed in two or more architectural components. Indicatively, in the architecture discussed
in [73] virtualization is applied to both Cloud and Fog nodes. Also, a fully virtualized HVA
architecture [31][75], optimizes the performance of mobility management schemes, since it
provides increased system reliability, resource utilization and performance isolation.
Table 3.25 The Factors considered in each Architecture.
Architecture Virtualization Centralization Infrastructure
requirements
Vehicular Cloud (VC) Yes Optional No
Vehicles using Cloud
(VuC)
Yes No Yes
Vehicles using Fog (VuF) Yes No Yes
Software Defined Vehicu-
lar Architectures (SDN-V)
Yes Optional Yes
Hybrid Vehicular Architec-
tures (HVA)
Yes Optional Yes
112 Mobility Management
Table 3.26 The Applicability of each Scheme to the Available 5G-VCC Architectures.
Scheme
Vehicular
Cloud (VC)
Vehicles
using
Cloud
(VuC)
Vehicles
using
Fog
(VuF)
Software
Defined
Vehicular
Architectures
(SDN-V)
Hybrid
Vehicular
Architectures
(HVA)
VHOMP [225]
SSHVeT [180]
PHMVV [204]
MAH-SCE [205]
NASH [226]
MAH-UDVE [186]
RHVN [227]
S-VHO [207]
BFP-NEMO [200]
IINH [182]
IHVN [229]
VANBA [230]
iMAG-IDH [221]
VFMIPv6 [231]
MIH-PGI [208]
CVHO [209]
DPVHO [183]
GVHO-TW [197]
GVHO-PD [197]
NA-GVHO [197]
ePFMIPv6 [202]
AAMP [211]
INS [187]
HMM-KF [222]
QAH-SIP [223]
CAHP [184]
HO-CALB [185]
TOPSIS [188][189]
TFT [171]
TFT-ACW [66]
VHO-VCC [67]
GEO-MACHU [214]
SAW [188]
MEW [188]
GRA [192]
DIA [188]
WPM [195]
QICA-NS [196]
IAS-FNN [199]
FLB-VHO [219]
FMVHO [220]
HCA [217]
VAH [218]
3.2 Mobility Management Schemes for 5G Wireless Networks 113
3.2.3.2 Mobility Management schemes for supporting 5G-VCC Communication Mod-
els
Each communication model could be applied to specific 5G-VCC architectures (Table 3.27). In
general, V2V and V2P models can be applied in each 5G-VCC architecture, since the entire
topologies can include both vehicular and pedestrian users. However, the V2I communication
model requires a network infrastructure. Consequently, it cannot be applied to a VC architecture
which is completely ad-hoc. On the other hand, V2I could be used in VuC and VuF topologies,
since they provide access to network infrastructure through RSUs. Also, HVC could be applied
to the entire topologies, since it combines multiple communication models.
Table 3.27 The Applicability of each Communication Model to each Architecture.
PPPPPPPPPP
Communication
Model
5G-VCC
Architecture
Vehicular
Cloud (VC)
Vehicles
using
Cloud
(VuC)
Vehicles
using
Fog
(VuF)
Software
Defined
Vehicular
Architectures
(SDN-V)
Hybrid
Vehicular
Architectures
(HVA)
Vehicle to
Vehicle (V2V)
Vehicle to
Infrastructure
(V2I)
Vehicle to
Pedestrian (V2P)
Hybrid Vehicular
Communication
(HVC)
Table 3.28 presents the applicability of each mobility management scheme to the available
communication models. As could be observed the entire mobility management schemes support
V2I communications, since these schemes could be applied to 5G-VCC topologies where an
access network infrastructure exists. However, only the HCA [217] scheme supports V2V and
V2P communications since it could also be applied to VC architectures where no access network
infrastructure exists. Thus, the design of mobility management algorithms for supporting V2V
and V2P communications could be considered as a scientific field for further future research,
since these communications are necessary for supporting several vehicular services in smart
cities environments [95][250].
114 Mobility Management
Table 3.28 The Applicability of each Scheme to each Communication Model.
Scheme
Vehicle to
Vehicle
(V2V)
Vehicle to
Infrastructure
(V2I)
Vehicle to
Pedestrian
(V2P)
Hybrid
Vehicular
Communication
(HVC)
VHOMP [225]
SSHVeT [180]
PHMVV [204]
MAH-SCE [205]
NASH [226]
MAH-UDVE [186]
RHVN [227]
S-VHO [207]
BFP-NEMO [200]
IINH [182]
IHVN [229]
VANBA [230]
iMAG-IDH [221]
VFMIPv6 [231]
MIH-PGI [208]
CVHO [209]
DPVHO [183]
GVHO-TW [197]
GVHO-PD [197]
NA-GVHO [197]
ePFMIPv6 [202]
AAMP [211]
INS [187]
HMM-KF [222]
QAH-SIP [223]
CAHP [184]
HO-CALB [185]
TOPSIS [188][189]
TFT [171]
TFT-ACW [66]
VHO-VCC [67]
GEO-MACHU [214]
SAW [188]
MEW [188]
GRA [192]
DIA [188]
WPM [195]
QICA-NS [196]
IAS-FNN [199]
FLB-VHO [219]
FMVHO [220]
HCA [217]
VAH [218]
Chapter 4
A Proposed Mobility Management
Approach for 5G-VCC Systems
4.1 Mobility Management Requirements
This section describes the requirements that must be satisfied by a mobility management
scheme. In a 5G-VCC system, vehicles move in several trajectories, while at the same time
have different velocities. Also, each vehicle could serve multiple passengers with different
services. Thus several requirements need to be addressed by HO schemes.
• Seamless mobility During the vehicles movement, their ability to remain connected while
roaming across different access networks must be ensured, in order to avoid interruption
of user’s services.
• Minimization of handover latency Mobility management schemes should offer lightweight
solutions to minimize the delay of the decision process as well as the signaling delays
during the handover execution. Additionally, in urban environments multiple vehicles
have similar trajectories requiring similar mobility management decisions and signaling-
exchanges to be performed. For this reason, modern mobility management schemes
cluster the vehicles with similar mobility and service requirements so that similar tasks
are executed once for the entire cluster than for each vehicle.
• Minimization of handovers count Even in cases where the handover latency has been
reduced enough, more handovers will always occur to higher total latencies and network
signaling overhead. In the modern 5G network access environment, where multiple cells
coexist in the same place, a vehicle could perform a large number of handovers reducing
the perceived Quality of Service (QoS) of vehicular services.
116 A Proposed Mobility Management Approach for 5G-VCC Systems
• Support of heterogeneous network access environments Mobility management schemes
for 5G networks should support the coexistence of multiple network access technologies.
Thus, the utilization of the available spectrum will be maximized, since each technology
operates to specific frequency bands, determined by its technical specifications.
• Optimal network selection for satisfying QoS constraints of vehicular services Connec-
tivity to the most appropriate network supporting the constraints of vehicular services
must be ensured. Accordingly, the available network alternatives must be continuously
evaluated considering vehicular services requirements, as well as changes in the radio
environment and operators policies.
4.2 System Architecture
The proposed HO management scheme uses some of the methods described in the previous
section. Its design has been optimized to be applied in 5G network architectures where both
Fog and Cloud infrastructures are available. The HO process includes the HO Initiation, the
Velocity Monitoring, the Network Selection and the HO Execution subprocesses as presented
in Figure 4.1.
Initially, the HO Initiation is executed in the Fog considering the Quality of Service (QoS)
and the Signal to Noise plus Interference Ratio (SINR) that the vehicle perceives from its
current network to evaluate the necessity to perform a handover. Both the Fog and the Cloud
cooperate to accomplish the Velocity Monitoring process. Finally, the Cloud performs the
Network Selection among the available networks depending on the vehicle’s velocity. The
vehicle is informed through the Fog infrastructure, to make a handover to the selected network.
The following subsections describe in depth each one of the aforementioned subprocesses.
4.2.1 VHO Initiation
During the HO initiation process the Su,i indicator is defined, determining the satisfaction
grade of user u from his current network i. More specifically, the Su,i value is estimated
considering as input the SINRu,i and the Qu,i parameters. The SINRu,i represents the Signal
to Noice plus Interference, while the Qu,i represents the quality of the users’ services offered
from the current network. Qu,i is calculated using formula 4.1, where thu,i,k, du,i,k, ju,i,k and
plu,i,k represent the throughput, the delay, the jitter and the packet loss ratio respectively,
obtained by user u for service k. Additionally, wth,k, wd,k ,wj,k and wp,kl represent the weights
of the aforementioned parameters estimated using the PF-ANP method, while N represents the
4.2 System Architecture 117
number of the parameters considered and K the number of the available services.
Qu,i =
K
∑
k=1
(wth,k ·thu,i,k +wd,k ·
1
du,i,k
+wj,k ·
1
ju,i,k
+wpl,k ·
1
plu,i,k
)/N /K
(4.1)
The user’s equipment continuously monitors its perceived SINRu,i and Qu,i values. When
either SINRu,i or Qu,i becomes less than a predefined threshold, the user equipment sends
the obtained values to the Fog infrastructure. Subsequently, the Fog infrastructure uses the
Mamdani satisfaction chart presented in Figure 4.2, in order to determine the Su,i satisfaction
grade. If the satisfaction grade is less than a predefined Sth threshold value, then the network
selection process is executed.
The satisfaction indicators chart presents the Su,i values obtained for each possible SINRu,i
and Qu,i combination. Indicatively, when the SINRu,i and Qu,i values are too low, the produced
Su,i value is too low as well. On the contrary, when the SINRu,i and Qu,i values are close to
1, the produced Su,i value is also high, indicating that the user is fully satisfied. Furthermore,
when only one of the SINRu,i or the Qu,i values is close to 0, the user satisfaction is in quite
low levels.
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 at the Fog is
minimal. Also, the method does not impose any significant overhead at the user equipment due
to the monitoring of the SINRu,i and Qu,i parameters.
4.2.1.1 Evaluation of the Satisfaction Indicators
The Mamdani satisfaction chart is evaluated once during the instantiation of the Fog services.
Each satisfaction indicator Su,i of Figure 4.2 is obtained using the MPFIS method, considering
the SINRu,i and the Qu,i as input parameters. Both SINRu,i and Qu,i are normalized in order
to have values within the range [0, 1]. Also, the MFSINR, MFQ, MFS membership functions
(MF) are defined using the EUM method, indicating the linguistic terms and the corresponding
Interval Valued Pentagonal Fuzzy Numbers (I-VPFN) for the fuzzy representation of the
SINRu,i, Qu,i and Su,i respectively. Thus, for each crisp value, two membership degrees are
determined in the corresponding MF, one for the upper pentagon and one for the lower pentagon.
Table 4.1 represents the linguistic terms and the corresponding interval-valued pentagonal fuzzy
numbers of MFSINR, MFQ and MFS membership functions, which are equally distributed inside
the domain [Umin,Umax] = [0, 1] as illustrated in Figures 4.3, 4.4 and 4.5, respectively. Table
4.2 shows the considered fuzzy rule base.
118 A Proposed Mobility Management Approach for 5G-VCC Systems
Table 4.1 Linguistic Terms and the corresponding Interval-Valued Pentagonal Fuzzy Numbers
used for MFSINR, MFQ and MFS.
MFSINR membership functions.
Linguistic term Interval-valued trapezoidal fuzzy number
Absolute Bad (AB) [(0.0, 0.0, 0.0, 0.062, 0.093, 0.8, 0.6, 0.6),(0.0, 0.0, 0.0, 0.083, 0.125, 1.0, 0.8, 0.8)]
Too Bad (TB) [(0.072, 0.104, 0.166, 0.229, 0.26, 0.8, 0.6, 0.6),(0.041, 0.083, 0.166, 0.25, 0.291, 1.0, 0.8, 0.8)]
Bad (B) [(0.239, 0.27, 0.333, 0.395, 0.427, 0.8, 0.6, 0.6),(0.208, 0.25, 0.333, 0.416, 0.458, 1.0, 0.8, 0.8)]
Enough (EN) [(0.406, 0.437, 0.5, 0.562, 0.593, 0.8, 0.6, 0.6),(0.375, 0.416, 0.5, 0.583, 0.625, 1.0, 0.8, 0.8)]
More than Enough (ME) [(0.572, 0.604, 0.667, 0.729, 0.76, 0.8, 0.6, 0.6),(0.541, 0.583, 0.667, 0.75, 0.791, 1.0, 0.8, 0.8)]
Almost Excellent (AE) [(0.739, 0.77, 0.833, 0.895, 0.927, 0.8, 0.6, 0.6),(0.708, 0.75, 0.833, 0.916, 0.958, 1.0, 0.8, 0.8)]
Excellent (EX) [(0.906, 0.937, 1.0, 1.0, 1.0, 0.8, 0.6, 0.6),(0.875, 0.916, 1.0, 1.0, 1.0, 1.0, 0.8, 0.8)]
MFQ membership functions.
Linguistic term Interval-valued trapezoidal fuzzy number
Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.046, 0.07, 0.8, 0.6, 0.6),(0.0, 0.0, 0.0, 0.062, 0.093, 1.0, 0.8, 0.8)]
Very Poor (VP) [(0.054, 0.078, 0.125, 0.171, 0.195, 0.8, 0.6, 0.6),(0.031, 0.062, 0.125, 0.187, 0.218, 1.0, 0.8, 0.8)]
Poor (P) [(0.179, 0.203, 0.25, 0.296, 0.32, 0.8, 0.6, 0.6),(0.156, 0.187, 0.25, 0.312, 0.343, 1.0, 0.8, 0.8)]
Medium Poor (MP) [(0.304, 0.328, 0.375, 0.421, 0.445, 0.8, 0.6, 0.6),(0.281, 0.312, 0.375, 0.437, 0.468, 1.0, 0.8, 0.8)]
Medium (M) [(0.429, 0.453, 0.5, 0.546, 0.57, 0.8, 0.6, 0.6),(0.406, 0.437, 0.5, 0.562, 0.593, 1.0, 0.8, 0.8)]
Medium Good (MG) [(0.554, 0.578, 0.625, 0.671, 0.695, 0.8, 0.6, 0.6),(0.531, 0.562, 0.625, 0.687, 0.718, 1.0, 0.8, 0.8)]
Good (G) [(0.679, 0.703, 0.75, 0.796, 0.82, 0.8, 0.6, 0.6),(0.656, 0.687, 0.75, 0.812, 0.843, 1.0, 0.8, 0.8)]
Very Good (VG) [(0.804, 0.828, 0.875, 0.921, 0.945, 0.8, 0.6, 0.6),(0.781, 0.812, 0.875,0.937, 0.968, 1.0, 0.8, 0.8)]
Absolutely Good (AG) [(0.929, 0.953, 1.0, 1.0, 1.0, 0.8, 0.6, 0.6),(0.906, 0.937, 1.0, 1.0, 1.0, 1.0, 0.8, 0.8)]
MFS membership functions.
Linguistic term Interval-valued trapezoidal fuzzy number
Absolute Unsatisfactory (AU) [(0.0, 0.0, 0.0, 0.034, 0.051, 0.8, 0.6, 0.6),(0.0, 0.0, 0.0, 0.045, 0.068, 1.0, 0.8, 0.8)]
Very Unsatisfactory (VU) [(0.039, 0.056, 0.09, 0.125, 0.142, 0.8, 0.6, 0.6),(0.022, 0.045, 0.09, 0.136, 0.159, 1.0, 0.8, 0.8)]
Unsatisfactory (U) [(0.13, 0.147, 0.181, 0.215, 0.232, 0.8, 0.6, 0.6),(0.113, 0.136, 0.181, 0.227, 0.25, 1.0, 0.8, 0.8)]
Slightly Unsatisfactory (SU) [(0.221, 0.238, 0.272, 0.306, 0.323, 0.8, 0.6, 0.6),(0.204, 0.227, 0.272, 0.318, 0.34, 1.0, 0.8, 0.8)]
Less than Acceptable (LA) [(0.312, 0.329, 0.363, 0.397, 0.414, 0.8, 0.6, 0.6),(0.295, 0.318, 0.363, 0.409, 0.431, 1.0, 0.8, 0.8)]
Slightly Acceptable (SA) [(0.403, 0.42, 0.454, 0.488, 0.505, 0.8, 0.6, 0.6),(0.386, 0.409, 0.454, 0.5, 0.522, 1.0, 0.8, 0.8)]
Acceptable (A) [(0.494, 0.511, 0.545, 0.579, 0.596, 0.8, 0.6, 0.6),(0.477, 0.5, 0.545, 0.59, 0.613, 1.0, 0.8, 0.8)]
More than Acceptable (MA) [(0.585, 0.602, 0.636, 0.67, 0.687, 0.8, 0.6, 0.6),(0.568, 0.59, 0.636, 0.681, 0.704, 1.0, 0.8, 0.8)]
Slightly Satisfactory (SS) [(0.676, 0.693, 0.727, 0.761, 0.778, 0.8, 0.6, 0.6),(0.659, 0.681, 0.727, 0.772, 0.795, 1.0, 0.8, 0.8)]
Satisfactory (S) [(0.767, 0.784, 0.818, 0.852, 0.869, 0.8, 0.6, 0.6),(0.75, 0.772, 0.818, 0.863, 0.886, 1.0, 0.8, 0.8)]
Very Satisfactory (VS) [(0.857, 0.875, 0.909, 0.943, 0.96, 0.8, 0.6, 0.6),(0.84, 0.863, 0.909, 0.954, 0.977, 1.0, 0.8, 0.8)]
Absolute Satisfactory (AS) [(0.948, 0.965, 1.0, 1.0, 1.0, 0.8, 0.6, 0.6),(0.931, 0.954, 1.0, 1.0, 1.0, 1.0, 0.8, 0.8)]
4.2.2 Velocity Monitoring
During the entire vehicle movement, its velocity is monitored by the Fog-Cloud infrastructure.
An enhanced version of the Mobility State Estimation (MSE) model defined in 3GPP LTE
Release 11 [251] is used to estimate the vehicles’ velocity. The MSE considers the number of
handovers or reselections (NCRu) performed by a vehicle during a sliding time window (TCRmax).
The vehicle is categorized into one of three velocity states, namely the Normal, the Medium
and the High, considering the NCRMedium
and NCRHigh
thresholds with NCRMedium
< NCRHigh
. The
concept of this method is that the more handovers the vehicle performs during the TCRmax
period, the faster the vehicle is moving. In heterogeneous network environments that include
both Macrocells and Femtocells, the default TCRmax value is 120 seconds, while the default
NCRMedium
and NCRHigh
values are equal to 10 and 16 handovers, respectively [251]. Furthermore,
the estimated residence time tresidence
u,i of vehicle u in each available cell i is estimated using
4.2 System Architecture 119
formula 4.2 defined in [252], where rf is the radius of femtocell i and vu is the velocity of the
vehicle u.
tresidence
u,i =
π ·ri
2·vu
(4.2)
Then, the vehicle velocity is obtained by formula 4.3 defined in [253].
vu =
π ·NCRu
4·TCRmax ·
√
λu
(4.3)
The λu parameter, obtained by the SDN controller, denotes the cell’s density in the location of
vehicle u.
4.2.3 Network Selection
The mobility state of each vehicle is considered in order to select the set A = {A1,A2,...,An}
of possible network alternatives based on the SINR perceived by each network. If the vehicle
mobility state is Normal then the vehicle considers all the available networks as alternatives,
including both Macrocells and Femtocells. On the contrary, if vehicle mobility state is Medium
then the vehicle skips some Femtocells along its trajectory. In particular, the Femtocell i is
considered as alternative if tresidence
u,i tresidence
u,mean , where tresidence
u,mean is the average residence time of
vehicle u considering all the available Femtocells in its current location. Finally, if the vehicle
mobility state is High then only Macrocells are considered as alternatives.
Thereafter the network selection is performed using the Pentagonal interval-valued Fuzzy
TOPSIS (PFT), considering both QoS aware (throughput, delay, jitter and packet loss) and
operator policies (service reliability, security and price) criteria. Since the list of network
alternatives is constructed considering the vehicle’s velocity and, then, the network selection is
performed using QoS and policy related parameters, the ping pong effect is eliminated.
4.2.4 Handover Execution
During the handover execution, the vehicle is connected to the selected network. After each
successfull handover of a vehicle, the number of handovers or reselections NCRu increases, in
order the aforementioned handover to be considered for the estimation of the vehicle velocity.
4.2.5 Computational Complexity of the Proposed Approach
Regarding the computational complexity of the proposed approach the HO initiation subprocess
requires a constant time to complete its tasks by performing simple checks against predefined
thresholds, resulting in O(1). Also, the network selection phase introduces an O(n2) complexity,
due to the weighting and normalization of the n×m decision matrices. Similar complexities
120 A Proposed Mobility Management Approach for 5G-VCC Systems
are introduced by other handover algorithms proposed in the research literature. The novelty
in our approach is that most of the computational complexity is performed at the Cloud/Fog
infrastructure.
4.3 Simulation Setup
In our experiments, the Software Defined Vehicular Cloud topology presented in Figure 4.6 is
considered. A mobility trace indicating the map of the city of Piraeus along with road traffic
data has been created using the Open Street Map (OSM) software [176]. Then, the mobility
trace has been used as input in the Simulator of Urban Mobility (SUMO) [177] allowing the
production of a realistic mobility pattern for the simulated vehicles including 39807 vehicles
in total, moving inside the Piraeus city in a 24 hours period. The average arrival rate of the
vehicles into the map is equal to 0,460729167 vehicles per second, while their average departure
rate is equal to 0,46 vehicles per second. Furthermore, the network topology is being built
upon the map, using the Network Simulator 3 (NS3) [178]. It includes a Fog infrastructure
and a Cloud infrastructure. The Fog infrastructure consists of 18 LTE Macrocell e-Node Bs
(eNBs), 39 LTE Femtocell eNBs, 16 WiMAX Macrocell Base Stations (BSs), 26 WiMAX
Femtocell BSs and 22 802.11p WAVE RSUs, equipped with additional computational and
storage resources. The access networks have been located on the map, according to the Hellenic
Telecommunications and Post Commission (EETT) [254] data about BSs’ positions in the
city of Piraeus. The positions and the spectrum of the BSs are presented in A1 to A3 tables
(Appendix A), for the LTE, WiMAX and WAVE technologies, respectively. The SDN controller
has a global view of the entire network environment. The Cloud infrastructure includes a set
of Virtual Machines (VMs) providing services such as Navigation Assistance (NAV), Voice
over IP (VoIP), Conversational Video (CV), Buffered Streaming (BS) and Web Browsing (WB).
Furthermore, a Software Defined Network (SDN) controller provides centralized control for
the entire system.
Each access network supports at least one of the aforementioned Cloud services, while four
Service Level Agreements (SLAs) are defined. SLA1 has the higher service priority and SLA 4
has the lower service priority. SLA1 supports all the service types and provides the best values
for QoS as well as policy decision criteria. SLA2 supports a smaller number of service types,
by not providing support for the VoIP and NAV services. Additionally, it provides slightly
worse decision criteria values than those offered by the SLA1. SLA3 supports only the BS and
the WB services and satisfactory QoS characteristics and policies. Finally, SLA4 supports only
the WB service while it provides acceptable decision criteria values.
4.3 Simulation Setup 121
Network specifications are expressed directly using linguistic terms (Appendix B). In
particular, the crisp values of the network QoS characteristics are converted into linguistic
terms which correspond to specific ranges of values per service type. Table 4.3 illustrates the
mapping between ranges of network QoS characteristics values and the respective linguistic
terms for the VoIP service. Table 4.4 summarizes the simulation parameters.
4.3.1 Study of a Simulation Snapshot
In this subsection, a snapshot of the simulation at time equal to 3600 seconds is considered.
Specifically, the case where 10 of the vehicles are monitored is studied, while each vehicle
needs to connect to a network which satisfies the requirements of its services and at the same
time complies with its respective SLA agreements. Table 4.5 presents the available networks in
the location of each vehicle.
4.3.1.1 VHO Initiation
During the HO initiation process, the user satisfaction Su,i is obtained using the MPFIS
Satisfaction Chart, considering the estimated Qu,i and SINRu,i values. It should be noted that
the services weights used for the Qu,i estimation are calculated using the PF-ANP method. The
criteria used include throughput, delay, jitter and packet loss. Figure 4.7 depicts the estimated
HO initiation weights for each service. Furthermore, the Sth,SLA thresholds given in Table
4.6 are estimated considering the minimum acceptable QSLA and SINRSLA values per SLA. If
the Su,i becomes less than the respective Sth,SLA threshold then the vehicle should perform a
handover to a new access network. The HO initiation results for each vehicle are presented in
Table 4.7. As it can be observed, vehicle 8 will remain to its current network i, while the rest of
the vehicles will procceed to handover.
4.3.1.2 Velocity Monitoring
For each one of the monitored vehicles, Table 4.8 presents its SLA, the services used, its
geographical position and its estimated velocity.
4.3.1.3 Network Selection
During the network selection process the PF-ANP method is applied in order to estimate the
weights of the network selection criteria per service type and SLA. Figure 4.8 depicts the
PF-ANP network model. The criteria are classified into two groups, namely the Network
QoS and the Network Policy characteristics. The Network QoS characteristics group contains
122 A Proposed Mobility Management Approach for 5G-VCC Systems
network performance related criteria including throughput, delay, jitter and packet loss. The
Network Policy characteristics group contains operator defined rules such as price, security and
service reliability. Pairwise comparison decision matrices are created based on relations among
the eight selection criteria depicted in Figure 4.9. Then, these pairwise comparison decision
matrices are used to evaluate the priority vectors of the criteria and to form the supermatrix
per service type and SLA. Subsequently, the weighted supermatrices and, finally, the limited
supermatrices are obtained. Indicatively, for the SLA1 NAV service, the initial, the weighted
and the limited supermatrices are presented in Tables 4.9, 4.10 and 4.11 respectively.
The criteria weights per service and SLA obtained by the limit supermatrices are presented
in Figures 4.10 - 4.13. As illustrated, the weights are proportional to the constraints of each
service as well as to the agreements of each SLA. In particular, the weight of the price criterion
is low for SLA1, in which the service reliability and the network QoS characteristics are
considered as the most important factors. In SLA2 the price criterion is more important than in
SLA1, thus the respective weight is greater than that of SLA1. Consequently, the weights of the
service reliability and QoS characteristics criteria in SLA2 are lower compared to the relative
weights of SLA1. In SLA3 the weights of price and service reliability criteria are balanced
as they are almost of equivalent importance. Finally, in SLA4 the price is the most important
criterion resulting in a high estimated weight value.
The PFT algorithm selects the best network for each vehicle considering the vehicle service
requirements. Figure 4.14 compares the results of the proposed scheme with the ones obtained
using VAH [218], FAT [255], FAS [255], FAM [255] and FAE [172]. In this Figure, for each
vehicle the PFT ranking of the current network as well as of the target network connection
estimated by each of the six schemes are presented. From the obtained results it is clear that
the suggested algorithm outperforms the existing schemes since it selects as target networks for
vehicles the ones with the best ranks. Also, in special cases where the velocity of the vehicles
is high (eg. for vehicle 7) the proposed scheme considers only the wide coverage candidate
networks as alternatives avoiding the handovers to femtocell networks.
Additionally, for a further evaluation of the proposed scheme, the user’s satisfaction grade
Su,i after the HO completion is considered. Figure 4.15 presents the estimated Su,i after
the execution of each HO scheme. As it can be observed, the results are similar to the
aforementioned PFT rankings, while the proposed approach achieves higher satisfaction grades
than the existing schemes.
4.3 Simulation Setup 123
4.3.2 24 Hours Simulation Results
For the entire 24-hour simulation, Tables C1, C2 and C3 (Appendix C) present the number of
vehicles that start their movement from each LTE, WiMAX and WAVE network, respectively,
as well as their corresponding velocities.
Table C4 presents the vehicle count per service and SLA. The entire service combinations
per SLA are considered, in order all the possible use cases to be studied during the simulation.
The number of possible service combinations (Sc) is estimated using formula 4.4 [256] where Sn
represents the number of the considered services. In this experiment, 5 services are considered,
namely the Navigation Assistance (NAV), Voice over IP (VoIP), Conversational Video (CV),
Buffered Streaming (BS) and Web Browsing (WB) and, thus, Sc is equal to 31. It should be
noted that SLA 1 supports all the services, while SLA 2 supports only the CV, BS and WB
services. Also, SLA 3 supports only the BS and WB services, while SLA 4 supports only the
WB service.
Sc = 2Sn
−1 (4.4)
The average PFT rankings of each HO scheme are presented in Figure 4.16, where all the
39807 vehicles are considered. As it can be observed, the proposed scheme accomplishes
higher ranking than the other schemes. On the contrary, the VAH scheme accomplishes the
lower ranking, due to the fact that it does not consider neither QoS related parameters, nor
operator policy related parameters. The other schemes accomplish intermediate results. The
FAT results are slightly better than the ones achieved from the rest of the schemes. Also,
Figure 4.17 presents the average satisfaction grade Su,i estimated for each HO scheme. The
proposed approach accomplishes the highest average values, compared to the rest of the HO
schemes. It should be noted that the number of HOs performed should be considered as a
critical parameter for the evaluation of the proposed HO scheme efficiency, since a smaller
number of HOs implies a lower network signaling overhead in both the user and the operator
sides. Figure 4.18 presents the total number of HOs performed in each scheme, during the
entire 24 hours simulation. As it is shown, the proposed scheme outperforms the other schemes,
since it performs a smaller number of HOs. Also, the VAH scheme accomplishes an acceptable
number of HOs, since it also considers the vehicle velocity for the handover process. However,
it does not avoid useless HOs to femtocells providing worse results than the proposed scheme.
The rest of the schemes accomplish similar HO numbers, since they are based on the perceived
RSS per user for the HO initiation process.
124 A Proposed Mobility Management Approach for 5G-VCC Systems
MMaaS
Vehicle uVehicle u Cloud
SDN Controller
Cloud
SDN Controller
Execute PFT for
Alternatives_Set_A(Macrocells)
Obtain offered characteristics of
Alternatives_Set_A(Macrocells)
If Su,i < Sth:
Result=Selected_Network
Fog
Current
Network i
Fog
Current
Network i
If velocity = High:
Obtain Su,i (Qu,i, SINRu,I)
Result=Handover_not_required
Else:
ObtainVelocityu(NCRu, TCRmax, λu)
Execute PFT for
Alternatives_Set_A
(Macrocells, Femtocells_subset)
Obtain offered characteristics of
Alternatives_Set_A
(Macrocells, Femtocells_subset)
Result=Selected_Network
If velocity = Medium:
Execute PFT for Alternatives_Set_A
(Macrocells, Femtocells)
Obtain offered characteristics of
Alternatives_Set_A
(Macrocells, Femtocells)
Result=Selected_Network
If velocity = Low:
Obtain Femtocells_subset
considering tresidence
If Result=Selected_Network:
D. VHO execution
C. Network selection
A. VHO initiation
B.VelocityMonitoring
Fog
Selected_Network
Fog
Selected_Network
Monitoring of
Qu,i and SINRu,i
When Qu,i < Qth or
SINRu,i < SINRth:
Figure 4.1 The Proposed Methodology.
4.3 Simulation Setup 125
Figure 4.2 The S Values Range as obtained using the FIS.
Figure 4.3 MFSINR Membership Functions Balance.
Figure 4.4 MFQ Membership Functions Balance.
Figure 4.5 MFS Membership Functions Balance.
126 A Proposed Mobility Management Approach for 5G-VCC Systems
Table 4.2 The Fuzzy Rule (or Knowledge) Base.
Rule MFSINR Operator MFQ MFS
1 AB or AP AU
2 TB and VP AU
3 B and VP VU
4 EN and VP U
5 ME and VP U
6 AE and VP SU
7 EX and VP SU
8 TB and P AU
9 B and P VU
10 EN and P U
11 ME and P U
12 AE and P SU
13 EX and P SU
14 TB and MP AU
15 B and MP VU
16 EN and MP SU
17 ME and MP SU
18 AE and MP LA
19 EX and MP SA
20 TB and M AU
21 B and M VU
22 EN and M LA
23 ME and M SA
24 AE and M A
25 EX and M MA
26 TB and MG VU
27 B and MG U
28 EN and MG SA
29 ME and MG A
30 AE and MG MA
31 EX and MG SS
32 TB and G VU
33 B and G U
34 EN and G A
35 ME and G MA
36 AE and G SS
37 EX and G S
38 TB and VG U
39 B and VG SU
40 EN and VG MA
41 ME and VG SS
42 AE and VG S
43 EX and VG VS
44 TB and AG U
45 B and AG LA
46 EN and AG S
47 ME and AG VS
48 AE and AG AS
49 EX and AG AS
4.3 Simulation Setup 127
WAVE RSU
WiMAX Femtocell
WiMAX Macrocell
LTE Femtocell
LTE Macrocell
Vehicle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
a b c d e f g h ui vj wk l m n o p tq r s x ya b c d e f g h ui vj wk l m n o p tq r s x y
a b c d e f g h ui vj wk l m n o p tq r s x ya b c d e f g h ui vj wk l m n o p tq r s x y
Cloud
VM
Services
VM
Services
VM
Services
VM
Services
VM
Services
VM
Services
VM
Services
VM
Services
...
...
...
... ...
...
...
...
Fog
SDN controller
MMaaS
SDN controller
MMaaS
Fog
WiMAX MacrocellsWiMAX Macrocells
LTE MacrocellsLTE Macrocells
LTE FemtocellsLTE Femtocells
WiMAX FemtocellsWiMAX Femtocells
WAVE RSUsWAVE RSUsWAVE RSUs
Figure 4.6 The Simulated Topology for the Evaluation of the proposed Mobility Management
Scheme.
Table 4.3 Relation of the Network QoS Characteristics and Linguistic Terms for VoIP.
Linguistic
term
Throughput
range (Kbps)
Delay
range (ms)
Jitter
range (ms)
Packet
loss range
AP ≤ 164 ≥ 116 ≥ 65 ≥ 0.4
VP 165 - 174 111-115 55 - 64 ≥ 0.2 - 0.4
P 175 - 184 106-110 45 - 54 >10−1
- <0.2
MP 185 - 194 100 - 105 40 - 44 10−1
M 195 - 204 95 - 99 35 - 49 10−2
MG 205 - 214 86 - 94 30 - 34 10−3
G 215 - 224 66 - 85 25 - 29 10−4
VG 225 - 239 41 - 65 20 - 24 10−5
AG ≥ 240 ≤ 40 ≤ 20 ≤ 10−6
0
0,1
0,2
0,3
0,4
0,5
Navigation Assistance VoIP Conversational Video Buffered Streaming Web
Weight
Network Initiation weights
Throughput Delay Jitter Packet loss
Figure 4.7 Criteria Weights per Service for the HO Initiation.
128 A Proposed Mobility Management Approach for 5G-VCC Systems
Table 4.4 The Simulation Parameters for the Evaluation of the proposed Mobility Management
Scheme.
Parameter Value
Simulation duration 86400 seconds (24 hours)
Networks count
LTE Macrocell BSs: 20
LTE Femtocell BSs: 37
WiMAX Macrocell BSs: 17
WiMAX Femtocell BSs: 25
WAVE RSUs: 22
Total: 121
Cells radius
LTE/WiMAX Macrocells: 400 meters
LTE/WiMAX Femtocells: 30 meters
WAVE RSUs: 150 meters
Networks positions
According to the Hellenic Telecommu-
nications and Post Commission (EETT)
[254] data (see Appendix A)
Networks frequencies See Appendix A
Service Layer Agreements
(SLA) count
4
Vehicles count 39807
Average vehicles arrival rate 0,460729167 vehicles per second
Average vehicles departure rate 0,46 vehicles per second
Vehicles per SLA
SLA 1: 9952 vehicles (25,00062803 %)
SLA 2: 9952 vehicles (25,00062803 %)
SLA 3: 9952 vehicles (25,00062803 %)
SLA 4: 9951 vehicles (24,99811591 %)
Available networks per SLA See Appendix B
Services
Navigation Assistance (NAV)
Voice over IP (VoIP)
Conversational Video (CV)
Buffered Streaming (BS)
Web Browsing (WB)
Distribution of services to
vehicles
See Appendix C
Vehicles per velocity
Normal: 13348 (33.53 %)
Medium: 13348 (33.53 %)
High: 13111 (32.94 %)
Table 4.5 The available Networks for each Monitored Vehicle.
Vehicle Available Networks in Current Location
1 LTE Macro 9, LTE Macro 11, LTE Femto 17, WiMAX Macro 8, WiMAX Macro 9, WiMAX Macro 11, WiMAX Femto
13, WAVE 14
2 LTE Macro 9, LTE Macro 11, LTE Femto 17, WiMAX Macro 8, WiMAX Macro 9, WiMAX Macro 11, WiMAX Femto
13, WAVE 14
3 LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Macro 18, LTE Femto 30, WiMAX Macro 8, WiMAX Macro 9,
WiMAX Macro 11, WiMAX Macro 13
4 LTE Macro 4, LTE Macro 6, LTE Macro 7, LTE Macro 9, LTE Macro 11, LTE Macro 13, WiMAX Macro 6, WiMAX
Macro 8, WiMAX Macro 11, WAVE 9, WAVE 11, WAVE 13
5 LTE Macro 4, LTE Macro 6, LTE Macro 7, WiMAX Macro 6, WAVE 9
6 LTE Macro 7, LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Femto 26, WiMAX Macro 6, WiMAX Macro 7,
WiMAX Macro 8, WiMAX Macro 11, WiMAX Macro 13, WiMAX Femto 15, WAVE 11, WAVE 15
7 LTE Macro 10, LTE Macro 13, LTE Macro 17, LTE Macro 18, LTE Femto 29, WiMAX Macro 7, WiMAX Macro 13,
WiMAX Macro 15, WAVE 19
8 LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Macro 18, LTE Femto 30, WiMAX Macro 8, WiMAX Macro 9,
WiMAX Macro 11, WiMAX Macro 13
9 LTE Macro 3, LTE Macro 5, LTE Macro 9, WiMAX Macro 5, WiMAX Macro 8, WiMAX Macro 9
10 LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Macro 18, LTE Femto 30, WiMAX Macro 8, WiMAX Macro 9,
WiMAX Macro 11, WiMAX Macro 13
4.3 Simulation Setup 129
Table 4.6 The QSLA, SINRSLA and Sth,SLA thresholds per SLA.
SLA QSLA SINRSLA Sth,SLA
1 0.9 0.8 0.81675
2 0.8 0.7 0.70856
3 0.7 0.6 0.54440
4 0.6 0.5 0.42725
Table 4.7 The HO Initiation Results.
Vehicle Current Network i Qu,i SINRu,i (SINRdB
u,i ) Su,i Sth,SLAu Handover Required
1 WAVE 14 0.871 0.14 (-5.1 dB) 0.18157 0.81843 Yes
2 LTE Macro 11 0.912 0.17 (-4.05 dB) 0.18212 0.81843 Yes
3 WiMAX Macro 8 0.948 0.29 (0.15 dB) 0.32523 0.81843 Yes
4 LTE Macro 7 0.644 0.23 (-1.95 dB) 0.12122 0.66980 Yes
5 WAVE 9 0.990 0.14 (-5.1 dB) 0.18156 0.66980 Yes
6 WAVE 11 0.827 0.04 (-8.6 dB) 0.02539 0.66980 Yes
7 WiMAX Macro 7 0.999 0.21 (-2.65 dB) 0.18965 0.57767 Yes
8 WiMAX Macro 11 0.704 0.71 (14.85 dB) 0.61247 0.57767 No
9 WiMAX Macro 5 0.988 0.25 (-1.25 dB) 0.27297 0.45457 Yes
10 LTE Macro 18 0.990 0.29 (0.15 dB) 0.35622 0.45457 Yes
Table 4.8 The Monitored Vehicles Status.
Vehicle SLA Services Current Position (Latitude, Longitude) Velocity
1 1 VoIP, CV, BS 9n (37.942128, 23.650937) Medium
2 1 NAV, VoIP, WB 9m (37.942178, 23.650796) Normal
3 1 NAV 13j (37.938831, 23.647276) Medium
4 2 CV, BS 8i (37.942819, 23.647134) Normal
5 2 BS 7g (37.943935, 23.645180) High
6 2 CV, WB 10h (37.941048, 23.645664) Normal
7 3 BS 14e (37.938048, 23.642797) High
8 3 BS, WB 13j (37.988787, 23.647321) Medium
9 4 WB 8o (37.943331, 23.652023) High
10 4 WB 13j (37.938858, 23.647291) Normal
Network Selection Weights per Service
Network QoS
Characteristics
Network Policy
Characteristics
Troughput
Delay
Jitter
Packet Loss
Service Reliability
Price
Goal
Criteria Groups
Criteria
Security
Figure 4.8 The PF-ANP Network Model.
130 A Proposed Mobility Management Approach for 5G-VCC Systems
Throughput
Delay Jitter
Packet loss
Throughput
Delay Jitter
Packet loss
Service
Reliability
Price
Security
Figure 4.9 The Relations of the Criteria considered by the PF-ANP Network Model.
0
0,05
0,1
0,15
0,2
0,25
Navigation Assistance VoIP Conversational Video Buffered Streaming Web
Weight
Network Selection weights for SLA 1
Throughput Delay Jitter Packet loss Service Reliability Security Price
Figure 4.10 The Network Selection Weights per Service for SLA 1.
0
0,05
0,1
0,15
0,2
0,25
Conversational Video Buffered Streaming Web
Weight
Network Selection weights for SLA 2
Throughput Delay Jitter Packet loss Service Reliability Security Price
Figure 4.11 The Network Selection Weights per Service for SLA 2.
0
0,05
0,1
0,15
0,2
0,25
Buffered Streaming Web
Weight
Network Selection weights for SLA 3
Throughput Delay Jitter Packet loss Service Reliability Security Price
Figure 4.12 The Network Selection Weights per Service for SLA 3.
0
0,05
0,1
0,15
0,2
0,25
Web
Weight
Network Selection weights for SLA 4
Throughput Delay Jitter Packet loss Service Reliability Security Price
Figure 4.13 The Network Selection Weights per Service for SLA 4.
4.3 Simulation Setup 131
Table 4.9 The PF-ANP Initial Supermatrix for the SLA 1 NAV Service.
Throughput Delay Jitter Packet loss Service
Reliability
Security Price
Throu-
ghput
[(0.37,0.36,0.34,
0.33,0.32,1,0.8,0.8),
(0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)]
[(0.37,0.36,0.34,
0.33,0.32,1,0.8,0.8),
(0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)]
[(0.37,0.36,0.34,
0.33,0.32,1,0.8,0.8),
(0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)]
[(0.37,0.36,0.34,
0.33,0.32,1,0.8,0.8),
(0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)]
[(0.37,0.36,0.349
0.33,0.32,1,0.8,0.8),
(0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)]
[(0.37,0.36,0.34,
0.33,0.32,1,0.8,0.8),
(0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)]
[(0.37,0.36,0.34,
0.33,0.32,1,0.8,0.8),
(0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)]
Delay
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)]
[(0.23,0.21,0.21
,0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)]
Jitter
[(0.16,0.2,0.22,
0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)]
[(0.16,0.2,0.22,
0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)]
[(0.16,0.2,0.22,
0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)]
[(0.16,0.2,0.22,
0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)]
[(0.16,0.2,0.22,
0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)]
[(0.16,0.2,0.22,
0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)]
[(0.16,0.2,0.22,
0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)]
Packet
loss
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6)]
[(0.23,0.21,0.21,
0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21,
0.21,0.21,0.8,0.6)]
Service
Reliabil-
ity
[(0.52,0.47,0.42
,0.4,0.4,1,0.8,0.8),
(0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)]
[(0.52,0.47,0.42,
0.4,0.4,1,0.8,0.8),
(0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)]
[(0.52,0.47,0.42,
0.4,0.4,1,0.8,0.8),
(0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)]
[(0.52,0.47,0.42,
0.4,0.4,1,0.8,0.8),
(0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)]
[(0.52,0.47,0.42,
0.4,0.4,1,0.8,0.8),
(0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)]
[(0.52,0.47,0.42,
0.4,0.4,1,0.8,0.8),
(0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)]
[(0.52,0.47,0.42,
0.4,0.4,1,0.8,0.8),
(0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)]
Security
[(0.37,0.39,0.4,
0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4,
0.4,0.4,0.8,0.6,0.6)]
[(0.37,0.39,0.4,
0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4,
0.4,0.4,0.8,0.6,0.6)]
[(0.37,0.39,0.4,
0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4,
0.405,0.4,0.8,0.6,0.6)]
[(0.37,0.39,0.4,
0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4,
0.4,0.403,0.8,0.6,0.6)]
[(0.37,0.39,0.4,
0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4,
0.4,0.4,0.8,0.6,0.6)]
[(0.37,0.39,0.4,
0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4,
0.4,0.4,0.8,0.6,0.6)]
[(0.37,0.39,0.4,
0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4,
0.4,0.4,0.8,0.6,0.6)]
Price
[(0.09,0.13,0.16,
0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.16,
0.18,0.18,0.8,0.6,0.6)]
[(0.09,0.13,0.16,
0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.16,
0.18,0.18,0.8,0.6,0.6)]
[(0.09,0.13,0.16,
0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.166,
0.18,0.18,0.8,0.6,0.6)]
[(0.09,0.13,0.16,
0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.16,
0.18,0.18,0.8,0.6,0.6)]
[(0.09,0.13,0.16,
0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.16,
0.18,0.18,0.8,0.6,0.6)]
[(0.09,0.13,0.16,
0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.16,
0.18,0.18,0.8,0.6,0.6)]
[(0.09,0.13,0.16,
0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.16,
0.18,0.18,0.8,0.6,0.6)]
Table 4.10 The PF-ANP Weighted Supermatrix for the SLA 1 NAV Service.
Throughput Delay Jitter Packet loss Service
Reliability
Security Price
Throu-
ghput
[(0.18,0.18,0.17,
0.16,0.16,1,0.8,0.8),
(0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)]
[(0.18,0.18,0.17,
0.16,0.16,1,0.8,0.8),
(0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)]
[(0.18,0.18,0.17,
0.16,0.16,1,0.8,0.8),
(0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)]
[(0.18,0.18,0.17,
0.16,0.16,1,0.8,0.8),
(0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)]
[(0.18,0.18,0.17,
0.16,0.16,1,0.8,0.8),
(0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)]
[(0.18,0.18,0.17,
0.16,0.16,1,0.8,0.8),
(0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)]
[(0.18,0.18,0.17,
0.16,0.16,1,0.8,0.8),
(0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)]
Delay
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.106,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,0.1,
0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
Jitter
[(0.08,0.1,0.11,
0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)]
[(0.08,0.1,0.11,
0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)]
[(0.08,0.1,0.11,
0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)]
[(0.08,0.1,0.11,
0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)]
[(0.08,0.1,0.11,
0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)]
[(0.08,0.1,0.11,
0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)]
[(0.08,0.1,0.11,
0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)]
Packet
loss
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.106,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.10,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
[(0.11,0.1,0.1,
0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)]
Service
Reliabil-
ity
[(0.26,0.23,0.21,
0.2,0.2,1,0.8,0.8),
(0.24,0.22,0.21,
0.2,0.2,0.8,0.6,0.6)]
[(0.26,0.23,0.21,
0.2,0.2,1,0.8,0.8),
(0.24,0.22,0.21,
0.2,0.2,0.8,0.6,0.6)]
[(0.26,0.23,0.21,
0.2,0.2,1,0.8,0.8),
(0.24,0.22,0.21,
0.2,0.2,0.8,0.6,0.6)]
[(0.26,0.23,0.21,
0.2,0.2,1,0.8,0.8),
(0.24,0.22,0.21,
0.2,0.2,0.8,0.6,0.6)]
[(0.26,0.23,0.21,
0.2,0.2,1,0.8,0.8),
(0.24,0.22,0.21,
0.2,0.2,0.8,0.6,0.6)]
[(0.26,0.23,0.21,
0.2,0.2,1,0.8,0.8),
(0.24,0.22,0.21,
0.2,0.2,0.8,0.6,0.6)]
[(0.26,0.23,0.21,
0.2,0.2,1,0.8,0.8),
(0.24,0.2,0.21,
0.2,0.2,0.8,0.6,0.6)]
Security
[(0.18,0.19,0.2,
0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)]
[(0.18,0.19,0.2,
0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)]
[(0.18,0.19,0.2,
0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)]
[(0.18,0.19,0.2,
0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)]
[(0.18,0.19,0.2,
0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)]
[(0.18,0.19,0.2,
0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)]
[(0.18,0.19,0.2,
0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)]
Price
[(0.04,0.06,0.08,
0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)]
[(0.04,0.06,0.08,
0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)]
[(0.04,0.06,0.08,
0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)]
[(0.04,0.06,0.08,
0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)]
[(0.04,0.06,0.08,
0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)]
[(0.04,0.06,0.08,
0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)]
[(0.04,0.06,0.08,
0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)]
Table 4.11 The PF-ANP Limit Supermatrix for the SLA 1 NAV Service.
Throughput Delay Jitter Packet loss Service
Reliability
Security Price
Throughput 0.175346 0.175346 0.175346 0.175346 0.175346 0.175346 0.175346
Delay 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943
Jitter 0.104768 0.104768 0.104768 0.104768 0.104768 0.104768 0.104768
Packet loss 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943
Service
Reliability
0.195427 0.195427 0.195427 0.195427 0.195427 0.195427 0.195427
Security 0.188775 0.188775 0.188775 0.188775 0.188775 0.188775 0.188775
Price 0.115798 0.115798 0.115798 0.115798 0.115798 0.115798 0.115798
132 A Proposed Mobility Management Approach for 5G-VCC Systems
0
0,1
0,2
0,3
0,4
0,5
0,6
Vehicle 1
v=Medium
Vehicle 2
v=Normal
Vehicle 3
v=Medium
Vehicle 4
v=Normal
Vehicle 5
v=High
Vehicle 6
v=Normal
Vehicle 7
v=High
Vehicle 8
v=Medium
Vehicle 9
v=High
Vehicle 10
v=Normal
PFTrank
PFT ranking of each VHO scheme
Current Network Proposed Scheme VAH FAT FAS FAM FAE
Figure 4.14 The PFT Ranking of each HO Scheme.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
Satisfactiongrade(Su,i)
Satisfaction grade obtained from each VHO scheme
Proposed VAH FAT FAS FAM FAE
Figure 4.15 The Satisfaction Grade obtained from each HO Scheme.
0,43
0,44
0,45
0,46
0,47
0,48
0,49
Proposed VAH FAT FAS FAM FAE
AveragePFTrank
VHO scheme
Average PFT ranking of each VHO scheme
Figure 4.16 The Average PFT Ranking of each HO Scheme during the 24 Hours Simulation.
0,6
0,62
0,64
0,66
0,68
0,7
0,72
0,74
0,76
Proposed VAH FAT FAS FAM FAE
Averagesatisfactiongrade(Su,i)
VHO scheme
Average satisfaction grade obtained from each VHO scheme
Figure 4.17 The Average Satisfaction Grade obtained from each HO Scheme during the 24
Hours Simulation.
200000
250000
300000
350000
400000
450000
Proposed VAH FAT FAS FAM FAE
VHOscount
VHO scheme
VHOs count of each VHO scheme
Figure 4.18 The Total HOs Count of each HO Scheme during the 24 Hours Simulation.
Chapter 5
Conclusion
In this doctoral thesis, two key aspects of the 5G-VCC systems were studied, namely the
allocation of network resources and the handling of the vehicles’ mobility.
Regarding the allocation of the network resources, an overview of the available MAC
schemes for vehicular networks has been performed [257]. These schemes can be applied in
5G-VCC systems in order optimal manipulation of communication resources to be performed.
Some schemes organize the vehicles into clusters, while GPS receivers are used in some
cases in order the vehicles to be synchronized with each other. The discussed schemes apply
either distributed or centralized control. In a 5G-VCC system the centralized control could be
enhanced using an SDN controller, while the distributed control could be easily configured
using a Fog computing infrastructure. Furthermore, V2V communication is supported from
most schemes, while some schemes support V2I communication. Finally, during the medium
access, CRN could be applied to take advantage of free white spaces into the available spectrum.
Subsequently, a QoS aware scheduler called FLSA [258][259] was proposed in order to
improve the resource allocation for real time services in the LTE downlink. FLSA has been built
on three distinct levels which cooperate with each other to allocate the network resources to
users. In every TTI the upper level estimates the quota of the data that each real-time flow should
transmit to satisfy its QoS constraints. Then, the middle level uses the M-LWDF algorithm
to allocate RBs to real time flows in each TTI for transmitting their quota of data obtained by
the upper level. Thereafter, if there are free RBs available in the current TTI, the lower level
allocates them both to real time and to best effort flows, using the M-LWDF algorithm. The
performance of FLSA for real time flows was compared against other scheduling algorithms in
terms of PLR, attainable throughput and fairness. The simulation results showed that the FLSA
scheduler outperforms the rest of the schemes by achieving better resource allocation for real
time services.
134 Conclusion
Furthermore, FLSA-CC [260], QoS aware cross carrier downlink scheduler has also been
proposed as an extended version of the FLSA. FLSA-CC operates in an LTE-A network
with relay nodes in a CA mode. The proposed scheduler has been built upon three distinct
levels which cooperate with each other to allocate the network resources to users in a manner
that the requirements of strict real times services are satisfied while a starvation of the best
effort traffic is avoided. The performance of FLSA-CC is compared against other scheduling
algorithms in terms of PLR, throughput and fairness index, in a cloud assisted software defined
architecture. The simulation results showed that the FLSA-CC scheduler outperforms the rest
of the scheduling schemes by achieving better resource allocation for both real time and best
effort services.
An overview of existing mobility management schemes has been made. These schemes
can be applied to 5G-VCC systems in order an optimal manipulation of vehicles mobility to be
performed. Each scheme implements one or more mobility management subprocesses, namely
HO initiation, network selection and HO execution. The 5G-VCC topologies (e.g. VC, VuC,
VuF, SDN-V and HVT) that each scheme supports were mentioned, while the communication
models that could be applied in each scheme (V2V, V2I, V2P and HVC) were introduced. The
control type of each scheme (vehicle or network controlled) was also described, while at the
same time the OSI layer where each scheme was implemented indicate its mobility management
capabilities. In addition, the supported message exchange mechanisms were considered, while
the evaluation of each scheme considering the type of the implemented algorithms provided
useful knowledge about its design.
Novel mobility management algorithms for 5G networks were proposed. Specifically,
firstly, we described a network selection method that takes into account the network QoS
characteristics policies, application requirements and different types of user SLAs to select the
optimal network that will satisfy simultaneously all the applications’ requirements and the users’
preferences running on a mobile user’s device [171]. The proposed method employed two
MADM algorithms: the ANP for criteria weights calculation and the TFT for accomplishing
the overall rating of the network technologies. ANP was selected to determine the relative
importance and the dependence of the criteria. As selection criteria, we considered the network
QoS parameters, service constraints, user requirements and provider policies. These criteria
were represented by interval-valued trapezoidal fuzzy numbers. Then, the TFT algorithm was
applied to calculate the overall rating of the available networks. The performance evaluation of
TFT showed that when a user has only one service, it provides similar results to the original
TOPSIS and FAE methods. However, when a user requires multiple services, TFT performs
better by satisfying multiple groups of criteria per user since the original TOPSIS and FAE
methods cannot support more than one services. Furthermore, according to the sensitivity
135
analysis of results it was shown that the described method doesn’t suffer from the ranking
abnormality problem, thus, the results are normally adjusted to the heterogeneous network
environment changes.
Furthermore, we proposed a network selection scheme for supporting medical services in
5G-VCC systems [68][261]. The discussed scheme consists of the TF-ANP method to calculate
the relative importance of the selection criteria and the TFT to accomplish the ranking of the
candidate networks. The health status of each patient is considered, while the criteria used for
network evaluation included throughput, delay, jitter, packet loss, service reliability, security
and price. The performance evaluation showed that the proposed scheme outperforms existing
network selection methods by satisfying multiple groups of criteria and medical services per
user. Also, we proposed an improved version of this scheme [66]. In this case, the discussed
scheme consists of two FMADM algorithms, namely the TF-AANP to calculate the relative
importance of each service, as well as the weights of the selection criteria and the TFT-ACW to
accomplish the ranking of the candidate networks. The health status of onboard patients and
the SLA of each vehicle were considered, while the criteria used for network evaluation include
throughput, delay, jitter, packet loss, service reliability, security and price. The performance
evaluation showed that the proposed scheme outperforms existing network selection methods
by satisfying the strict constraints of medical services, when the patient’s health status becomes
immediate and multiple types of non-medical services coexist with medical services to the
vehicle.
Finally, we proposed a HO management scheme for 5G-VCC systems that takes into
account the vehicle velocity, network’s QoS and policy characteristics, the vehicular services’
requirements and the various vehicle SLAs to select the optimal network that will satisfy
simultaneously all the service requirements and onboard user preferences [67][262]. The
HO management services are executed at the Cloud or the Fog infrastructure alleviating the
vehicle’s processing load and reducing HO latency. IVPFNs are used for the representation
of both HO Initiation and Network Selection criteria values, while the PF-ANP algorithm is
used for the estimation of the criteria weights for both HO Initiation and Network Selection.
During the HO Initiation, MPFIS evaluates the necessity to perform a handover, while during
the Network Selection, the PFT algorithm selects the most appropriate network considering
the vehicle’s velocity, the constraints of used vehicular services and the SLA of the vehicle.
The performance evaluation showed that the Always Best Connected (ABC) principle is fully
ensured, while at the same time the proposed scheme outperforms existing HO management
algorithms in terms of the PFT ranks of the selected networks, the user satisfaction grade, as
well as the VHOs count.
136 Conclusion
5.1 Directions for Future Work
This section discusses some open issues arising from the study of the existing resource allo-
cation and mobility management schemes. Although several schemes have been proposed to
the research literature, some issues need to be resolved in cases where they resource allocation
and/or mobility management concerns a 5G-VCC system. Specifically, although many algo-
rithms can perform resource allocation and/or mobility management in 5G-VCC systems, the
support for relay vehicles is limited. Vehicular relaying could be used in order vehicles with
no access to RSUs/BSs to obtain this access through vehicles that already have it and could
be called as relay vehicles. In these cases, vehicular relaying increases the coverage area of
the 5G-VCC system providing access to an increased number of vehicles. Furthermore, in
these cases Vehicle to Vehicle (V2V) routing issues must be addressed, since a vehicle should
obtain access to RSUs/BSs through more than one relaying vehicles. However, the existing
resource allocation algorithms are not optimized for distributing the communication resources
of relay vehicles. Also, mobility management schemes do not address relay vehicles selection
or routing issues.
Furthermore, the resource allocation and/or mobility management functionalities of the
5G-VCC systems can be performed by a Cloud or a Fog infrastructure, as well as using SDN
controllers, leading to solutions where both Host and Network control are combined. An
open issue that arises from this situation is the need for the implementation of purely network
controlled solutions, where components of the 5G-VCC infrastructure with fully knowledge
about vehicles’ network status as well as with a complete view of the entire system, will perform
the resource allocation and/or the mobility management releasing the vehicular equipment from
this task, freeing up its resources and reducing its energy requirements.
Publications
1. Emmanouil Skondras, Eirini Zoumi, Angelos Michalas, Dimitrios D. Vergados, “A Net-
work Selection Algorithm for supporting Drone Services in 5G Network Architectures”,
Wireless Telecommunications Symposium (WTS), New York, USA, April 9-12, 2019
2. Konstantina Siountri, Emmanouil Skondras, Theodoros Mavroeidakos, Dimitrios D.
Vergados, “The Convergence of Blockchain, Internet of Things (IoT) and Building
Information Modeling (BIM): The smart museum case”, Wireless Telecommunications
Symposium (WTS), New York, USA, April 9-12, 2019
3. Emmanouil Skondras, Angelos Michalas, Dimitrios D. Vergados, “Mobility Manage-
ment on 5G Vehicular Cloud Computing Systems”, Vehicular Communications Journal,
Elsevier, vol. 16, pp. 15-44, April 2019
4. Emmanouil Skondras, Konstantina Siountri, Angelos Michalas, Dimitrios D. Vergados,
“Personalized Real-Time Virtual Tours in Places with Cultural Interest”, International
Journal of Computational Methods in Heritage Science (IJCMHS), IGI Global, vol. 3,
issue 1, January 2019
5. Konstantina Siountri, Emmanouil Skondras, Dimitrios D. Vergados, Christos-Nikolaos
Anagnostopoulos, “The Revival of Back-Filled Monuments through Augmented Reality
(AR)”, Visual Heritage Congress, Vienna, Austria, November 12-15, 2018
6. Konstantina Siountri, Emmanouil Skondras, Dimitrios D. Vergados, “A Delivery Model
for Cultural Heritage Services in Smart Cities Environments”, Euro-Mediterranean
Conference (EUROMED), Springer, pp.279-288, Nicosia, Cyprus, October 29-November
3, 2018
7. Emmanouil Skondras, Angelos Michalas, Dimitrios D. Vergados, “A Survey on Medium
Access Control Schemes for 5G Vehicular Cloud Computing Systems”, Global Informa-
tion Infrastructure and Networking Symposium (GIIS), Thessaloniki, Greece, October
23-25, 2018
138 Conclusion
8. Emmanouil Skondras, Konstantina Siountri, Angelos Michalas, Dimitrios D. Vergados,
“A Route Selection Scheme for supporting Virtual Tours in Sites with Cultural Interest
using Drones”, International Conference on Information, Intelligence, Systems and
Applications (IISA), Zakynthos, Greece, July 23-25, 2018
9. Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Dimitrios D. Vergados, “A
Network Selection Scheme with Adaptive Criteria Weights for 5G Vehicular Systems”,
International Conference on Information, Intelligence, Systems and Applications (IISA),
Zakynthos, Greece, July 23-25, 2018
10. Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Dimitrios D. Vergados, “A
VHO Scheme for supporting Healthcare Services in 5G Vehicular Cloud Computing
Systems”, Wireless Telecommunications Symposium (WTS), Phoenix, Arizona, USA,
April 18-20, 2018
11. Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Aggeliki Sgora, Dimitrios D.
Vergados, “A Network Selection Scheme for Healthcare Vehicular Cloud Computing Sys-
tems”, International Conference on Information, Intelligence, Systems and Applications
(IISA), Larnaka, Cyprus, August 28-30, 2017
12. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “A
Vertical Handover management scheme for VANET Cloud Computing systems”, IEEE
Symposium on Computers and Communications (ISCC), Heraklion, Crete, Greece, July
3-6, 2017
13. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “QoS-
aware scheduling in LTE-A networks with SDN control”, International Conference on
Information, Intelligence, Systems and Applications (IISA), Chalkidiki, Greece, July
13-15, 2016
14. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “A
downlink scheduler supporting real time services in LTE cellular networks”, Interna-
tional Conference on Information, Intelligence, Systems and Applications (IISA), Ionian
University, Corfu, Greece, July 6-8, 2015
15. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “A
QoS Aware Three Level Scheduler for the LTE Downlink”, Wireless Telecommunications
Symposium (WTS), Poster Paper, New York, USA, April 15-17, 2015
5.1 Directions for Future Work 139
16. Emmanouil Skondras, Aggeliki Sgora, Angelos Michalas, Dimitrios D. Vergados, “An
analytic network process and trapezoidal interval-valued fuzzy technique for order
preference by similarity to ideal solution network access selection method”, International
Journal of Communication Systems (IJCS), Wiley, September 2014
17. Emmanouil Skondras, Angelos Michalas, Malamati Louta, George Kouzas, “Personal-
ized Multimedia Web Services in Peer to Peer Networks Using MPEG-7 and MPEG-21
Standards”, Studies in Computational Intelligence – Semantic Hyper/Multimedia Adapta-
tion, Volume 418/2013 (book chapter), pp. 361-383, Springer-Verlag Berlin Heidelberg,
2013
Performance Analysis and Optimization of Next Generation Wireless Networks
Bibliography
[1] Ricard Vilalta, Victor Lopez, Alessio Giorgetti, Shuping Peng, Vittorio Orsini, Luis
Velasco, Rene Serral-Gracia, Donal Morris, Silvia De Fina, Filippo Cugini, et al. Tel-
cofog: A unified flexible fog and cloud computing architecture for 5g networks. IEEE
Communications Magazine, 55(8):36–43, 2017.
[2] Faqir Zarrar Yousaf, Michael Bredel, Sibylle Schaller, and Fabian Schneider. Nfv
and sdn-key technology enablers for 5g networks. IEEE Journal on Selected Areas in
Communications, 2017.
[3] Hojjat Salehinejad, Hossein Nezamabadi-pour, Saeid Saryazdi, and Fereydoun Farrahi-
Moghaddam. Combined a*-ants algorithm: a new multi-parameter vehicle navigation
scheme. arXiv preprint arXiv:1504.07329, 2015.
[4] Pietro Edoardo Carnelli, Joy Yeh, Mahesh Sooriyabandara, and Aftab Khan. Parkus: A
novel vehicle parking detection system. In AAAI, pages 4650–4656, 2017.
[5] Yang Li, Xiaoming Tao, and Jianhua Lu. Hybrid model-and-object-based real-time
conversational video coding. Signal Processing: Image Communication, 35:9–19, 2015.
[6] Toon De Pessemier, Isabelle Stevens, Lieven De Marez, Luc Martens, and Wout Joseph.
Quality assessment and usage behavior of a mobile voice-over-ip service. Telecommuni-
cation Systems, 61(3):417–432, 2016.
[7] Henrik Klessig and Gerhard Fettweis. Impact of inter-cell interference on buffered video
streaming startup delays. In Vehicular Technology Conference (VTC Fall), 2015 IEEE
82nd, pages 1–2. IEEE, 2015.
[8] Verdes Pedras, Marco Sousa, Pedro Vieira, Maria-Paula Queluz, and Antonio Rodrigues.
A no-reference user centric qoe model for voice and web browsing based on 3g/4g radio
measurements. In Wireless Communications and Networking Conference (WCNC), 2018
IEEE, pages 1–6. IEEE, 2018.
[9] Zinonas C Antoniou, Andreas S Panayides, Marios Pantziaris, Anthony G Constantinides,
Constantinos S Pattichis, and Marios S Pattichis. Dynamic network adaptation for real-
time medical video communication. In XIV Mediterranean Conference on Medical and
Biological Engineering and Computing 2016, pages 1099–1104. Springer, 2016.
[10] Luís FR Lucas, Nuno MM Rodrigues, Luis A da Silva Cruz, and Sérgio MM de Faria.
Lossless compression of medical images using 3-d predictors. IEEE transactions on
medical imaging, 36(11):2250–2260, 2017.
142 Bibliography
[11] Gopi Krishna Garge, Chitra Balakrishna, and Soumya Kanti Datta. Consumer health care:
Current trends in consumer health monitoring. IEEE Consumer Electronics Magazine,
7(1):38–46, 2018.
[12] Qinghan Xue and Mooi Choo Chuah. Incentivising high quality crowdsourcing medical
data for disease diagnose & survival prediction. Smart Health, 2017.
[13] Tugce Bilen, Berk Canberk, and Kaushik R Chowdhury. Handover management in
software-defined ultra-dense 5g networks. IEEE Network, 31(4):49–55, 2017.
[14] TS 36.213 version 14.2.0: Evolved Universal Terrestrial Radio Access Network (E-
UTRAN) (Release 14). Technical Specification, 3GPP, 2017.
[15] P802.16/d4 - ieee draft standard for air interface for broadband wireless access systems
(revision of ieee std 802.16-2012). IEEE Standard, 2017.
[16] 1609.12-2016 - ieee standard for wireless access in vehicular environments (wave) –
networking services. IEEE Standard, 2016.
[17] Hucheng Wang, Shanzhi Chen, Ming Ai, and Hui Xu. Localized mobility management
for 5g ultra dense network. IEEE Transactions on Vehicular Technology, 66(9):8535–
8552, 2017.
[18] Daniel Calabuig, Sokratis Barmpounakis, Sonia Gimenez, Apostolos Kousaridas, Tilak R
Lakshmana, Javier Lorca, Petteri Lunden, Zhe Ren, Pawel Sroka, Emmanuel Ternon,
et al. Resource and mobility management in the network layer of 5g cellular ultra-dense
networks. IEEE Communications Magazine, 55(6):162–169, 2017.
[19] Tarik Taleb, Adlen Ksentini, and Riku Jantti. " anything as a service" for 5g mobile
systems. IEEE Network, 30(6):84–91, 2016.
[20] Rakibul Islam Rony, Akshay Jain, Elena Lopez-Aguilera, Eduard Garcia-Villegas, and
Ilker Demirkol. Joint access-backhaul perspective on mobility management in 5g
networks. In Standards for Communications and Networking (CSCN), 2017 IEEE
Conference on, pages 115–120. IEEE, 2017.
[21] Akshay Jain, Elena Lopez-Aguilera, and Ilker Demirkol. Mobility management as a
service for 5g networks. arXiv preprint arXiv:1705.09101, 2017.
[22] Ke Zhang, Yuming Mao, Supeng Leng, Yejun He, and Yan Zhang. Mobile-edge
computing for vehicular networks: A promising network paradigm with predictive
off-loading. IEEE Vehicular Technology Magazine, 12(2):36–44, 2017.
[23] Binxu Yang, Wei Koong Chai, Zichuan Xu, Konstantinos V Katsaros, and George Pavlou.
Cost-efficient nfv-enabled mobile edge-cloud for low latency mobile applications. IEEE
Transactions on Network and Service Management, 2018.
[24] Xumin Huang, Rong Yu, Jiawen Kang, Yejun He, and Yan Zhang. Exploring mobile
edge computing for 5g-enabled software defined vehicular networks. IEEE Wireless
Communications, 24(6):55–63, 2017.
Bibliography 143
[25] Mehdi Sookhak, F Richard Yu, Ying He, Hamid Talebian, Nader Sohrabi Safa, Nan Zhao,
Muhammad Khurram Khan, and Neeraj Kumar. Fog vehicular computing: Augmenta-
tion of fog computing using vehicular cloud computing. IEEE Vehicular Technology
Magazine, 12(3):55–64, 2017.
[26] Cheng Huang, Rongxing Lu, and Kim-Kwang Raymond Choo. Vehicular fog computing:
architecture, use case, and security and forensic challenges. IEEE Communications
Magazine, 55(11):105–111, 2017.
[27] Jiafu Wan, Daqiang Zhang, Shengjie Zhao, Laurence T Yang, and Jaime Lloret. Context-
aware vehicular cyber-physical systems with cloud support: architecture, challenges,
and solutions. IEEE Communications Magazine, 52(8):106–113, 2014.
[28] A.R. Deepti G.Sasikala. Real time services for future cloud computing enabled vehicle
networks. In IOSR Journal of Computer Engineering (IOSR-JCE), volume 11, pages
8–14, 2013.
[29] Dipal Vashi Priyank Sharma, Sandip Vaniya. Communication as a service based cloud
computing. IEEE International Conference on Emerging Technology Trends (ICETECT),
Nagercoil, India, pages 15–17, 2011.
[30] Quang Hieu Vu, Tran-Vu Pham, Hong-Linh Truong, Schahram Dustdar, and Rasool Asal.
Demods: A description model for data-as-a-service. In 2012 IEEE 26th International
Conference on Advanced Information Networking and Applications, pages 605–612.
IEEE, 2012.
[31] Fekri M Abduljalil. Video capture service in the intelligent transportation system based
on cloud computing. International Journal of Computer Applications, 97(5), 2014.
[32] Rasheed Hussain, Fizza Abbas, Junggab Son, and Heekuck Oh. Tiaas: Secure cloud-
assisted traffic information dissemination in vehicular ad hoc networks. In Cluster, Cloud
and Grid Computing (CCGrid), 2013 13th IEEE/ACM International Symposium on,
pages 178–179. IEEE, 2013.
[33] Mario Gerla, Jui-Ting Weng, and Giovanni Pau. Pics-on-wheels: Photo surveillance
in the vehicular cloud. In Computing, Networking and Communications (ICNC), 2013
International Conference on, pages 1123–1127. IEEE, 2013.
[34] Stefano Ferretti and Gabriele D’Angelo. Smart shires: The revenge of countrysides.
In Computers and Communication (ISCC), 2016 IEEE Symposium on, pages 756–759.
IEEE, 2016.
[35] Rasheed Hussain and Heekuck Oh. Cooperation-aware vanet clouds: Providing secure
cloud services to vehicular ad hoc networks. JIPS, 10(1):103–118, 2014.
[36] Moustafa AbdelBaky, Manish Parashar, Kirk Jordan, Hyunjoo Kim, Hani Jamjoom,
Zon-Yin Shae, Gergina Pencheva, Vipin Sachdeva, James Sexton, Mary Wheeler, et al.
Enabling high-performance computing as a service. Computer, 45(10):72–80, 2012.
144 Bibliography
[37] Steffen Kächele, Christian Spann, Franz J Hauck, and Jörg Domaschka. Beyond iaas
and paas: An extended cloud taxonomy for computation, storage and networking. In
Proceedings of the 2013 IEEE/ACM 6th International Conference on Utility and Cloud
Computing, pages 75–82. IEEE Computer Society, 2013.
[38] Khaleel Mershad and Hassan Artail. Finding a star in a vehicular cloud. IEEE Intelligent
transportation systems magazine, 5(2):55–68, 2013.
[39] Rasheed Hussain, Junggab Son, Hasoo Eun, Sangjin Kim, and Heekuck Oh. Rethinking
vehicular communications: Merging vanet with cloud computing. In Cloud Computing
Technology and Science (CloudCom), 2012 IEEE 4th International Conference on, pages
606–609. IEEE, 2012.
[40] Alexander Stanik, Matthias Hovestadt, and Odej Kao. Hardware as a service (haas):
Physical and virtual hardware on demand. In Cloud Computing Technology and Science
(CloudCom), 2012 IEEE 4th International Conference on, pages 149–154. IEEE, 2012.
[41] Monica Mandal, Chaitrali Landge, Pramila Gaikwad, Uma Nagaraj, and Ashwini Abhale.
Implementing storage as a service in vanet using cloud environment. International
Journal of Advance Foundation and Research in Computer (IJAFRC), 1, 2014.
[42] Mario Gerla, Eun-Kyu Lee, Giovanni Pau, and Uichin Lee. Internet of vehicles: From
intelligent grid to autonomous cars and vehicular clouds. In Internet of Things (WF-IoT),
2014 IEEE World Forum on, pages 241–246. IEEE, 2014.
[43] Peyman Talebifard and Victor CM Leung. Towards a content-centric approach to
crowd-sensing in vehicular clouds. Journal of Systems Architecture, 59(10):976–984,
2013.
[44] Hajar Mousannif, Ismail Khalil, and Hassan Al Moatassime. Cooperation as a service in
vanets. J. UCS, 17(8):1202–1218, 2011.
[45] K Rajbhojsupriya and Pankaj R Ch. Implementation of enhanced security on vehic-
ular cloud computing. International Journal of Computer Science and Information
Technologies (IJCSIT), 5:1315–1318, 2014.
[46] Jithrendra H. N. Jyoti Metan, Narasimha K. N. Murthy. Moving vanet to vehicular
cloud. International Journal of Innovative Research in Computer and Communication
Engineering (IJIRCCE), 2, 2014.
[47] Mehmet Ali Ertürk, Muhammed Ali Aydin, Luca Vollero, and Roberto Setola. Ieee
802.11 s mesh network analysis for post disaster communication. In International
Telecommunications Conference, pages 53–59. Springer, 2019.
[48] Mehdi Sookhak, F Richard Yu, and Helen Tang. Secure data sharing for vehicular ad-hoc
networks using cloud computing. In Ad Hoc Networks, pages 306–315. Springer, 2017.
[49] Md Whaiduzzaman, Mehdi Sookhak, Abdullah Gani, and Rajkumar Buyya. A survey on
vehicular cloud computing. Journal of Network and Computer Applications, 40:325–344,
2014.
Bibliography 145
[50] Stephan Olariu, Tihomir Hristov, and Gongjun Yan. The next paradigm shift: from
vehicular networks to vehicular clouds, 2013.
[51] Benjamin Baron, Miguel Campista, Prométhée Spathis, Luís Henrique MK Costa,
Marcelo Dias de Amorim, Otto Carlos MB Duarte, Guy Pujolle, and Yannis Viniotis.
Virtualizing vehicular node resources: Feasibility study of virtual machine migration.
Vehicular Communications, 4:39–46, 2016.
[52] Tarek K Refaat, Burak Kantarci, and Hussein T Mouftah. Virtual machine migration
and management for vehicular clouds. Vehicular Communications, 4:47–56, 2016.
[53] Salim Bitam, Abdelhamid Mellouk, and Sherali Zeadally. Vanet-cloud: a generic cloud
computing model for vehicular ad hoc networks. IEEE Wireless Communications,
22(1):96–102, 2015.
[54] Neeraj Kumar, Rahat Iqbal, Sudip Misra, and Joel JPC Rodrigues. Bayesian coalition
game for contention-aware reliable data forwarding in vehicular mobile cloud. Future
Generation Computer Systems, 48:60–72, 2015.
[55] Yen-Wen Lin, Jie-Min Shen, and Hao-Chun Weng. Gateway discovery in vanet cloud.
In High Performance Computing and Communications (HPCC), 2011 IEEE 13th Inter-
national Conference on, pages 951–954. IEEE, 2011.
[56] Yen-Wen Lin, Jie-Min Shen, and Hao-Jun Weng. Cloud-assisted gateway discovery for
vehicular ad hoc networks. In Information Science and Service Science (NISS), 2011 5th
International Conference on New Trends in, volume 2, pages 237–240. IEEE, 2011.
[57] Rasheed Hussain, Zeinab Rezaeifar, Yong-Hwan Lee, and Heekuck Oh. Secure and
privacy-aware traffic information as a service in vanet-based clouds. Pervasive and
Mobile Computing, 24:194–209, 2015.
[58] Priya. V. Cloud service for best gateway in vanet. International Journal of Advanced
Research in Computer Science and Software Engineering, 4, 2014.
[59] Ms Madhuri H Badole and Mr Pritam Nikam. Performance evaluation of an efficient
cloud-assisted gateway discovery for vehicular ad hoc network. Performance Evaluation,
1(7), 2014.
[60] C Shravanthi and HS Guruprasad. Vanet using cloud [vuc]. 2:1–7, 2014.
[61] China Mobile. C-ran: the road towards green ran. White Paper, ver, 2, 2011.
[62] Diego Kreutz, Fernando MV Ramos, Paulo Esteves Verissimo, Christian Esteve Rothen-
berg, Siamak Azodolmolky, and Steve Uhlig. Software-defined networking: A compre-
hensive survey. Proceedings of the IEEE, 103(1):14–76, 2015.
[63] Ievgen Volvach and Larysa Globa. Mobile networks disaster recovery using sdn-nfv. In
Radio Electronics & Info Communications (UkrMiCo), 2016 International Conference,
pages 1–3. IEEE, 2016.
[64] Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De Turck, and
Raouf Boutaba. Network function virtualization: State-of-the-art and research challenges.
IEEE Communications Surveys & Tutorials, 18(1):236–262, 2015.
146 Bibliography
[65] Sherif Abdelwahab, Bechir Hamdaoui, Mohsen Guizani, and Taieb Znati. Network
function virtualization in 5g. IEEE Communications Magazine, 54(4):84–91, 2016.
[66] Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, and Dimitrios D Vergados.
A network selection scheme with adaptive criteria weights for 5g vehicular systems.
In Information, Intelligence, Systems & Applications (IISA), 2018 9th International
Conference on. IEEE, 2018.
[67] Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, and Dimitrios D Vergados. A
vertical handover management scheme for vanet cloud computing systems. In Computers
and Communications (ISCC), 2017 IEEE Symposium on, pages 371–376. IEEE, 2017.
[68] Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, and Dimitrios D Vergados. A
vho scheme for supporting healthcare services in 5g vehicular cloud computing systems.
In Wireless Telecommunications Symposium (WTS), 2018, pages 1–6. IEEE, 2018.
[69] Mohammad A Salahuddin, Ala Al-Fuqaha, Mohsen Guizani, and Soumaya Cherkaoui.
Rsu cloud and its resource management in support of enhanced vehicular applications.
In 2014 IEEE Globecom Workshops (GC Wkshps), pages 127–132. IEEE, 2014.
[70] Mohammad Ali Salahuddin. Opportunistic service differentiation and cloud resource
management in support of enhanced vehicular applications. Thesis at Western Michigan
University, 2014.
[71] Md Faizul Bari, Arup Raton Roy, Shihabur Rahman Chowdhury, Qi Zhang, Mo-
hamed Faten Zhani, Reaz Ahmed, and Raouf Boutaba. Dynamic controller provisioning
in software defined networks. In Proceedings of the 9th International Conference on
Network and Service Management (CNSM 2013), pages 18–25. IEEE, 2013.
[72] Nguyen B Truong, Gyu Myoung Lee, and Yacine Ghamri-Doudane. Software defined
networking-based vehicular adhoc network with fog computing. In 2015 IFIP/IEEE
International Symposium on Integrated Network Management (IM), pages 1202–1207.
IEEE, 2015.
[73] Nicola Cordeschi, Danilo Amendola, Mohammad Shojafar, and Enzo Baccarelli. Dis-
tributed and adaptive resource management in cloud-assisted cognitive radio vehicular
networks with hard reliability guarantees. Vehicular Communications, 2(1):1–12, 2015.
[74] Joy Eze, Sijing Zhang, Enjie Liu, and Elias Eze. Cognitive radio-enabled internet of
vehicles: a cooperative spectrum sensing and allocation for vehicular communication.
IET Networks, 2018.
[75] Rong Yu, Yan Zhang, Stein Gjessing, Wenlong Xia, and Kun Yang. Toward cloud-based
vehicular networks with efficient resource management. IEEE Network, 27(5):48–55,
2013.
[76] Md Ali Al Mamun, Khairul Anam, Md Fakhrul Alam Onik, and AM Esfar-E-Alam.
Deployment of cloud computing into vanet to create ad hoc cloud network architecture.
In Proceedings of the World Congress on Engineering and Computer Science, volume 1,
pages 24–26, 2012.
Bibliography 147
[77] Carl Bergenhem, Erik Coelingh, Rolf Johansson, and Ali Tehrani. V2v communica-
tion quality: measurements in a cooperative automotive platooning application. SAE
International Journal of Passenger Cars-Electronic and Electrical Systems, 7(2014-01-
0302):462–470, 2014.
[78] Mohammed Abdulhakim Al-Absi, Ahmed Abdulhakim Al-Absi, Young-Jin Kang, and
Hoon Jae Lee. Obstacles effects on signal attenuation in line of sight for different envi-
ronments in v2v communication. In 2018 20th International Conference on Advanced
Communication Technology (ICACT), pages 17–20. IEEE, 2018.
[79] Juinn-Horng Deng, Su-Hua Chen, Chia-Fang Lee, Chorng-Ren Sheu, Hua-Lung Tsai,
Shubhranshu Singh, and Jen-Shun Yang. Joint time-frequency dmrs design for high
mobility lte-a v2v communication systems. In Microwaves, Antennas, Communications
and Electronic Systems (COMCAS), 2017 IEEE International Conference on, pages 1–6.
IEEE, 2017.
[80] Hazem M Fahmy, Gerd Baumann, Mohamed A Abd El Ghany, and Hassan Mostafa.
V2v-based vehicle risk assessment and control for lane-keeping and collision avoidance.
In Microelectronics (ICM), 2017 29th International Conference on, pages 1–5. IEEE,
2017.
[81] Wanlu Sun, Erik G Ström, Fredrik Brännström, Yutao Sui, and Kin Cheong Sou. D2d-
based v2v communications with latency and reliability constraints. In 2014 IEEE
Globecom Workshops (GC Wkshps), pages 1414–1419. IEEE, 2014.
[82] Hao Ye and Geoffrey Ye Li. Deep reinforcement learning for resource allocation in v2v
communications. In 2018 IEEE International Conference on Communications (ICC),
pages 1–6. IEEE, 2018.
[83] Yanbing Liu, Yuhang Wang, and Guanghui Chang. Efficient privacy-preserving dual
authentication and key agreement scheme for secure v2v communications in an iov
paradigm. IEEE Transactions on Intelligent Transportation Systems, 18(10):2740–2749,
2017.
[84] Arindam Ghosh, Vishnu Vardhan Paranthaman, Glenford Mapp, Orhan Gemikonakli,
and Jonathan Loo. Enabling seamless v2i communications: toward developing coop-
erative automotive applications in vanet systems. IEEE Communications Magazine,
53(12):80–86, 2015.
[85] Yuanguo Bi, Haibo Zhou, Weihua Zhuang, and Hai Zhao. Safety message dissemination
in v2i communication networks. In Safety Message Broadcast in Vehicular Networks,
pages 83–101. Springer, 2017.
[86] Xiao-Feng Xie and Zun-Jing Wang. Siv-dss: Smart in-vehicle decision support system
for driving at signalized intersections with v2i communication. Transportation Research
Part C: Emerging Technologies, 90:181–197, 2018.
[87] Michał Hoeft and Jacek Rak. How to provide fair service for v2i communications in
vanets? Ad Hoc Networks, 37:283–294, 2016.
148 Bibliography
[88] Gerard Aguilar Ubiergo and Wen-Long Jin. Mobility and environment improvement
of signalized networks through vehicle-to-infrastructure (v2i) communications. Trans-
portation Research Part C: Emerging Technologies, 68:70–82, 2016.
[89] Ribal Atallah, Maurice Khabbaz, and Chadi Assi. Multihop v2i communications: A
feasibility study, modeling, and performance analysis. IEEE Transactions on Vehicular
Technology, 66(3):2801–2810, 2017.
[90] Otilia Popescu, Sarwar Sha-Mohammad, Hussein Abdel-Wahab, Dimitrie C Popescu,
and Samy El-Tawab. Automatic incident detection in intelligent transportation systems
using aggregation of traffic parameters collected through v2i communications. IEEE
Intelligent Transportation Systems Magazine, 9(2):64–75, 2017.
[91] I Rashdan, F de Ponte Muller, Wei Wang, M Schmidhammer, and S Sand. Vehicle-to-
pedestrian channel characterization: Wideband measurement campaign and first results.
2018.
[92] Pooya Rahimian, Elizabeth E O’Neal, Shiwen Zhou, Junghum Paul Yon, Luke Franzen,
Jodie M Plumert, and Joseph K Kearney. Vehicle-to-pedestrian (v2p) communications
technology: Do cell phone warnings improve road-crossing safety for texting pedes-
trians? AND30 Standing Committee on Simulation and Measurement of Vehicle and
Operator Performance, 2018.
[93] José Javier Anaya, Pierre Merdrignac, Oyunchimeg Shagdar, Fawzi Nashashibi, and
José E Naranjo. Vehicle to pedestrian communications for protection of vulnerable road
users. In Intelligent Vehicles Symposium Proceedings, 2014 IEEE, pages 1037–1042.
IEEE, 2014.
[94] Pooya Rahimian, Elizabeth E O’Neal, Shiwen Zhou, Jodie M Plumert, and Joseph K
Kearney. Harnessing vehicle-to-pedestrian (v2p) communication technology: Sending
traffic warnings to texting pedestrians. Human Factors, 2018.
[95] Pierre Merdrignac, Oyunchimeg Shagdar, and Fawzi Nashashibi. Fusion of percep-
tion and v2p communication systems for the safety of vulnerable road users. IEEE
Transactions on Intelligent Transportation Systems, 18(7):1740–1751, 2017.
[96] Ahmed Hussein, Fernando García, José María Armingol, and Cristina Olaverri-Monreal.
P2v and v2p communication for pedestrian warning on the basis of autonomous vehicles.
In Intelligent Transportation Systems (ITSC), 2016 IEEE 19th International Conference
on, pages 2034–2039. IEEE, 2016.
[97] Mehrdad Bagheri, Matti Siekkinen, and Jukka K Nurminen. Cellular-based vehicle to
pedestrian (v2p) adaptive communication for collision avoidance. In Connected Vehicles
and Expo (ICCVE), 2014 International Conference on, pages 450–456. IEEE, 2014.
[98] Kai Liu, Joseph KY Ng, Victor CS Lee, Sang H Son, and Ivan Stojmenovic. Cooperative
data scheduling in hybrid vehicular ad hoc networks: Vanet as a software defined network.
2015.
[99] Yuanzhi Ni, Jianping He, Lin Cai, and Yuming Bo. Data uploading in hybrid v2v/v2i
vehicular networks: Modeling and cooperative strategy. IEEE Transactions on Vehicular
Technology, 67(5):4602–4614, 2018.
Bibliography 149
[100] Norbert Bissmeyer, Jan-Felix van Dam, Christian Zimmermann, and Kurt Eckert. Secu-
rity in hybrid vehicular communication based on its-g5, lte-v, and mobile edge computing.
In AmE 2018-Automotive meets Electronics; 9th GMM-Symposium, pages 1–6. VDE,
2018.
[101] Susumu Ishihara, Vince Rabsatt, and Mario Gerla. Secure autonomous platooning with
hybrid vehicular communication. ACM HotMobile, 2015.
[102] Kai Liu, Joseph KY Ng, Victor Lee, Sang H Son, and Ivan Stojmenovic. Cooperative
data scheduling in hybrid vehicular ad hoc networks: Vanet as a software defined network.
IEEE/ACM Transactions on Networking (TON), 24(3):1759–1773, 2016.
[103] Nils Dreyer, Andreas Moller, Zeeshan Hameed Mir, Fethi Filali, and Thomas Kurner.
A data traffic steering algorithm for ieee 802.11 p/lte hybrid vehicular networks. In
Vehicular Technology Conference (VTC-Fall), 2016 IEEE 84th, pages 1–6. IEEE, 2016.
[104] Nils Dreyer, Andreas Moeller, Johannes Baumgarten, Zeeshan Hameed Mir, Thomas
Kuerner, and Fethi Filali. On building realistic reference scenarios for ieee 802.11
p/lte-based vehicular network evaluations. In 2018 IEEE 87th Vehicular Technology
Conference (VTC Spring), pages 1–7. IEEE, 2018.
[105] Wei-dong YANG, LI Pan, Hong-song ZHU, et al. Adaptive tdma slot assignment
protocol for vehicular ad-hoc networks. The Journal of China Universities of Posts and
Telecommunications, 20(1):11–25, 2013.
[106] Tsang-Ling Sheu and Yu-Hung Lin. A cluster-based tdma system for inter-vehicle
communications. J. Inf. Sci. Eng., 30(1):213–231, 2014.
[107] Kazi Atiqur Rahman and Kemal E Tepe. Towards a cross-layer based mac for smooth
v2v and v2i communications for safety applications in dsrc/wave based systems. In 2014
IEEE Intelligent Vehicles Symposium Proceedings, pages 969–973. IEEE, 2014.
[108] Rui Zou, Zishan Liu, Lin Zhang, and Muhammad Kamil. A near collision free reservation
based mac protocol for vanets. In 2014 IEEE Wireless Communications and Networking
Conference (WCNC), pages 1538–1543. IEEE, 2014.
[109] Hassan Aboubakr Omar, Weihua Zhuang, and Li Li. Vemac: A tdma-based mac
protocol for reliable broadcast in vanets. IEEE Transactions on Mobile Computing,
12(9):1724–1736, 2013.
[110] VanDung Nguyen, Duc Ngoc Minh Dang, Sungman Jang, and Choong Seon Hong. e-
vemac: an enhanced vehicular mac protocol to mitigate the exposed terminal problem. In
Network Operations and Management Symposium (APNOMS), 2014 16th Asia-Pacific,
pages 1–4. IEEE, 2014.
[111] Nurullah Shahin and Young-Tak Kim. An enhanced tdma cluster-based mac (etcm) for
multichannel vehicular networks. In Selected Topics in Mobile & Wireless Networking
(MoWNeT), 2016 International Conference on, pages 1–8. IEEE, 2016.
[112] Xiaoxiao Jiang and David Du. Ptmac: A prediction-based tdma mac protocol for
reducing packet collisions in vanet. 2015.
150 Bibliography
[113] Rongqing Zhang, Xiang Cheng, Liuqing Yang, Xia Shen, and Bingli Jiao. A novel
centralized tdma-based scheduling protocol for vehicular networks. IEEE Transactions
on Intelligent Transportation Systems, 16(1):411–416, 2015.
[114] Sailesh Bharati and Weihua Zhuang. Cah-mac: Cooperative adhoc mac for vehicular
networks. IEEE Journal on Selected Areas in Communications, 31(9):470–479, 2013.
[115] Lili Zheng, Yi Wu, Zhexin Xu, and Xiao Lin. A novel mac protocol for vanet based
on improved generalized prime sequence. In Advanced Infocomm Technology (ICAIT),
2014 IEEE 7th International Conference on, pages 1–7. IEEE, 2014.
[116] Hang Yu, Zhiqiang He, and Kai Niu. Stdma for vehicle-to-vehicle communication in
a highway scenario. In Microwave, Antenna, Propagation and EMC Technologies for
Wireless Communications (MAPE), 2013 IEEE 5th International Symposium on, pages
133–138. IEEE, 2013.
[117] Mohammad S Almalag, Stephan Olariu, and Michele C Weigle. Tdma cluster-based mac
for vanets (tc-mac). In World of Wireless, Mobile and Multimedia Networks (WoWMoM),
2012 IEEE International Symposium on a, pages 1–6. IEEE, 2012.
[118] Shanqiang Yi, Wuwen Lai, Di Tang, and Hua Wang. A context-aware mac protocol
in vanet based on bayesian networks. In Communications and Networking in China
(CHINACOM), 2014 9th International Conference on, pages 191–196. IEEE, 2014.
[119] Xin Zhou, Changwen Zheng, Xiaoxin He, et al. Adaptive contention window tuning
for ieee 802.11. In 22nd International Conference on Telecommunications: ICT 2015,
page 74. Engineers Australia, 2015.
[120] Peppino Fazio, Floriano De Rango, and Cesare Sottile. A predictive cross-layered
interference management in a multichannel mac with reactive routing in vanet. 2015.
[121] Hikmat El Ajaltouni, Richard W Pazzi, and Azzedine Boukerche. An efficient qos
mac for ieee 802.11p over cognitive multichannel vehicular networks. In 2012 IEEE
International Conference on Communications (ICC), pages 413–417. IEEE, 2012.
[122] Celimuge Wu, Satoshi Ohzahata, Yusheng Ji, and Toshihiko Kato. A mac protocol for
delay-sensitive vanet applications with self-learning contention scheme. In 2014 IEEE
11th Consumer Communications and Networking Conference (CCNC), pages 438–443.
IEEE, 2014.
[123] Weijie Guo, Liusheng Huang, Long Chen, Hongli Xu, and Jietao Xie. An adaptive
collision-free mac protocol based on tdma for inter-vehicular communication. In Wireless
Communications & Signal Processing (WCSP), 2012 International Conference on, pages
1–6. IEEE, 2012.
[124] Rongqing Zhang, Jinsung Lee, Xia Shen, Xiang Cheng, Liuqing Yang, and Bingli Jiao. A
unified tdma-based scheduling protocol for vehicle-to-infrastructure communications. In
Wireless Communications & Signal Processing (WCSP), 2013 International Conference
on, pages 1–6. IEEE, 2013.
Bibliography 151
[125] Duc Ngoc Minh Dang, Hanh Ngoc Dang, Vandung Nguyen, Zaw Htike, and
Choong Seon Hong. Her-mac: A hybrid efficient and reliable mac for vehicular ad
hoc networks. In 2014 IEEE 28th International Conference on Advanced Information
Networking and Applications, pages 186–193. IEEE, 2014.
[126] Weijie Guo, Liusheng Huang, Long Chen, Hongli Xu, and Chenglin Miao. R-mac:
Risk-aware dynamic mac protocol for vehicular cooperative collision avoidance system.
International Journal of Distributed Sensor Networks, 2013, 2013.
[127] Lin Zhang, Zishan Liu, Rui Zou, Jinjie Guo, and Yu Liu. A scalable csma and self-
organizing tdma mac for ieee 802.11 p/1609. x in vanets. Wireless Personal Communi-
cations, 74(4):1197–1212, 2014.
[128] Alessandro Bazzi, Alberto Zanella, and Barbara Maví Masini. An ofdma-based mac
protocol for next-generation vanets. IEEE Transactions on Vehicular Technology,
64(9):4088–4100, 2015.
[129] Baozhu Li, Xuhui Zhao, Shiyuan Han, and Zhenxiang Chen. New sdn-based architecture
for integrated vehicular cloud computing networking. In 2018 International Conference
on Selected Topics in Mobile and Wireless Networking (MoWNeT), pages 1–4. IEEE,
2018.
[130] Redowan Mahmud, Ramamohanarao Kotagiri, and Rajkumar Buyya. Fog computing:
A taxonomy, survey and future directions. In Internet of everything, pages 103–130.
Springer, 2018.
[131] Behnam Khodapanah, Ahmad Awada, Ingo Viering, David Oehmann, Meryem Sim-
sek, and Gerhard P Fettweis. Fulfillment of service level agreements via slice-aware
radio resource management in 5g networks. In 2018 IEEE 87th Vehicular Technology
Conference (VTC Spring), pages 1–6. IEEE, 2018.
[132] Dizhi Zhou, Nicola Baldo, and Marco Miozzo. Implementation and Validation of LTE
Downlink Schedulers for ns-3. In Simulation Tools and Techniques (SimuTools ’13), 6th
International ICST Conference on, pages 211–218, 2013.
[133] F. Capozzi, G. Piro, L. A. Grieco, G. Boggia, and P. Camarda. Downlink packet
scheduling in LTE cellular networks: Key design issues and a survey. Communications
Surveys and Tutorials, IEEE, 99, 2012.
[134] Akhilesh Pokhariyal, Klaus I Pedersen, Guillaume Monghal, Istvan Z Kovacs, Claudio
Rosa, Troels E Kolding, and Preben E Mogensen. HARQ aware frequency domain packet
scheduler with different degrees of fairness for the UTRAN long term evolution. In
Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th, pages 2761–2765.
IEEE, 2007.
[135] Dizhi Zhou, Wei Song, Nicola Baldo, and Marco Miozzo. Evaluation of TCP perfor-
mance with LTE downlink schedulers in a vehicular environment. In Wireless Communi-
cations and Mobile Computing Conference (IWCMC), 2013 9th International, pages
1064–1069. IEEE, 2013.
152 Bibliography
[136] Huda Adibah Mohd Ramli, Kumbesan Sandrasegaran, Riyaj Basukala, Rachod Patacha-
ianand, and Toyoba Sohana Afrin. Video Streaming Performance Under Well-Known
Packet Scheduling Algorithms. International Journal of Wireless & Mobile Networks
(IJWMN)l, 3:25–38, 2011.
[137] Yasir Zaki, Thushara Weerawardane, Carmelita Gorg, and Andreas Timm-Giel. Multi-
QoS-aware fair scheduling for LTE. In Vehicular technology conference (VTC spring),
2011 IEEE 73rd, pages 1–5. IEEE, 2011.
[138] Li Chen, Bin Wang, Xiaohang Chen, Xin Zhang, and Dacheng Yang. Utility-based
resource allocation for mixed traffic in wireless networks. In Computer Communications
Workshops (INFOCOM WKSHPS), 2011 IEEE Conference on, pages 91–96. IEEE, 2011.
[139] M Andrews, K. Kumaran, K. Ramanan, A. Stolyar, P. Whiting, and R. Vijayakumar.
Providing quality of service over a shared wireless link. Communications Magazine,
IEEE, 39(2):150–154, 2001.
[140] K. Sandrasegaran R. Basukala, H. Mohd Ramli. Performance analysis of EXP/PF
and M-LWDF in downlink 3GPP LTE system. In AH-ICI 2009. 1st Asian Himalayas
International Conference on Internet, pages 1–5. IEEE, 2009.
[141] Bilal Sadiq, Ritesh Madan, and Ashwin Sampath. Downlink scheduling for multi-
class traffic in LTE. EURASIP Journal on Wireless Communications and Networking,
2009(14), 2009.
[142] Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, Rossella Fortuna, and Pietro
Camarda. Two-level downlink scheduling for real-time multimedia services in LTE
networks. Multimedia, IEEE Transactions on, 13(5):1052–1065, 2011.
[143] Huda Adibah Mohd Ramli, Riyaj Basukala, Kumbesan Sandrasegaran, and Rachod
Patachaianand. Performance of well known packet scheduling algorithms in the downlink
3GPP LTE system. In Communications (MICC), 2009 IEEE 9th Malaysia International
Conference on, pages 815–820. IEEE, 2009.
[144] Sadiq Bilal, Madan Ritesh, and Sampath Ashwin. Downlink scheduling for multiclass
traffic in LTE. EURASIP Journal on Wireless Communications and Networking, 2009,
2009.
[145] Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, Francesco Capozzi, and Pietro
Camarda. Simulating LTE cellular systems: An open-source framework. Vehicular
Technology, IEEE Transactions on, 60(2):498–513, 2011.
[146] TS 36.322 (V8.8.0): Evolved Universal Terrestrial Radio Access (E-UTRA), Radio Link
Control (RLC) protocol specification(Release 8). Technical Specification, 3GPP, 2010.
[147] Mohamed Hadi Habaebi Mohammed Abdul Jawad M. Al-Shibly and Md. Rafiqul Islam.
Radio resource scheduling in LTE-Advanced system with Carrier Aggregation. ARPN
Journal of Engineering and Applied Sciences, 10(22):17281–17285, 2015.
Bibliography 153
[148] Sangchul Oh, JeeHyeon Na, and Dongseung Kwon. Performance Analysis of Cross
Component Carrier Scheduling in LTE Small Cell Access Point System. In The Second
International Conference on Electrical, Electronics, Computer Engineering and their
Applications (EECEA2015), page 146, 2015.
[149] Alberto Núñez, Jose L Vázquez-Poletti, Agustin C Caminero, Gabriel G Castañé,
Jesus Carretero, and Ignacio M Llorente. iCanCloud: A flexible and scalable cloud
infrastructure simulator. Journal of Grid Computing, 10(1):185–209, 2012.
[150] Dominik Klein and Michael Jarschel. An OpenFlow extension for the OMNeT++ INET
framework. In Proceedings of the 6th International ICST Conference on Simulation
Tools and Techniques, pages 322–329. ICST (Institute for Computer Sciences, Social-
Informatics and Telecommunications Engineering), 2013.
[151] András Varga and Rudolf Hornig. An overview of the OMNeT++ simulation envi-
ronment. In Proceedings of the 1st international conference on Simulation tools and
techniques for communications, networks and systems & workshops, page 60. ICST (In-
stitute for Computer Sciences, Social-Informatics and Telecommunications Engineering),
2008.
[152] TR 36.814 (V9.0.0): Further advancements for E-UTRA physical layer aspects (Release
9). Technical Specification Group Radio Access Network, 3GPP, 2010.
[153] TR 36.942 (V10.2.0): Radio Frequency (RF) system scenarios (Release 10). Technical
Specification, 3GPP, 2011.
[154] Lotfi Asker Zadeh. Fuzzy sets. Information and control, 8(3):338–353, 1965.
[155] Roland Sambuc. Fonctions and floues: application a l’aide au diagnostic en pathologie
thyroidienne. Faculté de Médecine de Marseille, 1975.
[156] Peide Liu and Fang Jin. A multi-attribute group decision-making method based on
weighted geometric aggregation operators of interval-valued trapezoidal fuzzy numbers.
Applied Mathematical Modelling, 36(6):2498–2509, 2012.
[157] Chris Cornelis, Glad Deschrijver, and EE Kerre. Advances and challenges in interval-
valued fuzzy logic. Fuzzy sets and systems, 157(5):622–627, 2006.
[158] Behzad Ashtiani, Farzad Haghighirad, Ahmad Makui, et al. Extension of fuzzy topsis
method based on interval-valued fuzzy sets. Applied Soft Computing, 9(2):457–461,
2009.
[159] Shih-Hua Wei and Shyi-Ming Chen. Fuzzy risk analysis based on interval-valued fuzzy
numbers. Expert Systems with Applications, 36(2):2285–2299, 2009.
[160] Apurba Panda and Madhumangal Pal. A study on pentagonal fuzzy number and its
corresponding matrices. Pacific Science Review B: Humanities and Social Sciences,
Elsevier, 1(3):131–139, 2015.
[161] Mu-Song Chen and Shinn-Wen Wang. Fuzzy clustering analysis for optimizing fuzzy
membership functions. Fuzzy sets and systems, Elsevier, 103(2):239–254, 1999.
154 Bibliography
[162] Marcos E Cintra, Heloisa A Camargo, and Maria Carolina Monard. Genetic generation of
fuzzy systems with rule extraction using formal concept analysis. Information Sciences,
Elsevier, 349:199–215, 2016.
[163] Jin-Shyan Lee and Chih-Lin Teng. An enhanced hierarchical clustering approach for
mobile sensor networks using fuzzy inference systems. IEEE Internet of Things Journal,
4(4):1095–1103, 2017.
[164] Javier Andreu-Perez, Fan Cao, Hani Hagras, and Guang-Zhong Yang. A self-adaptive
online brain machine interface of a humanoid robot through a general type-2 fuzzy
inference system. IEEE Transactions on Fuzzy Systems, 2016.
[165] Chengdong Li, Junlong Gao, Jianqiang Yi, and Guiqing Zhang. Analysis and design
of functionally weighted single-input-rule-modules connected fuzzy inference systems.
IEEE Transactions on Fuzzy Systems, 2016.
[166] Thomas L Saaty. Decision making with dependence and feedback: The analytic network
process. 1996.
[167] ˙Ihsan Yüksel and Metin Dagdeviren. Using the analytic network process (anp) in a swot
analysis–a case study for a textile firm. Information Sciences, 177(16):3364–3382, 2007.
[168] Thomas L Saaty and Luis G Vargas. Diagnosis with dependent symptoms: Bayes
theorem and the analytic hierarchy process. Operations Research, 46(4):491–502, 1998.
[169] Tong Wu, Xin-Wang Liu, and Shu-Li Liu. A fuzzy anp with interval type-2 fuzzy
sets approach to evaluate enterprise technological innovation ability. In Fuzzy Systems
(FUZZ-IEEE), 2015 IEEE International Conference on, pages 1–8. IEEE, 2015.
[170] Ching-Lai Hwang and Kwangsun Yoon. Multiple attribute decision making. Springer,
1981.
[171] Emmanouil Skondras, Aggeliki Sgora, Angelos Michalas, and Dimitrios D Vergados.
An analytic network process and trapezoidal interval-valued fuzzy technique for order
preference by similarity to ideal solution network access selection method. International
Journal of Communication Systems, 29(2):307–329, 2016.
[172] Dimitris E Charilas, Ourania I Markaki, John Psarras, and Philip Constantinou. Appli-
cation of fuzzy ahp and electre to network selection. In Mobile Lightweight Wireless
Systems, pages 63–73. Springer, 2009.
[173] Thereza Raquel Machado Azeredo, Helisamara Mota Guedes, Ricardo Alexandre Rebelo
de Almeida, Tânia Couto Machado Chianca, and José Carlos Amado Martins. Efficacy
of the manchester triage system: a systematic review. International emergency nursing,
Elsevier, 23(2):47–52, 2015.
[174] Hoe Tung Yew, Eko Supriyanto, Muhammad H Satria, and YW Hau. Adaptive network
selection mechanism for telecardiology system in developing countries. In Biomedical
and Health Informatics (BHI), 2016 IEEE-EMBS International Conference on, pages
94–97. IEEE, 2016.
Bibliography 155
[175] Driss Aboutajdine Maroua Drissi, Mohammed Oumsis. A fuzzy ahp approach to network
selection improvement in heterogeneous wireless networks. Networked Systems, pages
169–182.
[176] Open street map (osm). https://www.openstreetmap.org, 2018. Accessed: 2018.
[177] Michael Behrisch, Laura Bieker, Jakob Erdmann, and Daniel Krajzewicz. Sumo–
simulation of urban mobility: an overview. In Proceedings of SIMUL 2011, The Third
International Conference on Advances in System Simulation. ThinkMind, 2011.
[178] Network simulator 3 (ns3). https://www.nsnam.org/, 2018. Accessed: 2018.
[179] E Roszkowska and D Kacprzak. The fuzzy saw and fuzzy topsis procedures based on
ordered fuzzy numbers. Information Sciences, 369:564–584, 2016.
[180] Zhe Ren, Peter Fertl, Qi Liao, Federico Penna, and Slawomir Stanczak. Street-specific
handover optimization for vehicular terminals in future cellular networks. In Vehicular
Technology Conference (VTC Spring), 2013 IEEE 77th, pages 1–5. IEEE, 2013.
[181] David González, Mario García-Lozano, Silvia Ruiz, and Dong Seop Lee. A
metaheuristic-based downlink power allocation for lte/lte-a cellular deployments. Wire-
less Networks, 20(6):1369–1386, 2014.
[182] Soumaya Cherkaoui, Tarik Taleb, and Eugene David Ngangue Ndih. Improved inter-
network handover for highly mobile users and vehicular networks. In Vehicular Technol-
ogy Conference (VTC Spring), 2011 IEEE 73rd, pages 1–5. IEEE, 2011.
[183] Suganthi Evangeline and Vinoth Babu Kumaravelu. Decision process for vertical
handover in vehicular adhoc networks. In Microelectronic Devices, Circuits and Systems
(ICMDCS), 2017 International conference on, pages 1–5. IEEE, 2017.
[184] Francesco Guidolin, Irene Pappalardo, Andrea Zanella, and Michele Zorzi. Context-
aware handover policies in hetnets. IEEE Transactions on Wireless Communications,
15(3):1895–1906, 2016.
[185] Abhijit Sarma, Sandip Chakraborty, and Sukumar Nandi. Deciding handover points
based on context-aware load balancing in a wifi-wimax heterogeneous network environ-
ment. IEEE Transactions on Vehicular Technology, 65(1):348–357, 2016.
[186] Shipra Kapoor, David Grace, and Tim Clarke. A base station selection scheme for
handover in a mobility-aware ultra-dense small cell urban vehicular environment. In
Personal, Indoor, and Mobile Radio Communications (PIMRC), 2017 IEEE 28th Annual
International Symposium on, pages 1–5. IEEE, 2017.
[187] Ali Safa Sadiq, Kamalrulnizam Abu Bakar, Kayhan Zrar Ghafoor, Jaime Lloret, and
Rashid Khokhar. An intelligent vertical handover scheme for audio and video streaming
in heterogeneous vehicular networks. Mobile Networks and Applications, 18(6):879–895,
2013.
[188] Mohamed Lahby, Cherkaoui Leghris, and Abdellah Adib. New multi access selection
method based on mahalanobis distance. Applied Mathematical Sciences, 6(53-56):2745–
2760, 2012.
156 Bibliography
[189] Vishal Gupta. Network selection in 3g-wlan interworking environment using topsis.
In Industrial and Information Systems (ICIIS), 2016 11th International Conference on,
pages 512–517. IEEE, 2016.
[190] Werner Toth and Harald Vacik. A comprehensive uncertainty analysis of the analytic
hierarchy process methodology applied in the context of environmental decision making.
Journal of Multi-Criteria Decision Analysis, 2018.
[191] Mohamed Lahby, Cherkaoui Leghris, and Abdellah Adib. New multi access selection
method using differentiated weight of access interface. In Communications and Infor-
mation Technology (ICCIT), 2012 International Conference on, pages 237–242. IEEE,
2012.
[192] KSS Anupama, S Sri Gowri, and B Prabakara Rao. Application of grey relational
analysis to network selection: A case study. 2017.
[193] Abudukeremu Kadier, Peyman Abdeshahian, Yibadatihan Simayi, Manal Ismail,
Aidil Abdul Hamid, and Mohd Sahaid Kalil. Grey relational analysis for compara-
tive assessment of different cathode materials in microbial electrolysis cells. Energy,
90:1556–1562, 2015.
[194] Wei-Yu Chiu, Gary G Yen, and Teng-Kuei Juan. Minimum manhattan distance approach
to multiple criteria decision making in multiobjective optimization problems. IEEE
Transactions on Evolutionary Computation, 20(6):972–985, 2016.
[195] Novi Sofia Fitriasari, Syifa Afifah Fitriani, and Rosa Ariani Sukamto. Comparison
of weighted product method and technique for order preference by similarity to ideal
solution method: Complexity and accuracy. In Science in Information Technology
(ICSITech), 2017 3rd International Conference on, pages 453–458. IEEE, 2017.
[196] Xingwei Wang, Dapeng Qu, Keqin Li, Hui Cheng, Sajal K Das, Min Huang, Renzheng
Wang, and Shuliu Chen. A flexible and generalized framework for access network
selection in heterogeneous wireless networks. Pervasive and Mobile Computing, 40:556–
576, 2017.
[197] Lei Sun, Hui Tian, and Ping Zhang. Decision-making models for group vertical handover
in vehicular communications. Telecommunication Systems, 50(4):257–266, 2012.
[198] B Farhadinia. Sensitivity analysis in interval-valued trapezoidal fuzzy number linear
programming problems. Applied Mathematical Modelling, 38(1):50–62, 2014.
[199] Huiqiang Wang, Zhendong Wang, Guangsheng Feng, Hongwu LV, Xiaoming Chen, and
Qiang Zhu. Intelligent access selection in cognitive networks: A fuzzy neural network
approach. Journal of Computational Information Systems, 8(21):8877–8884, 2012.
[200] Mun-Suk Kim and SuKyoung Lee. Group-based fast handover for pmipv6-based network
mobility in vehicular networks. In Computer Communications Workshops (INFOCOM
WKSHPS), 2015 IEEE Conference on, pages 113–114. IEEE, 2015.
Bibliography 157
[201] Jonathan Prados-Garzon, Juan J Ramos-Munoz, Pablo Ameigeiras, Pilar Andres-
Maldonado, and Juan M Lopez-Soler. Modeling and dimensioning of a virtualized
mme for 5g mobile networks. IEEE Transactions on Vehicular Technology, 66(5):4383–
4395, 2017.
[202] Mun-Suk Kim, SuKyoung Lee, and Nada Golmie. Enhanced fast handover for proxy
mobile ipv6 in vehicular networks. Wireless Networks, 18(4):401–411, 2012.
[203] Mun-Suk Kim, Sukyoung Lee, David Cypher, and Nada Golmie. Performance analysis
of fast handover for proxy mobile ipv6. Information Sciences, 219:208–224, 2013.
[204] Emna Bouzid Smida, Sonia Gaied Fantar, and Habib Youssef. Predictive handoff
mechanism for video streaming in a cloud-based urban vanet. In Computer Systems
and Applications (AICCSA), 2017 IEEE/ACS 14th International Conference on, pages
1170–1177. IEEE, 2017.
[205] Massimo Dalla Cia, Federico Mason, Davide Peron, Federico Chiariotti, Michele Polese,
Toktam Mahmoodi, Michele Zorzi, and Andrea Zanella. Mobility-aware handover strate-
gies in smart cities. In Wireless Communication Systems (ISWCS), 2017 International
Symposium on, pages 438–443. IEEE, 2017.
[206] Ammar Gharaibeh, Mohammad A Salahuddin, Sayed Jahed Hussini, Abdallah
Khreishah, Issa Khalil, Mohsen Guizani, and Ala Al-Fuqaha. Smart cities: A sur-
vey on data management, security, and enabling technologies. IEEE Communications
Surveys & Tutorials, 19(4):2456–2501, 2017.
[207] Flavio Esposito, Anna Maria Vegni, Ibrahim Matta, and Alessandro Neri. On modeling
speed-based vertical handovers in vehicular networks:“dad, slow down, i am watching
the movie”. In GLOBECOM Workshops (GC Wkshps), 2010 IEEE, pages 11–15. IEEE,
2010.
[208] Chi Ma, Enda Fallon, Yuansong Qiao, and Brian Lee. Optimizing media independent
handover using predictive geographical information for vehicular based systems. In
UKSim Fourth European Modelling Symposium on Computer Modelling and Simulation,
pages 420–425. IEEE, 2010.
[209] Sourav Dhar, Amitava Ray, and Rabindranath Bera. Cognitive vertical handover engine
for vehicular communication. Peer-to-Peer Networking and Applications, 6(3):305–324,
2013.
[210] Gul Muhammad Khan. Artificial neural network (anns). In Evolution of Artificial Neural
Development, pages 39–55. Springer, 2018.
[211] Guoxia Zhang and Fuqiang Liu. An auction approach to group handover with mobility
prediction in heterogeneous vehicular networks. In ITS Telecommunications (ITST),
2011 11th International Conference on, pages 584–589. IEEE, 2011.
[212] Rahul Garg and Sanjiv Kapoor. Auction algorithms for market equilibrium. Mathematics
of Operations Research, 31(4):714–729, 2006.
158 Bibliography
[213] Faisal Riaz, Rehana Asif, Hina Sajid, and Muaz A Niazi. Augmenting autonomous vehic-
ular communication using the appreciation emotion: A mamdani fuzzy inference system
model. In Frontiers of Information Technology (FIT), 13th International Conference on,
pages 178–184. IEEE, 2015.
[214] Johann Marquez-Barja, Carlos T Calafate, Juan-Carlos Cano, and Pietro Manzoni. A
geolocation-based vertical handover decision algorithm for vehicular networks. In Local
Computer Networks (LCN), 2012 IEEE 37th Conference on, pages 360–367. IEEE,
2012.
[215] Johann M Marquez-Barja, Hamed Ahmadi, Sergio M Tornell, Carlos T Calafate, Juan-
Carlos Cano, Pietro Manzoni, and Luiz A DaSilva. Breaking the vehicular wireless
communications barriers: Vertical handover techniques for heterogeneous networks.
IEEE Transactions on Vehicular Technology, 64(12):5878–5890, 2015.
[216] Wei-Kuo Chiang and Shih-Chieh Chien. Deploying the media independent information
service at the edge of next-generation network. In Electronics Information and Emer-
gency Communication (ICEIEC), 2015 5th International Conference on, pages 182–185.
IEEE, 2015.
[217] Mohamed Ben Brahim, Zeeshan Hameed Mir, Wassim Znaidi, Fethi Filali, and Noured-
dine Hamdi. Qos-aware video transmission over hybrid wireless network for connected
vehicles. IEEE Access, 5:8313–8323, 2017.
[218] Rabe Arshad, Hesham ElSawy, Sameh Sorour, Tareq Y Al-Naffouri, and Mohamed-Slim
Alouini. Velocity-aware handover management in two-tier cellular networks. IEEE
Transactions on Wireless Communications, 16(3):1851–1867, 2017.
[219] Lu Zhang, Lu Ge, Xin Su, and Jie Zeng. Fuzzy logic based vertical handover algorithm
for trunking system. In Wireless and Optical Communication Conference (WOCC), 2017
26th, pages 1–5. IEEE, 2017.
[220] Aymen Ben Zineb, Mohamed Ayadi, and Sami Tabbane. Fuzzy madm based vertical
handover algorithm for enhancing network performances. In Software, Telecommuni-
cations and Computer Networks (SoftCOM), 2015 23rd International Conference on,
pages 153–159. IEEE, 2015.
[221] Kang-Won Lee, Won-Kyeong Seo, You-Ze Cho, Jong-Woo Kim, Jin-Soo Park, and
Byoung-Sub Moon. Inter-domain handover scheme using an intermediate mobile
access gateway for seamless service in vehicular networks. International Journal of
Communication Systems, 23(9-10):1127–1144, 2010.
[222] Alexander Magnano, Xin Fei, Azzedine Boukerche, and Antonio AF Loureiro. A novel
predictive handover protocol for mobile ip in vehicular networks. IEEE Transactions on
Vehicular Technology, 65(10):8476–8495, 2016.
[223] Bayrem Triki, Slim Rekhis, and Noureddine Boudriga. Secure and qos-aware sip han-
dover for voip communication in vehicular adhoc networks. In Wireless Communications
and Mobile Computing Conference (IWCMC), 2011 7th International, pages 695–700.
IEEE, 2011.
Bibliography 159
[224] Ashraf A Ali and Khalid Al-Begain. Ip multimedia subsystem and sip signaling perfor-
mance metrics. In Multimedia Services and Applications in Mission Critical Communi-
cation Systems, pages 19–35. IGI Global, 2017.
[225] U Kumaran and RS Shaji. Vertical handover in vehicular ad-hoc network using mul-
tiple parameters. In Control, Instrumentation, Communication and Computational
Technologies (ICCICCT), 2014 International Conference on, pages 1059–1064. IEEE,
2014.
[226] Ming-Chin Chuang and Meng Chang Chen. Nash: Navigation-assisted seamless han-
dover scheme for smart car in ultradense networks. IEEE Transactions on Vehicular
Technology, 67(2):1649–1659, 2018.
[227] Hayoung Oh and Chong-kwon Kim. A robust handover under analysis of unexpected
vehicle behaviors in vehicular ad-hoc network. In Vehicular Technology Conference
(VTC 2010-Spring), 2010 IEEE 71st, pages 1–7. IEEE, 2010.
[228] Hayoung Oh. Mobility-aware video streaming in mimo-capable heterogeneous wireless
networks. Mathematical Problems in Engineering, 2016, 2016.
[229] André Almeida, Nuno Lopes, and Alexandre Santos. Intelligent handover for vehicular
networks. In Software, Telecommunications and Computer Networks (SoftCOM), 2014
22nd International Conference on, pages 298–304. IEEE, 2014.
[230] José Antonio Olivera, Ismael Cortázar, Carolina Pinart, Alberto Los Santos, and Iván
Lequerica. Vanba: a simple handover mechanism for transparent, always-on v2v
communications. In Vehicular Technology Conference, 2009. VTC Spring 2009. IEEE
69th, pages 1–5. IEEE, 2009.
[231] Laurence Banda, Mjumo Mzyece, and Guillaume Nóel. Fast handover management in
ip-based vehicular networks. In Industrial Technology (ICIT), 2013 IEEE International
Conference on, pages 1279–1284. IEEE, 2013.
[232] Jasmine P Valera and Sunguk Lee. Security measures in overcoming mobile ipv6 security
issues. International Journal of Database Theory and Application, 9(7):297–304, 2016.
[233] H. Takahashi and T. Minohara. Enhancing location privacy in mobile ipv6 by using
redundant home agents. In 2012 IEEE International Conference on Pervasive Computing
and Communications Workshops, pages 451–454, March 2012.
[234] Yuqing Zhu, Weili Wu, and Deying Li. Efficient client assignment for client-server
systems. IEEE Transactions on Network and Service Management, 13(4):835–847,
2016.
[235] Luis Diego Briceno, Howard Jay Siegel, Anthony A Maciejewski, Ye Hong, Brad
Lock, Charles Panaccione, Fadi Wedyan, Mohammad Nayeem Teli, and Chen Zhang.
Resource allocation in a client/server system for massive multi-player online games.
IEEE Transactions on Computers, 63(12):3127–3142, 2014.
[236] Hiroshi Nishida and Thinh Nguyen. Optimal client-server assignment for internet
distributed systems. IEEE Transactions on Parallel and Distributed Systems, 24(3):565–
575, 2013.
160 Bibliography
[237] Farkhana Muchtar, Abdul Hanan Abdullah, Suhaidi Hassan, and Farhan Masud. Energy
conservation strategies in host centric networking based manet: A review. Journal of
Network and Computer Applications, 2018.
[238] Christian Dannewitz, Dirk Kutscher, BöRje Ohlman, Stephen Farrell, Bengt Ahlgren,
and Holger Karl. Network of information (netinf)–an information-centric networking
architecture. Computer Communications, Elsevier, 36(7):721–735, 2013.
[239] Hongbin Luo, Hongke Zhang, Moshe Zukerman, and Chunming Qiao. An incrementally
deployable network architecture to support both data-centric and host-centric services.
IEEE Network, 28(4):58–65, 2014.
[240] Bengt Ahlgren, Christian Dannewitz, Claudio Imbrenda, Dirk Kutscher, and Borje
Ohlman. A survey of information-centric networking. IEEE Communications Magazine,
50(7), 2012.
[241] Haolin Guo, Dewan Tanvir Ahmed, and Abdulmotaleb El Saddik. Web services for
vanet: a service oriented architecturefor infotainment system based on mashup using
open apis. In Proceedings of the third ACM international symposium on Design and
analysis of intelligent vehicular networks and applications, pages 61–68. ACM, 2013.
[242] Wei-Tek Tsai, Xin Sun, and Janaka Balasooriya. Service-oriented cloud computing
architecture. In Information Technology: New Generations (ITNG), 2010 Seventh
International Conference on, pages 684–689. IEEE, 2010.
[243] Xiang Sun and Nirwan Ansari. Dynamic resource caching in the iot application layer
for smart cities. IEEE Internet of Things Journal, 5(2):606–613, 2018.
[244] Jyoti Deogirikar and Amarsinh Vidhate. An improved publish-subscribe method in appli-
cation layer protocol for iot. In 2017 International Conference On Smart Technologies
For Smart Nation (SmartTechCon), pages 1070–1075. IEEE, 2017.
[245] Zubaida Alazawi, Saleh Altowaijri, Rashid Mehmood, and Mohmmad B Abdljabar.
Intelligent disaster management system based on cloud-enabled vehicular networks. In
ITS Telecommunications (ITST), 2011 11th International Conference on, pages 361–368.
IEEE, 2011.
[246] Weijing Qi, Qingyang Song, Xiaojie Wang, Lei Guo, and Zhaolong Ning. Sdn-enabled
social-aware clustering in 5g-vanet systems. IEEE Access, 6:28213–28224, 2018.
[247] Hamada Alshaer. An overview of network virtualization and cloud network as a service.
International Journal of Network Management, 25(1):1–30, 2015.
[248] Navid Nikaein, Raymond Knopp, Lionel Gauthier, Eryk Schiller, Torsten Braun, Do-
minique Pichon, Christian Bonnet, Florian Kaltenberger, and Dominique Nussbaum.
Closer to cloud-ran: Ran as a service. In Proceedings of the 21st Annual International
Conference on Mobile Computing and Networking, pages 193–195. ACM, 2015.
[249] Rastin Pries, Hans-Jochen Morper, Nandor Galambosi, and Michael Jarschel. Network
as a service-a demo on 5g network slicing. In Teletraffic Congress (ITC 28), 2016 28th
International, volume 1, pages 209–211. IEEE, 2016.
Bibliography 161
[250] Hiroki Nishiyama, Thuan Ngo, Shoki Oiyama, and Nei Kato. Relay by smart de-
vice: Innovative communications for efficient information sharing among vehicles and
pedestrians. IEEE Vehicular Technology Magazine, 10(4):54–62, 2015.
[251] TS 36.839 version 11.1.0: Mobility enhancements in heterogeneous networks (Release
11). Technical Specification, 3GPP, 2012.
[252] Jae-Wook Lee and Sang-Jo Yoo. Probabilistic path and data capacity based handover
decision for hierarchical macro-and femtocell networks. Mobile Information Systems,
2016, 2016.
[253] Arvind Merwaday and Ismail Güvenç. Handover count based velocity estimation and mo-
bility state detection in dense hetnets. IEEE Transactions on Wireless Communications,
15(7):4673–4688, 2016.
[254] Hellenic telecommunications and post commission (eett). http://keraies.eett.gr/, 2018.
Accessed: 2018.
[255] Raman Kumar Goyal, Sakshi Kaushal, and Arun Kumar Sangaiah. The utility based
non-linear fuzzy ahp optimization model for network selection in heterogeneous wireless
networks. Applied Soft Computing, 2017.
[256] John Riordan. Introduction to combinatorial analysis. Courier Corporation, 2012.
[257] Emmanouil Skondras, Angelos Michalas, and Dimitrios D Vergados. A survey on
medium access control schemes for 5g vehicular cloud computing systems. In 2018
Global Information Infrastructure and Networking Symposium (GIIS), pages 1–5. IEEE,
2018.
[258] Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, and Dimitrios D Vergados. A
downlink scheduler supporting real time services in lte cellular networks. In 2015 6th
International Conference on Information, Intelligence, Systems and Applications (IISA),
pages 1–6. IEEE, 2015.
[259] Emmanouil Skondras, Angelos Michalas, Angeliki Sgora, and Dimitrios D Vergados. A
qos aware three level scheduler for the lte downlink. In 2015 Wireless Telecommunica-
tions Symposium (WTS), Poster Session, pages 1–2. IEEE, 2015.
[260] Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, and Dimitrios D Vergados.
Qos-aware scheduling in lte-a networks with sdn control. In 2016 7th International
Conference on Information, Intelligence, Systems & Applications (IISA), pages 1–6.
IEEE, 2016.
[261] Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Aggeliki Sgora, and Dim-
itrios D Vergados. A network selection scheme for healthcare vehicular cloud computing
systems. In 2017 8th International Conference on Information, Intelligence, Systems &
Applications (IISA), pages 1–6. IEEE, 2017.
[262] Emmanouil Skondras, Angelos Michalas, and Dimitrios D Vergados. Mobility manage-
ment on 5g vehicular cloud computing systems. Vehicular Communications, 16:15–44,
2019.
Performance Analysis and Optimization of Next Generation Wireless Networks
Appendix A
The positions of the available networks
In this appendix the positions and the spectrum of the available access networks are presented.
Table A1 The positions of the available LTE Access Networks.
Network Position Geographic Latitude Geographic Longitude Downlink & Uplink Spectrum in MHz (LTE Band)
LTE Macro 1 2e 37.948056 23.643056 1805-1825 & 1710-1730 (3)
LTE Macro 2 2l 37.947500 23.650278 2150-2170 & 1960-1980 (1)
LTE Macro 3 3p 37.946667 23.653611 2130-2150 & 1940-1960 (1)
LTE Macro 4 4i 37.946111 23.646389 2110-2130 & 1920-1940 (1)
LTE Macro 5 5q 37.945556 23.654167 1805-1825 & 1710-1730 (3)
LTE Macro 6 6f 37.945000 23.644444 1825-1845 & 1730-1750 (3)
LTE Macro 7 8f 37.942778 23.643611 1845-1865 & 1750-1770 (3)
LTE Macro 8 8t 37.942778 23.656944 1825-1845 & 1730-1750 (3)
LTE Macro 9 9l 37.941944 23.649444 925-945 & 880-900 (8)
LTE Macro 10 11c 37.940000 23.641111 1805-1825 & 1710-1730 (3)
LTE Macro 11 11l 37.939722 23.648611 778-798 & 723-743 (28)
LTE Macro 12 11t 37.939722 23.656111 2150-2170 & 1960-1980 (1)
LTE Macro 13 12i 37.939722 23.645833 758-778 & 703-723 (28)
LTE Macro 14 12y 37.938333 23.661389 1845-1865 & 1750-1770 (3)
LTE Macro 15 14q 37.938056 23.653889 2110-2130 & 1920-1940 (1)
LTE Macro 16 14v 37.937222 23.658333 2130-2150 & 1940-1960 (1)
LTE Macro 17 16b 37.936667 23.640000 2110-2130 & 1920-1940 (1)
LTE Macro 18 16h 37.936667 23.645556 1825-1845 & 1730-1750 (3)
LTE Macro 19 18c 37.934722 23.640833 2130-2150 & 1940-1960 (1)
LTE Macro 20 18f 37.934444 23.643889 2150-2170 & 1960-1980 (1)
LTE Femto 1 4f 37.946944 23.644444 925-945 & 880-900 (8)
LTE Femto 2 4j 37.946111 23.647222 758-778 & 703-723 (28)
LTE Femto 3 4r 37.946389 23.655000 925-945 & 880-900 (8)
LTE Femto 4 5d 37.945833 23.641944 758-778 & 703-723 (28)
LTE Femto 5 5j 37.945556 23.647500 778-798 & 723-743 (28)
LTE Femto 6 6h 37.944444 23.645833 2180-2200 & 2000-2020 (23)
LTE Femto 7 6i 37.944444 23.646667 1475.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 8 7h 37.944167 23.645833 860-875 & 815-830 (18)
LTE Femto 9 7i 37.943889 23.647222 2130-2150 & 1940-1960 (1)
LTE Femto 10 7k 37.943889 23.648056 2180-2200 & 2000-2020 (23)
LTE Femto 11 8k 37.942778 23.648611 1475.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 12 8m 37.942500 23.650556 2180-2200 & 2000-2020 (23)
LTE Femto 13 9e 37.941667 23.643333 860-875 & 815-830 (18)
LTE Femto 14 9g 37.942222 23.645000 2180-2200 & 2000-2020 (23)
LTE Femto 15 9h 37.941944 23.645833 860-875 & 815-830 (18)
LTE Femto 16 9j 37.942222 23.647778 2180-2200 & 2000-2020 (23)
LTE Femto 17 9n 37.942222 23.651111 1475.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 18 10e 37.941944 23.643333 2130-2150 & 1940-1960 (1)
LTE Femto 19 10f 37.941389 23.644167 2180-2200 & 2000-2020 (23)
LTE Femto 20 10g 37.941111 23.644444 860-875 & 815-830 (18)
LTE Femto 21 10h 37.941389 23.645833 2180-2200 & 2000-2020 (23)
LTE Femto 22 10j 37.941389 23.647500 860-875 & 815-830 (18)
LTE Femto 23 10l 37.941111 23.649722 1475.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 24 11e 37.940556 23.643056 1475.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 25 11f 37.940278 23.643611 860-875 & 815-830 (18)
LTE Femto 26 11h 37.940833 23.645833 1475.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 27 12k 37.940000 23.648889 1180-2200 & 2000-2020 (23)
LTE Femto 28 13c 37.939444 23.641111 1475.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 29 13e 37.938333 23.642778 925-945 & 880-900 (8)
LTE Femto 30 13j 37.939444 23.648333 1175.9-1495.9 & 1427.9-1447.9 (11)
LTE Femto 31 14d 37.938333 23.642222 1180-2200 & 2000-2020 (23)
LTE Femto 32 14n 37.938333 23.650556 1805-1825 & 1710-1730 (3)
LTE Femto 33 15b 37.937222 23.639722 925-945 & 880-900 (8)
LTE Femto 34 15c 37.937222 23.640833 778-798 & 723-743 (28)
LTE Femto 35 15u 37.936944 23.657778 925-945 & 880-900 (8)
LTE Femto 36 16c 37.936389 23.641111 860-875 & 815-830 (18)
LTE Femto 37 18h 37.934444 23.645278 925-945 & 880-900 (8)
164 The positions of the available networks
Table A2 The positions of the available WiMAX Access Networks.
Network Position Geographic Latitude Geographic Longitude Downlink & Uplink Spectrum in MHz (WiMAX 2 Band)
WiMAX Macro 1 1e 37.949444 23.642500 3500-3510 & 3400-3410 (5L)
WiMAX Macro 2 3e 37.947778 23.643333 3510-3520 & 3410-3420 (5L)
WiMAX Macro 3 3j 37.947222 23.647500 3530-3540 & 3430-3440 (5L)
WiMAX Macro 4 3o 37.947222 23.652778 3540-3550 & 3440-3450 (5L)
WiMAX Macro 5 6r 37.944722 23.655000 3590-3600 & 3490-3600 (5L)
WiMAX Macro 6 8g 37.943333 23.645278 3590-3600 & 3490-3600 (5L)
WiMAX Macro 7 11d 37.940833 23.641944 3500-3510 & 3400-3410 (5L)
WiMAX Macro 8 11l 37.940556 23.649722 3530-3540 & 3430-3440 (5L)
WiMAX Macro 9 11n 37.940000 23.651389 3540-3550 & 3440-3450 (5L)
WiMAX Macro 10 11r 37.940278 23.655278 3550-3560 & 3450-3460 (5L)
WiMAX Macro 11 12j 37.939494 23.648333 3510-3520 & 3410-3420 (5L)
WiMAX Macro 12 12u 37.939444 23.657778 3500-3510 & 3400-3410 (5L)
WiMAX Macro 13 14e 37.938056 23.643333 3580-3590 & 3480-3490 (5L)
WiMAX Macro 14 14v 37.937222 23.658611 3510-3520 & 3410-3420 (5L)
WiMAX Macro 15 17b 37.935833 23.639722 3540-3550 & 3440-3450 (5L)
WiMAX Macro 16 18c 37.934722 23.640833 3530-3540 & 3430-3440 (5L)
WiMAX Macro 17 18i 37.934444 23.645278 2305-2315 & 2345-2355 (2)
WiMAX Femto 1 3f 37.947500 23.644444 3520-3530 & 3420-3430 (5L)
WiMAX Femto 2 5g 37.945278 23.644167 3550-3560 & 3450-3460 (5L)
WiMAX Femto 3 6e 37.945000 23.642222 3560-3570 & 3460-3470 (5L)
WiMAX Femto 4 6g 37.944444 23.645278 3570-3580 & 3470-3480 (5L)
WiMAX Femto 5 6j 37.944444 23.647222 3580-3500 & 3480-3490 (5L)
WiMAX Femto 6 7j 37.943889 23.647778 3520-3530 & 3420-3430 (5L)
WiMAX Femto 7 8h 37.942222 23.646111 2305-2315 & 2345-2355 (2)
WiMAX Femto 8 8k 37.942500 23.648056 3550-3560 & 3450-3460 (5L)
WiMAX Femto 9 8n 37.942778 23.651389 3520-3530 & 3420-3430 (5L)
WiMAX Femto 10 9g 37.942222 23.645278 2305-2315 & 2345-2355 (2)
WiMAX Femto 11 9i 37.941667 23.646389 3550-3560 & 3450-3460 (5L)
WiMAX Femto 12 9j 37.941944 23.647500 2305-2315 & 2345-2355 (2)
WiMAX Femto 13 9m 37.942222 23.651111 2305-2315 & 2345-2355 (2)
WiMAX Femto 14 10f 37.941389 23.644167 3520-3530 & 3420-3430 (5L)
WiMAX Femto 15 10h 37.941389 23.645833 3520-3530 & 3420-3430 (5L)
WiMAX Femto 16 10j 37.941389 23.647500 3550-3560 & 3450-3460 (5L)
WiMAX Femto 17 10m 37.941389 23.650000 3520-3530 & 3420-3430 (5L)
WiMAX Femto 18 10s 37.941389 23.655556 3520-3530 & 3420-3430 (5L)
WiMAX Femto 19 11f 37.940278 23.643333 2305-2315 & 2345-2355 (2)
WiMAX Femto 20 11h 37.940556 23.645556 2305-2315 & 2345-2355 (2)
WiMAX Femto 21 11k 37.939722 23.648611 2305-2315 & 2345-2355 (2)
WiMAX Femto 22 12k 37.929167 23.648056 3520-3530 & 3420-3430 (5L)
WiMAX Femto 23 15b 37.937222 23.640000 2305-2315 & 2345-2355 (2)
WiMAX Femto 24 15d 37.936944 23.641667 3520-3530 & 3420-3430 (5L)
WiMAX Femto 25 15u 37.936944 23.657778 2305-2315 & 2345-2355 (2)
Table A3 The positions of the available WAVE Access Networks.
Network Position Geographic Latitude Geographic Longitude Spectrum in MHz (DSRC Europe Band)
WAVE 1 2f 37.948056 23.644444 5915-5925 (SCH4)
WAVE 2 2h 37.947500 23.646389 5905-5915 (SCH3)
WAVE 3 3m 37.946667 23.650278 5895-5905 (SCH2)
WAVE 4 4e 37.946111 23.642500 5895-5905 (SCH2)
WAVE 5 4u 37.945556 23.658056 5875-5885 (SCH1)
WAVE 6 5i 37.945000 23.646944 5915-5925 (SCH4)
WAVE 7 6k 37.944167 23.648056 5905-5915 (SCH3)
WAVE 8 7e 37.943056 23.643333 5875-5885 (SCH1)
WAVE 9 7i 37.943889 23.646667 5895-5905 (SCH2)
WAVE 10 7n 34.943889 23.651111 5875-5885 (SCH1)
WAVE 11 9h 37.942222 23.646389 5915-5925 (SCH4)
WAVE 12 10e 37.941667 23.643333 5895-5905 (SCH2)
WAVE 13 10j 37.941667 23.647500 5875-5885 (SCH1)
WAVE 14 10n 37.941111 23.651667 5905-5915 (SCH3)
WAVE 15 11h 37.940556 23.645556 5905-5915 (SCH3)
WAVE 16 12c 37.939444 23.641389 5875-5885 (SCH1)
WAVE 17 12q 37.938889 23.654444 5875-5885 (SCH1)
WAVE 18 14b 37.938056 23.640556 5915-5925 (SCH4)
WAVE 19 14f 37.937778 23.644167 5905-5915 (SCH3)
WAVE 20 17c 37.935000 23.641389 5895-5905 (SCH2)
WAVE 21 17n 37.935278 23.651389 5895-5905 (SCH2)
WAVE 22 18i 37.934722 23.645278 5875-5885 (SCH1)
Appendix B
The available networks per SLA
In this appendix the available networks per SLA are presented.
166 The available networks per SLA
TableB1TheavailableLTEnetworksofSLA1.
SLA1
NAVVoIPCVBSWeb
Network
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
LTEMacro1AGAGGVGMGGAPAGAGGVGGVGVPGVGGMGMGMAPMMGAGMGAGPAGAGGVGVGAGAP
LTEMacro2VGAGGGAGAGAPMMGMGMGMPAGAGMVGMMGAPMGGMGMMGAGVPVGAGGGGAGP
LTEMacro3VGAGMGMGVPMMGMGMMGVGVPMGGGMVGMGVPGVGMGMGVGMPVGAGGGMAGVP
LTEMacro4MMGMMVGAGPMMGMGMGGPVGAGAGGVGAGPAGAGMVGMGGPMGGMGMGGVP
LTEMacro5AGAGVGVGVGAGVPAGAGVGVGMVGAPGVGAGMGAGMAPMGGVGMGAGGVPGVGAGMGMGVP
LTEMacro6MMGGMVGGPMGGMGMVGMGAPVGAGAGGGMGVPGGVGMGVGVGPAGAGVGVGVGAGVP
LTEMacro7MGGMGMAGGVPMGGGMMVGVPMGGGMMMGPVGAGAGGGMGPAGAGGVGGVGP
LTEMacro8MGGAGMGAGMPAGAGGVGAGAGAPAGAGAGVGAGGPGGMMGAGAGPGVGMGMGVGAGAP
LTEMacro9MMGVGMAGMVPMMGAGMMGMAPGVGGMGMGVGPVGAGVGGVGVGPMMGVGMAGAGP
LTEMacro10MGGAGMGMGMGAPAGAGMVGVGMPGVGGMGMAGVPGVGGMGAGAGPGVGMGMGGGVP
LTEMacro11MMGVGMVGMGVPMMGMGMAGMGVPGVGGMGMVGAPMMGMGMGGPGGMGMGGVGAP
LTEMacro12MMGMMVGGAPVGAGAGGGMGAPVGAGGGAGGVPAGAGMGVGGVGAPAGAGVGVGMGMGP
LTEMacro13VGAGMGGGMGAPMMGMMMGMGPAGAGVGVGGMPAGAGVGVGMGGAPVGAGVGGVGAGAP
LTEMacro14VGAGAGGMGMAPAGAGVGVGVGGPVGAGGGGAGVPVGAGGGGMAPGVGGMGGAGAP
LTEMacro15MMGMGMGVGPAGAGGVGGMPMMGGMVGVGAPMMGAGMVGAGVPAGAGMVGVGGAP
LTEMacro16AGAGMGVGAGVGVPVGAGVGGMGMGPVGAGAGGAGMGVPGGMGMGAGMPGVGMGMGGVGP
LTEMacro17GVGMGMGMGMVPAGAGAGVGAGMPGVGVGMGMGAGPGVGVGMGGAGAPVGAGVGGGMGAP
LTEMacro18MGGMGMGGVPVGAGGGVGVGVPGVGGMGAGMGAPMGGMGMVGMGAPMMGAGMGGVP
LTEMacro19AGAGMGVGAGVGVPMGGMGMGMVPGVGAGMGGGPGVGMMGVGMGAPVGAGVGGVGVGP
LTEMacro20MMGMGMAGAGVPMGGGMMGPMGGGMAGMGVPGVGGMGMGMAPMGGAGMVGVGP
LTEFemto1MGGAGMMGMPVGAGMGVGMVPMGGVGMVGAGAPVGAGMGGVGVPGVGMGMGAGGVP
LTEFemto2VGAGMGMMAPAGAGGVGMMAPMGGMMVGMGAPMGGMMVGMGPGVGMGMGGMGP
LTEFemto3AGAGMGVGVGMGPAGAGGVGAGVGVPGVGGMGVGGPAGAGVGVGGGVPVGAGMGGMGVGAP
LTEFemto4MGGAGMVGAGVPGVGVGMGVGAGVPGVGGMGAGMGVPMGGGMMAGAPAGAGGVGMGGVP
LTEFemto5MGGMMGGVPMMGMGMAGMPVGAGAGGVGAGAPVGAGAGGGVGPGVGVGMGAGVGP
LTEFemto6AGAGMVGVGVGAPAGAGAGVGMGMPMMGAGMGVGAPMMGMGMVGAGAPMGGGMMGAGP
LTEFemto7MGGMMMMGAPVGAGVGGVGMVPAGAGGVGMGMGAPMGGMGMVGVGPAGAGGVGAGGP
LTEFemto8MMGAGMMGMVPAGAGMVGMMVPAGAGAGVGGAGPGVGGMGMGMPAGAGAGVGVGGAP
LTEFemto9GVGMMGAGVGVPMGGGMMMGAPGVGMGMGMGMGAPMGGGMMGAGPMMGMGMMGAGAP
LTEFemto10VGAGAGGGMAPVGAGVGGVGVGVPAGAGVGVGMGAGAPVGAGMGAGMGAPVGAGVGGGAGAP
LTEFemto11AGAGGVGVGAGPAGAGGVGMMGAPGGMMGMMPAGAGGVGMGMPAGAGGVGMGVGVP
LTEFemto12MGGMMVGMGPMMGVGMVGAGAPMGGAGMGGAPAGAGMGVGGGAPMMGGMVGVGP
LTEFemto13MGGMGMMMPVGAGMGMMVPAGAGMVGAGGVPMGGAGMGMGVPAGAGGVGGMGAP
LTEFemto14GVGMMGMAGVPMGGGMAGGVPVGAGVGGVGMGVPAGAGMVGMGGVPGVGMGMGGAGAP
LTEFemto15MGGGMGGAPMGGGMAGMGPMMGAGMAGMVPMGGMGMGAGAPVGAGMGGMGMGVP
LTEFemto16VGAGMGVGMGVPAGAGMVGAGGVPGVGMGMGGMGPGGMGGAGVGVPAGAGMVGMAGAP
LTEFemto17VGAGMGAGVGPVGAGAGGVGMGVPMGGAGMVGVGPAGAGVGVGGMAPGGMGMGGVGAP
LTEFemto18MGGMMVGGPGVGMMGMGGVPVGAGMGGAGMGPGVGMGMGVGMGAPGVGVGMGVGAGVP
LTEFemto19VGAGGGAGMPVGAGAGGGAGAPAGAGMVGVGMAPVGAGGGGGPVGAGMGGMGGP
LTEFemto20GVGGMGMGAGAPMMGMGMMGMVPVGAGAGGMGMGAPVGAGVGGGGVPMGGGMGMGVP
LTEFemto21MMGGMVGAGVPMMGMMMGAGAPGVGGMGMGVGAPMMGGMMGMAPVGAGMGGVGMGP
LTEFemto22AGAGMGVGVGAGVPGVGMGMGAGVGVPAGAGAGVGVGAGPMMGVGMGGPMGGVGMMMVP
LTEFemto23MMGGMMAGPAGAGMVGMGAGAPAGAGMGVGGMGPGVGAGMGVGGAPMMGMMAGGP
LTEFemto24MGGMGMAGAGAPAGAGMGVGMMVPMGGMGMGGAPMMGVGMMGPVGAGMGGAGGP
LTEFemto25GVGAGMGGMGAPGVGGMGMGMGVPAGAGAGVGVGVGPVGAGAGGGGAPAGAGAGVGVGAGVP
LTEFemto26GVGGMGMGVPMGGAGMGGVPAGAGMVGGGVPGVGGMGVGGVPMMGVGMGVGAP
LTEFemto27MGGGMGMAPVGAGGGVGAGPMGGGMGAGAGVPGVGAGMGGVGPAGAGAGVGVGGAP
LTEFemto28MMGGMMGGVPMGGGMGGVPMGGAGMGGAPGGVGMGGMGVPGVGVGMGGMGP
LTEFemto29VGAGMGMMGAPAGAGVGVGVGAGPGVGMGMGMGMVPAGAGAGVGMGMGVPMMGVGMMGGAP
LTEFemto30AGAGAGVGMAGVPGVGMMGMGMGAPMGGGMGGVPAGAGGVGGAGPMMGMMGGVP
LTEFemto31VGAGAGGAGMGPAGAGVGVGVGAGAPMGGGMGMAPMMGMGMMGMAPAGAGGVGAGGAP
LTEFemto32VGAGAGGVGMGAPGVGMMGGMGVPVGAGVGGMMGVPMGGMMMGGAPMMGMMVGMGVP
LTEFemto33AGAGMGVGAGMGPGVGMMGMVGVPVGAGAGGGAGPVGAGGGVGVGVPGVGVGMGGVGP
LTEFemto34AGAGGVGMGMGVPVGAGMGGMGMGPVGAGMGGMGVPMMGVGMAGAGVPMGGVGMGMP
LTEFemto35VGAGGGMGMVPGVGMMGAGVGPVGAGVGGMGMGPVGAGGGMGAGPGVGGMGVGMP
LTEFemto36GVGMMGMGGAPMGGVGMMGAGVPVGAGGGAGMGAPMGGVGMAGMGPGVGMGMGMGAP
LTEFemto37GVGAGMGMMGPAGAGVGVGVGAGAPAGAGVGVGMGAPAGAGAGVGMGMGAPGVGVGMGVGMGP
167
TableB2TheavailableWiMAXandWAVEnetworksofSLA1.
SLA1
NAVVoIPCVBSWeb
Network
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
WiMAXMacro1MGGGMGVGPGVGVGMGVGGPMMGMMVGMPGGVGMGGMGAPMGGMMAGGAP
WiMAXMacro2MGGMMMGGPMGGVGMMGGPAGAGGVGAGMGAPAGAGVGVGMGMAPGVGAGMGAGMP
WiMAXMacro3GVGMGMGGGVPMGGMMVGMPVGAGMGGGMPMMGGMMGMVPVGAGMGGAGMVP
WiMAXMacro4MGGMMAGVGVPMGGMMAGMGAPVGAGMGGVGMVPAGAGAGVGMGGPGVGMMGGAGAP
WiMAXMacro5AGAGAGVGMGMVPVGAGGGMGAGPVGAGMGAGMAPMGGVGMGGPAGAGGVGMGVP
WiMAXMacro6MMGMGMGMPMGGVGMVGVGAPVGAGGGVGMPGVGMGMGVGVGAPGVGGMGVGVGVP
WiMAXMacro7AGAGGVGMVGAPAGAGMGVGVGGPGVGMGMGVGMAPGVGMMGAGGAPMGGMMAGGAP
WiMAXMacro8MMGVGMAGMGVPVGAGMGGMGVGAPMMGVGMGGVPMGGGMGAGVPGVGMGMGMMGP
WiMAXMacro9AGAGMVGMMGPMMGMMAGVGAPAGAGGVGGMVPMGGMGMGMAPMMGMGMAGGVP
WiMAXMacro10MGGMMVGGPAGAGAGVGMGGVPAGAGGVGGMGVPGVGMMGMVGAPVGAGAGGGVGVP
WiMAXMacro11MMGGMVGMGAPMGGAGMGMGPGVGMMGGMAPGVGVGMGVGGPMMGVGMVGGVP
WiMAXMacro12GVGAGMGGMPAGAGVGVGGGPVGAGMGGAGAPVGAGGGGMGPVGAGGGMMGP
WiMAXMacro13GVGMGMGAGMVPMMGVGMMGPAGAGVGVGVGGVPMMGAGMAGGAPGVGGMGAGAGVP
WiMAXMacro14AGAGAGVGGMPMMGMMMVGPVGAGGGAGVGPMGGGMMVGAPMGGMGMGMGVP
WiMAXMacro15VGAGVGGMGGAPAGAGGVGGMVPMGGVGMVGMGPMMGMMAGGPGVGGMGVGMGAP
WiMAXMacro16MMGMMVGMGAPVGAGMGGMVGAPMMGMMMGMGAPGGVGMGVGGPAGAGAGVGGAGAP
WiMAXMacro17MMGGMGAGAPMMGMGMAGAGVPMGGGMAGVGVPAGAGVGVGGMGAPVGAGVGGVGMGVP
WiMAXFemto1VGAGAGGGMGAPMMGMMVGMGPMGGMGMGMGAPVGAGGGAGGAPGVGVGMGVGGP
WiMAXFemto2MMGGMMGAGVPGVGAGMGAGAGPMMGMGMVGVGVPGVGMMGMVGVPMGGVGMGVGP
WiMAXFemto3MMGGMAGGAPMMGAGMGMAPVGAGVGGGGAPMGGVGMMAGVPMMGMGMAGAGAP
WiMAXFemto4MGGVGMMGVGPAGAGAGVGVGMGPGVGGMGMGMGVPMMGMMMMGPGGGMGGMAP
WiMAXFemto5AGAGGVGGMVPVGAGMGGMGAGVPVGAGAGGAGVGVPVGAGMGVGVGPMGGMMMGMAP
WiMAXFemto6MMGMGMGVGAPMGGAGMMMGPVGAGGGMGMAPMGGVGMGGVPAGAGGVGVGVGVP
WiMAXFemto7MGGGMMGMVPMMGMMVGVGPGVGVGMGGVGPMMGGMGVGPAGAGVGVGGAGP
WiMAXFemto8GVGGMGGMGAPVGAGMGGVGPAGAGMGVGAGGPVGAGAGGMGAGVPAGAGVGVGVGMGAP
WiMAXFemto9MGGMGMVGMPMMGMMAGGAPMGGGMGMGVPMMGVGMAGMAPMGGMGMGGAP
WiMAXFemto10AGAGAGVGMAGAPGVGAGMGMMGAPGVGMMGGAGVPVGAGGGVGGPAGAGAGVGMGMGP
WiMAXFemto11MGGGMGAGPVGAGAGGVGGPAGAGAGVGMGGPAGAGVGVGGVGAPAGAGAGVGVGAGVP
WiMAXFemto12GVGGMGAGVGPMMGMGMMMGAPMGGMGMVGGPGVGGMGVGAGVPGVGMGMGGMP
WiMAXFemto13AGAGMGVGVGVGVPMMGAGMGMAPGVGVGMGGVGPAGAGVGVGGVGVPVGAGMGGMGMAP
WiMAXFemto14AGAGVGVGMGAPAGAGMVGMMAPVGAGMGGMGGVPAGAGVGVGVGGAPMGGGMVGGAP
WiMAXFemto15AGAGGVGGMGVPMGGVGMGMGVPGGMGMGGAGAPAGAGMVGMGGPGVGMMGMGMGP
WiMAXFemto16MMGMMMGMVPGVGMMGGMAPVGGMGGGAGPVGAGMGGAGVGPAGAGAGVGAGGP
WiMAXFemto17MMGGMMGMAPGVGVGMGMMAPGVGAGMGAGVGPMGGVGMVGAGVPVGAGAGGAGMGP
WiMAXFemto18GVGAGMGMVGVPAGAGVGVGVGMVPVGAGGGMGGPMMGAGMGVGPVGAGVGGAGMVP
WiMAXFemto19MMGMMGMVPAGAGMVGAGMVPAGAGGVGGMAPGVGMGMGGMGAPVGAGMGGVGP
WiMAXFemto20GVGAGMGGAGVPMMGMMMMGAPGVGMGMGMAGPMGGGMVGGPMMGAGMVGVGAP
WiMAXFemto21MGGMMMGAGPMMGMMMAGPMMGAGMMAGPGVGMMGVGGAPVGAGGGGGAP
WiMAXFemto22VGAGAGGMGMAPGVGMMGMAGVPGVGGMGVGMAPMMGVGMMVGVPMGGMMGMGAP
WiMAXFemto23MGGGMMGMAPVGAGAGGAGMVPMGGMGMGMGAPMGGGMGAGAPVGAGGGVGAGVP
WiMAXFemto24GVGMMGVGGVPAGAGAGVGMGMGAPGVGMGMGMGMVPGVGAGMGGMGAPVGAGVGGGGP
WiMAXFemto25MGGVGMMGVGAPVGAGGGVGGPMGGGMAGMGPVGAGAGGMGMGAPMGGAGMVGMGAP
WAVE1AGAGGVGVGVGVPGVGVGMGAGAGPMGGMMVGGPMGGGMVGAGPVGAGGGAGMVP
WAVE2VGAGMGGAGMGVPMGGMGMGMPVGAGAGGGMVPMMGVGMGVGAPMMGVGMVGMGP
WAVE3VGAGMGMVGAPMMGGMVGVGVPAGAGMGVGVGMGVPMGGMMVGGPMGGGGMVGVP
WAVE4AGAGAGVGAGAGPGVGMMGMGMGVPGGMMGAGGVPAGAGGVGAGMGVPGVGMGMGGVGAP
WAVE5MMGMMAGVGAPMGGVGMVGAGAPGVGVGMGMGMGAPAGAGGVGMGMGPMMGAGMMGAP
WAVE6MMGVGMGMGMVPGVGAGMGAGVGAPMMGGMMGGVPAGAGMVGGVGAPMGGGMGMGAP
WAVE7MMGAGMMGVGVPVGAGMGGMGPVGAGVGGAGGVPAGAGVGVGGGPVGAGGGAGVGAP
WAVE8MGGGMGMGMGVPMMGMMAGMGPVGAGAGGMMGAPAGAGGVGMMGPVGAGAGGGVGAP
WAVE9MGGGMGGMPMMGMMVGMGVPMMGMMVGVGPAGAGMVGVGGAPMMGGMAGGP
WAVE10MGGGMAGVGPMMGVGMAGMVPAGAGMVGMGGVPMMGGMMGGVPMGGVGMGAGAP
WAVE11MMGGMGAGAPVGAGGGMMVPGVGGMGMGMGVPAGAGGVGAGMGVPVGAGGGVGMP
WAVE12AGAGMGVGMVGVPAGAGVGVGVGGVPMMGVGMGVGVPVGAGMGGMGVGAPAGAGMVGGAGAP
WAVE13MMGGMGMVPMGGVGMVGMGPAGAGGVGVGGVPVGAGMGGAGGAPAGAGVGVGVGVGP
WAVE14AGAGAGVGGVGAPGVGVGMGGMAPGGGMGVGAGPMMGGMGMGPMGGMGMAGGVP
WAVE15GVGGMGMMGVPAGAGVGVGGMGAPAGAGGVGAGMVPMMGVGMGMGPMGGGMGAGVP
WAVE16VGAGMGMVGGVPGVGMGMGVGAGVPGVGAGMGGGAPVGAGAGGMGGAPGVGGMGAGGAP
WAVE17MMGVGMVGVGPVGAGAGGMMGVPMMGGMAGMGVPVGAGMGGMGMAPVGAGGGAGVGP
WAVE18GVGGMGMGAGAPMGGMMVGVGAPMGGMMVGGVPAGAGGVGAGGPMMGAGMVGGP
WAVE19VGAGMGGMGMPGVGAGMGVGGAPVGAGGGAGGPMGGAGMMGVGAPAGAGAGVGMAGAP
WAVE20MMGMMGGAPMGGAGMGMGVPVGAGMGGAGAGAPMMGMGMVGAGPMMGVGMAGAGVP
WAVE21MMGVGMVGAGPGVGAGMGMGGAPGVGMMGMGMGPGVGGMGAGVGVPGVGMMGMGGP
WAVE22MGGGMGMGGVPMGGGMGAGAPAGAGMGVGMGAGVPVGAGGGGMGVPAGAGGVGGAGAP
168 The available networks per SLA
TableB3TheavailableLTEnetworksofSLA2,SLA3andSLA4.
SLA2SLA3SLA4
CVBSWebBSWebWeb
Network
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Secutiy
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
LTEMacro1GGGMGMGPPMPMMGPGMPPGGGMGGMPPMPMMGPMMPMPMPMGPMGMPMVPPVPAPVPPVG
LTEMacro2MMGPMPMMPMMGGMMPMGMGGMPMGMPMGPPMPMPPPMPMMMGMPMPMPMGMGMMAPMPMPPG
LTEMacro3MGGGMGMGMPPMPMPPPMMGGPMMPMPMPPPPPMMGMGPMMPGAPVPVPAPMVPAG
LTEMacro4MMGPMPPMPMPGGPMGPGPMGGMMGMPMPMPPPPMMGMGMPMMGPMMMMPMPVPPAG
LTEMacro5MPMMPPMMMGGGMMGGMMGGPMMGMMGMGMGMPMPMMMGPMPMMPMAPVPPAPAPPAG
LTEMacro6MPMMPPGMGMGGGMGMPGMMMGGMPMGMPMPMGMGMPMMPPMMMGMPMPMPPGPMPMPVPVPPG
LTEMacro7MGGGMPMPMMGMGMPMPMMMGPMPGMPMPMPPMPPMGMPMPPPPMAPVPVPAPAPVPVG
LTEMacro8GGPMGPMPMGGPMGMGGMPMMGMMPGMPPMPPMPPMGMMGPMPMPMPMPMPAPVPVPMPAG
LTEMacro9MGGPMMGMPMPMMGPGMPPMMGMGMPMGMGPPMPMPVPMPGPMPMVPPMPGPMPPVPPVPAG
LTEMacro10GGGMGMMMMGGGMMPMGMPMPPPGMMPMPMPPMPPGPMPPPMMPMGPMPVPPAPMPVG
LTEMacro11MMGMPMPPMGMPPMPMGPGPMGGPMGGGMPMPMGPPPMGMMGPMPMPPGPMPVPVPMPPAG
LTEMacro12MPMGPMPGMMPMMGPMMGMPMPMPPMGMGPMPMMGPMMPMGMPMPPMPMMMPMVPPVPAPVG
LTEMacro13GGGMGGMPMPPMPMGPMGGMPMPPMPPPMPPMPMGPMPMMPMPPVPPPGPMPPVPPVPVG
LTEMacro14MMGMGMPGPMGGGMGPMMPPMPGPGGPMMGMMPPMPMPMPMGPMPPGPMPMVPMPAPG
LTEMacro15MMGMGMPGMPPPMPMPMGMPMPMGGPMPPPPMPMPPPMMPMPPPVPGMPMPPPVPVG
LTEMacro16MGGMPMPMGPGGMGMGMGPMMMGMGMPMMPMPMPMPPPMMMGPMPMPMMMPMPMPPG
LTEMacro17MPMPPPGMPMPPPPMGPMMGPMPMPMGPPMPPPPMGPMPPPMPMMGPMPAPVPVPVPG
LTEMacro18MGGMMMPMMPMGGMGMPMPMMMGGMPMGPPMPPPPMPGPMPPVPMPPGAPVPPAPPAPVG
LTEMacro19MPMMPPMPMGGMPMGMGPMMPMMGPMPMGMMPMMPMPMPPMMPMMPPMPMPGMPMPPPMPAG
LTEMacro20MGGMGMMMGMMMGGMPMGMMPMGGGMGMMMPMPPPMGMPMMPPMMGPMPAPPAPAPAG
LTEFemto1PMPGPGMMPGGMMGMGPPMPMPPMPPPMPPPMGPMGMPMPPMPMMPMVPPAPVPG
LTEFemto2PMPMPPMMGMPMMGPMPPMGMPMPMPMPGMMMMGPMPPMPGPMPPVPPPGPMPAPVPAPVPG
LTEFemto3GGMGMGMGMMGGGMMPPPMPMMPPPMMPMPPPMPPMGMPMMPPPPMVPPMPAPPAPVG
LTEFemto4GGPMGGMPMGGMGMPMPPMGGMMPGMPMPMMGPPPGMPMMPPPPGMPMMPPVPPVG
LTEFemto5GGMMGPMPMMGGMGMMGPMPMPGPGMPPMPPPMPPGPMPMPPMGPGPMPMPVPPVPVG
LTEFemto6PMPMPGPPPMPMGPMGMPMPMGPPMMPPMPMGPPPMGMPMMGPPMPMGMPMAPPVPMPG
LTEFemto7MMGPMPMMMPMGGMGMMPPPMGGGMMPMMMMGMPMPPPMPMPPPPPGPMPPVPVPPVG
LTEFemto8GGMPMGMPMPPMPGPMGMPPGGMPMGGMPPMPPPMPPGMGMGMPMPPGMMPMPPVPVG
LTEFemto9MGGMMMGMPMGGMMMGMPMMMGMMPMPMGMPMPMPMPMPGMMGMMPMPMGMPMMPPMPMPG
LTEFemto10PMPMGPMPMGMGGPMGMPMPMPMPMGPGGPMPMPPMPMPMMPMPPMMGGPMPPPPPAG
LTEFemto11GGPMGPMPMMPMGPMGMPMGGMMMMGPMPMPPPMMPMPMPPPMGPPPPVPVPAG
LTEFemto12PMPMPMPPMPMPMMGPGPMPMPMGPMGMMPMPMPMPMGPMPPVPMPMPMPMPVPVPVPMPG
LTEFemto13MMGPMPMPMMPMGGGMMPPMPMPMMGPGMGPMGMGMGMMPPGMPMMPMGMPMPMPVPVPVPVPVG
LTEFemto14MGGGMMGMPMPMGGPMMGMPPMPMPPMPGPPMPPPMMPGPMPMPPMPMPMVPPVPPVPMPVG
LTEFemto15PMPGPGPMPMGGMMMGMPMGGMGMMPMMMGMGPMMPMPMGPMPMPPMPMMPMPVPVPVPMVG
LTEFemto16MMGPMPGMGPMGGMGMMGMGGMMGMPMPPMPMPPPPMMGMGMPMMPMPMMPMMPPMPAPVG
LTEFemto17MGGMGMGMGMMGGPMMGMGPPMPPPMGMPMGMGPMMGMPMGPMPPVPMPMGGPMPAPVPMPMG
LTEFemto18MPMPPGMGMPMPMGPMGMPMMGGMMMGMMPMPMPPMMPGMGMGMMMGPMGMMAPMPMVPAG
LTEFemto19GGMMGGPMPMPMMPPGMGMPGGMMGPMGMPMPMPPMMGMGMGMGMMPMPMMMMMPAPMPAG
LTEFemto20MMGMMPMGPMPMPMMPGMPMPMGGMGMMGMGMMPMMPPMPGPMPMPMPMVPPAPAPMVPG
LTEFemto21PMPPPPMPPMPGPMGMPMPMGGMMGMMPMPMPVPMPMPMGMGMGMMMMMMMMPMPPAPG
LTEFemto22MGGGMMPMGPPMPMGPGMPMPMGGGMMMMPPMPMPPPPMGMGMGMMMMGAPVPMAPAPPAG
LTEFemto23MGGMMMMMPMGGGMMMMMMGMMPGPPMPMMPMPGMMGPMPMPMGMPMVPPPPAG
LTEFemto24MMGMMPGGMMPMMPPMGMMGGPMMPPMMPMMPPPGMMGPMPPPMMMVPMPPVPG
LTEFemto25GGGMGGMGMPPMPMGPMGMGMPMMGMGMPGGPPMPMPVPMGPGMMGMMPMPMGMPMPMVPVPVPVG
LTEFemto26MGGMMMGPMMGGMGMMPMPMPGGMPMGMMMPMPMGPPMPMMMGMMPPMPGMMMMPPPG
LTEFemto27MGGGMGGMPPMPPPMGPMPGGMMGPPMVPPPVPMPMMMGMMPPPMGMPMAPPVPVPAG
LTEFemto28PMPMPPMPPGGMPMGMPPMPMMGPMPMGMMPMGMGPMPPMMMGPMPPMMPMPAPVPAPAPG
LTEFemto29GGPMGPPMPGGGMGMMPMPMPMPPMMMPMGMGMMMGMMMPMPPMMMMPMPPPVPAG
LTEFemto30GGMMGMGPPPMPMPMGMMPMPGPMMPMMPMMGPMMPMGMMGMGMPMPMPMGMPMMPMPMPVG
LTEFemto31MMGGMPGPPMMGPMPPMPMPMPMGPMPMPPMPMPPPMPMGMPMPPMPPMVPPAPVPVPPG
LTEFemto32MMGGMPMPMGMMPMMPPPMGMPMMGMPMPMGPPMPMMPPPMPMGMPMPPMPGPMPAPVPMPAPAG
LTEFemto33MGGPMMPMPPMMGPMPMGPMMPMGPMGMPMPMPPMPPMMPMMPMMGMPMMPVPMAG
LTEFemto34PMPPPPMMPMMGGMPMMPMPMPMMGPGMPMPMPMMMPMPMGPMPPVPMMPGVPPPAPMPVG
LTEFemto35PMPPPMPMPPGGGMGPMPPMGGGMGMPMPMPMGMPPPMPMPMPPMPPGPMPMPVPMPPAG
LTEFemto36MMGGMPMGPPMMGMPMPMPMPMPMPMPPGMPMPPPMPMVPPPMPPMMVPPVPPPAPVG
LTEFemto37PMPGPMMPMGGMPMMMGPPMPMPPMPMGMMMGMPMPMMGGPMPMPPMPMMGPMPVPPAPVPVG
169
TableB4TheavailableWiMAXandWAVEnetworksofSLA2,SLA3andSLA4.
SLA2SLA3SLA4
CVBSWebBSWebWeb
Network
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Secutiy
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
Throughput
Delay
Jitter
PacketLoss
ServiceReliability
Security
Price
WiMAXMacro1MPMMPPPPGGGMGGMPMMGMPMPMGMGPMMGMGMPPMPGMMGMPMPMPGAPVPAPAPMVPG
WiMAXMacro2GGMGMGGMGPPMPPPMMPPMMGMPMPMPMPPMPPPPMPMMMGMPMPMPMMMAPMPPPAG
WiMAXMacro3MGGMGMGMPPPMPPPPPMPMPPPMMMPMPPPPPMGPMPPPMPMGVPPVPAPAPMPG
WiMAXMacro4MMGPMPPPMPMPMMGPMGGMPMGGMPMMPGMPMPMMGPMPMMMGMGMPMPMGAPVPVPAPPMPG
WiMAXMacro5MPMMPPGPMPMPMPPMGGMPMGGMMMMPPMPMPPMPMPMGPMPMPMPPMAPVPPAPAPVPAG
WiMAXMacro6MPMGPGMMGGMMGPMPMMMGMPMPMGPMPMGMMMPMPMGMMGMPMPPPMVPPMPAPPAPVG
WiMAXMacro7MMGMGMPMGMPPMGGMMMGMGMPMPMPPMGMPMPMPPMPMPMMPMPPPPMGPMPAPVPMPAPAG
WiMAXMacro8MMGMMPGMPMPMMGGMPMPMPMPMMPPPMGPMMMMPMPPMMPMMPPPPMGPMPMPVPPVPAG
WiMAXMacro9MMGMMPGMMMPMPPMPPPMPMMPPMPGPMPMPPMPPGMPMPPPMPMGMPMVPPAPAPVG
WiMAXMacro10PMPMGPMGMMPMPMMPMPMPPPMPMGPGMPMPMPMMPMPMPMPMPMGPPPMGPMPAPVPPPG
WiMAXMacro11MPMPPGMMPPMPGPGMPMMMGMGMPPMGMPMMGMMPMPMPGPMPMPPMPPMVPPVPAPMPPAG
WiMAXMacro12MGGMMPMGMPMPGPGMGPPMPGPPMPMPMPMPPMPMGVPPPPPMPMAPVPPAPAPVPG
WiMAXMacro13MPMMPPGMPMMGGMPPMGPMPMMPPGMGMPMPMPPMGGPMPMPPMPMGPMPMPVPMVPVG
WiMAXMacro14MPMMGPMGMPMPGPMGMPMGGMPMGMPMVPPMGPMPMMMGPMPMPMPMGPMPVPVPMPAPG
WiMAXMacro15MGGPMPPMPMPPPMGMMPPMPGPMMPMPPMPPPPMPGPMPMPPMPGVPPVPAPPAPAG
WiMAXMacro16MPMPPMGMGMPGGMPMGGGMMGGMMMPMMPMMGMPMPMPMPMMGMGMMPMGPMPAPVPPMPVG
WiMAXMacro17MGGMPMPMPMGGMGMGMMPMPMMGMGMPMGMGMPMMGMPMPMMPGPMPPVPMGMGMGPMPAPVPPVPG
WiMAXFemto1MPMMGPGMGPMMGMMPMGMGMPGGMMGGMGPMMGMPMPPMGMMPMMPMPMPMGAPVPMAPVPPAG
WiMAXFemto2MMGMPMPMPMPMGGMMMPMPMPMGGPMPMGPPMPMPPMPMPMMPMPPPPGMPMAPPVPAPVG
WiMAXFemto3PMPMPPGMMMGGMMPMPMPMPMMPMMMPPMPMPPPPGMPMMPMMMVPPPAPAPPAG
WiMAXFemto4GGPMGMPPMPPMPMPPPMGPGGGMGPMPPPMPPPPMPMMMGMPMPPMPMMPMPPAPPVG
WiMAXFemto5GGMPMGMGMMMGPMPMPPPMPMMPPPMMPMMGPMPPPMMPMMPPPMGPMPAPPAPVPG
WiMAXFemto6MMGMMPMPMPMMGMGMPPMGMMPMGPMMPMMMGMPMPPMMGMPMMPPMPGAPVPVPAPMPPVG
WiMAXFemto7MMGMGMPMGMMPMPPPMGPMMGGMPMMGMMPMPPPPPGMPMMPPMMGVPPMPAPPVPVG
WiMAXFemto8GGMMGPMPMPMGGMMMPGMPPMPMPMPMMPPMPPPMPPMPMPPPMPMMGPMPVPVPMPPAG
WiMAXFemto9MGGGMPMPPMPMMGPMGPPPMPMPGGPMPMPPMPPGPMPMVPMGPMAPVPMAPMPVPG
WiMAXFemto10MGGMPMMPMPMMPMGPMMPMPPMPPPMGMGMMPMMPMMPGPMPPPMGMMVPPAPAPPPAG
WiMAXFemto11MMGMMPMGMPGGPMGMPMPPMPMMPMMPMPMGMGPMMPMPMGMPMMPMPMPGAPVPMAPVPVPAG
WiMAXFemto12MPMMGPGGPMMGGMPGMGPMPMMPMMPMPMPMPPMPMGGMPMMPMPPMAPVPMPAPMPPAG
WiMAXFemto13GGMGMGGPMPGGPMGGMGPMPMMGPMPMPPMMGPMPPMGGMPMPPMPMPMPMPPVPMPAPVG
WiMAXFemto14MPMPPMGPMMGMPMPMPGMPMPMMPPGPMMGMPMPPMGMGPMPMPPPMVPPAPVPAPAPAG
WiMAXFemto15GGMMGMPMPMMPMPPMGMPPGGMPMGMGPMMPMPPMGMPGMMGMPMPMPPGMMMPMPMPVPG
WiMAXFemto16GGMGMGGMGMPPMPMPMGPPMMGMGMPMMPMPMPMPPPMMMGMGMPMMPMGVPPMPAPAPAPVG
WiMAXFemto17MGGPMGMPPMPMPPPPMPGGMPMGMPPMMPMPPVPPGPMPMPPMPPMVPPAPAPPVPG
WiMAXFemto18GGGMGPMPPMMGMPMPPMPMGGMGMGMMMPPMPVPPPPMPMPMPPMPMGPMPVPPVPPAG
WiMAXFemto19MGGMPMMGMPPMPMGPMMPMMPMMPPGMPMPMPMGPMMPMPMPPPPPMPMPPVPPPVG
WiMAXFemto20MGGMGMMMGPMPMMPPGPMPMPMPPPMPMPMPMMPPMGPMPMPPPPMPMGPMPPPVPAPG
WiMAXFemto21PMPPPMPMGGMMGPMPMMGMPMPMGMPMGMGPMPMPGMMGMPMPMPMMMMVPMPMPPAG
WiMAXFemto22PMPPPGPMPMPGPPGMPMMGPMPPPMPPMPMPPMGMGPMPPPPPMGPMPAPVPVPAPAG
WiMAXFemto23MGGMGMGMGPMGGMPMMMPMGGMMMGMGMMMGMPMPMPMGMMGMPMPMMGMGPMPPVPAPAPVG
WiMAXFemto24MGGMPMMMPMMPMMGPPPMMMGPMPGMMMPMMGPPPMGMPMPPMGMGMPMPPAPMPAG
WiMAXFemto25MGGMMGPMPMGGMMMGMGPMPMMPGMGMMGMPMMGMPMPMPMPMGMMGVPPPAPAPMPAG
WAVE1MGGMPMMGGMPPMPMPPMPMPMPMMPMGPMPMPMPPMPMMGPMPMVPMPPGPMPMVPVPPG
WAVE2MMGPMPPMMPMPGPGGPMMGMGMPPMPMPPMPMPVPMPMPGMPMMPPMPMGVPPMPAPAPMPAG
WAVE3MMGMPMPGMPMPMPMMPMGGPMPMGPMPMGPMPMMPPMPMMGMPMMPPMGMAPVPMAPVPPAG
WAVE4GGMMGMMGPMPMGPGPMPMMGMMPGGPMPMPMPPPMPMPMPMPMPMVPPMAPAPAPAG
WAVE5MGGMPMMGPPPMPGPMPMGMMPMMGPMPPPMPMPPMPPGMPMMPPPGVPPPAPPAPVG
WAVE6MMGGMPMGPMMGMMPMGGMPPMPGPMPPMMPMPPMGMGPMPMGPMPPGPMPPVPVPVPAG
WAVE7PMPMGPPMPPMGGMGMMMPMPMPMMGPMGMPPMMGMGMPPMPGPMPPVPMGMPMVPPVPVPMPMPG
WAVE8GGPMGPMMPMGGMMPMMPGGGMGPMPMPMMMPMPPMGPMPMVPPMPGPMPPVPAPMPG
WAVE9MPMPPMPMMGGPMGMPGPPMPMPPPMGMMGMPMMPMMPMPMPPPPGVPPAPPVPPAG
WAVE10GGMPMGMGMPMMPMMPPMGGPPMPGPGMPPMPMMPPMGMPGPMPMPPPMPMGPMPVPVPPAPVG
WAVE11MPMPPMPMGMMPMMGPMPMGGMMGGMPMPMMPPPMGMGMGMMMPMPGMMMMPPVPG
WAVE12MMGMGMPGPMPMMGMGMPMGGPMGGMPMGGMMMMPMPMMGGMMGMPMPMGMPMMMMPMPVPMPVG
WAVE13GGGMGMPGPGGMGMGMGGPGGMMGMGMPPMGMGPMMGMPGPMPMPMPPMVPPMAPMPPAG
WAVE14GGMPMGMMGMPPMPGPGPPMMGMPMPPGMPMPPPMGPMGMPMMPPPPMGVPPVPAPAPVPAG
WAVE15PMPGPMPMMPMGPPMPMPPMPMGPGMPMPMPMMPPMPMGPMPPPMPMPMPMPVPVPAPVPAG
WAVE16GGPMGMGMGMMPMMPMGPPMMGMPMPPGMMPMPPMGPGMPMMPPPMMMPMVPPAPVPG
WAVE17PMPPPMGMMMMGMGMPMMPMMGGMGMMPMPMPMPMMPPMMPMGMPMMPMPMPGPMPPVPAPAPAG
WAVE18MGGMPMGGMPMGGMGMMPMPMPMPMPMPGMPMPMGPPMPMPMPPPMPMPMAPVPPAPAPMPAG
WAVE19MMGMMPMGMPMMPMMPPMPPMGGGMPMPPMPMPPMPPMMPMMPPPMPMGAPVPMPAPAPVPG
WAVE20MMGPMPMPPPMPMPPGMMPMMGGMPGMPPPMPPPMGMPMGMMGPMPMPMPMPMPAPVPVPPAG
WAVE21GGMMGMPMGMPMMGPMPGGPMPMPPMMMPPPPMMMMPMPPMMGMPMVPPVPPVG
WAVE22GGMMGMGMGMMGGGMGMMMPMMGPGMGPPMPPPMGMPMMPMMPMMMGVPPAPAPPMVG
Performance Analysis and Optimization of Next Generation Wireless Networks
Appendix C
The distribution of vehicles during the 24
hours simulation
In this appendix the distribution of vehicles across velocity categories, access networks, services
and SLAs, during the 24 hours simulation is presented.
172 The distribution of vehicles during the 24 hours simulation
Table C1 Number of vehicles that start from each LTE network and their corresponding
velocities. Network Number of vehi-
cles (%)
Normal
velocity
Medium
velocity
High
velocity
LTE Macro 1 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 2 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 3 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 4 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 5 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 6 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 7 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 8 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 9 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 10 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 11 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 12 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 13 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 14 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 15 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 16 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 17 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 18 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 19 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Macro 20 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 1 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 2 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 3 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 4 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 5 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 6 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 7 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 8 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 9 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 10 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 11 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 12 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 13 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 14 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 15 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 16 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 17 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 18 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 19 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 20 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%)
LTE Femto 21 329 (0,82648%) 110 (0,27633%) 110 (0,27633%) 109 (0,27382%)
LTE Femto 22 329 (0,82648%) 110 (0,27633%) 110 (0,27633%) 109 (0,27382%)
LTE Femto 23 329 (0,82648%) 110 (0,27633%) 110 (0,27633%) 109 (0,27382%)
LTE Femto 24 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 25 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 26 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 27 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 28 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 29 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 30 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 31 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 32 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 33 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 34 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 35 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 36 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
LTE Femto 37 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
173
Table C2 Number of vehicles that start from each WiMAX network and their corresponding
velocities.
Network Number of vehi-
cles (%)
Normal
velocity
Medium
velocity
High
velocity
WiMAX Macro 1 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 2 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 3 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 4 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 5 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 6 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 7 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 8 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 9 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 10 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 11 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 12 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 13 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 14 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 15 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 16 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Macro 17 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 1 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 2 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 3 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 4 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 5 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 6 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 7 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 8 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 9 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 10 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 11 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 12 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 13 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 14 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 15 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 16 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 17 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 18 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 19 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 20 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 21 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 22 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 23 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 24 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WiMAX Femto 25 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
Table C3 Number of vehicles that start from each WAVE network and their corresponding
velocities.
Network
Number of ve-
hicles (%)
Normal
velocity
Medium
velocity
High
velocity
WAVE 1 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 2 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 3 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 4 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 5 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 6 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 7 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 8 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 9 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 10 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 11 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 12 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 13 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 14 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 15 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 16 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 17 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 18 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 19 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 20 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
WAVE 21 328 (0,82397%) 111 (0,27884%) 109 (0,27382%) 108 (0,27130%)
WAVE 22 328 (0,82397%) 111 (0,27884%) 109 (0,27382%) 108 (0,27130%)
174 The distribution of vehicles during the 24 hours simulation
Table C4 Vehicles count per service and SLA.
Services SLA 1
vehicles (%)
SLA 2
vehicles (%)
SLA 3
vehicles (%)
SLA 4
vehicles (%)
Sum
NAV 322
(0,808902%)
- - - 322
(0,808902%)
VoIP 321
(0,806390%)
- - - 321
(0,806390%)
CV 321
(0,806390%)
1422
(3,572236%)
- - 1743
(4,378626%)
BS 321
(0,806390%)
1422
(3,572236%)
3318
(8,335217%)
- 5061
(12,71384%)
WB 321
(0,806390%)
1422
(3,572236%)
3317
(8,332705%)
9951
(24,99811%)
15011
(37,70944%)
NAV,
VoIP
321
(0,806390%)
- - - 321
(0,806390%)
NAV, CV 321
(0,806390%)
- - - 321
(0,806390%)
NAV, BS 321
(0,806390%)
- - - 321
(0,806390%)
NAV, WB 321
(0,806390%)
- - - 321
(0,806390%)
VoIP, CV 321
(0,806390%)
- - - 321
(0,806390%)
VoIP, BS 321
(0,806390%)
- - - 321
(0,806390%)
VoIP, WB 321
(0,806390%)
- - - 321
(0,806390%)
CV, BS 321
(0,806390%)
1422
(3,572236%)
- - 1743
(4,378626%)
CV, WB 321
(0,806390%)
1422
(3,572236%)
- - 1743
(4,378626%)
BS, WB 321
(0,806390%)
1421
(3,569723%)
3317
(8,332705%)
- 5059
(12,7088%)
NAV,
VoIP, CV
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
VoIP, BS
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
VoIP, WB
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
CV, BS
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
CV, WB
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
BS, WB
321
(0,806390%)
- - - 321
(0,806390%)
VoIP,
CV, BS
321
(0,806390%)
- - - 321
(0,806390%)
VoIP,
CV, WB
321
(0,806390%)
- - - 321
(0,806390%)
VoIP,
BS, WB
321
(0,806390%)
- - - 321
(0,806390%)
CV, BS,
WB
321
(0,806390%)
1421
(3,569723%)
- - 1742
(4,376114%)
NAV,
VoIP, CV,
BS
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
VoIP, CV,
WB
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
VoIP, BS,
WB
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
CV, BS,
WB
321
(0,806390%)
- - - 321
(0,806390%)
VoIP,
CV, BS,
WB
321
(0,806390%)
- - - 321
(0,806390%)
NAV,
VoIP, CV,
BS, WB
321
(0,806390%)
- - - 321
(0,806390%)
Sum: 9952
(25,00062%)
9952
(25,00062%)
9952
(25,00062%)
9951
(24,99811%)
39807
(100%)

More Related Content

PDF
Tcl telecom expertise v 2 00 vs 220812
PDF
URLLC for 5G and Beyond: Physical, MAC, and Network Solutions
PPTX
5G Technology
PDF
Aviation 5G/5G in Aviation
PDF
5G’s Impact on Telecom Infrastructure 2019 report by Yole Développement
PDF
5G-Advanced-Technology-Evolution-from-a-Network-Perspective-2021
PPTX
From broadband to 5G
Tcl telecom expertise v 2 00 vs 220812
URLLC for 5G and Beyond: Physical, MAC, and Network Solutions
5G Technology
Aviation 5G/5G in Aviation
5G’s Impact on Telecom Infrastructure 2019 report by Yole Développement
5G-Advanced-Technology-Evolution-from-a-Network-Perspective-2021
From broadband to 5G

What's hot (20)

PDF
COMPARATIVE AND QOS PERFORMANCE ANALYSIS OF TERRESTRIAL-AERIAL PLATFORMS-SATE...
PDF
Summary of Network Security Conference (#NetworkSecurity)
PDF
5g tutorial
PPTX
Jisc's Vision for 5G - Digital Catapult Future of 5G Summit
PDF
Including VoIP over WLAN in a Seamless Next-Generation ...
PDF
Mobile technology g, e, 3 g, 3g +, h, h + or 4g _4g bd _ third and fourth gen...
PDF
Technology trends towards 6G
DOC
39698403 5g
PDF
WiFi_in right perpectives_2018
PDF
ZTE Communication - March 2015
PDF
IPLOOK Technologies(E.V)
PDF
Reporte a cerca de 6G
PDF
5G in Europe 2020
PDF
See the driving force and challenge of 6G in 7 major dimensions - C&T RF Ante...
PDF
Green Future Networks: Network Energy Efficiency
PPTX
Security and Transport Performance in 5G
DOCX
5G technology
PPTX
Noma-5G technology
PDF
5G-Advanced Technology Evolution from a Network Perspective White Paper 2.0
COMPARATIVE AND QOS PERFORMANCE ANALYSIS OF TERRESTRIAL-AERIAL PLATFORMS-SATE...
Summary of Network Security Conference (#NetworkSecurity)
5g tutorial
Jisc's Vision for 5G - Digital Catapult Future of 5G Summit
Including VoIP over WLAN in a Seamless Next-Generation ...
Mobile technology g, e, 3 g, 3g +, h, h + or 4g _4g bd _ third and fourth gen...
Technology trends towards 6G
39698403 5g
WiFi_in right perpectives_2018
ZTE Communication - March 2015
IPLOOK Technologies(E.V)
Reporte a cerca de 6G
5G in Europe 2020
See the driving force and challenge of 6G in 7 major dimensions - C&T RF Ante...
Green Future Networks: Network Energy Efficiency
Security and Transport Performance in 5G
5G technology
Noma-5G technology
5G-Advanced Technology Evolution from a Network Perspective White Paper 2.0
Ad

Similar to Performance Analysis and Optimization of Next Generation Wireless Networks (20)

PDF
Mobility Management on 5G Vehicular Cloud Computing Systems
PDF
NEW TECHNOLOGY FOR MACHINE TO MACHINE COMMUNICATION IN SOFTNET TOWARDS 5G
PDF
NEW TECHNOLOGY FOR MACHINE TO MACHINE COMMUNICATION IN SOFTNET TOWARDS 5G
PDF
8 of the Must-Read Network & Data Communication Articles Published this weeke...
PDF
Michael ghorbanzadeh, ahmed abdelhadi practical channel-aware resource allo...
PDF
Ziyuan Cai Research Statement
PDF
Networking IEEE 2014 Projects
PDF
Networking ieee-2014-projects
PDF
Lv2018
PDF
TOWARD A GENERIC VEHICULAR CLOUD NETWORK ARCHITECTURE: A CASE OF VIRTUAL VEHI...
PDF
An optimum dynamic priority-based call admission control scheme for universal...
PDF
Towards automated service-oriented lifecycle management for 5G networks
PDF
Security schemes based on conditional privacy-preserving vehicular ad hoc net...
PDF
Ijsrp p10274
PDF
Traffic Control System by Incorporating Message Forwarding Approach
PDF
Preprint-CSAE,China,21-23 October 2022.pdf
PDF
Spectral efficient network and resource selection model in 5G networks
PDF
A Network and Position Proposal Scheme using a Link-16 based C3I System
PDF
Rapidly IPv6 multimedia management schemes based LTE-A wireless networks
PDF
Mobility Management on 5G Vehicular Cloud Computing Systems
NEW TECHNOLOGY FOR MACHINE TO MACHINE COMMUNICATION IN SOFTNET TOWARDS 5G
NEW TECHNOLOGY FOR MACHINE TO MACHINE COMMUNICATION IN SOFTNET TOWARDS 5G
8 of the Must-Read Network & Data Communication Articles Published this weeke...
Michael ghorbanzadeh, ahmed abdelhadi practical channel-aware resource allo...
Ziyuan Cai Research Statement
Networking IEEE 2014 Projects
Networking ieee-2014-projects
Lv2018
TOWARD A GENERIC VEHICULAR CLOUD NETWORK ARCHITECTURE: A CASE OF VIRTUAL VEHI...
An optimum dynamic priority-based call admission control scheme for universal...
Towards automated service-oriented lifecycle management for 5G networks
Security schemes based on conditional privacy-preserving vehicular ad hoc net...
Ijsrp p10274
Traffic Control System by Incorporating Message Forwarding Approach
Preprint-CSAE,China,21-23 October 2022.pdf
Spectral efficient network and resource selection model in 5G networks
A Network and Position Proposal Scheme using a Link-16 based C3I System
Rapidly IPv6 multimedia management schemes based LTE-A wireless networks
Ad

More from University of Piraeus (20)

PDF
A Route Selection Scheme for supporting Virtual Tours in Sites with Cultural ...
PPTX
A Route Selection Scheme for supporting Virtual Tours in Sites with Cultural ...
PDF
A VHO Scheme for supporting Healthcare Services in 5G Vehicular Cloud Computi...
PDF
A Network Selection Scheme with Adaptive Criteria Weights for 5G Vehicular Sy...
PDF
A Network Selection Algorithm for supporting Drone Services in 5G Network Arc...
PPTX
A Network Selection Algorithm for supporting Drone Services in 5G Network Arc...
PDF
A Survey on Medium Access Control Schemes for 5G Vehicular Cloud Computing Sy...
PPTX
A Survey on Medium Access Control Schemes for 5G Vehicular Cloud Computing Sy...
PDF
The enhancement of Underwater Cultural Heritage Assets using Augmented Realit...
PPTX
Performance Analysis and Optimization of Next Generation Wireless Networks (P...
PDF
Personalized Real-Time Virtual Tours in Places with Cultural Interest
PPTX
The Convergence of Blockchain, Internet of Things (IoT) and Building Informat...
PDF
The convergence of blockchain, internet of things (io t) and building informa...
PPTX
The revival of back-filled monuments through Augmented Reality (AR) (presenta...
PDF
An analytic network process and trapezoidal interval-valued fuzzy technique f...
PPT
A Personalized Audio Web Service using MPEG-7 and MPEG-21 standards (presenta...
PPT
A Personalized Audio Server using MPEG-7 and MPEG-21 standards (presentation)
PPTX
A downlink scheduler supporting real time services in LTE cellular networks (...
PDF
A Vertical Handover Management Scheme for VANET Cloud Computing Systems
PPTX
QoS-aware scheduling in LTE-A networks with SDN control (presentation)
A Route Selection Scheme for supporting Virtual Tours in Sites with Cultural ...
A Route Selection Scheme for supporting Virtual Tours in Sites with Cultural ...
A VHO Scheme for supporting Healthcare Services in 5G Vehicular Cloud Computi...
A Network Selection Scheme with Adaptive Criteria Weights for 5G Vehicular Sy...
A Network Selection Algorithm for supporting Drone Services in 5G Network Arc...
A Network Selection Algorithm for supporting Drone Services in 5G Network Arc...
A Survey on Medium Access Control Schemes for 5G Vehicular Cloud Computing Sy...
A Survey on Medium Access Control Schemes for 5G Vehicular Cloud Computing Sy...
The enhancement of Underwater Cultural Heritage Assets using Augmented Realit...
Performance Analysis and Optimization of Next Generation Wireless Networks (P...
Personalized Real-Time Virtual Tours in Places with Cultural Interest
The Convergence of Blockchain, Internet of Things (IoT) and Building Informat...
The convergence of blockchain, internet of things (io t) and building informa...
The revival of back-filled monuments through Augmented Reality (AR) (presenta...
An analytic network process and trapezoidal interval-valued fuzzy technique f...
A Personalized Audio Web Service using MPEG-7 and MPEG-21 standards (presenta...
A Personalized Audio Server using MPEG-7 and MPEG-21 standards (presentation)
A downlink scheduler supporting real time services in LTE cellular networks (...
A Vertical Handover Management Scheme for VANET Cloud Computing Systems
QoS-aware scheduling in LTE-A networks with SDN control (presentation)

Recently uploaded (20)

PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
PDF
Machine learning based COVID-19 study performance prediction
PPTX
Big Data Technologies - Introduction.pptx
PDF
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
PDF
Encapsulation theory and applications.pdf
PDF
Peak of Data & AI Encore- AI for Metadata and Smarter Workflows
PDF
Diabetes mellitus diagnosis method based random forest with bat algorithm
PPTX
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
PPTX
MYSQL Presentation for SQL database connectivity
PDF
Approach and Philosophy of On baking technology
PDF
Bridging biosciences and deep learning for revolutionary discoveries: a compr...
PDF
Electronic commerce courselecture one. Pdf
PDF
Chapter 3 Spatial Domain Image Processing.pdf
PDF
The Rise and Fall of 3GPP – Time for a Sabbatical?
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
PDF
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
PPTX
20250228 LYD VKU AI Blended-Learning.pptx
PDF
Empathic Computing: Creating Shared Understanding
PPTX
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
PDF
Network Security Unit 5.pdf for BCA BBA.
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Machine learning based COVID-19 study performance prediction
Big Data Technologies - Introduction.pptx
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
Encapsulation theory and applications.pdf
Peak of Data & AI Encore- AI for Metadata and Smarter Workflows
Diabetes mellitus diagnosis method based random forest with bat algorithm
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
MYSQL Presentation for SQL database connectivity
Approach and Philosophy of On baking technology
Bridging biosciences and deep learning for revolutionary discoveries: a compr...
Electronic commerce courselecture one. Pdf
Chapter 3 Spatial Domain Image Processing.pdf
The Rise and Fall of 3GPP – Time for a Sabbatical?
Mobile App Security Testing_ A Comprehensive Guide.pdf
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
20250228 LYD VKU AI Blended-Learning.pptx
Empathic Computing: Creating Shared Understanding
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
Network Security Unit 5.pdf for BCA BBA.

Performance Analysis and Optimization of Next Generation Wireless Networks

  • 1. Performance Analysis and Optimization of Next Generation Wireless Networks Emmanouil Skondras Three-member advisory committee Assoc. Prof. Dimitrios D. Vergados (Supervisor) Prof. Angelos Michalas Prof. Christos Douligeris Department of Informatics School of Information and Communication Technologies University of Piraeus This dissertation is submitted for the degree of Doctor of Philosophy University of Piraeus April 2019
  • 3. Performance Analysis and Optimization of Next Generation Wireless Networks PhD Thesis of Emmanouil Skondras (Submitted at University of Piraeus, School of Information and Communication Technologies, Department of Informatics, April 2019) Seven-member PhD evaluation committee 1. Dimitrios D. Vergados, Associate Professor, University of Piraeus 2. Angelos Michalas, Professor, Technological Education Institution of Western Macedonia 3. Christos Douligeris, Professor, University of Piraeus 4. George Tsihrintzis, Professor, University of Piraeus 5. Konstantinos Oikonomou, Associate Professor, Ionian University 6. Ioannis Anagnostopoulos, Associate Professor, University of Thessaly 7. Stavros Kotsopoulos, Professor, University of Patras April 22, 2019
  • 5. I would like to thank Assoc. Prof. Dimitrios D. Vergados for his supervision, knowledge, support and persistent encouragement during my PhD at Department of Informatics, School of Information and Communication Technologies, University of Piraeus. I could not have imagined having a better mentor for my PhD study. Also, I would like to thank my advisor Prof. Angelos Michalas for his guidance and expertise. His discussion, ideas and feedback have been invaluable and this work would not have been possible without his input. Furthermore, I would like to express my sincere gratitude to my advisor Prof. Christos Douligeris for the continuous support of my PhD study and the related research. His guidance helped me in all the time of research and writing of this thesis. I would also like to thank my family for their constant support and encouragement over the years. They have been there for me and I am thankful for everything they helped me achieve. A special note of appreciation to my fiancée Eirini Zoumi. I would like to express my gratitude for putting her faith in me and supporting me in every possible way.
  • 7. Acknowledgements The publications made in the context of this PhD thesis have been partly supported by the University of Piraeus Research Center (UPRC) and the Technological Educational Institute of Western Macedonia.
  • 9. Abstract The Fifth Generation (5G) networks, including the 5G Vehicular Cloud Computing (5G-VCC) systems, have evolved rapidly offering multiple services to users. The operating principles of vehicular networks, Cloud Computing (CC), Fog Computing (FC), Mobile Edge Computing (MEC) and Software Defined Networks (SDN) are applied to 5G infrastructures. In a 5G-VCC system, the vehicles are equipped with On-Board Units (OBUs) which communicate with each other as well as with Road Side Units (RSUs). Each RSU interacts with a Cloud infrastructure which offers vehicular services with strict Quality of Service (QoS) requirements, including Driver Assistance (DA), Passengers Entertainment and Information (PEnI) and Medical (MED) services. Dense deployments of 5G access networks are also implemented, called Ultra Dense Networks (UDNs), aiming to support high data rates produced by an increased number of vehicular users. In this environment, heterogeneous technologies are used to transfer the network services to vehicles. Optimal manipulation of the communication resources is required, while at the same time vehicular users should always obtain connectivity to the most appropriate network access technology, in order the constraints of the vehicular services to be satisfied. In this thesis, existing schemes for resource allocation as well as for mobility management are studied, while novel solutions are proposed for each topic. Initially, the theoretical background of the 5G wireless networks and 5G-VCC systems is described. Subsequently, the available delivery models for providing cloud services in 5G infrastructures are mentioned, while the available 5G-VCC architectures and the communication models are presented. Regarding the topic of the manipulation of the available network resources in 5G-VCC systems, the available Medium Access Control schemes (MAC schemes) are studied, while at the same time resource scheduling algorithms implemented at the MAC layer of 5G-VCC systems are described. Subsequently, two novel solutions are proposed to optimize the resource allocation process in modern networks. The first one is called FLS Advanced (FLSA) and opti- mizes the resource allocation for real-time services. Additionally, the second one is called FLS Advanced - Cross Carrier (FLSA-CC) and is specialized for LTE-Advanced (LTE-A) access networks where carrier aggregation is applied in order to provide widened bandwidth to the
  • 10. x users. The evaluation of the proposed algorithms is performed through extended experiments. Simulation results show that the proposed algorithms outperform existing solutions. The mobility management requirements arising at the 5G-VCC systems are also studied. As a result of this study, initially three methods for calculating the significance of the criteria affecting the mobility management are proposed, namely the Trapezoidal Fuzzy Analytical Network Process (TF-ANP), the Trapezoidal Fuzzy Adaptive Analytical Network Process (TF-AANP) and the Pentagonal Fuzzy Analytical Network Process (PF-ANP). Subsequently, three network selection algorithms are proposed, namely the Trapezoidal Fuzzy TOPSIS (TFT), the Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW) and the Pentagonal Fuzzy TOPSIS (PFT). Following this study and regarding the research results of the implemented algorithms, a mobility management scheme is proposed. This scheme takes into consideration the Signal to Noise plus Interference (SINR) parameters as well as the velocity of the vehicular users to evaluate the necessity of performing a handover. Then, it applies the PFT algorithm to select the most appropriate network for the user. Experimental results showed that the proposed scheme outperforms the existing solutions described in the research literature.
  • 11. Περίληψη Η μελέτη της διατριβής εντάσσεται στην ερευνητική περιοχή των ασύρματων τηλεπικοινω- νιακών συστημάτων και ειδικότερα των δικτύων Πέμπτης Γενιάς (Fifth Generation -5G). Τα δίκτυα 5G, συμπεριλαμβανομένων των συστημάτων 5G Vehicular Cloud Computing (5G- VCC) , έχουν εξελιχθεί με ταχείς ρυθμούς προσφέροντας πολλαπλές σύγχρονες υπηρεσίες στους χρήστες. Σε μία υποδομή 5G, συνηθίζεται να εφαρμόζονται οι αρχές λειτουργίας που διέπουν τα οχηματικά δίκτυα, το Cloud Computing (CC) , το Fog Computing (FC) , το Mobile Edge Computing (MEC) και τα Software Defined Networks (SDN) . Επιπρόσθε- τα, σε ένα σύστημα 5G-VCC, τα οχήματα είναι εξοπλισμένα με υπολογιστικές μονάδες επί του οχήματος (On Board Units - OBU) οι οποίες επικοινωνούν μεταξύ τους καθώς και με υπολογιστικές μονάδες εγκατεστημένες δίπλα στο οδικό δίκτυο (Road Side Units - RSU). Κάθε μονάδα RSU αλληλεπιδρά με μία υποδομή Cloud, η οποία προσφέρει υπηρεσίες με αυστηρές απαιτήσεις ως προς την Ποιότητας της Υπηρεσίας (Quality of Service - QoS). Ενδεικτικά, υπηρεσίες υποστήριξης του οδηγού (Driver Assistance - DA) , υπηρεσίες ψυχα- γωγίας και ενημέρωσης των επιβατών (Passengers Entertainment and Information - PEnI) , καθώς και ιατρικές υπηρεσίες (Medical - MED) συνηθίζεται να παρέχονται στα οχήματα από την προαναφερθείσα υποδομή Cloud. Επίσης, σε μία αρχιτεκτονική 5G, συνηθίζεται η ανάπτυξη πυκνών υποδομών πρόσβασης στο δίκτυο, οι οποίες αναφέρονται ως Ultra Dense Networks (UDN) . ΄Ενα UDN αναπτύσσεται με στόχο την υποστήριξη των υψηλών ρυθ- μών δεδομένων που παράγονται από τον αυξημένο αριθμό οχηματικών χρηστών. Στο εν λόγω περιβάλλον ασύρματης πρόσβασης χρησιμοποιούνται ετερογενείς τεχνολογίες για τη μεταφορά των δικτυακών υπηρεσιών από το Cloud στα οχήματα. ΄Οπως γίνεται σαφές, απαιτείται βέλτιστος χειρισμός των τηλεπικοινωνιακών πόρων, ενώ ταυτόχρονα οι χρήστες των οχημάτων θα πρέπει πάντα να αποκτούν συνδεσιμότητα με την καταλληλότερη τεχνολογία πρόσβασης στο δίκτυο, προκειμένου να ικανοποιούνται οι περιορισμοί των υπηρεσιών που χρησιμοποιούν. Στο πλαίσιο της παρούσας διδακτορικής διατριβής μελετώνται τα μοντέλα κατανομής πόρων, καθώς και τα μοντέλα διαχείρισης της κινητικότητας των χρηστών, που έχουν προ- ταθεί από την ερευνητική κοινότητα, ενώ νέες βελτιστοποιημένες λύσεις προτείνονται για κάθε ένα από τα εν λόγω ζητήματα. Συγκεκριμένα, αρχικά αναλύεται το θεωρητικό υ-
  • 12. xii πόβαθρο στο οποίο βασίζεται η διατριβή. Περιγράφονται οι βασικές αρχές που διέπουν τα συστήματα 5G, και πραγματοποιείται μνεία στα συστήματα 5G Vehicular Cloud Computing (5G-VCC). Πραγματοποιείται επίσης μία επισκόπηση των διαθέσιμων μοντέλων παροχής υπηρεσιών υπολογιστικού νέφους, καθώς και κατηγοριοποίησή τους. Ακολούθως, πραγ- ματοποιείται εκτενής επισκόπηση των ασύρματων δικτύων 5G, με έμφαση στα συστήματα 5G-VCC που έχουν προταθεί στην ερευνητική βιβλιογραφία, όπου αναλύονται οι αρχιτε- κτονικές τους, τα μοντέλα επικοινωνίας μεταξύ των συστατικών τους, καθώς και οι αρχές που εφαρμόζονται για την διάθεση των υπηρεσιών που αυτά προσφέρουν. Στη συνέχεια, εξετάζεται ο τομέας της διαχείρισης των δικτυακών πόρων των ασύρμα- των δικτύων επόμενης γενιάς, συμπεριλαμβανομένων των δικτύων 5G και των συστημάτων 5G-VCC. Στο πλαίσιο της μελέτης αυτής, προτείνονται δύο νέοι αλγόριθμου χρονοπρο- γραμματισμού για ασύρματα δίκτυα 5G. Συγκεκριμένα, αρχικά προτείνεται ο αλγόριθμος χρονοπρογραμματισμού FLS Advanced (FLSA) , ο οποίος βελτιστοποιεί την εξυπηρέτηση υπηρεσιών πραγματικού χρόνου. Στη συνέχεια προτείνεται ο αλγόριθμος χρονοπρογραμμα- τισμού FLS Advanced - Cross Carrier (FLSA-CC) ο οποίος αποτελεί εξέλιξη του αλγορίθμου FLSA του οποίου η εφαρμογή εξειδικεύεται για δίκτυα LTE-Advanced (LTE-A) όπου πραγ- ματοποιείται συνένωση πολλαπλών φερουσών συχνοτήτων (carrier aggregation) με σκοπό τη διεύρυνση του διαθέσιμου εύρους ζώνης. Εξετάζεται επίσης ο τομέας της διαχείρισης της κινητικότητας των χρηστών ασύρματων δικτύων επόμενης γενιάς. Αρχικά, πραγματοποιείται μελέτη των απαιτήσεων που υπάρ- χουν στα ασύρματα δίκτυα 5G, με έμφαση στα συστήματα 5G-VCC, ως προς τη διαχείριση της κινητικότητας των χρηστών. Ακολούθως, προτείνεται ένα σύνολο μεθόδων για τον υπολογισμό της σημαντικότητας των κριτηρίων που μπορεί να ληφθούν υπόψη κατά τη δι- άρκεια της διαχείρισης της κινητικότητας των χρηστών. Οι εν λόγω μέθοδοι αναφέρονται ως Trapezoidal Fuzzy Analytic Network Process (TF-ANP), Trapezoidal Fuzzy Adaptive Analytic Network Process (TF-AANP) και Pentagonal Fuzzy Analytic Network Process (PF-ANP) . Επίσης, προτείνεται ένα σύνολο αλγορίθμων που αφορούν την επιλογή του καταλληλότερου δικτύου πρόσβασης για τον εκάστοτε χρήστη, οι οποίοι αναφέρονται ως Trapezoidal Fuzzy TOPSIS (TFT), Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW) και Pentagonal Fuzzy TOPSIS (PFT). Ως αποτέλεσμα της εν λόγω έρευνας, προτείνεται ένα νέο μοντέλο, το οποίο εξειδικεύεται στη διαχείριση της κινητικότητας των χρηστών που αλληλοεπιδρούν με συστήματα 5G-VCC. Το μοντέλο αυτό, λαμβάνει υπόψη το Signal to Noise plus Interference (SINR) καθώς και την ταχύτητα κίνησης του χρήστη, ώστε να αξιολογήσει την ανάγκη πραγματοποίησης διαπομπής, ενώ στη συνέχεια εφαρμόζει τον αλγόριθμο PFT για την επιλογή του καταλληλότερου δικτύου για τον χρήστη. Το μο- ντέλο αξιολογείται ενδελεχώς μέσω προσομοιώσεων, μέσω των οποίων αποδεικνύεται ότι
  • 13. xiii βελτιστοποιεί τη διαχείριση της κινητικότητας των χρηστών ξεπερνώντας τις υπάρχουσες λύσεις που περιγράφονται στη βιβλιογραφία.
  • 15. Contents List of Figures xix List of Tables xxiii 1 Introduction 1 1.1 Delivery Models for Cloud Services . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Software as a Service (SaaS) based Delivery Models . . . . . . . . . 4 1.1.2 Platform as a Service (PaaS) based Delivery Models . . . . . . . . . 5 1.1.3 Infrastructure as a Service (IaaS) based Delivery Models . . . . . . . 5 1.1.4 Comparison of the Delivery Models . . . . . . . . . . . . . . . . . . 5 1.2 5G Vehicular Cloud Computing Systems (5G-VCC) . . . . . . . . . . . . . . 7 1.2.1 5G-VCC Architectures . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.1.1 Vehicular Cloud (VC) . . . . . . . . . . . . . . . . . . . . 7 1.2.1.2 Vehicles using Cloud (VuC) . . . . . . . . . . . . . . . . . 8 1.2.1.3 Vehicles using Fog (VuF) . . . . . . . . . . . . . . . . . . 8 1.2.1.4 Software Defined Vehicular Architectures (SDN-V) . . . . 9 1.2.1.5 Hybrid Vehicular Architectures (HVA) . . . . . . . . . . . 10 1.2.2 Communication Models for 5G-VCC Systems . . . . . . . . . . . . 11 1.2.2.1 Vehicle to Vehicle (V2V) . . . . . . . . . . . . . . . . . . 11 1.2.2.2 Vehicle to Infrastructure (V2I) . . . . . . . . . . . . . . . 12 1.2.2.3 Vehicle to Pedestrian (V2P) . . . . . . . . . . . . . . . . . 12 1.2.2.4 Hybrid Vehicular Communication (HVC) . . . . . . . . . . 12 1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4 Thesis Novelty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 Resource Allocation - Scheduling 15 2.1 Medium Access Control (MAC) Schemes for 5G-VCC systems . . . . . . . . 15 2.1.1 Time Division Multiple Access (TDMA) based MAC Schemes . . . . 15
  • 16. xvi Contents 2.1.2 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) based MAC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.3 Hybrid MAC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.4 Discussion on MAC Schemes for 5G-VCC Systems . . . . . . . . . 20 2.2 Overview of Downlink Packet Schedulers . . . . . . . . . . . . . . . . . . . 21 2.2.1 Non-QoS Aware Schedulers . . . . . . . . . . . . . . . . . . . . . . 21 2.2.2 QoS Aware Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3 The Proposed FLS Advanced (FLSA) Scheduler . . . . . . . . . . . . . . . . 25 2.3.1 The Upper Level of the Scheduler . . . . . . . . . . . . . . . . . . . 26 2.3.2 The Middle Level of the Scheduler . . . . . . . . . . . . . . . . . . . 26 2.3.3 The Lower Level of the Scheduler . . . . . . . . . . . . . . . . . . . 26 2.3.4 Performance Evaluation of the FLSA . . . . . . . . . . . . . . . . . 26 2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler . . . . . 32 2.4.1 Simulation Environment for the FLSA-CC Evaluation . . . . . . . . 33 2.4.2 Performance Evaluation of the FLSA-CC Algorithm . . . . . . . . . 34 2.4.2.1 Real Time Services Results . . . . . . . . . . . . . . . . . 35 2.4.2.2 Best Effort Services Results . . . . . . . . . . . . . . . . . 38 3 Mobility Management 39 3.1 Related Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.1.1 Fuzzy Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.1.1.1 The Interval-Valued Trapezoidal Fuzzy Numbers (IVTFN) 39 3.1.1.2 The Interval-Valued Pentagonal Fuzzy Numbers (IVPFN) . 40 3.1.1.3 Creating Fuzzy Numbers: The Equalized Universe Method (EUM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1.1.4 The Mamdani Pentagonal Fuzzy Inference System (MPFIS) 41 3.1.2 Estimating the Mobility Management Criteria Importance . . . . . . 43 3.1.2.1 The Analytic Network Process (ANP) . . . . . . . . . . . 43 3.1.3 The Trapezoidal Fuzzy Analytic Network Process (TF-ANP) . . . . . 45 3.1.3.1 The Trapezoidal Fuzzy Adaptive Analytic Network Process (TF-AANP) . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1.3.2 The Pentagonal Fuzzy Analytic Network Process (PF-ANP) 49 3.1.4 Network Selection Methods . . . . . . . . . . . . . . . . . . . . . . 52 3.1.4.1 The Trapezoidal Interval-Valued Fuzzy TOPSIS (TFT) . . 52 3.1.4.2 The Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW) . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.1.4.3 The Pentagonal Fuzzy TOPSIS (PFT) . . . . . . . . . . . . 57
  • 17. Contents xvii 3.1.5 Evaluation of the Proposed Methods . . . . . . . . . . . . . . . . . . 59 3.1.5.1 Network Selection using the ANP and the TFT Algorithms 59 3.1.5.1.1 Simulation Setup . . . . . . . . . . . . . . . . . 59 3.1.5.1.2 Performance Evaluation . . . . . . . . . . . . . . 61 3.1.5.1.3 Sensitivity Analysis . . . . . . . . . . . . . . . . 66 3.1.5.2 Network Selection using the TF-ANP and the TFT Algo- rithms for supporting Medical Services . . . . . . . . . . . 75 3.1.5.2.1 Simulation Setup . . . . . . . . . . . . . . . . . 75 3.1.5.2.2 Performance Evaluation . . . . . . . . . . . . . . 75 3.1.5.3 Network Selection using the TF-AANP and the TFT-ACW Algorithms for supporting Medical Services . . . . . . . . 79 3.1.5.3.1 Simulation Setup . . . . . . . . . . . . . . . . . 79 3.1.5.3.2 Performance Evaluation . . . . . . . . . . . . . . 83 3.2 Mobility Management Schemes for 5G Wireless Networks . . . . . . . . . . 87 3.2.1 Existing Mobility Management Schemes . . . . . . . . . . . . . . . 87 3.2.2 Taxonomy of Existing Mobility Management Schemes . . . . . . . . 100 3.2.2.1 Control Entities . . . . . . . . . . . . . . . . . . . . . . . 100 3.2.2.1.1 Vehicle Controlled Mobility Management . . . . 100 3.2.2.1.2 Network Controlled Mobility Management . . . . 100 3.2.2.1.3 Hybrid Controlled Mobility Management . . . . 101 3.2.2.1.4 Discussion on Mobility Management Control Entities101 3.2.2.2 Message Exchange Models . . . . . . . . . . . . . . . . . 103 3.2.2.2.1 Information Centric . . . . . . . . . . . . . . . . 103 3.2.2.2.2 Host Centric . . . . . . . . . . . . . . . . . . . . 103 3.2.2.2.3 Discussion on compatibility of each Mobility Man- agement scheme with the available Message Ex- change Models . . . . . . . . . . . . . . . . . . 104 3.2.2.3 Mobility Management Algorithm Categories . . . . . . . . 106 3.2.2.3.1 Context Aware . . . . . . . . . . . . . . . . . . . 106 3.2.2.3.2 Cost Function based . . . . . . . . . . . . . . . . 106 3.2.2.3.3 Multi Attribute Decision Making (MADM) . . . 106 3.2.2.3.4 User Centric . . . . . . . . . . . . . . . . . . . . 106 3.2.2.3.5 Fuzzy Logic based . . . . . . . . . . . . . . . . 107 3.2.2.3.6 Neural Network based . . . . . . . . . . . . . . . 107 3.2.2.3.7 MIH based . . . . . . . . . . . . . . . . . . . . . 107 3.2.2.3.8 Probabilistic . . . . . . . . . . . . . . . . . . . . 107
  • 18. xviii Contents 3.2.2.3.9 Group based . . . . . . . . . . . . . . . . . . . . 107 3.2.2.3.10 Auction based . . . . . . . . . . . . . . . . . . . 107 3.2.2.3.11 Discussion on Mobility Management Algorithm Categories . . . . . . . . . . . . . . . . . . . . . 108 3.2.3 Mobility Management on 5G-VCC Systems . . . . . . . . . . . . . . 110 3.2.3.1 Mobility Management schemes for supporting 5G-VCC Ar- chitectures . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.2.3.2 Mobility Management schemes for supporting 5G-VCC Communication Models . . . . . . . . . . . . . . . . . . . 113 4 A Proposed Mobility Management Approach for 5G-VCC Systems 115 4.1 Mobility Management Requirements . . . . . . . . . . . . . . . . . . . . . . 115 4.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.2.1 VHO Initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.2.1.1 Evaluation of the Satisfaction Indicators . . . . . . . . . . 117 4.2.2 Velocity Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.2.3 Network Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.2.4 Handover Execution . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.2.5 Computational Complexity of the Proposed Approach . . . . . . . . 119 4.3 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 4.3.1 Study of a Simulation Snapshot . . . . . . . . . . . . . . . . . . . . 121 4.3.1.1 VHO Initiation . . . . . . . . . . . . . . . . . . . . . . . . 121 4.3.1.2 Velocity Monitoring . . . . . . . . . . . . . . . . . . . . . 121 4.3.1.3 Network Selection . . . . . . . . . . . . . . . . . . . . . . 121 4.3.2 24 Hours Simulation Results . . . . . . . . . . . . . . . . . . . . . . 123 5 Conclusion 133 5.1 Directions for Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Bibliography 141 Appendix A The positions of the available networks 163 Appendix B The available networks per SLA 165 Appendix C The distribution of vehicles during the 24 hours simulation 171
  • 19. List of Figures 1.1 The Three-Layer Stack of the 5G-VCC Systems. . . . . . . . . . . . . . . . 2 1.2 Classification of Delivery Models for Cloud Services. . . . . . . . . . . . . . 3 1.3 Classification of 5G-VCC systems. . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 The Vehicular Cloud (VC) architecture. . . . . . . . . . . . . . . . . . . . . 8 1.5 The Vehicles using Cloud (VuC) architecture. . . . . . . . . . . . . . . . . . 8 1.6 The Vehicles using Fog (VuF) architecture. . . . . . . . . . . . . . . . . . . 9 1.7 A hybrid architecture which combines the design characteristics of both VC, VuC and VuF architectures. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.8 The available communication models. . . . . . . . . . . . . . . . . . . . . . 12 2.1 MAC Schemes for 5G-VCC Systems. . . . . . . . . . . . . . . . . . . . . . 15 2.2 The Three-Level Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 The Topology Simulated for the Evaluation of the FLSA Scheduler. . . . . . 27 2.4 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio using Different Target Delays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.5 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio using Different Target Delays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio. . . . . 29 2.7 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio. . . . 29 2.8 Evaluation of the FLSA Scheduler in terms of VoIP Throughput. . . . . . . . 30 2.9 Evaluation of the FLSA Scheduler in terms of Video Throughput. . . . . . . 30 2.10 Evaluation of the FLSA Scheduler in terms of VoIP Fairness Index. . . . . . 31 2.11 Evaluation of the FLSA Scheduler in terms of Video Fairness Index. . . . . . 31 2.12 The FLSA-CC Scheduler Design. . . . . . . . . . . . . . . . . . . . . . . . 33 2.13 The Topology Simulated for the Evaluation of the FLSA-CC Scheduler. . . . 35 2.14 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the Real Time Flows using Different Target Delays. . . . . . . . . . . . . . . . . 36
  • 20. xx List of Figures 2.15 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the Real Time Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.16 The FLSA-CC Scheduler Evaluation in terms of the Throughput of the Real Time Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.17 The FLSA-CC Scheduler Evaluation in terms of the Fairness Index of the Real Time Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.18 The FLSA-CC Scheduler Evaluation in terms of the Throughput and the Fair- ness Index of the Best Effort Flows. . . . . . . . . . . . . . . . . . . . . . . 38 3.1 The Interval-Valued Trapezoidal Fuzzy Numbers. . . . . . . . . . . . . . . . 40 3.2 The Interval-Valued Pentagonal Fuzzy Numbers. . . . . . . . . . . . . . . . 41 3.3 The ANP Network Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.4 The Relations of the Criteria considered by the ANP Network Model. . . . . 60 3.5 Criteria Weights for SLA1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.6 Criteria Weights for SLA2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.7 Criteria Weights for SLA3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.8 Criteria Weights for SLA4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.9 The TFT Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.10 The TFT’s Network Ranking for User 1 in case of Network Environment Changes. 68 3.11 The TFT’s Network Ranking for User 2 in case of Network Environment Changes. 68 3.12 The TFT’s Network Ranking for User 3 in case of Network Environment Changes. 71 3.13 The TFT’s Network Ranking for User 4 in case of Network Environment Changes. 71 3.14 The TFT’s Network Ranking for User 5 in case of Network Environment Changes. 72 3.15 The TFT’s Network Ranking for User 6 in case of Network Environment Changes. 72 3.16 The TFT’s Network Ranking for User 7 in case of Network Environment Changes. 73 3.17 The TFT’s Network Ranking for User 8 in case of Network Environment Changes. 73 3.18 The TFT’s Network Ranking for User 9 in case of Network Environment Changes. 74 3.19 The TF-ANP Weights per Service and Patient Health Status. . . . . . . . . . 76 3.20 The TFT Results for each Vehicle. . . . . . . . . . . . . . . . . . . . . . . . 77 3.21 The Simulated Topology for the Evaluation of the TF-ANP and the TFT Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.22 The Importance of each Service per Patient Health Status. . . . . . . . . . . . 84 3.23 The TF-AANP Criteria Weights for the DA Services per SLA. . . . . . . . . 85 3.24 The TF-AANP Criteria Weights for the PeNI Services per SLA. . . . . . . . 85 3.25 The TF-AANP Criteria Weights for the MED Services per SLA and Patient Health Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.26 The TF-AANP Weights for each Vehicle. . . . . . . . . . . . . . . . . . . . 86
  • 21. List of Figures xxi 3.27 Classification of Mobility Management Schemes. . . . . . . . . . . . . . . . 100 4.1 The Proposed Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . 124 4.2 The S Values Range as obtained using the FIS. . . . . . . . . . . . . . . . . . 125 4.3 MFSINR Membership Functions Balance. . . . . . . . . . . . . . . . . . . . . 125 4.4 MFQ Membership Functions Balance. . . . . . . . . . . . . . . . . . . . . . 125 4.5 MFS Membership Functions Balance. . . . . . . . . . . . . . . . . . . . . . 125 4.6 The Simulated Topology for the Evaluation of the proposed Mobility Manage- ment Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 4.7 Criteria Weights per Service for the HO Initiation. . . . . . . . . . . . . . . . 127 4.8 The PF-ANP Network Model. . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.9 The Relations of the Criteria considered by the PF-ANP Network Model. . . 130 4.10 The Network Selection Weights per Service for SLA 1. . . . . . . . . . . . . 130 4.11 The Network Selection Weights per Service for SLA 2. . . . . . . . . . . . . 130 4.12 The Network Selection Weights per Service for SLA 3. . . . . . . . . . . . . 130 4.13 The Network Selection Weights per Service for SLA 4. . . . . . . . . . . . . 130 4.14 The PFT Ranking of each HO Scheme. . . . . . . . . . . . . . . . . . . . . . 132 4.15 The Satisfaction Grade obtained from each HO Scheme. . . . . . . . . . . . 132 4.16 The Average PFT Ranking of each HO Scheme during the 24 Hours Simulation.132 4.17 The Average Satisfaction Grade obtained from each HO Scheme during the 24 Hours Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.18 The Total HOs Count of each HO Scheme during the 24 Hours Simulation. . 132
  • 23. List of Tables 2.1 The Characteristics of the discussed MAC Schemes. . . . . . . . . . . . . . . 22 2.2 The Parameters considered in each Scheduler in comparison with the ones considered by the FLSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3 The Simulation Parameters for the Evaluation of the FLSA Scheduler. . . . . 28 2.4 The Sub-Frequencies that are assigned to each Cell. . . . . . . . . . . . . . . 34 2.5 The Parameters considered in each Scheduler in comparison with the ones considered by the FLSA-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.6 The Simulation Parameters for the Evaluation of the Proposed Algorithm. . . 36 3.1 The Saaty’s Nine-Point Importance Scale. . . . . . . . . . . . . . . . . . . . 43 3.2 The Linguistic Terms that are used for the Criteria Pairwise Comparisons. . . 50 3.3 QoS Class Mapping and SLAs. . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.4 The ANP Supermatrix for the SLA1 VoIP Service. . . . . . . . . . . . . . . 61 3.5 The ANP Weighted Supermatrix for the SLA1 VoIP Service. . . . . . . . . . 61 3.6 The ANP Limit Supermatrix for the SLA1 VoIP Service. . . . . . . . . . . . 62 3.7 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy Numbers used for the Evaluation of the TFT algorithm. . . . . . . . . . . . . 66 3.8 Relation of the Network QoS Characteristics and the Linguistic Terms for VoIP. 66 3.9 The Available Networks of SLA1 and SLA2. . . . . . . . . . . . . . . . . . 69 3.10 The Available Networks of SLA3 and SLA4. . . . . . . . . . . . . . . . . . 70 3.11 The Required Services per User. . . . . . . . . . . . . . . . . . . . . . . . . 70 3.12 Networks’ Classification in respect of TFT, TOPSIS (T) and FAE Results. . . 70 3.13 Linguistic Terms and the Corresponding Interval-Valued Trapezoidal Fuzzy Numbers used for the Criteria Attributes for the Evaluation of the TFT Algo- rithm in cases where Medical Services are used. . . . . . . . . . . . . . . . . 77 3.14 The Available Wide Coverage Networks for each Service. . . . . . . . . . . . 78 3.15 The Simulated Vehicles for the Evaluation of the TFT Algorithm. . . . . . . . 79 3.16 Networks’ Classification in respect of TFT, ANST and FAS Results. . . . . . 79
  • 24. xxiv List of Tables 3.17 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy Numbers used for the Criteria Attributes for the Evaluation of the TFT-ACW Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.18 The Available Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.19 The Simulated Vehicles for the Evaluation of the TFT-ACW Algorithm. . . . 82 3.20 The Classification of the Networks according to TFT-ACW, TFT and FSAW Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.21 The Mobility Management Activities of each Scheme. . . . . . . . . . . . . 99 3.22 The Control Types that each Scheme supports. . . . . . . . . . . . . . . . . . 102 3.23 The Applicability of each Scheme to the Available Message Exchange Models. 105 3.24 The Type of Algorithms used in each Scheme. . . . . . . . . . . . . . . . . . 109 3.25 The Factors considered in each Architecture. . . . . . . . . . . . . . . . . . . 111 3.26 The Applicability of each Scheme to the Available 5G-VCC Architectures. . 112 3.27 The Applicability of each Communication Model to each Architecture. . . . . 113 3.28 The Applicability of each Scheme to each Communication Model. . . . . . . 114 4.1 Linguistic Terms and the corresponding Interval-Valued Pentagonal Fuzzy Numbers used for MFSINR, MFQ and MFS. . . . . . . . . . . . . . . . . . . . 118 4.2 The Fuzzy Rule (or Knowledge) Base. . . . . . . . . . . . . . . . . . . . . . 126 4.3 Relation of the Network QoS Characteristics and Linguistic Terms for VoIP. . 127 4.4 The Simulation Parameters for the Evaluation of the proposed Mobility Man- agement Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 4.5 The available Networks for each Monitored Vehicle. . . . . . . . . . . . . . 128 4.6 The QSLA, SINRSLA and Sth,SLA thresholds per SLA. . . . . . . . . . . . . . . 129 4.7 The HO Initiation Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.8 The Monitored Vehicles Status. . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.9 The PF-ANP Initial Supermatrix for the SLA 1 NAV Service. . . . . . . . . . 131 4.10 The PF-ANP Weighted Supermatrix for the SLA 1 NAV Service. . . . . . . . 131 4.11 The PF-ANP Limit Supermatrix for the SLA 1 NAV Service. . . . . . . . . . 131 A1 The positions of the available LTE Access Networks. . . . . . . . . . . . . . 163 A2 The positions of the available WiMAX Access Networks. . . . . . . . . . . . 164 A3 The positions of the available WAVE Access Networks. . . . . . . . . . . . . 164 B1 The available LTE networks of SLA 1. . . . . . . . . . . . . . . . . . . . . . 166 B2 The available WiMAX and WAVE networks of SLA 1. . . . . . . . . . . . . 167 B3 The available LTE networks of SLA 2, SLA 3 and SLA 4. . . . . . . . . . . 168 B4 The available WiMAX and WAVE networks of SLA 2, SLA 3 and SLA 4. . . 169
  • 25. List of Tables xxv C1 Number of vehicles that start from each LTE network and their corresponding velocities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 C2 Number of vehicles that start from each WiMAX network and their correspond- ing velocities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 C3 Number of vehicles that start from each WAVE network and their corresponding velocities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 C4 Vehicles count per service and SLA. . . . . . . . . . . . . . . . . . . . . . . 174
  • 27. Chapter 1 Introduction In a Fifth Generation Vehicular Cloud Computing (5G-VCC) system the operating principles of vehicular networks, Cloud Computing (CC) [1] and Software Defined Networks (SDN) [2], considered as the key enabling technologies for the 5G networks, are combined. In a typical VCC system, vehicles are equipped with On-Board Units (OBUs) with computational, storage and communication resources. Vehicles communicate with each other as well as with Road Side Units (RSUs). Also, each RSU interacts with a Cloud infrastructure which offers a variety of modern services with strict Quality of Service (QoS) requirements. Vehicles such as cars, motorcycles, buses and trains provide a wide variety of cloud services to their passengers. Each vehicle could serve many passengers with different services and various requirements. Such services may include Driver Assistance (DA), Passenger Entertainment and Information (PEnI), and Medical (MED) services. The DA services include Navigation Assistance (NAV) [3] and Parking Assistance (PRK) [4] services. The PEnI services include Conversational Video (CV) [5], Voice over IP (VoIP) [6], Buffered Streaming (BS) [7] and Web Browsing (WB) [8] services. Moreover, the MED services include Live Healthcare Video (LHVideo) [9], Medical Images (MedImages) [10], Health Monitoring (HMonitoring) [11] and Clinical Data Transmission (CData) [12] services. To support the communication needs of the vehicles, dense deployments of 5G networks are implemented, called Ultra Dense Networks (UDNs) [13]. UDNs aim to support the high data rates produced by the increased number of vehicular users. Heterogeneous network access technologies, such as the 3GPP Long Term Evolution Advanced (LTE-A) [14], the IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMAX) [15] or the IEEE 802.11p Wireless Access for Vehicular Environment (WAVE) [16] RSUs are used to provide network services to vehicles. In addition, a large number of small cells, such as Femtocells, is deployed inside the network coverage area in order to increase the overall capacity of the network [17][18]. Network operators use the Anything as a Service (ANYaaS) [19] delivery
  • 28. 2 Introduction Service Layer Cloud & Fog services Network Layer Wireless communication equipment including Road Side Units (RSUs) and Base Stations (BSs) Device Layer On-Board Units (OBUs), Sensors, Navigation devices, Smart phones, Tablets etc. Figure 1.1 The Three-Layer Stack of the 5G-VCC Systems. model in order to deploy and orchestrate network management algorithms and services using the Cloud infrastructure. Specifically, the Mobility Management as a Service (MMaaS) [20] [21] subcategory of ANYaaS, could be applied to accomplish mobility management operations by the Cloud infrastructure. The MMaaS model allows for each vehicular user the creation of a Mobility Instance (MI) at the Cloud, offering mobility management services and manipulating the user’s mobility. In this way, the user equipment resources will experience a decreased workload and will consume less energy during the mobility management. The 5G architecture could be improved by applying the operating principles of Fog or Mobile Edge Computing (MEC) [22–26]. Specifically, WAVE RSUs, as well as LTE and WiMAX Base Stations (BSs) are equipped with additional computational and storage resources and thus they are called as micro-datacenter RSUs (md-RSUs) and micro-datacenter BSs (md-BSs), respectively. Vehicular services are provided directly from the access network. Thus, the durability and the response latency of the services are improved, compared with the traditional centralized cloud server approach. 5G-VCC systems could be described considering the three-layer stack [27][28] presented in Figure 1.1, where the Service, the Network and the Device layers are defined. The Device layer contains the end-user equipment such as On-Board Units (OBUs), smart phones, tablets, navigation devices and sensors. The Network layer contains the communication equipment, such as Macrocell/Femtocell Base Stations (BSs) or Road-Side Units (RSUs), as well as in- vehicle network devices. The Service layer contains Cloud or Fog infrastructures that offer vehicular services. The vehicular users should always obtain connectivity to the most appropriate network access technology, according to the requirements of their services. In general, the mobility management process consists of three subprocesses, namely the VHO initiation, the network selection and the VHO execution. The VHO initiation decides when a handover must be performed. Subsequently, the network selection deals with the selection of the most appropriate network for the vehicle to handover. Finally, during the VHO execution two general techniques
  • 29. 1.1 Delivery Models for Cloud Services 3 are considered. The first one is called Soft Handover or "Connect before Break". It defines that the OBU is firstly connected to the new network and then it is disconnected from its previous network. The second technique is called Hard Handover or "Break before Connect". In this case, the OBU is firstly disconnected from its previous network and then it is connected to the next network. 1.1 Delivery Models for Cloud Services The delivery models refer to the way in which the service is delivered to the users. The main cloud computing delivery models are the Software as a Service (SaaS), the Platform as a Service (PaaS) and the Infrastructure as a Service (IaaS). As presented in Figure 1.2, each one of the main delivery models contains a variety of delivery models. These delivery models are described in the following subsections. Delivery Models Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (IaaS) User Communication as a Service (UCaaS) Data as a Service (DaaS) Entertainment as a Service (EaaS) Information as a Service (INaaS) Pictures as a Service (PICaaS) Sensing as a Service (SEaaS) Warning as a Service (WaaS) Framework as a Service (FaaS) Runtime Environment as a Service (RaaS) Discovery as a Service (DISCaaS) Network as a Service (NaaS) Hardware as a Service (HaaS) Computing as a Service (COaaS) Storage as a Service (STaaS) Figure 1.2 Classification of Delivery Models for Cloud Services.
  • 30. 4 Introduction 1.1.1 Software as a Service (SaaS) based Delivery Models Software as a Service (SaaS) provides cloud services to the end-users, while at the same time it prevents them from configuring the services’ source code or controlling the underlying cloud infrastructure. The SaaS delivery model includes the following subcategories: • User Communication as a Service (UCaaS): This delivery model [29] provides the necessary applications to the users, in order to be able to communicate with each other, by making voice or video calls, sending emails, using chat boxes etc. • Data as a Service (DaaS): In a 5G network architecture, data sourcing and data manipu- lation could be performed in the cloud infrastructure using the appropriate applications. DaaS allows users to retrieve data from the cloud, in order to avoid the permanent storage of big data sets on their devices [30]. • Entertainment as a Service (EaaS): Modern 5G network infrastructures offer media services such as video, music or advertisements to users. EaaS defines that the provided media services are hosted in the cloud and broadcasted to users or offered to them on-demand [31]. • Information as a Service (INaaS): Users often need information related to events, points of interest (POIs) or emergency situations. The INaaS delivery model provides that information to the users. Indicatively, in [32] users share information about their location with other users as well as with a cloud infrastructure. Then, if a user needs information about a specific location, he/she interacts with the cloud and subscribes to the INaaS in order to receive it. • Pictures as a Service (PICaaS): According to the PICaaS operating principles described in [33], users are registered to a centralized cloud manager and they periodically share their geographical coordinates. A customer user requests multimedia material about a specific geographic area. Thus, some users are selected according to their positions, to take photos or videos of the given area using their cameras. Finally, such multimedia material is sent to the consumer user. • Sensing as a Service (SEaaS): Sensors are distributed to the countryside to collect data about the respective environment. The sensor data are collected in the cloud and, subsequently, they are broadcasted to the SEaaS users [34]. • Warning as a Service (WaaS): The cloud infrastructure collects information about emer- gency situations or disasters. Subsequently, warning messages are transmitted to users depending on their locations [35].
  • 31. 1.1 Delivery Models for Cloud Services 5 1.1.2 Platform as a Service (PaaS) based Delivery Models In the Platform as a Service (PaaS) model, the users are considered as application developers. Specifically, PaaS provides computational and storage resources to the users by hiding the underlying hardware infrastructure from them [36]. Also, PaaS offers the necessary platform (e.g. the underlying Operation System - OS) to users for the deployment of their applications. The users are able to remotely develop and deploy their applications. These applications should be compatible with the provided cloud platform. The following delivery models could be considered as PaaS subcategories [37]: • Framework as a Service (FaaS): FaaS provides a framework for the implementation of user applications. • Runtime Environment as a Service (RaaS): RaaS provides a deployment and execution environment for the user applications. 1.1.3 Infrastructure as a Service (IaaS) based Delivery Models Infrastructure as a Service (IaaS) refers to the provision of infrastructure from the cloud to the users in order to be able to set up a specific platform (e.g. an OS) to deploy their applications. The IaaS delivery model provides resources to users. Furthermore, the IaaS model includes the following subcategories: • Discovery as a Service (DISCaaS): This delivery model allows users to discover cloud recourses with specific characteristics [38]. • Network as a Service (NaaS): In NaaS the users with internet access can offer this facility to the users that do not have any access [39]. • Hardware as a Service (HaaS): In HaaS the user devices or the cloud with plenty computational resources can offer these to the users that need more resources [40]. The HaaS model contains two subcategories, the Computing as a Service (COaaS) [36] and the Storage as a Service (STaaS) [41]. COaaS provides computational resources, such as Central Processing Unit (CPU) cores to users, in order to develop and run their applications. STaaS provides storage space to users to deploy their applications. 1.1.4 Comparison of the Delivery Models The determination of the advantages and the disadvantages of each of the main delivery models is necessary, in order to provide a complete view of their functionalities. SaaS is the most
  • 32. 6 Introduction cost effective delivery model, due to the fact that the user leases only the software that he uses and not the resources that host it. In addition, the SaaS services are easy in use and they can be rapidly provided on-demand, because they are already deployed on the cloud by their provider. Also, the user does not have to worry about the services management, as this is the provider’s responsibility. On the other hand, the user has no control neither over the application implementation and parameterization, nor on the data processing functionalities. Also, the user has limited control over the application deployment and upgrade processes, while integration with other user’s software or systems is difficult, considering the fact that the integration must be presupported by the service provider. PaaS is less cost effective in comparison to SaaS, while at the same time it is more cost effective than IaaS, as the user is leasing only the software platform (e.g. an Operating System installation) and not the entire infrastructure that hosts the platform. Unlike SaaS, a user can deploy his own applications to run on the aforementioned platform and, thus, he has full control over the software that he runs. Therefore, the user has also full control over the rights of the users accessing his software as well as over the data processing functionalities of his applications. Furthermore, the integration between user applications and external systems can be done at the application level, since the user has full control over the source code of his applications. Another PaaS advantage is the minimal Virtual Machine (VM) management that is required, since such processes are handled by the infrastructure provider. However, the lack of control over the VM could create security risks in terms of application data privacy. Also, the provided platform is usually a shared platform and other users could be running their applications at the same time over it, creating even more privacy risks as well as overloading the underlying infrastructure with additional workflows. In IaaS, the user has full control over his VM, while he can deploy and run anything he wants inside it. Furthermore, the user has full control of data processing functionalities inside the entire VM and not only inside his applications as it happens in PaaS. As a consequence, IaaS simplifies ever more the integration with other systems compared with PaaS. In addition, it is considered as the most privacy aware cloud service due to the fact that the user can deploy, run and control his own virtual infrastructure with full control to his VMs. However, IaaS is more expensive than SaaS and PaaS, since the user is leasing physical resources, such as CPU cores, RAM and storage space. Also, unlike SaaS or PaaS, in IaaS the user is responsible for the entire VM manipulation processes, which may lead to additional tasks for him. Table 1 summarizes the main delivery models’ advantages and disadvantages.
  • 33. 1.2 5G Vehicular Cloud Computing Systems (5G-VCC) 7 5G-VCC Systems Classification Architectures Communication Models Vehicular Cloud (VC) Vehicles using Cloud (VuC) Vehicles using Fog (VuF) Hybrid Vehicular Architectures (HVA) Vehicle to Vehicle (V2V) Vehicle to Infrastructure (V2I) Vehicle to Pedestrian (V2P) Software Defined Networking Vehicular Architectures (SDN-V) Hybrid Vehicular Communication (HVC) Figure 1.3 Classification of 5G-VCC systems. 1.2 5G Vehicular Cloud Computing Systems (5G-VCC) 1.2.1 5G-VCC Architectures Three main 5G-VCC architectures are derived in the research literature, namely the Vehicular Cloud (VC), the Vehicles using Cloud (VuC) and the Vehicles using Fog (VuF). Moreover, 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 (Figure 1.3). 1.2.1.1 Vehicular Cloud (VC) According to the VC architecture [38, 41–46], the cloud is consisted of vehicles with computing resources (Figure 1.4). Vehicles directly interact with each other, while data forwarding is supported by proprietary protocols such as the 802.11s [47]. Vehicles’ resources [48] remain idle for a long period of time in vehicles parked for many hours each day, or even for many days in some cases, as well as in vehicles that remain stuck due to congested traffic roads. The resources of such vehicles could be used for constructing a cloud infrastructure [49][50]. In such cases, additional resource manipulation factors are arising, since the constructed cloud is based on an ever-changing architecture where vehicular VMs (VVMs) [51] are continuously added or removed. Thus, in order to assure service continuity, multiple instances of each service should be distributed simultaneously in several VVMs [52]. Furthermore, the authorization of each vehicle’s owner is required [53], for the vehicles’ resources to be provided to the VC architecture.
  • 34. 8 Introduction Vehicular Cloud Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Figure 1.4 The Vehicular Cloud (VC) architecture. Vehicular Environment Cloud RSU/BS RSU/BS Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Figure 1.5 The Vehicles using Cloud (VuC) architecture. 1.2.1.2 Vehicles using Cloud (VuC) According to the VuC architecture [27, 28, 35, 54–60], the vehicles interact with a Cloud infrastructure through Macrocell/Femtocell BSs or RSUs, as presented in Figure 1.5. Compared to the VC architecture, in a VuC architecture the vehicles are considered as the end users. 1.2.1.3 Vehicles using Fog (VuF) The VuF architecture [61] presented in Figure 1.6, could be considered as an evolution of the aforementioned VuC architecture, where the operating principles of Fog computing [22–26] are applied. Specifically, the VuF architecture defines that the BSs or RSUs are equipped with additional computational and storage resources, while they are also referred as micro-datacenter BSs (md-BSs) and micro-datacenter RSUs (md-RSUs), respectively. In this case, the vehicles
  • 35. 1.2 5G Vehicular Cloud Computing Systems (5G-VCC) 9 Vehicular Environment Fog micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Figure 1.6 The Vehicles using Fog (VuF) architecture. interact with computing and storage resources characterized by proximity, low latency and high bandwidth. 1.2.1.4 Software Defined Vehicular Architectures (SDN-V) Each VCC architecture could be enhanced with advanced manipulation functionalities using the Software Defined Networks (SDN) technology [62]. More specifically, the SDN technology simplifies the network management procedures, while at the same time it reduces the network equipment cost. Its operating principles include: • The network control plane and the data plane are decoupled. • The network orchestration and management is 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 [63], considering the operating principles of Network Functions Virtualization (NFV) [64][65], in order to reduce the required SDN hardware as well as to improve the overall system sustainability. In particular, concerning the Cloud- based SDN control, in [66], [67] and [68] the SDN controller is implemented at the Cloud infrastructure, by one or more Virtual Machines (VM). On the other hand, in [69] and [70] a Fog infrastructure implementing the SDN control is described. Specifically, an md-RSU contains a computing device and an OpenFlow (OF) Switch. The computing device include
  • 36. 10 Introduction a VM and a lightweight hypervisor. The hypervisor is a middleware which enables VMs to share resources to their hosted services [71]. 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 OF and Cloud controllers via the data plane and disseminates information about services and data flows changes. Furthermore, in [72], the authors describe a Software Defined VCC architecture, where an SDN controller exists between the RSUs and the Cloud infrastructure, providing centralized resource manipulation functionalities for the entire architecture. 1.2.1.5 Hybrid Vehicular Architectures (HVA) The previous main models are combined in hybrid 5G-VCC architectures. Indicatively, in [73] a hybrid 5G-VCC architecture combining both the VuC and VuF models, is discussed. Services are offered by both Cloud and Fog infrastructures, while the Cognitive Radio Networks (CRN) [74] 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, in [75] and [31] an HVA architecture (Figure 1.7) 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 resources sustainability. Also, in [76] a HVA architecture which combines both VC and VuC architectures is described. More specifically, a VC provides vehicle cooperation functionalities such as Internet access via multihop 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 conclusions are sent to the central cloud. Thus, vehicles that does not belong to the VC can obtain the traffic related information concerning the VC area. Furthermore, the extended version of this architecture includes multiple VCs could. 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.
  • 37. 1.2 5G Vehicular Cloud Computing Systems (5G-VCC) 11 Fog micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS micro-datacenter RSU/BS Cloud Vehicular Cloud micro-datacenter RSU/BS micro-datacenter RSU/BS Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Service Layer Network Layer Device Layer Figure 1.7 A hybrid architecture which combines the design characteristics of both VC, VuC and VuF architectures. 1.2.2 Communication Models for 5G-VCC Systems Communication models determine which entities communicate with each other in a VCC architecture. In general, they are referred as Vehicle to Everything or V2X, where V stands for vehicle and X determines the entity which 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 (Figure 1.3). 1.2.2.1 Vehicle to Vehicle (V2V) V2V communications [77–83] comprises a wireless network where vehicles exchange infor- mation each other. Such information could include vehicle location, speed, direction, braking, stability loss as well as any other information including traffic or multimedia. V2V could 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 condi- tions but not took control of the vehicle, while later implementations improve the braking or steering capabilities of the vehicles.
  • 38. 12 Introduction Cloud RSU/BSRSU/BS Vehicular Environment Pedestrian Pedestrian Pedestrian Vehicle to Vehicle (V2V) Vehicle to Infrastructure (V2I) Vehicle to Pedestrian (V2P) Vehicle to Vehicle (V2V) Vehicle to Infrastructure (V2I) Vehicle to Pedestrian (V2P) Figure 1.8 The available communication models. 1.2.2.2 Vehicle to Infrastructure (V2I) V2I communication [84–90] is performed through the RSUs, while the information gathered by the infrastructure could include traffic or road conditions and Points of Interest (PoI). Indicatively, the vehicles velocities and accelerations as well as the inter-vehicle distances could be suggested by the infrastructure considering the traffic conditions and optimizing the traffic manipulation, the fuel consumption and the driver safety. 1.2.2.3 Vehicle to Pedestrian (V2P) In a V2P communication [91–97] information between vehicles and pedestrians is exchanged. The pedestrians could exchange road safety information with vehicles using their mobile devices in order to avoid accidents. 1.2.2.4 Hybrid Vehicular Communication (HVC) In a 5G-VCC architecture, multiple communication models could also be used together [98– 104] (Figure 1.8). 1.3 Thesis Structure In the first chapter the fundamental operating principles of the Fifth Generation (5G) wireless networks and 5G Vehicle Cloud Computing (5G-VCC) systems are introduced. Additionally, the three-layer stack used to design and analyze the 5G-VCC systems is described. Subse- quently, the theoretical background of the thesis is analyzed. Specifically, the available delivery models for cloud services are mentioned and existing 5g-VCC architectures are presented. Finally, the main communication models are described.
  • 39. 1.4 Thesis Novelty 13 The second chapter, which deals with the management of network resources in 5G-VCC systems, firstly describes the available Medium Access Control schemes (MAC schemes). Subsequently, existing resource scheduling algorithms implemented at the MAC layer of 5G- VCC systems are described, while two novel solutions are proposed to optimize the resource allocation process. In the third chapter, the requirements of the 5G-VCC systems for the management of mobility of vehicular users are described. Three methods for calculating the significance of the criteria affecting the mobility management are proposed. Furthermore, three network selection algorithms are proposed. Subsequently, the proposed algorithms are evaluated. The fourth chapter describes a proposed scheme for performing mobility management in 5G wireless networks. The scheme takes into consideration the Signal to Noise plus Interference (SINR) while at the same time it performs optimized supervision of the user’s velocity, in order to evaluate the necessity of performing a handover. Subsequently, it selects the most appropriate network for the user. Experimental results showed that the proposed model outperforms the existing solutions described in the research literature. Finally, in the fifth chapter a brief review of the thesis is made. The conclusions extracted from the performed research are mentioned, while guidance for future work is given. 1.4 Thesis Novelty The novelty of this thesis is found in the following points: • Medium Access Control (MAC) schemes for 5G Wireless Networks – Study, classification and evaluation of the most used medium access mechanisms for 5G wireless networks and specifically for 5G-VCC systems. • 5G Wireless Network Architectures – Study, classification and evaluation of the 5G wireless network architectures and in particular of 5G-VCC systems, considering the applied network topologies and communication models proposed in the research literature. • Delivery Models for Cloud Services in 5G Wireless Networks – Study, classification and evaluation of the most used cloud delivery models that can be applied to 5G network architectures. • Resource Allocation (scheduling) in 5G Wireless Networks
  • 40. 14 Introduction – Two novel resource allocation (scheduling) algorithms that can be applied to 5G Wireless Networks, including 5G-VCC systems, are proposed. The experimental results showed that they optimize the allocation of network resources in order the constraints of real-time services to be optimally satisfied. • Mobility Management in 5G Wireless Networks – Three novel methods for calculating the weights of mobility management criteria are proposed. Experimental results showed that the proposed methods optimize the calculation of the significance of each mobility management criterion. – Three novel network selection algorithms for 5G wireless network, including 5G- VCC systems, are proposed. The experimental results showed that these algorithms select the optimal network considering the requirements of both users and network operators. – An integrated mobility management scheme for 5G wireless networks, including 5G-VCC systems, is proposed. Extensive experimental results demonstrated that it optimizes the mobility management process by minimizing the number of required handovers, while at the same time it ensures that the user is connected to the optimal access network considering both his requirements as well as network operators constraints.
  • 41. Chapter 2 Resource Allocation - Scheduling 2.1 Medium Access Control (MAC) Schemes for 5G-VCC systems This section describes MAC schemes that can be applied in 5G-VCC systems. The schemes are organized considering their underlying multiple access mechanism. Since the vehicular environment often changes due to the high mobility of vehicles, while at the same time both V2V and V2I communications must be supported, sometimes in an ad-hoc manner, the most common multiple access mechanisms considered in vehicular MAC schemes include the TDMA and the CSMA/CA. Hybrid schemes have also been proposed in the literature combining more than one multiple access mechanism. Figure 2.1 presents the schemes that will be discussed in the following subsections. MAC Schemes for 5G-VCC TDMA based CSMA/CA based Hybrid ATSA CAH-MAC CBT CESFRA CFR-MAC ETCM IGPS-MAC PTMAC UTSP TC-MAC VeMAC e-VeMAC STDMA CA-MAC QL-MACMMAC-CL MQOG ACFM CBRC-MAC CS-TDMA HER-MAC R-MAC OBV Figure 2.1 MAC Schemes for 5G-VCC Systems. 2.1.1 Time Division Multiple Access (TDMA) based MAC Schemes TDMA-based MAC schemes share the medium in the field of time. In the Adaptive TDMA Slot Assignment (ATSA) [105] scheme, for example, each vehicle selects a frame length, which
  • 42. 16 Resource Allocation - Scheduling is reduced to improve channel utilization when the vehicle density becomes low, or increased when the vehicle density becomes high to ensure that each vehicle can access the medium. Time slots are divided in two sets, namely the Left and the Right set. A slot management mechanism based on a binary tree model is used. The vehicles on the left sub-tree can compete for the Left time slots, while the vehicles on the right sub-tree can compete for the Right time slots. When a vehicle receives slot allocation information from its neighbors, it discovers which slots are in use. Thus, the remaining slots are available to compete for. The Cluster Based TDMA (CBT) [106] scheme provides a mechanism for intra-cluster and inter-cluster communication to minimize the packet collisions that could occur when two clusters are moving close to each other. In each cluster, the vehicles are synchronized in time using their GPS devices, while one vehicle is elected as the Cluster Head (CH). A TDMA related technique is used where each frame consists of N time slots. The CH maintains a Slot Allocation Map (SAM) allocating time slots to vehicles. Moreover, the CH periodically broadcasts its SAM and a beacon frame to its cluster’s vehicles. The cluster remains in the intra-cluster communication state if the beacon frames from the CHs of the other clusters are not received. However, if a beacon frame comes from an external CH, the two neighboring clusters’ CHs exchange their SAMs in order to prevent inter-cluster interference. The CH that successfully sends first its SAM is considered as the Winner, while the other is considered as the Loser. The Loser must reschedule its own SAM. Another TDMA-based MAC scheme is the Cross-layer Extended Sliding Frame Reservation Aloha (CESFRA) [107]. In CESFRA safety information is disseminated up to the third hop neighboring vehicles without any routing scheme. This scheme divides each frame into N time slots. All the vehicles are considered to be synchronized in time using their Geographical Positioning System (GPS) devices. When a vehicle has packets to transmit, it senses the medium in order to find an idle time slot. Once an idle time slot is found, the vehicle starts transmitting its packets. The time slot is also reserved by the vehicle in the subsequent frames in order to transmit the remaining packets. The Collision Free Reservation MAC (CFR-MAC) [108] is another mechanism that provides TDMA based medium access. It considers the vehicles’ traffic flows as well as their velocities. As in the ATSA, the time slots are divided into two sets, the Left and the Right set. The Left set is assigned to vehicles that are moving to the one direction, while the Right set is assigned to vehicles moving to the opposite. In general, when multiple vehicles are moving on the same street with different velocities the interference levels on the wireless environment are constantly changing leading on unpredictable changes in the medium quality. CFR-MAC addresses this problem by dividing each slot’s set into three subsets. Each subset is associated to a specific
  • 43. 2.1 Medium Access Control (MAC) Schemes for 5G-VCC systems 17 velocity, namely the High, the Medium and the Low velocity. In this way the interference levels inside each subset become less variable and the medium quality more resistant. The Vehicular MAC (VeMAC) [109] supports broadcast services. Similar to the CBT and CFR-MAC schemes, the two vehicles’ moving directions are considered, namely the Left and the Right direction. A set of time slots is assigned to vehicles that move in the Left direction and the Right direction, respectively. Using these time slots, the vehicles of each direction communicate with each other, while the vehicles’ time synchronization is performed using their GPS devices. Although VeMAC supports reliable transmission, it is not fully applicable in vehicular networks with parallel transmissions. In [110] an enhanced version of VeMAC scheme, the e-VeMAC, is proposed. The e-VeMAC scheme is based on the insight of the one-hop neighboring vehicles in order to improve the performance of the VeMAC scheme when parallel transmission occurs. The Enhanced TDMA Cluster-based MAC (ETCM) [111], the Prediction-based TDMA MAC (PTMAC) [112] and the Unified TDMA-Based Scheduling Protocol (UTSP) [113] schemes also implement TDMA based multiple access. The ETCM scheme defines that the vehicles are organized into clusters, while a vehicle of each cluster is defined as the CH. Subsequently, the CH applies a TDMA based method to assign time slots to the cluster’s vehicles. The main operating principle of PTMAC is the packet collision prediction. PTMAC consists of three parts, namely the collision prediction part, the collision detection part and the collision elimination part. According to the collision prediction part, data traffic and vehicles mobility information is used in order to predict potential future collisions. Furthermore, the collision detection uses time slot information to detect collisions that occurred in cases where two vehicles transmit data using the same time slot. Finally, the collision elimination part reschedules the slots considering the information obtained from both the collision prediction and the collision detection parts, in order to eliminate the packet collisions. The UTSP scheme implements a centralized resource allocation mechanism for V2I commu- nication. Initially, the RSU collects information about the channel state, the vehicles’ velocities and the priorities of the vehicles’ services. Then, it uses a weighted function to compute a score for each vehicle. Finally, the RSU assigns TDMA time slots to each vehicle according to its score, where the amount of time slots assigned to each vehicle is proportional to the corresponding vehicle’s score. Similar to the aforementioned MAC schemes, other TDMA-based schemes are the Cooper- ative ADHOC MAC (CAH-MAC) [114], the Improved Generalized Prime Sequence Based MAC (IGPS-MAC) [115], the Self-organizing Time Division Multiple Access (STDMA) [116], and the TDMA Cluster-based MAC (TC-MAC) [117].
  • 44. 18 Resource Allocation - Scheduling 2.1.2 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) based MAC Schemes The schemes of this category share the medium by applying the CSMA/CA operating principles. The Context Aware MAC (CA-MAC) [118] considers the network load status in order to improve the medium access performance of 802.11p MAC. More specifically, CA-MAC consists of two parts, the Reasoning part and the Self-adaption part. Initially, the Reasoning part obtains the network load based on context information. Thus, the network is characterized as congested, idle or normal. Subsequently, the Self-adaption part considers the network load and dynamically adjusts the 802.11p Contention Window [119] size, which is used for channel reservation by the vehicles. Accordingly, if a high network load is observed, the CW is incremented to reduce the collisions probability. On the contrary, if a low network load is observed the CW is decreased to avoid unnecessary medium access delays. More specifically, if the Reasoning part indicates that the network is congested, the CW will be increased by 1, while if the Reasoning part indicates that the network status is idle, the value of CW will be halved. The CW will remain unchanged, if the Reasoning part indicates that the network status is normal. Another CSMA/CA-based scheme called Multichannel MAC - Cross Layer (MMAC-CL) [120] aims to reduce the interference between vehicles at both the MAC and the Network layers considering two multichannel radio interfaces per vehicle. The MMAC-CL maximizes the average Signal to Interference Ratio (SIR) between the source and the destination. Transmis- sion channels are selected considering a SIR evaluation, in order to minimize the cochannel interference observed by the vehicles. The Multichannel QoS Cognitive MAC (MQOG) [121] is a multichannel scheme using a dedicated Control Channel (CCH) for control information exchange and multiple Service Channels (SCHs) for data transmission. Each vehicle assesses the interference level in each channel and acquires the best one for transmission. Subsequently, each vehicle tracks its neighbors’ communications using a Channel Neighbor State Table (CNST). The vehicles obtain information from the CCH in order to update their CNST tables and select the appropriate SCHs for their data transmission. The Q-Learning MAC (QL-MAC) [122] provides a delay tolerant medium access, where neighboring vehicles exchange positioning information. A Contention Window (CW) is defined, while the best CW size is evaluated using a Q-Learning algorithm, in order to improve the contention efficiency. A positive reward is awarded to each vehicle when a data frame is successfully transferred. On the contrary, a negative reward is given when a data frame transmission is failed. The dynamic CW size adjustment reduces the packet collisions, while at the same time it achieves a low medium access delay. When the payload size is larger than a
  • 45. 2.1 Medium Access Control (MAC) Schemes for 5G-VCC systems 19 predefined threshold, the RTS/CTS mechanism is applied in order to avoid the hidden terminal and the exposed terminal problems, otherwise the position information is utilized in order to decide whether to start the transmission. 2.1.3 Hybrid MAC Schemes This category includes MAC schemes that use the operating principles of more than one of the aforementioned multiple access mechanisms. The Adaptive Collision Free MAC (ACFM) [123] scheme combines both TDMA and FDMA. ACFM implements a time slot reservation mechanism located at each RSU. Each frame operates in a specific frequency and contains 36 time slots that can be used for data transmission and 1 slot that is called RSU Slot (RS). Furthermore, each RSU maintains a Slot Assignment Cycle (SAC) for the next 100ms, while each cycle can contain from 1 and up to 5 frames according to the vehicles density. Specifically, if the vehicle density is low, the RSU uses a few frames in order to avoid situations where a lot of slots remain unused. On the contrary, if the vehicle density is high, the RSU uses more frames in order to support the increased needs for resources. Similar to the ACFM scheme, the Cluster Based RSU Centric MAC (CBRC-MAC) [124] combines both TDMA and FDMA for providing multiple access to vehicles. Firstly, the available spectrum is divided into a set of subfrequencies using FDMA and, subsequently, each subfrequency is divided into a set of time slots. Thus, Resource Blocks (RBs) are created including a specific subfrequency in the frequency domain and a specific slot in the time domain. RSUs assign RBs to vehicles considering their communication needs. Some schemes combine TDMA with CSMA/CA to accomplish the multiple access. In the Hybrid Efficient and Reliable MAC (HER-MAC) [125] scheme, vehicles are synchronized using their GPS devices. When a vehicle needs to transmit data, it uses the CSMA/CA to perform a 3-way handshake in Wireless Access for Vehicular Environment (WAVE) [16] called Wireless Service Announcement/Request for Service (WSA/RFS). During this handshake, the transmitter vehicle broadcasts a WSA message in order to reserve TDMA time slots for data transmission. When the slot reservation is complete, the transmitter vehicle sends a RFS message to the recipient vehicle. Subsequently, the recipient vehicle responds with an acknowledgment message (ACK) and, then, the transmitter vehicle can start the data transmission. The Risk-Aware MAC (R-MAC) [126] scheme divides each frame into two segments, namely the RSU segment and the vehicle segment. RSUs broadcast control messages using the RSU segment, while the vehicle segment is further divided into two sub-segments, namely the CSMA/CA sub-segment and the TDMA sub-segment. The CSMA/CA sub-segment is used for
  • 46. 20 Resource Allocation - Scheduling warning messages transmission (e.g. in case of an accident) while the TDMA sub-segment is used for non-safety data transmission. It should also be noted that in some hybrid mechanisms, the TDMA or CSMA/CA are com- bined with the Space Division Multiple Access (SDMA) that considers the geographic position of each vehicle. For example, the CSMA-based Self-Organizing TDMA (CS-TDMA) [127] combines TDMA, CSMA/CA and SDMA to support both safety and non-safety applications. A CCH channel is used for the data transmissions of the safety applications, while a SCH channel is used for the non-safety applications. The ratio between the CCH and SCH lengths is adjusted taking into consideration the vehicle density in each location. If the vehicles density is high, the CCH length is increased and the SCH length is decreased in order to guarantee a maximum delay for safety applications. On the contrary, if the vehicles density is low, the CCH length is decreased and the SCH length is increased in order to improve the throughput for non-safety applications. Finally, in the OFDMA-based MAC scheme for VANETs (OBV) [128] the CSMA/CA is combined with the OFDMA mechanism. During a resource negotiation phase, vehicles allocate resources using CSMA/CA. Thereafter, the data transmissions are performed using OFDMA, while at the same time the vehicles are synchronized using their GPS receivers in order to guarantee the orthogonality between the OFDMA subcarriers. 2.1.4 Discussion on MAC Schemes for 5G-VCC Systems Although most of the available MAC schemes have been designed for vehicular systems and not necessarily for 5G-VCC systems, they could be easily applied to the vehicular part of a 5G-VCC architecture. The study of these schemes reveals the fact that various approaches have been proposed to the literature. As mentioned in the previous sections, a main factor of the discussed schemes is the underlying multiple access protocol. The most common multiple access protocols used include TDMA and CSMA/CA. Additionally, some schemes apply hybrid solutions by combining more than one multiple access protocols. These schemes combine FDMA with TDMA (e.g. ACFM and CBRC-MAC), CSMA/CA with TDMA (e.g. HER-MAC and R-MAC), OFDMA with CSMA/CA (e.g. OBV) and so on. Furthermore, some schemes organize the vehicles into clusters (e.g. CBRC-MAC, CBT, ETCM, IGPS-MAC, R-MAC and TC-MAC), while the rest do not consider clusters of vehicles. In general, clustering could be considered as a useful methodology which offers an improved use of the available spectrum. A positioning system is also required in some cases in order to monitor the vehicles positions. The existence of a positioning system enables the vehicles to be synchronized in time with each other using their GPS receivers.
  • 47. 2.2 Overview of Downlink Packet Schedulers 21 Another important factor is the control type applied in each scheme. Some schemes apply distributed control, while other schemes apply centralized control. Although the distributed con- trol distributes the resource manipulation workload, the centralized control could be considered as more appropriate in some cases, since it simplifies the manipulation of the communication resources. In 5G-VCC architectures where a centralized Software Defined Network (SDN) [129] controller supervises the manipulation of the entire system, centralized MAC schemes could be easily configured considering the complete view of the system’s resources. Distributed schemes could also be configured in 5G-VCC systems considering the operating principles of Fog computing [130]. Cognitive Radio Networking (CRN) [74] is another factor that is proposed in 5G-VCC systems to organize the vehicles into two groups, namely the Primary and the Secondary vehicles. Primary vehicles obtain immediate access to network resources as determined in their Service Level Agreements (SLAs) [131]. However, sometimes Primary vehicles do not need the entire network resources provided according to their SLAs. In such cases, Secondary vehicles could use the free network resources, which are also called White Spaces. Furthermore, whenever a Primary vehicle requires the resources defined in its SLA, it immediately reserves them, while the Secondary vehicles should obtain access to other free network resources. Considering the CRN operating principles, some MAC schemes (e.g. MQOG) take advantage of the free white spaces into the available spectrum in order to serve more vehicles. Finally, the communication type (V2V or V2I) that each scheme supports is considered. Table 4.2 presents the characteristics of the discussed MAC schemes considering the aforementioned factors. 2.2 Overview of Downlink Packet Schedulers Several downlink packet schedulers have been proposed in the literature. They can be classified into two groups, namely non-QoS and QoS aware, respectively. A non-QoS aware scheduler does not take into account parameters that affect the service quality, while a QoS aware distributes resources considering the specific constraints of each service. This section makes a brief overview of the available scheduling strategies for LTE systems, since LTE is considered as one of the most important network access technologies for the 5G architectures. 2.2.1 Non-QoS Aware Schedulers In [132] the non-QoS aware schedulers Maximum Throughput (MT), Proportional Fair (PF) and Throughput to Average (TTA) are evaluated in terms of the throughput and the fairness index. The MT scheduler aims at the maximization of the overall system throughput and
  • 48. 22 Resource Allocation - Scheduling Table 2.1 The Characteristics of the discussed MAC Schemes. MAC Scheme Multiple Access Cluster based Positioning System Required Centralized /Distributed control CRN Support Communication ACFM [123] FDMA, TDMA No No Centralized No V2I ATSA [105] TDMA No No Distributed No V2V CAH-MAC [114] TDMA No Yes Distributed No V2V CA-MAC [118] CSMA/CA No No Distributed No V2V, V2I CBRC-MAC [124] FDMA, TDMA Yes No Centralized No V2I CBT [106] TDMA Yes Yes Centralized No V2V CESFRA [107] TDMA No Yes Distributed No V2V CFR-MAC [108] TDMA No Yes Distributed No V2V CS-TDMA [127] CSMA/CA, SDMA, TDMA No Yes Distributed No V2V ETCM [111] TDMA Yes Yes Centralized No V2V HER-MAC [125] CSMA/CA, TDMA No Yes Distributed No V2V IGPS-MAC [115] TDMA Yes Yes Centralized No V2V MMAC-CL [120] CSMA/CA No Optional Distributed No V2V, V2I MQOG [121] CSMA/CA No No Distributed Yes V2V, V2I OBV [128] CSMA/CA, OFDMA No Yes Distributed No V2V, V2I PTMAC [112] TDMA No Yes Distributed No V2V QL-MAC [122] CSMA/CA No Yes Distributed No V2V R-MAC [126] CSMA/CA, TDMA Yes Yes Centralized No V2V, V2I STDMA [116] TDMA No Yes Distributed No V2V TC-MAC [117] TDMA Yes Yes Centralized No V2V UTSP [113] TDMA No Yes Centralized No V2I VeMAC [109] TDMA No Yes Distributed No V2V e-VeMAC [110] TDMA No Yes Distributed No V2V allocates resources using the metric calculated by formula 2.1, where di k(t) represents the available throughput in the kth RB of the ith Transmission Time Interval (TTI). The PF aims at fair distribution of network resources to users. Its metric is estimated using formula 2.2, where ¯Ri(t − 1) denotes the past average throughput. Finally, the TTA metric is calculated using formula 2.3 where di(t) represents the available throughput in the ith TTI. Simulation results in [132], [133] showed that the MT achieves higher throughput, the TTA has better performance in terms of the fairness index while the PF provides satisfactory throughput and fairness. mMT i,k = di k(t) (2.1) mPF i,k = di k(t) ¯Ri(t −1) (2.2) mTTA i,k = di k(t) di(t) (2.3) The Blind Equal Throughput (BET) non-QoS aware scheduler described in [134] distributes equally the throughput to the users using formula 2.4. The authors of [135] compare the MT,
  • 49. 2.2 Overview of Downlink Packet Schedulers 23 the PF and the BET schedulers using TCP traffic in a vehicular environment. Numerical results showed that the MT and the PF schedulers achieve similar throughputs, while their performance is better than the one achieved by the BET algorithm. mBET i,k = 1 ¯Ri(t −1) (2.4) Moreover, the authors of [136] evaluate the performance of video streaming using the MT, the PF and the Round Robin (RR) which allocates resources sequentially to users. Simulation results showed that the PF algorithm achieves a higher Mean Opinion Score (MOS) and throughput for a large number of users, while the MT performs better in terms of the Freezing Delay Ratio (FDR). 2.2.2 QoS Aware Schedulers In [137] a QoS aware downlink scheduler is proposed which considers requirements of Guar- anteed Bit Rate (GBR) and non - Guaranteed Bit Rate (non-GBR) bearers as well as channel conditions for resource allocation. Scheduling is performed in two phases. At the time domain (TD) phase a list of GBR and a list of non-GBR users requiring transmission are created and their priorities are defined. At the frequency domain (FD) phase the allocation of users to RBs is performed. Evaluation results showed that the suggested scheduler can handle effectively VoIP, Video, HTTP and FTP traffic. The authors of [138] propose a scheduling algorithm in wireless networks which uses a utility function to perform resource allocation for both QoS aware and Best Effort (BE) traffic. Numerical results showed that the proposed solution satisfies users with various QoS requirements while it provides fairness to BE users. The Modified Largest Weighted Delay First (M-LWDF) and the Exponential/PF (EXP/PF) QoS aware schedulers are described in [139] and [140], respectively. Both algorithms extend the PF metric by taking into consideration network factors such as delays and packet losses that affect the service quality. Specifically, the M-LWDF metric is estimated using formula 2.5, while the EXP/PF metric is calculated by formula 2.6. The DHOL,i parameter represents the head of line delay. Additionally, the αi value is determined by formula 2.7, where δi is the target packet loss ratio and τi is the delay constraint. Finally, the X value is calculated by formula 2.8, where Nrt is the number of active real time flows. Numerical results showed that the M-LWDF scheduler performs better when the network load is low, while the EXP/PF algorithm gives better results when the load increases. mM−LWDF i,k = ai ·DHOL,i ·mPF i,k (2.5)
  • 50. 24 Resource Allocation - Scheduling m EXP/PF i,k = exp( ai ·DHOL,i −X 1− √ X )·mPF i,k (2.6) αi = − logδi τi (2.7) X = 1 Nrt · Nrt ∑ i=1 ai ·DHOL,i (2.8) The LOG RULE and the EXP RULE schedulers presented in [141] take into account the head of line packet delay and the channel quality reported by UEs, to support delay sensitive flows. The LOG RULE metric is estimated using formula 2.9, where Γi k is the spectral efficiency for the ith user on the kth subchannel. The EXP RULE metric is estimated using formula 2.10, where bi and c are configurable parameters. Simulation results showed that both LOG RULE and EXP RULE could guarantee delay constraints by configuring scheduler parameters according to the users’ target delays. mLOGRULE i,k = bi ·log(c+ai ·DHOL,i)·Γi k (2.9) mEXPRULE i,k = bi ·exp( ai ·DHOL,i c+ (1/Nrt)∑j DHOL,j )·Γi k (2.10) The FLS scheduler described in [142] implements a two level QoS aware strategy. The upper level uses formula 2.11 to estimate the ui(k) quota of data that the ith real time flow must transmit at the kth frame to satisfy its QoS constraints. In this formula, qi(k) represents the queue length in the kth frame, Mi the number of coefficients used and ci(n) the nth coefficient value. Coefficients are used in order to guarantee the required delay constraints for real time flows. The number Mi of coefficients is estimated using formula 2.12, where τi represents the target delay. Additionally, the coefficient value ci(n) is determined by formula 2.13. The lower level uses the PF metric to allocate network resources to real time flows for transmitting their quota of data, whereas the remaining resources are allocated to best effort flows. Simulation results showed that the proposed model improves the performance of real time flows compared to the EXP RULE and LOG RULE schedulers. ui(k) = qi(k)+ Mi ∑ n=2 [qi ·(k −n+1) −qi ·(k −n+2)−ui ·(k −n+1)]·ci(n) (2.11) τi = (Mi +1)·Tf (2.12)
  • 51. 2.3 The Proposed FLS Advanced (FLSA) Scheduler 25 Best-effort queue Real-time queues YES ui(t) Link Adaptation CQI Middle Level (M-LWDF) Schedule RBs in TTI for ui(t) data ds Upper Level (FLSA) Compute data to be transmitted ui(t) ds Free RBs? Lower Level (M-LWDF) Schedule RBs in TTI for: 1. qi-ui(t) data for real time flows 2. Best effort flows Figure 2.2 The Three-Level Scheduler. ci(n) =    0 , when n = 0 1 , when n = 1 ci(n−1)/2 , when n ≥ 2 (2.13) The work described in [133] classifies the LTE downlink schedulers into five categories namely the channel-unaware, the channel-aware/QOS-unaware, the channel-aware/QoS-aware, the semi-persistent for VoIP support and finally the energy aware scheduling algorithms. Simulations that performed for the channel-aware/QoS-aware category showed that the FLS scheduler outperforms the M-LWDF, the EXP/PF, the EXP RULE and the LOG RULE in terms of packet losses and packet delays as the number of video flows increases. 2.3 The Proposed FLS Advanced (FLSA) Scheduler This section describes the proposed FLSA scheduler which aims at the optimization of real time flows in the LTE downlink. It has been built on three distinct levels as presented in Figure 2.2. The three levels cooperate to dynamically assign radio resources to users in each TTI. The real time flows receive a higher priority than the best effort ones because of their strict service constraints.
  • 52. 26 Resource Allocation - Scheduling 2.3.1 The Upper Level of the Scheduler The upper level of FLSA uses formula 2.11 of FLS to estimate the quota ui(k) of data that the ith real time flow should transmit in each kth TTI, to satisfy its QoS constraints. In other words, ui(k) quota is estimated in each kth TTI of a frame, whereas in FLS it is estimated once at the beginning of each kth frame. Performance improvement has been observed due to the fact that in FLS, when a real time flow transmits its ui(k) quota of data, it loses the opportunity to continue the transmission until the beginning of the next frame. By recalculating the formula 2.11 in each TTI (instead of estimating it only at the beginning of each frame), the FLSA provides more resources to real time flows that have remaining data for transmission. 2.3.2 The Middle Level of the Scheduler In every TTI, the middle level uses the M-LWDF scheduler to allocate resource blocks (RBs) to real time flows for transmitting their ui(t) quota of data obtained from the upper level. Parameters such as the signal to interference plus noise ratio (SINR), the throughput, the head of line delay, the target delay, the target packet loss ratio and the queue length, are considered according to formula 2.5. Moreover, the use of the QoS aware M-LWDF scheduler realizes an improved resource distribution among the real time flows in comparison with the FLS scheduler which at the second level uses the non-QoS aware PF algorithm. 2.3.3 The Lower Level of the Scheduler The third level has been added to allocate the remaining RBs of each TTI to both real time and best effort flows using the M-LWDF algorithm, in a way similar to [143]. The RBs are allocated to real time flows for transmitting their qi −ui(t) data, where qi denotes the queue length for the flow i, as well as to best effort flows, considering the fact that the latter have no specific service constraints. In comparison with the FLS scheduler, which allocates the remaining RBs only to best effort flows using the PF scheduler, this level of FLSA further improves the resource distribution in a QoS aware manner. 2.3.4 Performance Evaluation of the FLSA The performance of the FLSA was evaluated against the PF, M-LWDF, EXP/PF, FLS, EXP- RULE and LOG-RULE schedulers. For the EXP-RULE metric the used parameter set is ai ∈ [5/(0.99·τi),10/(0.99·τi)], bi = 1/E[Γi] and c = 1 as proposed in [144] for best perfor- mance. Table 2.5 summarizes the factors considered by each scheduler for resource allocation, demonstrating that the FLSA is the most complete strategy, since it considers the entire factors.
  • 53. 2.3 The Proposed FLS Advanced (FLSA) Scheduler 27 Table 2.2 The Parameters considered in each Scheduler in comparison with the ones considered by the FLSA. Scheduler SINR Throughput HOL Delay Max. Delay Max. PLR Queue Length PF x x M-LWDF x x x x x EXP/PF x x x x x FLS x x x x FLSA x x x x x x EXP RULE x x x x LOG RULE x x x x Figure 2.3 The Topology Simulated for the Evaluation of the FLSA Scheduler. In the simulations, an LTE network topology composed of 19 cells is considered. Each cell contains 1 eNB with 43 dBm transmission power and 10 MHz downlink bandwidth providing 50 RBs available for allocation per TTI. The system sub-frequencies have been distributed to cells using a reuse factor equal to 2 as presented in Figure 2.3, to avoid interference between neighbor cells. A full bandwidth periodic Channel Quality Indication (CQI) reporting scheme is applied and each user equipment (UE) reports its downlink Signal to Interference plus Noise Ratio (SINR) to eNB, in every TTI. The eNB quantizes the reported SINR value and calculates the CQI as described in [145], Then, it uses the CQI to guarantee a maximum block error rate (BLER) less than 10% regardless of the scheduling strategy applied. A number of users, between the range [10, 40], is moving inside the borders of each eNB according to the random way-point mobility model. Each user receives two real time flows, including an H264 video with bitrate equal to 440 kbps and a voice over IP (VoIP) using the G.729 codec. Furthermore, one best effort flow is added as background traffic. Table 2.6 summarizes the simulation parameters. In general, QoS aware schedulers increase the packet loss ratio (PLR) as they try to maintain the required target delay. This strategy is based on the assumption that real time services such as VoIP and video have no advantages of receiving expired packets. Thus, since the delay constraint is satisfied, the algorithms are evaluated in terms of PLR, so as to have a
  • 54. 28 Resource Allocation - Scheduling Table 2.3 The Simulation Parameters for the Evaluation of the FLSA Scheduler. Parameter Value Simulation time 100 seconds Downlink bandwidth 10 MHz Modulation QPSK, QAM-16 and QAM-64 Number of cells 19 Cell radius 0.5 km Number of users up to 40 users per cell Users mobility Random way point Traffic models Real time traffics: H264 video at 440 kbps, VoIP using G.729 codec Best effort traffic: Web Figure 2.4 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio using Different Target Delays. comprehensive view about the performance improvements. Figures 2.4 and 2.5 illustrate the impact of the target delay parameter in the PLR for VoIP and video flows, respectively, for the case of having 20 users per cell. While the target delay increases from 50ms to 150ms, the PLR decreases. Additionally, it may be observed that FLSA compared with FLS exhibits a lower PLR by up to 7%. In Figures 2.6 and 2.7, the PLR for the VOIP and video flows is presented as the number of cell users varies from 10 to 40. The considered target delays are set to 100ms and 150ms for VoIP and video flows respectively, as determined by the LTE QoS class specifications for these service types [146]. As shown, FLSA results in a lower PLR than the rest of the algorithms. FLSA shows a marginal decrease of its PLR compared to FLS for VoIP flows. Also, its PLR is 10% lower than that of FLS for video flows. The analysis of the throughput provides an important insight on the performance of the FLSA in comparison with the other schedulers. As presented in Figures 2.8 and 2.9 the FLSA outperforms the rest of the schedulers, independently of the number of users for VoIP and video
  • 55. 2.3 The Proposed FLS Advanced (FLSA) Scheduler 29 Figure 2.5 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio using Different Target Delays. Figure 2.6 Evaluation of the FLSA Scheduler in terms of VoIP Packet Loss Ratio. Figure 2.7 Evaluation of the FLSA Scheduler in terms of Video Packet Loss Ratio.
  • 56. 30 Resource Allocation - Scheduling Figure 2.8 Evaluation of the FLSA Scheduler in terms of VoIP Throughput. Figure 2.9 Evaluation of the FLSA Scheduler in terms of Video Throughput. flows, respectively. This is expected due to the recalculation of formula 2.11 in each TTI by the upper level of FLSA as well as the inclusion of the lower level in the scheduler. The FLSA achieves higher throughputs than the rest of the algorithms providing rates of up to 330kbps for VoIP and up to 4.7 Mbps for video services. The proposed scheduler is also evaluated in terms of the Jain fairness index, which is estimated using formula 2.14 where n is the number of the service flows and xi is the throughput of the ith flow. Jain_Fairness = (∑n i=1 xi)2 n·∑n i=1 x2 i (2.14) Flows with the same service constraints must receive similar QoS to avoid the situation of having a set of satisfied users against a set of dissatisfied ones of the same service type. The maximum value of fairness is 1 while the more a scheduler accomplishes a value close to 1, the more the resource allocation is fair. As presented in Figure 2.10 the fairness for VoIP flows is
  • 57. 2.3 The Proposed FLS Advanced (FLSA) Scheduler 31 Figure 2.10 Evaluation of the FLSA Scheduler in terms of VoIP Fairness Index. Figure 2.11 Evaluation of the FLSA Scheduler in terms of Video Fairness Index. very close to 1. Additionally, Figure 2.11 demonstrates that the FLSA scheduler improves the fairness for the video flows compared with the rest of the schedulers.
  • 58. 32 Resource Allocation - Scheduling 2.4 The Proposed FLS Advanced - Cross Carrier (FLSA- CC) Scheduler This section describes the proposed FLSA-CC scheduler (Fig. 2.12) which aims at the opti- mization of system performance using carrier aggregation in the LTE downlink. The FLSA-CC improves the FLSA scheduler in a cross carrier manner adapting the resource allocation process at different channel conditions of the aggregated component carriers. Furthermore, due to the fact that in the Cross Carrier Scheduling (CCS) methodology adopted by this scheduler, only the PCC uses the PDCCH channel for transmission of scheduling information, an interference decrement is observed resulting in better channel conditions in terms of SINR, thus increasing the overall system capacity. The FLSA-CC has been built upon three distinct levels, which cooperate with each other for dynamically assigning radio resources to users in each TTI. The upper level of FLSA-CC uses the formula (2.11) of the FLS [142] to estimate the ui(x) quota of data that the ith real time flow should transmit in each xth TTI, in order to satisfy its QoS constraints. In other words, ui(x) quota is estimated in each xth TTI of a frame, whereas in FLS it is estimated once, at the beginning of each frame. The FLSA-CC estimates the coefficient value ci(n) using formula (2.15), where N represents the number of component carriers. A performance improvement has been observed due to the fact that in FLS, when a real time flow transmits its ui(x) quota of data, it loses the opportunity to continue the transmission until the beginning of the next frame. By recalculating the formula (2.11) in each TTI (instead of estimating it only at the beginning of each frame), the FLSA-CC provides more resources to real time flows that have remaining data for transmission. ci(n) =    n , when 0 ≤ n ≤ 1 ci(n−1)/(2·N) , when n ≥ 2 (2.15) In each TTI, the middle level uses a cross carrier version of the MLWDF scheduler, called MLWDF-CC, to allocate RBs to real time flows for transmitting their ui(x) quota of data which have been calculated by the upper level. This scheduler extends the PF-CC metric [147] [148] mPF−CC i,k given in formula (2.16). The MLWDF-CC metric is evaluated by formula (2.17) where the αi value is determined by formula (2.7). The use of the cross carrier QoS aware MLWDF-CC scheduler achieves an improved resource distribution among the real time flows in comparison with the FLS scheduler which at the second level uses the non-cross carrier principle as well as the non-QoS aware PF algorithm. The third level has been added to allocate the remaining RBs of each TTI to best effort flows using formula (2.16) of the PF-CC algorithm. mPF−CC i,k = di k(t) ∑N j=1 ¯Ri,j(t −1) (2.16)
  • 59. 2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler 33 Figure 2.12 The FLSA-CC Scheduler Design. mMLWDF−CC i,k = ai ·DHOL,i ·mPF−CC i,k (2.17) 2.4.1 Simulation Environment for the FLSA-CC Evaluation The simulation environment is implemented using an extended version of the Lte-Sim [145] simulator. More specifically, the iCanCloud [149] and the OpenFlow [150] modules of the Omnet++ [151] simulator have been configured and embedded to the Lte-Sim enabling the ability to include a cloud infrastructure and SDN controllers to the simulated LTE topologies. The simulation environment consists of an LTE Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) and a Cloud infrastructure. The E-UTRAN includes 7 DeNBs and 28 RNs (4 per DeNB). The transmission radius is equal to 1 kilometer for each DeNB and 100 meters for each RN. Each RN is positioned at 90% of the transmission radius of its DeNB. Furthermore, Type-1 Outband Relaying is applied and thus two link types are defined, namely the access link and the backhaul link. The access link is used for communication between a UE and an RN or a DeNB using a frequency f1, while the backhaul link is used for communication between an RN and a DeNB using a frequency f2 ̸= f1. Inter-band Carrier Aggregation (CA) is applied in each DeNB and RN. According to this CA configuration, two component carriers, which belong to different frequency bands, are aggregated. Each component carrier bandwidth is equal to 20MHz and contains 100 resource blocks. Thus, a 40MHz bandwidth is assigned to each cell (RN or DeNB) and a total of 200 RBs are available for scheduling in each TTI. Table 2.4 presents the system sub-frequencies assigned to each cell.
  • 60. 34 Resource Allocation - Scheduling Table 2.4 The Sub-Frequencies that are assigned to each Cell. Cell Aggregated Component Carriers DeNB0 PCC: 1805 MHz − 1825 MHz (band 3) SCC: 760 MHz − 780 MHz (band 28) DeNB1,3,5 PCC: 1825 MHz − 1845 MHz (band 3) SCC: 870 MHz − 890 MHz (band 5) DeNB2,4,6 PCC: 2110 MHz − 2130 MHz (band 1) SCC: 940 MHz − 960 MHz (band 8) Relay nodes Case 1 PCC: 2620 MHz − 2640 MHz (band 7) SCC: 780 MHz − 800 MHz (band 28) Case 2 PCC: 2640 MHz − 2660 MHz (band 7) SCC: 800 MHz − 820 MHz (band 20) The 3GPP urban channel model [152] [153] is used. Since the channel between DeNB or RN and UE encounters non-line-of-sight (NLOS) transmission, its propagation loss is estimated using formula (2.18) and (2.19), for DeNB-UE and RN-UE communication respectively, where d represents the distance among the nodes and fc the carrier frequency. Also, since the channel between a DeNB and an RN encounters line-of-sight (LOS) transmission, its propagation loss is estimated using formula (2.20). PLNLOS DeNB→UE = 37.6·log10(d)+58.94+21·log10(fc) (2.18) PLNLOS RN→UE = 36.7·log10(d)+22.7+26·log10(fc) (2.19) PLLOS DeNB→RN = 22·log10(d)+28+20·log10(fc) (2.20) The Cloud contains a set of virtual machines (VMs) and implements the functionalities of the LTE Evolved Packet Core (EPC). Additional VMs with user applications are created. Specifically, one VM is created for each UE running three applications namely one VoIP, one video and one best effort. Flow forwarding as well as resource scheduling in each DeNB and RN are performed using a centralized global controller placed into the Service Gateway (SGW) having a wide view of the entire system. The simulated topology is presented in Figure 2.13. 2.4.2 Performance Evaluation of the FLSA-CC Algorithm The performance of the FLSA-CC was evaluated against the PF, MLWDF, EXP/PF, FLS, FLSA, EXP-RULE and LOG-RULE schedulers. For the EXP-RULE metric the used parameter set is ai ∈ [5/(0.99 · τi),10/(0.99 · τi)], bi = 1/E[Γi] and c = 1 as proposed in [144] for best performance. Table 2.5 summarizes the factors considered by each scheduler for resource allocation, demonstrating that the FLSA-CC is the most complete strategy. Furthermore, the full band periodic Channel Quality Indication (CQI) reporting scheme is applied. Thus, each UE reports its downlink SINR to RN for each component carrier in every TTI. The RN quantizes
  • 61. 2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler 35 Figure 2.13 The Topology Simulated for the Evaluation of the FLSA-CC Scheduler. the reported SINR value and calculates the CQI as described in [145]. Then, it uses the CQI to guarantee a maximum BLER less than 10% regardless of the scheduling strategy applied. Table 2.5 The Parameters considered in each Scheduler in comparison with the ones considered by the FLSA-CC. Scheduler SINR Throughput HOL Delay Max. Delay Max. PLR Queue Length CCS PF MLWDF EXP/PF FLS FLSA FLSA-CC EXP RULE LOG RULE A number of users move inside the borders of each RN according to the random way-point mobility model. Each user receives two real time flows, an H264 video with bitrate equal to 440 kbps and a Voice over IP (VoIP) using the G.729 codec. Furthermore, one best effort flow is added as background traffic. Table 2.6 summarizes the simulation parameters. 2.4.2.1 Real Time Services Results Due to the fact that the simulation environment includes an LTE topology with RNs, a two hop target delay for real time flows τi = τi,DeNB→RN +τi,RN→UE is considered, where τi,DeNB→RN
  • 62. 36 Resource Allocation - Scheduling Table 2.6 The Simulation Parameters for the Evaluation of the Proposed Algorithm. Parameter Value Simulation time 100 seconds Downlink bandwidth 2*20 = 40 MHz Modulation QPSK, QAM-16 and QAM-64 DeNBs number / radius 7 / 1 km Relay nodes number / radius 4 per DeNB / 100 m Number of users up to 100 users per relay node Users mobility Random way point Traffic models Real time: H264 video at 440 kbps VoIP using G.729 codec Best effort: Web Figure 2.14 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the Real Time Flows using Different Target Delays. represents the target delay between a DeNB and an RN, and τi,RN→UE represents the target delay between an RN and a UE. We consider τi,DeNB→RN = τi,RN→UE. In general, QoS aware schedulers increase the packet loss ratio (PLR) to guarantee the required τi. This strategy is based on the assumption that real time services such as VoIP and Video can not use expired packets. Thus, since the delay constraint is satisfied, the algorithms are evaluated in terms of PLR, so as to have a comprehensive view about the performance improvements. Figure 2.14 illustrates the impact of the target delay parameter τi in the PLR for VoIP and video flows, for the case of having 100 users per RN. As the target delay increases from 50ms to 150ms, the PLR decreases. Additionally it may be observed that FLSA-CC compared with FLSA exhibits lower PLR independently of the target delay parameter. In Figure 2.15, the PLR for VOIP and video flows is presented while the number of cell RN users varies from 20 to 100. In this case, the considered target delays are set to 100ms and 150ms for VoIP and video flows respectively, as determined by the LTE QoS class specifications for these service types. As shown, FLSA-CC results in a lower PLR than the rest
  • 63. 2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler 37 Figure 2.15 The FLSA-CC Scheduler Evaluation in terms of the Packet Loss Ratio of the Real Time Flows. Figure 2.16 The FLSA-CC Scheduler Evaluation in terms of the Throughput of the Real Time Flows. of the algorithms. Specifically, FLSA shows a marginal decrease of its PLR for VoIP flows as well as up to a 3% lower PLR for video flows compared to FLSA. The analysis of the throughput offered to real time services provides an important insight on the performance of the FLSA-CC in comparison with the other schedulers. As presented in Figure 2.16 the FLSA-CC outperforms the rest of the schedulers, independently of the number of users for VoIP and video flows. This is expected due to the cross carrier scheduling operating principle applied as well as due to the recalculation of formula (2.11) in each TTI by the upper level of the FLSA-CC. More specifically, the FLSA-CC achieves higher throughputs than the rest of the algorithms providing rates of up to 800kbps for VoIP and up to 28Mbps for video services. The proposed scheduler is also evaluated in terms of Jain fairness index, which is estimated using formula 2.14. Figure 2.17 demonstrates that the FLSA-CC scheduler improves the fairness for both VoIP and video flows.
  • 64. 38 Resource Allocation - Scheduling Figure 2.17 The FLSA-CC Scheduler Evaluation in terms of the Fairness Index of the Real Time Flows. 2.4.2.2 Best Effort Services Results In this subsection tne FLSA-CC, FLSA and FLS schedulers, which accomplish better per- formance for real time services are evaluated for best effort flows in terms of the throughput and the fairness index. As presented in Figure 2.18, the FLSA-CC outperforms the other two schedulers and provides a throughput up to 1.5Mbps for best effort flows even when the number of users increases, while the FLSA accomplishes only a 100kbps throughput. Additionally, the FLSA-CC scheduler significantly improves the fairness index of the best effort flows. Figure 2.18 The FLSA-CC Scheduler Evaluation in terms of the Throughput and the Fairness Index of the Best Effort Flows.
  • 65. Chapter 3 Mobility Management 3.1 Related Methodologies 3.1.1 Fuzzy Logic 3.1.1.1 The Interval-Valued Trapezoidal Fuzzy Numbers (IVTFN) The concept of fuzzy logic was introduced by Zadeh [154] and is used to make a decision from indeterminate and approximate information. A fuzzy number is represented by a set of real values representing an uncertain quantity and a convex normalized continuous function which estimates the degree of membership for each value in the subset. Triangular or trapezoidal fuzzy numbers are frequently used to represent uncertain information. A trapezoidal fuzzy number can be defined as a vector x = (x1,x2,x3,x4,v ˆA) with a membership function µ(x): µ(x) =    x−x1 x2−x1 , if x1 ≤ x < x2; v ˆA, if x2 ≤ x ≤ x3; x−x4 x3−x4 , if x3 < x ≤ x4; 0, otherwise. (3.1) where x1 < x2 < x3 < x4 and v ˆA ∈ [0,1]. An Interval-valued fuzzy number (IVFN) was introduced by Sambuc [155]. An IVFN is defined as A = [AL,AU] consisting of the lower AL and the upper AU fuzzy numbers. IVFNs replace the crisp membership values by intervals in [0,1]. They were proposed due to the fact that fuzzy information can be better expressed by intervals than by single values. Liu and Jin [156] and Cornelis et al. [157] suggest that IVFNs are useful in multiple criteria decision making (MCDM) problems and particularly in cases where attribute values are in the form of linguistic expressions. Therefore, Ashtiani et al. [158] propose an extension of the fuzzy TOPSIS method using interval-valued triangular fuzzy numbers. Moreover, Liu and Jin [156] propose a decision making method using weighted geometric aggregation operators on attribute values expressed in the form of interval-valued trapezoidal fuzzy numbers. According to the
  • 66. 40 Mobility Management definition in [158], an IVFS A is defined as follows: A = {(x,[µL A(x),µU A (x)])} (3.2) µL A(x),µU A (x) : X → [0,1]∀x ∈ X,µL A(x) < µU A (x) (3.3) ˆµA(x) = [µL A(x),µU A (x)] (3.4) A = {(x, ˆµA(x))},x ∈ (−∞,∞) (3.5) In particular, the interval-valued trapezoidal fuzzy number defined in [159], is a general form of fuzzy number (Figure 3.1). This number can be represented as: A = [AL,AU] = [(xL 1,xL 2,xL 3,xL 4,vAL),(xU 1 ,xU 2 ,xU 3 ,xU 4 ,vAU ))] where: 0 ≤ xL 1 ≤ xL 2 ≤ xL 3 ≤ xL 4 ≤ 1, 0 ≤ xU 1 ≤ xU 2 ≤ xU 3 ≤ xU 4 ≤ 1, 0 ≤ vAL ≤ vAU ≤ 1 and AL ⊂ AU. The operational rules of the interval-valued trapezoidal fuzzy numbers are defined in [159]. Figure 3.1 The Interval-Valued Trapezoidal Fuzzy Numbers. 3.1.1.2 The Interval-Valued Pentagonal Fuzzy Numbers (IVPFN) A pentagonal fuzzy number can be defined as a vector x = (x1,x2,x3,x4,x5,v ˆA,v ˆA1,v ˆA2) with membership function: µ(x) =    v ˆA1 · x−x1 x2−x1 , if x1 x < x2; v ˆA −(v ˆA −v ˆA1)· x−x2 x3−x2 , if x2 x < x3; v ˆA, if x = x3; v ˆA −(v ˆA −v ˆA2)· x−x3 x4−x3 , if x3 < x x4; v ˆA2 · x−x5 x4−x5 , if x4 < x x5; 0, otherwise. (3.6) where x1 x2 x3 x4 x5 and v ˆA,v ˆA1,v ˆA2 ∈ [0,1].
  • 67. 3.1 Related Methodologies 41 The interval-valued pentagonal fuzzy number is a general IVFN case (Figure 3.2) defined as: A = [AL,AU] = [(xL 1,xL 2,xL 3,xL 4,xL 5,vL A,vL A1,vL A2),(xU 1 ,xU 2 ,xU 3 ,xU 4 ,xU 5 ,vU A , vU A1,vU A2))] where: AL ⊂ AU, 0 xL 1 xL 2 xL 3 xL 4 xL 5 1, 0 xU 1 xU 2 xU 3 xU 4 xU 5 1, vL A vU A , vL A1 vL A2 vL A, vU A1 vU A2 vU A and vL A,vL A1,vL A2,vU A ,vU A1,vU A2 ∈ [0,1]. The operational rules of the interval-valued pentagonal fuzzy numbers are defined in [160]. U x1 L x2 U x2 L x3 L x3 U x4 L x4 U x1 U AL AU 0 1 1x5 L x5 U 1 1 2 2 uL A uL A uL A uA UuA UuA , , Figure 3.2 The Interval-Valued Pentagonal Fuzzy Numbers. 3.1.1.3 Creating Fuzzy Numbers: The Equalized Universe Method (EUM) The Equalized Universe Method (EUM) [161] [162] creates IVFNs with their centroids equally spaced along a predefined domain of values. The values of the ith IVPFN are calculated using formula 3.7, where Umin and Umax are the minimum and maximum value of the domain and c represents the number of the IVPFNs created. The vL A1, vU A1, vL A2 and vU A2 are defined by the user. IVPFNi =    xU i,1 = xU i,2 − Umax−Umin 4·(c−1) ,xL i,1 = xU i,1 ·(vL A1/vU A1) xU i,2 = xU i,3 − Umax−Umin 2·(c−1) ,xL i,2 = xU i,2 ·(vL A1/vU A1) xU,L i,3 = Umin + Umax−Umin c−1 ·(i−1) xU i,4 = xU i,3 + Umax−Umin 2·(c−1) ,xL i,4 = xU i,4 ·(vL A2/vU A2) xU i,5 = xU i,4 + Umax−Umin 4·(c−1) ,xL i,5 = xU i,5 ·(vL A2/vU A2) (3.7) 3.1.1.4 The Mamdani Pentagonal Fuzzy Inference System (MPFIS) Fuzzy Inference (FI) [163–165] involves the mapping of a given input to an output using fuzzy logic. The Mamdani Pentagonal Fuzzy Inference System (MPFIS) considers two inputs (Input1 and Input2) to estimate the value of the Output. Both Input1 and Input2 have normalized values within the range [0, 1]. Also, the MFInput1, MFInput2, MFOutput membership functions (MF) are defined, indicating the linguistic terms and the corresponding Interval Valued Pentagonal Fuzzy Numbers (IVPFN) for the fuzzy representation of the Input1, Input2 and Output, respectively.
  • 68. 42 Mobility Management Thus, for each crisp value, two membership degrees are determined in the corresponding MF, one for the upper pentagon and one for the lower pentagon. The MPFIS implements the following methods: Step 1. Membership Functions Definition: The Membership Functions (MF) for Input1, Input2 and Output parameters are defined. Step 2. Fuzzy rule (or knowledge) base: A set R of fuzzy rules is defined, where each rule r ∈ R is a simple if-then statement with a condition and a conclusion. The rule’s condition consists of MFInput1 and MFInput2 membership functions, while its conclusion indicates an MFOutput membership function. Step 3. Fuzzification: The Input1 and Input2 crisp values are converted to degrees of member- ship indicated as Input′ 1 and Input′ 2 by a lookup in MFInput1 and MFInput2 membership functions respectively. Step 4. Combination of the fuzzified inputs (Fuzzy Operations): A Z′ r degree is calculated considering the rule’s condition, that indicates the strength of the r rule. Furthermore, in case that a rule’s condition has multiple parts, the fuzzy operators ‘AND’ and ‘OR’ may be used to combine more than one conditions. The ‘Algebraic product’ and the ‘Algebraic sum’ are applied for the ‘AND’ and the ‘OR’ operators respectively. In our study, the ‘Algebraic product’ is calculated using formula 3.8, while the ‘Algebraic sum’ is calculated using formula 3.9. Z′ u,i,r = Input′ 1ˆ·Input′ 2 = Input′ 1 ·Input′ 2 (3.8) Z′ u,i,r = (Input′ 1 +Input′ 2)−(Input′ 1 ·Input′ 2) (3.9) Step 5. Implication method: The implication method estimates the consequence MFOutputc r of the rule conclusion, considering both the rule conclusion MFOutputr and the rule strength Z′ r. The MFOutputr height is trimmed with respect to the Z′ r degree, using formula 3.10, which applies the Min method. MFOutputc rHeight = min{MFOutputrHeight ,Z′ r} (3.10) Step 6. Aggregation method: The aggregation method combines the R rules’ consequences to calculate the OutputA fuzzy set, using formula 3.11, which applies the Max method. OutputA = MFOutputc 1 ∪MFOutputc 2 ∪...∪MFOutputc R (3.11)
  • 69. 3.1 Related Methodologies 43 Step 7. Defuzzification: During the defuzzification, the OutputA fuzzy set is transformed to the crisp value Output. Formula 3.31 that applies the Weighted Average method is used, where µr is the height and hr is the centroid of each rule obtained from the OutputA. Also, symbols U and L represent the upper and the lower pentagon of each rule respectively . Output = R ∑ r=1 (µU r ·hU r + µL r ·hL r ) R ∑ r=1 (hU r +hL r ) (3.12) 3.1.2 Estimating the Mobility Management Criteria Importance 3.1.2.1 The Analytic Network Process (ANP) The Analytic Network Process (ANP) was introduced by Saaty [166] to deal with decision problems with criteria and alternatives that depend on each other. ANP is a generalization of the Analytic Hierarchy Process (AHP). A decision problem that is analyzed with the ANP can be designed either as a control-hierarchy or as a non-hierarchical network. The nodes of the network represent the components (or clusters) of the system while the arcs denote the interactions between them. All the interactions and the feedbacks within the clusters are called inner dependencies, while the interactions and the feedbacks between clusters are called outer dependencies. ANP is composed of four major steps [167]: Step 1. Model construction and problem structuring: During this step the problem is analyzed and decomposed into a rational system, like a network. Step 2. Pairwise comparison matrices and priority vectors: During this step, the pairwise comparison matrix is derived using Saaty’s nine-point importance scale based (Table 3.1). Table 3.1 The Saaty’s Nine-Point Importance Scale. Importance Definition 1 Equal Importance 3 Moderate Importance 5 Strong Importance 7 Very Strong Importance 9 Extreme Importance 2, 4, 6, 8 Intermediate Values Step 3. Supermatrix formation: During this step, the supermatrix of the ANP model is con- structed to represent the inner and the outer dependencies of the network. This is a
  • 70. 44 Mobility Management partitioned matrix, where each matrix segment represents a relationship between two clusters in the network. To construct the supermatrix the local priority vectors obtained in Step 2 are grouped and placed in the appropriate positions in a supermatrix based on the flow of influence from one cluster to another, or from a cluster to itself, as in the loop. Then, the supermatrix is transformed to a stochastic one, the weighted superma- trix. Finally, the weighted supermatrix is raised to limiting powers until all the entries converge to calculate the overall priorities, and thus the cumulative influence of each element on every other element with which it interacts is obtained [168]. At this point, all the columns of the new matrix, the limit supermatrix, are the same and their values show the global priority of each element of the network. For example, if we assume a network with n clusters, where each cluster Ck,k = 1,2,...,n, and has mn elements, denoted as ek1,ek2,...,ekmk , then the standard form, W, for a supermatrix can be expressed as: W = C1 ... Ck ... Cn e11 ...e1m1 ... ek1 ...ekmk ... en1 ...enmn                                                     e11 C1 ... W11 ... W1k ... W1n e1m1 ... ... ... ... ... ... ek1 Ck ... Wk1 ... Wkk ... Wkn ekmk ... ... ... ... ... ... en1 Cn ... Wn1 ... Wnk ... Wnn enmn (3.13) Step 4. Selection of the best alternatives: If the supermatrix formed in Step 3 covers the whole network, then the priority weights of the alternatives can be found in the column of the alternatives in the normalized supermatrix. Otherwise, additional calculations are required in order to obtain the overall priorities of the alternatives. The alternative with the largest overall priority should be selected, as it is the best alternative as determined by the calculations made using matrix operations.
  • 71. 3.1 Related Methodologies 45 3.1.3 The Trapezoidal Fuzzy Analytic Network Process (TF-ANP) A decision problem that is analyzed with the TF-ANP can be represented as a network of nodes. Each node represents a component (or cluster) of the system while arcs denote interactions between them. Interactions and feedbacks within clusters are called inner dependencies, while interactions and feedbacks between clusters are called outer dependencies. The TF-ANP is composed of five major steps: Step 1. Model Construction and Problem Structuring: During this step the problem is analyzed and decomposed into a rational system, consisting of a network of nodes. Step 2. Pairwise comparison matrices and priority vectors: In this step, initially the fuzzy pairwise comparison matrix ˜A is derived for each TF-ANP cluster using the linguistic terms presented in Table 3.2, which corresponds to the nine-point importance scale introduced in [166]. The standard form of the ˜A matrix is expressed as follows: ˜A =                   1 ... ˜a1 j ... ˜a1n ... ... ... 1/ ˜a1i ... 1 ... ˜ain ... ... ... 1/ ˜a1n ... 1/ ˜ajn ... 1 (3.14) where n denotes the number of the cluster elements. Subsequently, the geometric mean r ˜Ai of each row i in ˜A is estimated according to formula 3.34, where ⊗ denotes the multiplication operator of two fuzzy numbers as defined in [169]. r ˜Ai = ( ˜ai1 ⊗ ˜ai2 ⊗...⊗ ˜ain) 1 n (3.15) Then, the priority vector ˜Ωi of cluster elements is constructed as follows: ˜Ωi = [ ˜ω1 ˜ω2 ... ˜ωn ] (3.16) where each ˜ωi = (ωU 1 ,ωU 2 ,ωU 3 ,ωU 4 ,vU i );(ωL 1 ,ωL 2 ,ωL 3 ,ωL 4 ,vL i ) is calculated using for- mula 3.36. The ⊕ indicates the addition operator of two fuzzy numbers as defined in [169]. ˜ωi = r ˜Ai /(r ˜A1 ⊕r ˜A2 ⊕...⊕r ˜Ai ⊕...⊕r ˜An ) (3.17) Step 3. Construction of the Supermatrix: In this step, the fuzzy supermatrix ˜W of the TF-ANP model is constructed. This matrix represents the inner and outer dependencies of the TF-ANP network. It is a partitioned matrix, with each matrix segment representing the relationship between two clusters of the network. To construct the supermatrix, the local priority vectors ˜Ω are grouped and placed in the appropriate positions in the supermatrix
  • 72. 46 Mobility Management based on the flow of influence from one cluster to another, or from a cluster to itself, as in the loop. For example, if we assume a TF-ANP network of q clusters, Ck with k = [1,2,...,q] and that each cluster has nq elements, denoted as ek1,ek2,...,eknk , then the supermatrix ˜W is expressed as: ˜W = C1 ... Ck ... Cq e11...e1n1 ... ek1...eknk ... eq1...eqnq                                                     e11 C1 ... ˜W11 ... ˜W1 j ... ˜W1q e1n1 ... ... ... ... ... ... ek1 Ck ... ˜Wk1 ... ˜Wk j ... ˜Wkq eknk ... ... ... ... ... ... eq1 Cq ... ˜Wq1 ... ˜Wqj ... ˜Wqq eqnq (3.18) Step 4. Construction of the Weighted Supermatrix: During this step, the supermatrix is trans- formed to a stochastic one,the Weighted Supermatrix ˜W′ using formula 3.19. ˜W′ k,j = ˜Wk,j/q (3.19) Step 5. Calculation of the Limited Supermatrix: In this step, initially the deffuzified Weighted Supermatrix W is estimated using the Weighted Average method. According to this method formula 3.20 is used, where the parameters v and d represent the height and the centroid of each ˜W′ k,j trapezoid respectively. Subsequently, W is raised to limiting powers until all the entries converge. By this way, the overall priorities are calculated, and thus the cumulative influence of each element on every other interacting element is obtained [168]. At this point, all the columns of the produced Limit Supermatrix are the same and their values show the estimated weight for each element of the TF-ANP network. Wk,j = vU ·dU +vL ·dL dU +dL (3.20) 3.1.3.1 The Trapezoidal Fuzzy Adaptive Analytic Network Process (TF-AANP) A decision problem that is analyzed with the TF-AANP can be represented as a network of nodes. Each node represents a component (or cluster) of the system while arcs denote
  • 73. 3.1 Related Methodologies 47 interactions between them. Interactions and feedbacks within clusters are called inner depen- dencies, while interactions and feedbacks between clusters are called outer dependencies. The TF-AANP is composed of seven major steps: Step 1. Estimation of the importance of each service: The fuzzy pairwise comparison matrix ˜P is derived for the services using the linguistic terms presented in Table 3.2, which correspond to the nine-point importance scale introduced in [166]. The standard form of the ˜P matrix is expressed as follows: ˜P =                   1 ... ˜p1 j ... ˜p1S ... ... ... 1/ ˜p1s ... 1 ... ˜psS ... ... ... 1/ ˜p1S ... 1/ ˜pjS ... 1 (3.21) where S denotes the number of the services. Subsequently, the geometric mean r ˜Ps of each service (row) s in ˜P is estimated according to formula 3.22, where ⊗ denotes the multiplication operator of two fuzzy numbers as defined in [169]. r ˜Ps = ( ˜ps1 ⊗ ˜ps2 ⊗...⊗ ˜psS) 1 S (3.22) Then, the priority vector ˜Ω ˜Ps of services is constructed as follows: ˜Ω ˜Ps = [ ˜ω ˜p1 ˜ω ˜p2 ... ˜ω ˜pS ] (3.23) where each ˜ω ˜ps = (ωU ˜p1,ωU ˜p2,ωU ˜p3,ωU ˜p4,vU ps);(ωL ˜p1,ωL ˜p2,ωL ˜p3,ωL ˜p4,vL ps) is calculated us- ing formula 3.24. The ⊕ indicates the addition operator of two fuzzy numbers as defined in [169]. ˜ω ˜ps = r ˜Ps /(r ˜P1 ⊕r ˜P2 ⊕...⊕r ˜Ps ⊕...⊕r ˜PS ) (3.24) Step 2. Model Construction and Problem Structuring for each service: During this step, for each service s ∈ S the problem is analyzed and decomposed into a rational system, consisted of a network of nodes. Step 3. Pairwise comparison matrices and priority vectors: In this step, for each service s ∈ S, the fuzzy pairwise comparison matrix ˜As is derived for each TF-AANP cluster using the linguistic terms presented in Table 3.2. The standard form of the ˜A matrix is expressed as follows: ˜As =                   1 ... ˜as1 j ... ˜as1n ... ... ... 1/ ˜as1i ... 1 ... ˜asin ... ... ... 1/ ˜a1sn ... 1/ ˜asjn ... 1 (3.25)
  • 74. 48 Mobility Management where n denotes the number of the cluster elements. Subsequently, the geometric mean r ˜Asi of each row i in ˜As is estimated according to formula 3.26. r ˜Asi = ( ˜asi1 ⊗ ˜asi2 ⊗...⊗ ˜asin) 1 n (3.26) Then, the priority vector ˜Ωsi of the cluster elements is constructed as follows: ˜Ωsi = [ ˜ωs1 ˜ωs2 ... ˜ωsn ] (3.27) where each ˜ωsi = (ωU s1,ωU s2,ωU s3,ωU s4,vU si );(ωL s1,ωL s2,ωL s3,ωL s4,vL si) is calculated using formula 3.36. The ⊕ indicates the addition operator of two fuzzy numbers as defined in [169]. ˜ωsi = r ˜Asi /(r ˜As1 ⊕r ˜As2 ⊕...⊕r ˜Asi ⊕...⊕r ˜Asn ) (3.28) Step 4. Construction of the Supermatrices: In this step, the fuzzy supermatrix ˜Ws of the TF- AANP model is constructed for each service representing the inner and the outer depen- dencies of the TF-AANP network. It is a partitioned matrix, with each matrix segment representing the relationship between two clusters of the network. To construct the supermatrix, the local priority vectors ˜Ωs are grouped and placed in the appropriate positions in the supermatrix based on the flow of influence from one cluster to another, or from a cluster to itself, as in the loop. For example, if we assume that we have a TF-AANP network of q clusters, Ck, with k = [1,2,...,q] and that each cluster has nq elements, denoted as ek1,ek2,...,eknk , then the supermatrix is expressed as: ˜Ws = C1 ... Ck ... Cq e11...e1n1 ... ek1...eknk ... eq1...eqnq                                                     e11 C1 ... ˜Ws11 ... ˜Ws1 j ... ˜Ws1q e1n1 ... ... ... ... ... ... ek1 Ck ... ˜Wsk1 ... ˜Wsk j ... ˜Wskq eknk ... ... ... ... ... ... eq1 Cq ... ˜Wsq1 ... ˜Wsqj ... ˜Wsqq eqnq (3.29) Step 5. Construction of the Weighted Supermatrices: During this step, the supermatrix of each service is transformed to a stochastic one,the Weighted Supermatrix ˜W′ s using formula
  • 75. 3.1 Related Methodologies 49 3.38. ˜W′ s,k,j = ˜Ws,k,j/q (3.30) Step 6. Calculation of the Limited Supermatrices: In this step, initially the deffuzified Weighted Supermatrix Ws of each service is estimated by applying the Weighted Average method. According to this method formula 3.31 is used, where the parameters vs and ds represent the height and the centroid of each ˜W′ s,k,j trapezoid respectively. Subsequently, each Ws is raised to limiting powers until all the entries converge. By this way the overall priorities are calculated, and thus the cumulative influence of each element on every other interacting element is obtained [168]. At this point, all the columns of each produced Limit Supermatrix Ls, are the same and their values show the importance of each element e of the TF-AANP network for the corresponding service s. Ws,k,j = vU s ·dU s +vL s ·dL s dU s +dL s (3.31) Step 7. Estimation of the Criteria Weights: In this step, the weight we for each element e of the TF-AANP network is calculated using formula 3.32 where the importance ˜ω ˜Ps of each service s is considered. we = S ∑ s=1 ˜ω ˜P,s ∗Ls,e (3.32) 3.1.3.2 The Pentagonal Fuzzy Analytic Network Process (PF-ANP) The Pentagonal Fuzzy Analytic Network Process (PF-ANP) method is the IVPFN version of the typical ANP [166] method, used for the calculation of the criteria weights. PF-ANP allows complex relationships within and among clusters of selection criteria using a network model of dependencies. A decision problem that is analyzed with the PF-ANP can be represented as a network of nodes. Each node represents a component (or cluster) of the system while the arcs denote the interactions between them. The interactions and the feedbacks within the clusters are called inner dependencies, while the interactions and the feedbacks between clusters are called outer dependencies. Indicatively, we could consider one cluster with network characteristics criteria such as throughput, delay, jitter and packet loss, as well as one cluster with operator policy criteria such as service reliability, security and price. In this situation, the PF-ANP will consider two clusters. The PF-ANP is composed of five major steps of selection criteria: Step 1. Model Construction and Problem Structuring: During this step the problem is analyzed and decomposed into a rational system, consisting of a network of nodes. Step 2. Pairwise comparison matrices and priority vectors: Initially the fuzzy pairwise compari- son matrix ˜A is derived for each cluster using the linguistic terms presented in Table 3.2,
  • 76. 50 Mobility Management which are calculated using the EUM method and correspond to the nine-point importance scale introduced in [166]. The standard form of the ˜A matrix is expressed as follows: ˜A =                   1 ... ˜a1 j ... ˜a1n ... ... ... 1/ ˜a1i ... 1 ... ˜ain ... ... ... 1/ ˜a1n ... 1/ ˜ajn ... 1 (3.33) where n denotes the number of the cluster elements. Subsequently, the geometric mean Table 3.2 The Linguistic Terms that are used for the Criteria Pairwise Comparisons. Linguistic term Interval-valued pentagonal fuzzy number Equally Important (EI) [(0.043, 0.062, 0.1, 0.137, 0.156, 0.8, 0.6, 0.6), (0.025, 0.05, 0.1, 0.15, 0.175, 1.0, 0.8, 0.8)] More than Equally Important (MEI) [(0.143, 0.162, 0.2, 0.237, 0.256, 0.8, 0.6, 0.6), (0.125, 0.15, 0.2, 0.25, 0.275, 1.0, 0.8, 0.8)] Moderately More Important (MMI) [(0.243, 0.262, 0.3, 0.337, 0.356, 0.8, 0.6, 0.6), (0.225, 0.25, 0.3, 0.35, 0.375, 1.0, 0.8, 0.8)] More than Moderately More Important (MMMI) [(0.343, 0.362, 0.4, 0.437, 0.456, 0.8, 0.6, 0.6), (0.325, 0.35, 0.4, 0.45, 0.475, 1.0, 0.8, 0.8)] Strongly More Important (SMI) [(0.443, 0.462, 0.5, 0.537, 0.556, 0.8, 0.6, 0.6), (0.425, 0.45, 0.5, 0.55, 0.575, 1.0, 0.8, 0.8)] More than Strongly More Important (MSMI) [(0.543, 0.562, 0.6, 0.637, 0.656, 0.8, 0.6, 0.6), (0.525, 0.55, 0.6, 0.65, 0.675, 1.0, 0.8, 0.8)] Very Strongly More Important (VSMI) [(0.643, 0.662, 0.7, 0.737, 0.756, 0.8, 0.6, 0.6), (0.625, 0.65, 0.7, 0.75, 0.775, 1.0, 0.8, 0.8)] More than Very Strongly More Important (MVSMI) [(0.743, 0.762, 0.8, 0.837, 0.856, 0.8, 0.6, 0.6), (0.725, 0.75, 0.8, 0.85, 0.875, 1.0, 0.8, 0.8)] Extremely More Important (EMI) [(0.843, 0.862, 0.9, 0.937, 0.956, 0.8, 0.6, 0.6), (0.825, 0.85, 0.9, 0.95, 0.975, 1.0, 0.8, 0.8)] r ˜Ai of each row i in ˜A is calculated according to formula 3.34, where ⊗ denotes the multiplication operator of two fuzzy numbers as defined in [169]. r ˜Ai = ( ˜ai1 ⊗ ˜ai2 ⊗...⊗ ˜ain) 1 n (3.34) Then, the priority vector ˜Ωi of each cluster element is constructed as follows: ˜Ωi = [ ˜ω1 ˜ω2 ... ˜ωn ] (3.35) where each ˜ωi = [(ωU 1 ,ωU 2 ,ωU 3 ,ωU 4 ,ωU 5 ,vU i ,vU i1,vU i2); (ωL 1 , ωL 2 ,ωL 3 ,ωL 4 ,ωL 5 ,vL i ,vL i1,vL i2)] is calculated using formula 3.36. The ⊕ indicates the addi- tion operator of two fuzzy numbers as defined in [169]. ˜ωi = r ˜Ai /(r ˜A1 ⊕r ˜A2 ⊕...⊕r ˜Ai ⊕...⊕r ˜An ) (3.36) Step 3. Construction of the Supermatrix: In this step, the fuzzy supermatrix ˜W of the PF- ANP model is constructed representing the inner and outer dependencies of the PF- ANP network. This is a partitioned matrix, with each matrix segment representing the
  • 77. 3.1 Related Methodologies 51 relationship between two clusters of the network. To construst the supermatrix, the local priority vectors ˜Ω are grouped and placed in the appropriate positions in the supermatrix based on the flow of influence from one cluster to another. For example if we assume a network of q clusters, where each cluster Ck, k = [1,2,...,q] has nk elements, denoted as ek1,ek2,...,eknk , then the supermatrix is expressed as: ˜W = C1 ... Ck ... Cq e11...e1n1 ... ek1...eknk ... eq1...eqnq                                                     e11 C1 ... ˜W11 ... ˜W1 j ... ˜W1q e1n1 ... ... ... ... ... ... ek1 Ck ... ˜Wk1 ... ˜Wk j ... ˜Wkq eknk ... ... ... ... ... ... eq1 Cq ... ˜Wq1 ... ˜Wqj ... ˜Wqq eqnq (3.37) Step 4. Construction of the Weighted Supermatrix: During this step, the supermatrix is trans- formed to a stochastic one,the Weighted Supermatrix ˜W′ using formula 3.38. ˜W′ k,j = ˜Wk,j/q (3.38) Step 5. Calculation of the Limited Supermatrix: In this step, initially the deffuzified Weighted Supermatrix W is estimated by applying the Weighted Average method using formula 3.39. The parameters v and d represent the height and the centroid of each ˜W′ k,j pentagon respectively. Subsequently, W is raised to limiting powers until all the entries converge. In this way the overall priorities are calculated, and thus the cumulative influence of each element on every other interacting element is obtained [168]. At this point, all the columns of the produced Limited Supermatrix, are the same and their values show the global priority of each element of the network. Wk,j = vU ·dU +vL ·dL dU +dL (3.39)
  • 78. 52 Mobility Management 3.1.4 Network Selection Methods 3.1.4.1 The Trapezoidal Interval-Valued Fuzzy TOPSIS (TFT) TOPSIS, introduced by Hwang and Yoon [170], is based on the concept that the best alternative should have the shortest distance from the positive ideal solution and the longer distance from the negative ideal solution. In the present work, network selection is performed using a proposed fuzzy version of TOPSIS, namely the Trapezoidal interval-valued Fuzzy TOPSIS (TFT). This method assumes that the linguistic values of the criteria attributes are represented by interval-valued trapezoidal fuzzy numbers. Suppose that A = {A1,A2,...,An} is the set of possible alternatives, C = {C1,C2,...,Cn} is the set of criteria and w1,w2,...,wm are the weights of each criterion. The steps of the method are as follows: Step 1. Construction of the decision matrix: Each element xij of the n × m decision matrix D is an interval-valued trapezoidal fuzzy number which expresses the performance of alternative i for criterion j. Thus D = C1 ... Cm A1 x11 ... x1m ... ... ... ... An xn1 ... xnm (3.40) where: xij = (xL ij1,xL ij2,xL ij3,xL ij4,vL ij),(xU ij1,xU ij2,xU ij3,xU ij4,vU ij) In case there are Q decision makers, the decision matrix and the criteria weights include the average of the performance values and of the weights of the decision makers, re- spectively. Hence, assuming that for the k-th decision maker xijk is the performance of alternative i for criterion j, and wjk is the importance weight for criterion j, the average of the performance values and weights are given by xij = 1 Q Q ∑ k=1 xijk = 1 Q Q ∑ k=1 xL ijk1, 1 Q Q ∑ k=1 xL ijk2, 1 Q Q ∑ k=1 xL ijk3, 1 Q Q ∑ k=1 xL ijk4,vL ijk , 1 Q Q ∑ k=1 xU ijk1, 1 Q Q ∑ k=1 xU ijk2, 1 Q Q ∑ k=1 xU ijk3, 1 Q Q ∑ k=1 xU ijk4,vU ijk (3.41) and wj = 1 Q Q ∑ k=1 wjk. (3.42) Step 2. Normalization of the decision matrix: Consider that Ωb is the set of benefits attributes and Ωc is the set of costs attributes. Then the elements of the normalized decision matrix are computed as:
  • 79. 3.1 Related Methodologies 53 a) rij = xL ij1 bj , xL ij2 bj , xL ij3 bj , xL ij4 bj ,vL ij , xU ij1 bj , xU ij2 bj , xU ij3 bj , xU ij4 bj ,vU ij (3.43) where bj = maxi xU ij4 for each j ∈ Ωb and b) rij = cj xL ij4 , cj xL ij3 , cj xL ij2 , cj xL ij1 ,vL ij , cj xU ij4 , cj xU ij3 , cj xU ij2 , cj xU ij1 ,vU ij (3.44) where cj = mini xL ij4 for each j ∈ Ωc. Step 3. Construction of the weighted normalized decision matrix: The weighted normalized decision matrix is constructed by multiplying each element of the normalized decision matrix rij with the respective weight wj according to the formula uij = rL ij1 ·wj,rL ij2 ·wj,rL ij3 ·wj,rL ij4 ·wj,vL ij , rU ij1 ·wj,rU ij2 ·wj,rU ij3 ·wj,rU ij4 ·wj,vU ij (3.45) Step 4. Determination of the positive and negative ideal solution: The positive ideal solution X+ is defined as follows: X+ = x+L ij1 ,x+L ij2 ,x+L ij3 ,x+L ij4 ,v+L ij , x+U ij1 ,x+U ij2 ,x+U ij3 ,x+U ij4 ,v+U ij = i uL ij1, i uL ij2, i uL ij3, i uL ij4,vL ij , i uU ij1, i uU ij2, i uU ij3, i uU ij4,vU ij (3.46) where i ≡ maxi in case j ∈ Ωb and i ≡ mini in case j ∈ Ωc. The negative ideal solution X− is defined as follows: X− = x−L ij1 ,x−L ij2 ,x−L ij3 ,x−L ij4 ,v−L ij , x−U ij1 ,x−U ij2 ,x−U ij3 ,x−U ij4 ,v−U ij = i uL ij1, i uL ij2, i uL ij3, i uL ij4,vL ij , i uU ij1, i uU ij2, i uU ij3, i uU ij4,vU ij (3.47) where i ≡ mini in case j ∈ Ωb and i ≡ maxi in case j ∈ Ωc. Step 5. Measurement of the distance of each alternative from the ideal solutions: The distances d+ i1 and d+ i2 of each alternative from the positive ideal solution are evaluated as follows: d+ i1 = m ∑ j=1 1 4 uL ij1 −x+L ij1 2 + uL ij2 −x+L ij2 2 + uL ij3 −x+L ij3 2 + uL ij4 −x+L ij4 2 1 2 (3.48) d+ i2 = m ∑ j=1 1 4 uU ij1 −x+U ij1 2 + uU ij2 −x+U ij2 2 + uU ij3 −x+U ij3 2 + uU ij4 −x+U ij4 2 1 2 (3.49)
  • 80. 54 Mobility Management Likewise, the distances d− i1 and d− i2 of each alternative from the negative ideal solution are estimated as follows: d− i1 = m ∑ j=1 1 4 uL ij1 −x−L ij1 2 + uL ij2 −x−L ij2 2 + uL ij3 −x−L ij3 2 + uL ij4 −x−L ij4 2 1 2 (3.50) d− i2 = m ∑ j=1 1 4 uU ij1 −x−U ij1 2 + uU ij2 −x−U ij2 2 + uU ij3 −x−U ij3 2 + uU ij4 −x−U ij4 2 1 2 (3.51) Consequently, similarly to [158] the distance of the alternatives from the positive and the negative ideal solutions are expressed by intervals such as [d+ i1,d+ i2] and [d− i1,d− i2], instead of single values. In this way less information is lost. Step 6. Calculation of the relative closeness: The relative closeness of the distances from the ideal solutions are computed as: RCi1 = d− i1 d+ i1 +d− i1 (3.52) and RCi2 = d− i2 d+ i2 +d− i2 (3.53) The compound relative closeness RCi is obtained from the average of the above values: RCi = RCi1 +RCi2 2 (3.54) Step 7. Alternatives ranking: The alternatives are ranked according to their RCi values. The best alternative is the one with the higher RCi value. 3.1.4.2 The Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW) The candidate networks are ranked using the TFT-ACW algorithm, which improves the TFT [171] by using the adaptive weights that estimated from the TF-AANP method. Thus, the importance of the opinion of each service (decision maker) is considered, since the opinions of some decision makers could have a higher importance than the ones of the other decision makers. In general, similar to TFT, the TFT-ACW method is based on the concept that the best alternative should have the shortest distance from the positive ideal solution and the longer distance from the negative ideal solution. Also, it assumes that the linguistic values of the criteria attributes are represented by interval-valued trapezoidal fuzzy numbers. More specifically, suppose that AL = {AL1,AL2,...,ALz} is the set of possible alternatives, CR = {CR1,CR2,...,CRn} is the set of criteria and w1,w2,...,wn are the importance weights of the respective criteria obtained from the application of the TF-AANP algorithm. The steps of the method are as follows:
  • 81. 3.1 Related Methodologies 55 Step 1. Construction of the decision matrix: Each element ˜gie of the z×n decision matrix ˜D is an IVTFN number expressing the performance of alternative i for criterion e. Thus, ˜D = CR1 ... CRn AL1 ˜g11 ... ˜g1n ... ... ... ... ALz ˜gz1 ... ˜gzn (3.55) where ˜gie = (gL ie1,gL ie2,gL ie3,gL ie4,vL ie),(gU ie1,gU ie2,gU ie3,gU ie4,vU ie) . In the case that there are S services (decision makers) the decision matrix include the average of the performance values. Hence, assuming that for the sth decision maker ˜giex is the performance of alternative i for criterion (element) e, the average of the performance values is given by formula 3.56. ˜gie = S ∑ s=1 ( ˜gies · ˜ω ˜ps) (3.56) Step 2. Normalization of the decision matrix: Let Γb be the set of benefit attributes and Γc the set of cost attributes. Then, the elements of the normalized decision matrix are calculated using either formula 3.57 or 3.58, where be = maxi gU ie4 for each e ∈ Γb and ce = mini gL ie4 for each e ∈ Γc. ˜g′ ie = gL ie1 be , gL ie2 be , gL ie3 be , gL ie4 be ,vL ie , gU ie1 be , gU ie2 be , gU ie3 be , gU ie4 be ,vU ie (3.57) ˜g′ ie = ce gL ie4 , ce gL ie3 , ce gL ie2 , ce gL ie1 ,vL ie , ce gU ie4 , ce gU ie3 , ce gU ie2 , ce gU ie1 ,vU ie (3.58) Step 3. Construction of the weighted normalized decision matrix: The weighted normalized decision matrix is constructed by multiplying each element of the normalized decision matrix ˜g′ ie with the respective weight we according to the formula 3.59. ˜uie = g′L ie1 ·we,g′L ie2 ·we,g′L ie3 ·we,g′L ie4 ·we,v′L ie , g′U ie1 ·we,g′U ie2 ·we,g′U ie3 ·we,g′U ie4 ·we,vU ie (3.59) Step 4. Determination of the positive and negative ideal solution: The positive ideal solution is defined in formula 3.60, where i ≡ maxi in case e ∈ Γb and i ≡ mini in case e ∈ Γc. Correspondingly, the negative ideal solution is defined in formula 3.61, where i ≡ mini
  • 82. 56 Mobility Management in case e ∈ Γb and i ≡ maxi in case e ∈ Γc. ˜G+ = g+L ie1 ,g+L ie2 ,g+L ie3 ,g+L ie4 ,v+L ie , g+U ie1 ,g+U ie2 ,g+U ie3 ,g+U ie4 ,v+U ie = i uL ie1, i uL ie2, i uL ie3, i uL ie4,vL ie , i uU ie1, i uU ie2, i uU ie3, i uU ie4,vU ie (3.60) ˜G− = g−L ie1 ,g−L ie2 ,g−L ie3 ,g−L ie4 ,v−L ie , g−U ie1 ,g−U ie2 ,g−U ie3 ,g−U ie4 ,v−U ie = i uL ie1, i uL ie2, i uL ie3, i uL ie4,vL ie , i uU ie1, i uU ie2, i uU ie3, i uU ie4,vU ie (3.61) Step 5. Measurement of the distance of each alternative from the ideal solutions: The distances of each alternative from the positive ideal solution are evaluated using formulas 3.62 and 3.63. p+ i1 = n ∑ e=1 1 4 uL ie1 −g+L ie1 2 + uL ie2 −g+L ie2 2 + uL ie3 −g+L ie3 2 + uL ie4 −g+L ie4 2 1 2 (3.62) p+ i2 = n ∑ e=1 1 4 uU ie1 −g+U ie1 2 + uU ie2 −g+U ie2 2 + uU ie3 −g+U ie3 2 + uU ie4 −g+U ie4 2 1 2 (3.63) Likewise, the distances of each alternative from the negative ideal solution are estimated using formulas 3.64 and 3.65. p− i1 = n ∑ e=1 1 4 uL ie1 −g−L ie1 2 + uL ie2 −g−L ie2 2 + uL ie3 −g−L ie3 2 + uL ie4 −g−L ie4 2 1 2 (3.64) p− i2 = n ∑ e=1 1 4 uU ie1 −g−U ie1 2 + uU ie2 −g−U ie2 2 + uU ie3 −g−U ie3 2 + uU ie4 −g−U ie4 2 1 2 (3.65) Consequently, the alternative distance from the positive and from the negative ideal solutions are expressed by intervals such as [p+ i1, p+ i2] and [p− i1, p− i2], instead of single values, thus less information is lost. Step 6. Calculation of the relative closeness: The relative closeness of the distances from the ideal solutions are calculated using formula 3.66 and 3.67. RCi1 = p− i1 p+ i1 + p− i1 (3.66) RCi2 = p− i2 p+ i2 + p− i2 (3.67)
  • 83. 3.1 Related Methodologies 57 Subsequently, the compound relative closeness is obtained using formula 3.68 RCi = RCi1 +RCi2 2 (3.68) Step 7. Alternative networks ranking: The alternative networks are ranked according to their RCi values. The best alternative is that with the higher RCi value. 3.1.4.3 The Pentagonal Fuzzy TOPSIS (PFT) The Pentagonal Fuzzy TOPSIS (PFT) algorithm is an improved version of the TOPSIS using interval-valued pentagonal fuzzy numbers. PFT assumes that the linguistic values of the criteria attributes are represented by IVPFN numbers. Suppose that A = {A1,A2,...,An} is the set of possible alternatives, C = {C1,C2,...,Cm} is the set of criteria and w1,w2,...,wm are the weights of each criterion. The steps of the method are as follows: Step 1. Construction of the decision matrix: Each element xij of the n × m decision matrix D is an interval-valued pentagonal fuzzy number which expresses the performance of alternative i for criterion j. Thus D = C1 ... Cm A1 x11 ... x1m ... ... ... ... An xn1 ... xnm (3.69) where: xij = [(xL ij1,xL ij2,xL ij3,xL ij4,xL ij5,vL ij,vL ij1,vL ij2), (xU ij1,xU ij2,xU ij3,xU ij4,xU ij5,vU ij,vU ij1,vU ij2)]. In case there are Q decision makers the decision matrix and the criteria weights include the average of the performance values and of the weights respectively, of the decision makers. Hence, assuming that for the k-th decision maker xijk is the performance of alternative i for criterion j, and wjk is the importance weight for criterion j, the average of the performance values and weights are given by: xij = 1 Q Q ∑ k=1 xijk (3.70) and wj = 1 Q Q ∑ k=1 wjk. (3.71) Step 2. Normalization of the decision matrix: Consider that Ωb is the set of benefit attributes and Ωc is the set of cost attributes. Then, the elements of the normalized decision matrix are
  • 84. 58 Mobility Management computed as: rij = [( xL ij1 bj , xL ij2 bj , xL ij3 bj , xL ij4 bj , xL ij5 bj ,vL ij,vL ij1,vL ij2),( xU ij1 bj , xU ij2 bj , xU ij3 bj , xU ij4 bj , xU ij5 bj ,vU ij,vU ij1,vU ij2)] (3.72) where bj = maxi xU ij4 for each j ∈ Ωb, or rij = [( cj xL ij5 , cj xL ij4 , cj xL ij3 , cj xL ij2 , cj xL ij1 ,vL ij,vL ij2,vL ij1),( cj xU ij5 , cj xU ij4 , cj xU ij3 , cj xU ij2 , cj xU ij1 ,vU ij,vU ij2,vU ij1)] (3.73) where cj = mini xL ij4 for each j ∈ Ωc. Step 3. Construction of the weighted normalized decision matrix: The weighted normalized decision matrix is constructed by multiplying each element of the normalized decision matrix rij with the respective weight wj according to: uij = [(rL ij1 ·wj,rL ij2 ·wj,rL ij3 ·wj,rL ij4 ·wj,rL ij5 ·wj,vL ij,vL ij1, vL ij2),(rU ij1 ·wj,rU ij2 ·wj,rU ij3 ·wj,rU ij4 ·wj,rU ij5 ·wj,vU ij,vU ij1,vU ij2)] (3.74) Step 4. Determination of the positive and negative ideal solutions: The positive ideal solution is given by: X+ = [(x+L ij1 ,x+L ij2 ,x+L ij3 ,x+L ij4 ,x+L ij5 ,v+L ij ,v+L ij1 ,v+L ij2 ),(x+U ij1 ,x+U ij2 ,x+U ij3 ,x+U ij4 ,x+U ij5 ,v+U ij ,v+U ij1 ,v+U ij2 )] = [( i uL ij1, i uL ij2, i uL ij3, i uL ij4, i uL ij5,vL ij,vL ij1,vL ij2),( i uU ij1, i uU ij2, i uU ij3, i uU ij4, i uU ij5,vU ij,vU ij1,vU ij2)] (3.75) where i ≡ maxi in case j ∈ Ωb and i ≡ mini in case j ∈ Ωc. The negative ideal solutions is given by: X− = [(x−L ij1 ,x−L ij2 ,x−L ij3 ,x−L ij4 ,x−L ij5 ,v−L ij ,v−L ij1 ,v−L ij2 ),(x−U ij1 ,x−U ij2 ,x−U ij3 ,x−U ij4 ,x−U ij5 ,v−U ij ,v−U ij1 ,v−U ij2 )] = [( i uL ij1, i uL ij2, i uL ij3, i uL ij4, i uL ij5,vL ij,vL ij1,vL ij2),( i uU ij1, i uU ij2, i uU ij3, i uU ij4, i uU ij5,vU ij,vU ij1,vU ij2)] (3.76) where i ≡ mini in case j ∈ Ωb and i ≡ maxi in case j ∈ Ωc. Step 5. Measurement of the distance of each alternative from the ideal solutions: The distances of each alternative from the positive ideal solution are evaluated as follows: d+ i1 = m ∑ j=1 { 1 5 [(uL ij1 −x+L ij1 )2 +(uL ij2 −x+L ij2 )2 +(uL ij3 −x+L ij3 )2 +(uL ij4 −x+L ij4 )2 +(uL ij5 −x+L ij5 )2 ]} 1 2 (3.77) d+ i2 = m ∑ j=1 { 1 5 [(uU ij1 −x+U ij1 )2 +(uU ij2 −x+U ij2 )2 +(uU ij3 −x+U ij3 )2 +(uU ij4 −x+U ij4 )2 +(uU ij5 −x+U ij5 )2 ]} 1 2 (3.78)
  • 85. 3.1 Related Methodologies 59 Likewise the distances of each alternative from the negative ideal solution are estimated by: d− i1 = m ∑ j=1 {15[(uL ij1 −x−L ij1 )2 +(uL ij2 −x−L ij2 )2 +(uL ij3 −x−L ij3 )2 +(uL ij4 −x−L ij4 )2 +(uL ij5 −x−L ij5 )2 ]} 1 2 (3.79) d− i2 = m ∑ j=1 { 1 5 [(uU ij1 −x−U ij1 )2 +(uU ij2 −x−U ij2 )2 +(uU ij3 −x−U ij3 )2 +(uU ij4 −x−U ij4 )2 +(uU ij5 −x−U ij5 )2 ]} 1 2 (3.80) Consequently, similarly to [158] the distance of the alternatives from the positive and negative ideal solutions are expressed by intervals such as [d+ i1,d+ i2] and [d− i1,d− i2], instead of single values. In this way less information is lost. Step 6. Calculation of the relative closeness: The relative closeness RCi1 and RCi2 of the dis- tances from the ideal solutions are computed as: RCi1 = d− i1 d+ i1 +d− i1 (3.81) and RCi2 = d− i2 d+ i2 +d− i2 (3.82) The compound relative closeness RCi is obtained from the average of the above values RCi = RCi1 +RCi2 2 (3.83) Step 7. Alternatives ranking: The alternatives are ranked according to their RCi values. The best alternative is that with the higher RCi value. 3.1.5 Evaluation of the Proposed Methods 3.1.5.1 Network Selection using the ANP and the TFT Algorithms 3.1.5.1.1 Simulation Setup : In our experiments we consider a heterogeneous network environment consisting of a number of LTE, WiMAX and WiFi networks. Each network can provide at least one of the following five service types: VoIP, conversational video (CVideo), buffered streaming (BStreaming), real time gaming (RTGaming) and web browsing. In order to allow service continuity, QoS mapping among the QoS classes of the different access tech- nologies is required. Table 3.3 shows this mapping relation among the different technologies. Four SLAs are defined with SLA1 having the higher service priority and SLA 4 having the lower service priority. SLA1 supports all the service types and it provides the best values for the QoS and policy decision criteria. SLA2 supports a smaller number of service types, by it does not provide support for the VoIP and real time gaming services. Additionally, it provides
  • 86. 60 Mobility Management Table 3.3 QoS Class Mapping and SLAs. LTE QCI (Type/ Priority) WiMAX QoS class IEEE 802.11e QoS class Required Throughput Required Packet loss Required Delay Required Jitter Services 1 (GBR/ 2) UGS/ ertPS (802.16e- 802.16m) AC_VO 200 Kbps 10−2 100ms 50ms VoIP, CVideo, BStreaming, RTGaming, Web 3 (GBR/ 3) UGS AC_VO 250 Kbps 10−3 50ms 40ms CVideo, BStreaming, RTGaming, Web 2 (GBR/ 4) UGS AC_VI 8 Mbps 10−3 65ms 50ms CVideo, BStreaming, Web 4 (GBR/ 5) rtPS AC_VI 8 Mbps 10−5 65ms 60ms CVideo, BStreaming, Web 6 (Non-GBR/ 6) nrtPS AC_BE 2.5 Mbps 10−5 200ms N/A BStreaming, Web 7 (Non-GBR/ 7) nrtPS AC_BE 2 Mbps 10−5 160ms 100ms BStreaming, Web 8 (Non-GBR/ 8) BE AC_BE 1.5 Mbps 10−3 300ms N/A Web 9 (Non-GBR/ 9) BE AC_BE 1.5 Mbps 10−5 300ms N/A Network selection weights per service & SLA Network QoS Characteristics Network Policy Characteristics Throughput Delay Jitter Packet Loss Service Reliability Security Price Goal Criteria Groups Criteria Figure 3.3 The ANP Network Model. Throughput Delay Jitter Packet loss Service Reliability Price Security Figure 3.4 The Relations of the Criteria considered by the ANP Network Model.
  • 87. 3.1 Related Methodologies 61 slightly worse decision criteria values than those offered by SLA1. SLA3 supports only the buffered streaming and the web browsing services and satisfactory QoS characteristics and policies, whereas the low price SLA4 supports only the web browsing service while providing acceptable decision criteria values. 3.1.5.1.2 Performance Evaluation : The ANP method is applied in order to estimate the weights of network selection criteria per service type and SLA. Figure 3.3 depicts the ANP network model. The criteria are classified into two groups namely the QoS and the policy characteristics. The QoS characteristics group contains network performance related criteria including throughput, delay, jitter and packet loss while the policy characteristics group contains operator defined rules such as price, security and service reliability. Pairwise comparison decision matrices are created based on relations among the seven selection criteria depicted in Figure 3.4. Then, these pairwise comparison decision matrices are used to evaluate the priority vectors of criteria and form the supermatrix per service type and SLA. Subsequently, the weighted supermatrices and, finally, the limit supermatrices are obtained. Indicatively, for the SLA1 VoIP service, the initial, the weighted and the limit supermatrices are presented in Tables 3.4, 3.5 and 3.6 respectively. Table 3.4 The ANP Supermatrix for the SLA1 VoIP Service. Throughput Delay Jitter Packet loss Price Reliability Security Throughput 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 Delay 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 Jitter 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 Packet loss 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 0.328125 Price 0.05 0.05 0.05 0.05 0.019607 0.05 0.0625 Reliability 0.95 0.95 0.95 0.95 0.759804 0.95 0 Security 0 0 0 0 0.220588 0 0.9375 Table 3.5 The ANP Weighted Supermatrix for the SLA1 VoIP Service. Throughput Delay Jitter Packet loss Price Reliability Security Throughput 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 Delay 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 Jitter 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 Packet loss 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 Price 0.025 0.025 0.025 0.025 0.00980392 0.025 0.03125 Reliability 0.475 0.475 0.475 0.475 0.379902 0.475 0 Security 0 0 0 0 0.110294 0 0.46875 The criteria weights per service and SLA obtained by the limit supermatrices are presented in Figures 3.5, 3.6, 3.7 and 3.8. As illustrated, the weights are proportional to the constraints of each service as well as to the agreements of each SLA. In particular, the weight of the price
  • 88. 62 Mobility Management Table 3.6 The ANP Limit Supermatrix for the SLA1 VoIP Service. Throughput Delay Jitter Packet loss Price Reliability Security Throughput 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 Delay 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 Jitter 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 Packet loss 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 0.164062 Price 0.0246573 0.0246573 0.0246573 0.0246573 0.0246573 0.0246573 0.0246573 Reliability 0.470224 0.470224 0.470224 0.470224 0.470224 0.470224 0.470224 Security 0.0051191 0.0051191 0.0051191 0.0051191 0.0051191 0.0051191 0.0051191 criterion is low for SLA1, in which the service reliability and the network QoS characteristics are considered as the most important factors. In SLA2 the price criterion is more important than in SLA1, thus the respective weight is greater than that of SLA1. Consequently, the weights of the service reliability and QoS characteristics criteria in SLA2 are lower compared to the relative weights of SLA1. In SLA3 the weights of the price and the service reliability criteria are balanced as they are almost of equivalent importance. Finally, in SLA4 the price is the most important criterion resulting in a high estimated weight value. 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 VoIP ConversationalVideo BufferedStreaming RealTimeGaming Web Weight SLA1 Throughput Delay Jitter Packet Loss Price Reliability Security Figure 3.5 Criteria Weights for SLA1.
  • 89. 3.1 Related Methodologies 63 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 ConversationalVideo BufferedStreaming Web Weight SLA2 Throughput Delay Jitter Packet Loss Price Reliability Security Figure 3.6 Criteria Weights for SLA2. The ranking of the networks alternatives is performed using the TFT algorithm described in the subsection 3.1.4.1. The weights of the network selection criteria are obtained from Figures 3.5 - 3.8. The linguistic terms for the criteria attributes are represented by interval- valued trapezoidal fuzzy numbers as shown in Table 3.7. The network policy specifications are expressed directly using linguistic terms. Additionally, crisp values of network QoS characteristics are converted into linguistic terms which correspond to specific ranges of values per service type. Table 3.8 presents a relative example for the VoIP service, illustrating the correspondence between ranges of network QoS characteristics values and linguistic terms. The available - candidate networks in our simulations at the time of network selection per service and SLA, as well as, their specifications expressed by linguistic terms are depicted in Tables 3.9 and 3.10. The case of having several services of different QoS constraints running at the user site is being addressed by the TFT algorithm and network selection is performed in a way satisfying multiple groups of criteria per user. We consider the case where nine users need to select a network which satisfies the requirements of their services as presented in Table 3.11 and at the same time comply with their respective SLA agreements. To achieve this goal the proposed
  • 90. 64 Mobility Management 0 0.1 0.2 0.3 0.4 0.5 BufferedStreaming Web Weight SLA3 Throughput Delay Jitter Packet Loss Price Reliability Security Figure 3.7 Criteria Weights for SLA3. TFT algorithm is applied for each user and the available networks are ranked as shown in Figure 3.9. The positive and the negative ideal solutions are represented by unary and null trapezoidal fuzzy numbers respectively to eliminate the ranking abnormality problem. From the obtained results it is clear that the ranking of the network alternatives is in accordance with the users expectations. For example, user 1 who requires increased QoS provisioning selects LTE 1 network which guarantees the best QoS characteristics and service reliability. As Figure 3.9 depicts, LTE 1 achieves higher ranking than the other networks, due to the high values of the QoS characteristics and service reliability factors bearing higher importance according to the relative ANP weights in SLA1. On the contrary, user 9 whose prior selection criterion is the price of the service, selects the WiFi 1 network which satisfies his requirements as expressed in his SLA agreement. The performance of the TFT algorithm was evaluated against the original TOPSIS method, as well as, against the method presented in [172], the Fuzzy AHP - ELECTRE (FAE) method. The FAE method calculates the criteria weights using the Fuzzy AHP and performs the network selection by applying the ELECTRE algorithm. We consider the scenario of the nine users of Table 3.11. A critical weakness of TOPSIS and FAE is that they do not support users with
  • 91. 3.1 Related Methodologies 65 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 Web Weight SLA4 Throughput Delay Jitter Packet Loss Price Reliability Security Figure 3.8 Criteria Weights for SLA4 more than one service. In these cases, the TOPSIS and FAE methods consider only the most demanding service of the user. Specifically, for users 2 and 3 they applied only considering the VoIP service and for user 7 are applied only considering the BStreaming service, whereas for the rest users the methods are applied respectively for each single user service defined in Table 3.11. Table 3.12 presents the network classification performed by TFT, TOPSIS and FAE. From the analysis of the results we conclude that when a user has only one service, the methods usually provide similar results. However, when a user requires multiple services, TFT accomplishes more reliable results than TOPSIS and FAE, since it considers the weights of each service. For example, the results concerning user 1 using only the VoIP service, are similar for TFT and TOPSIS with the exception of the evaluation sequence of the WiFi 1 and WiFi 2 networks. Also, FAE accomplishes quite similar network rates with TFT and TOPSIS for this user. Nevertheless, TFT achieves more reliable results for user 4, compared with TOPSIS and FAE. In this case, only the RTGaming service is used and the most important criteria are service reliability, throughput and delay. TFT selects the WiMAX2 network which provides AG for service reliability, VG for throughput and AG for delay criterion. On the other hand,
  • 92. 66 Mobility Management Table 3.7 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy Numbers used for the Evaluation of the TFT algorithm. Linguistic term Interval-valued trapezoidal fuzzy number Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.0, 0.8), (0.0, 0.0, 0.0, 0.0, 1)] Very Poor (VP) [(0.01, 0.02, 0.03, 0.07, 0.8), (0.0, 0.01, 0.05, 0.08, 1)] Poor (P) [(0.04, 0.1, 0.18, 0.23, 0.8), (0.02, 0.08, 0.2, 0.25, 1)] Medium Poor (MP) [(0.17, 0.22, 0.36, 0.42, 0.8), (0.14, 0.18, 0.38, 0.45, 1)] Medium (M) [(0.32, 0.41, 0.58, 0.65, 0.8), (0.28, 0.38, 0.6, 0.7, 1)] Medium Good (MG) [(0.58, 0.63, 0.8, 0.86, 0.8), (0.5, 0.6, 0.9, 0.92, 1)] Good (G) [(0.72, 0.78, 0.92, 0.97, 0.8), (0.7, 0.75, 0.95, 0.98, 1)] Very Good (VG) [(0.93, 0.98, 1, 1, 0.8), (0.9, 0.95, 1, 1, 1)] Absolutely Good (AG) [(1, 1, 1, 1, 0.8), (1, 1, 1, 1, 1)] Table 3.8 Relation of the Network QoS Characteristics and the Linguistic Terms for VoIP. Linguistic term Throughput range (Kbps) Delay range (ms) Jitter range (ms) Packet loss range AP ≤ 164 ≥ 116 ≥ 65 ≥ 0.4 VP 165 - 174 111-115 55 - 64 ≥ 0.2 - 0.4 P 175 - 184 106-110 45 - 54 >10−1 - <0.2 MP 185 - 194 100 - 105 40 - 44 10−1 M 195 - 204 95 - 99 35 - 49 10−2 MG 205 - 214 86 - 94 30 - 34 10−3 G 215 - 224 66 - 85 25 - 29 10−4 VG 225 - 239 41 - 65 20 - 24 10−5 AG ≥ 240 ≤ 40 ≤ 20 ≤ 10−6 TOPSIS selects the LTE1 network, which has similar values with the WiMAX2 for service reliability and delay criteria but worse performance for throughout by providing G instead of VG. Moreover, FAE does not provide a clear choice for user 4 and results to equal rankings for both WiMAX2 and LTE1 networks. Finally, the classification of the networks obtained by the three methods is quite different for user 7 who requests both BStreaming and web browsing services. In this case, the TFT accomplishes more reliable results by taking into account the weights of both services. 3.1.5.1.3 Sensitivity Analysis : In this subsection, the sensitivity of TFT is evaluated when the number of the available access networks changes frequently. We consider three different network configuration scenarios for the users defined in Table 3.11. In the first scenario all the networks defined in Tables 3.9 and 3.10 are available. In the second and third scenarios the LTE 1 and the WiFi 2 networks respectively are not reachable. The graphs of Figures 3.10-3.18 include three column types of different patern indicating the ranking of network alternatives in each case. In the first case, user 1 selects the LTE 1 network. In the second case, the remaining networks improve their ranking order, thus user 1 selects the WiMAX 2 network. Furthermore, in the third case only the last rated WiFi 3 network increases its rank, since the WiFi 2 network preceded WiFi 3 in the other two cases. Similar behavior is observed in the ranking of the
  • 93. 3.1 Related Methodologies 67 0 0.05 0.1 0.15 0.2 User1 User2 User3 User4 User5 User6 User7 User8 User9 NetworkScore Trapezoidal Fuzzy Topsis Results LTE 1 LTE 2 WiMAX 1 WiMAX 2 WiFi 1 WiFi 2 WiFi 3 Figure 3.9 The TFT Results. network alternatives for the other users. From the aforementioned analysis we conclude that the ranking results of the proposed method are normally adjusted with respect to the heterogeneous network environment changes, highlighting thus the method’s sensitivity.
  • 94. 68 Mobility Management 0 1 2 3 4 5 6 7 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.10 The TFT’s Network Ranking for User 1 in case of Network Environment Changes. 0 1 2 3 4 5 6 7 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.11 The TFT’s Network Ranking for User 2 in case of Network Environment Changes.
  • 95. 3.1 Related Methodologies 69 Table 3.9 The Available Networks of SLA1 and SLA2. SLA Service Network Throughput Delay Jitter Packet Loss Price Service Reliability Security SLA1 VoIP LTE 1 MG AG VG VG VP AG VG LTE 2 AG MG AG MG VP VG AG WiMAX 1 M M MP AG P VG AG WiMAX 2 G G G G P AG VG WiFi 1 VG VG MG AG MP G G WiFi 2 MG M MG VG MP MG MG WiFi 3 M MP M AG MP G G CVideo LTE 1 MP MG VG G AP AG VG LTE 2 AG AG AG VG AP VG AG WiMAX 1 MP M MG AG AP VG AG WiMAX 2 MG MG G AG VP AG VG WiFi 1 M MG M VG P G G WiFi 2 VG VG VG AG P MG MG WiFi 3 G G M VG P G G BStreaming LTE 1 M G VG VG AP AG VG LTE 2 VG VG AG AG AP VG AG WiMAX 1 M MG MG VG VP VG AG WiMAX 2 MG G MG G P AG VG WiFi 1 VG G M AG P G G WiFi 2 AG AG G VG P MG MG WiFi 3 G VG VG AG MP G G RTGaming LTE 1 G AG AG VG VP AG VG LTE 2 G MG VG AG VP VG AG WiMAX 1 MP MG G AG P VG AG WiMAX 2 VG AG AG VG VP AG VG WiFi 1 AG VG VG VG VP G G WiFi 2 M M MG AG MP MG MG WiFi 3 P M M AG MP G G Web LTE 1 AG AG AG AG VP AG VG LTE 2 MG M G VG MP VG AG WiMAX 1 G M G AG P VG AG WiMAX 2 VG G VG AG P AG VG WiFi 1 MG MP MG VG MP G G WiFi 2 VG G M VG MP MG MG WiFi 3 AG VG AG AG MP G G SLA2 CVideo LTE 1 MG G VG AG MP G G LTE 2 MP M MG VG M G G WiMAX 1 M MG G AG MP MG MG WiMAX 2 MP M M AG M MG MG WiFi 2 G VG VG AG MG G M WiFi 3 MP G M VG MG P M BStreaming LTE 1 M G G VG MP G G LTE 2 MG MG AG G MP G G WiMAX 1 M MG MP AG MP MG MG WiMAX 2 G G MG VG MP MG MG WiFi 1 G VG MG AG MP MP MP WiFi 2 AG AG VG VG MP M M WiFi 3 MG VG VG AG M P M Web LTE 2 M MP MG VG M G G WiMAX 1 MG M G AG MG MG MG WiMAX 2 VG G AG AG M MG MG WiFi 1 MG MP M VG MG MP MP WiFi 2 MG M G VG MG M M WiFi 3 VG VG AG AG MG P M
  • 96. 70 Mobility Management Table 3.10 The Available Networks of SLA3 and SLA4. SLA Service Network Throughput Delay Jitter Packet Loss Price Service Re- liability Security SLA3 BStreaming LTE 1 M MG G VG MG MP MP LTE 2 G G M AG MG M M WiMAX 1 M G MP VG MG M M WiFi 1 G G MG AG G VP P WiFi 2 G AG G VG MG VP P WiFi 3 MG VG MG AG G VP P Web LTE 1 MG MP M G G MP MP LTE 2 M M G VG G M M WiMAX 1 MG M M AG G M M WiMAX 2 VP M AG AG VG P MP WiFi 1 MG MP M AG G VP P WiFi 2 AP AP VP G VG VP P SLA4 Web LTE 1 MP M M VG VG P P LTE 2 M M G MG VG P MP WiMAX 1 VP P M AG AG VP VP WiMAX 2 P MP MP G VG VP P WiFi 1 MG G M G AG AP AP WiFi 2 AP AP VP G AG AP VP WiFi 3 AP VP P AG AG AP VP Table 3.11 The Required Services per User. User SLA Required services 1 SLA1 -VoIP 2 SLA1 -VoIP,-RTGaming, -BStreaming, -Web 3 SLA1 -VoIP, -RTGaming 4 SLA1 -RTGaming 5 SLA2 -CVideo 6 SLA2 -BStreaming 7 SLA3 -BStreaming, -Web 8 SLA3 -Web 9 SLA4 -Web Table 3.12 Networks’ Classification in respect of TFT, TOPSIS (T) and FAE Results. User1 User2 User3 User4 User5 User6 User7 User8 User9 ❵❵❵❵❵❵❵❵❵❵Networks Method TFT T FAE TFT T FAE TFT T FAE TFT T FAE TFT T FAE TFT T FAE TFT T FAE TFT T FAE TFT T FAE LTE 1 1 1 1 2 1 1 1 1 1 2 1 1 4 2 2 4 2 5 4 2 5 2 1 4 4 6 4 LTE 2 3 3 3 3 3 3 3 3 3 4 4 2 2 3 6 1 1 4 1 3 1 3 2 5 3 3 4 WiMAX 1 5 5 5 5 5 5 5 5 5 5 5 4 3 4 3 5 4 7 2 1 4 1 3 1 6 7 3 WiMAX 2 2 2 4 1 2 4 2 2 4 1 2 1 5 5 4 2 3 2 - - - 5 5 3 5 5 4 WiFi 1 4 6 2 4 6 2 4 6 2 3 3 3 - - - 6 6 3 3 5 3 4 4 2 1 1 1 WiFi 2 6 4 6 7 4 6 6 4 6 6 7 5 1 1 1 3 5 1 5 4 2 6 6 6 7 4 4 WiFi 3 7 7 6 6 7 6 7 7 6 7 6 6 6 6 5 7 7 6 - - - - - - 2 2 2
  • 97. 3.1 Related Methodologies 71 0 1 2 3 4 5 6 7 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.12 The TFT’s Network Ranking for User 3 in case of Network Environment Changes. 0 1 2 3 4 5 6 7 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.13 The TFT’s Network Ranking for User 4 in case of Network Environment Changes.
  • 98. 72 Mobility Management 0 1 2 3 4 5 6 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.14 The TFT’s Network Ranking for User 5 in case of Network Environment Changes. 0 1 2 3 4 5 6 7 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.15 The TFT’s Network Ranking for User 6 in case of Network Environment Changes.
  • 99. 3.1 Related Methodologies 73 0 1 2 3 4 5 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.16 The TFT’s Network Ranking for User 7 in case of Network Environment Changes. 0 1 2 3 4 5 6 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.17 The TFT’s Network Ranking for User 8 in case of Network Environment Changes.
  • 100. 74 Mobility Management 0 1 2 3 4 5 6 7 LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3 NetworkScore Available Networks Scenario 1 Scenario 2 Scenario 3 Figure 3.18 The TFT’s Network Ranking for User 9 in case of Network Environment Changes.
  • 101. 3.1 Related Methodologies 75 3.1.5.2 Network Selection using the TF-ANP and the TFT Algorithms for supporting Medical Services 3.1.5.2.1 Simulation Setup : We consider an heterogeneous network environment consist- ing of a number of LTE, WAVE and WiMAX networks. Each network supports at least one of the following medical service types: Live Video, Medical Data, Sensor Data and Clinical Data. Also, we consider the case where 10 vehicles with patients are moving inside the network environment and need to be connected to a network which satisfies the requirements of their services and at the same time complies with their patient health status. The health status of each patient is evaluated using the Manchester Triage System (MTS) [173] healthcare classification system, which defines 5 health statuses, called Non-Urgent, Standard, Urgent, Very-Urgent and Immediate. The Non-Urgent status has the lower risk about patient’s life, while the Immediate status has the higher one. 3.1.5.2.2 Performance Evaluation : During the network selection process the TF-ANP method is applied initially, in order to estimate the decision weights per service type and patient health status, considering the ANP network model proposed in [171]. The criteria used include throughput, delay, jitter, packet loss, service reliability, security and price. Pairwise comparison decision matrices are created to evaluate the priority vectors of criteria and to form the fuzzy Supermatrix per service type and patient health status. Subsequently, the fuzzy Weighted Supermatrix and, finally, the Limit Supermatrix are obtained. Indicatively, when the patient health status is evaluated as Non-Urgent, for the Sensor Data service the initial, the weighted and the limit supermatrices are presented in Tables 3.4, 3.5 and 3.6 respectively. For each health status, the criteria weights per healthcare service obtained by the corresponding Limit Supermatrix are presented in Figure 3.19. As illustrated, the weights are proportional to the constraints of each service as well as to the health status of each patient. In particular, the weight of the price criterion is low for Immediate health status, resulting in a weight value which is very close to 0. Accordingly, when the health status is evaluated as Non-Urgent, the medical risk for the patient is very low and the price criterion becomes more important. The ranking of the networks alternatives is performed using the TFT algorithm using the weights of the network selection criteria obtained using the TF-ANP method. The linguistic terms for the criteria attributes are represented by IVTFNs as shown in Table 4.1. Furthermore, the available-candidate networks in our simulations at the time of network selection per service as well as their specifications expressed by linguistic terms are depicted in Table 3.14. The case of having several medical services of different QoS constraints running at the vehicle site is also addressed. The network selection is performed in a way that satisfies multiple groups of criteria per vehicle. The vehicles need to select a network which satisfies
  • 102. 76 Mobility Management Figure 3.19 The TF-ANP Weights per Service and Patient Health Status.
  • 103. 3.1 Related Methodologies 77 Table 3.13 Linguistic Terms and the Corresponding Interval-Valued Trapezoidal Fuzzy Numbers used for the Criteria Attributes for the Evaluation of the TFT Algorithm in cases where Medical Services are used. Linguistic term Interval-valued trapezoidal fuzzy number Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.0, 0.9), (0.0, 0.0, 0.0, 0.0, 1.0)] Very Poor (VP) [(0.01, 0.02, 0.03, 0.07, 0.9), (0.0, 0.01, 0.05, 0.08, 1.0)] Poor (P) [(0.04, 0.1, 0.18, 0.23, 0.9), (0.02, 0.08, 0.2, 0.25, 1.0)] Medium Poor (MP) [(0.17, 0.22, 0.36, 0.42, 0.9), (0.14, 0.18, 0.38, 0.45, 1.0)] Medium (M) [(0.32, 0.41, 0.58, 0.65, 0.9), (0.28, 0.38, 0.6, 0.7, 1.0)] Medium Good (MG) [(0.58, 0.63, 0.8, 0.86, 0.9), (0.5, 0.6, 0.9, 0.92, 1.0)] Good (G) [(0.72, 0.78, 0.92, 0.97, 0.9), (0.7, 0.75, 0.95, 0.98, 1.0)] Very Good (VG) [(0.93, 0.98, 1.0, 1.0, 0.9), (0.9, 0.95, 1.0, 1.0, 1.0)] Absolutely Good (AG) [(1.0, 1.0, 1.0, 1.0, 0.9), (1.0, 1.0, 1.0, 1.0, 1.0)] 0 0,02 0,04 0,06 0,08 0,1 0,12 0,14 Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10 NetworkScore Trapezoidal Fuzzy Topsis results LTE1 LTE2 LTE3 LTE4 WAVE1 WAVE2 WAVE3 WAVE4 WiMAX1 WiMAX2 Figure 3.20 The TFT Results for each Vehicle. the requirements of their healthcare services as presented in Table 4.8 considering the health status of each patient. To achieve this goal the proposed TFT algorithm is applied for each vehicle. The available networks are ranked as shown in Figure 3.20. From the obtained results it is clear that the ranking of the network alternatives is in accordance with the vehicles expectations. For example, vehicle 1 requiring increased QoS provisioning selects the LTE 1 network which guarantees the best QoS characteristics and service reliability. In particular, LTE 1 achieves higher ranking than the other networks, due to the high values of the QoS characteristics and the service reliability factors bearing higher importance according to the relative ANP weights for the Live Video service. On the contrary, vehicle 4 whose prior selection criterion is the throughput of the service, selects the WAVE 1 network which satisfies his requirements considering the Clinical Data service constraints and the Non-Urgent health status of its patient. The performance of TFT, was evaluated against the ANST [174] and the FAS [175] methods. A critical weakness of ANST is that it considers only the throughput criterion, while a weakness of FAS is that it does not support vehicles with more than one service. Therefore, in the case of FAS only the most demanding service of the vehicle is considered when more than one service is required. Specifically, for vehicles 5, 7, 9 and 10 FAS is applied only for the Sensor Data
  • 104. 78 Mobility Management Table 3.14 The Available Wide Coverage Networks for each Service. Medical Service Network Throughput Delay Jitter Packet Loss Service Reliability Security Price Live Video LTE1 VG AG AG VG AG VG P LTE2 G MG VG AG VG AG AP LTE3 AG AG MG VG AG AG VG LTE4 MP P VG G M P MG WAVE1 MG MG G VG MG MG AG WAVE2 AP AP G VP AP AG M WAVE3 MP M MG G AG G AG WAVE4 M M VG MG MG MG G WiMAX1 VG AG VG G AG VG MG WiMAX2 MG M MP VG MG MG M Medical Images LTE1 MG MG VG AG AG VG P LTE2 AG AG AG MG VG AG AP LTE3 AG VG G G AG VG VG LTE4 M VG G M VG P MG WAVE1 MG MG AG MG MG G AG WAVE2 G G VG VG AG AG M WAVE3 MG MG AG VG MP G AG WAVE4 G G VG VG MG G G WiMAX1 MG VP AG G VG AG MG WiMAX2 VG AG AG VG MP G M Sensor Data LTE1 MP P P VP VG G P LTE2 M G MG MP MG G AP LTE3 G G VG VG M G VG LTE4 MG MP M MG M AG MG WAVE1 MP MG VG MG AG VG AG WAVE2 AG AG AG VG VG AG M WAVE3 G VG AG AG VG G AG WAVE4 MG AG G MG MG VG G WiMAX1 MG MP VG G MG MG MG WiMAX2 G G AG MG MG VG M Clinical Data LTE1 G M VG VG AG VG P LTE2 VG AG VG AG MG AG AP LTE3 G G VG AG VG G VG LTE4 AG VP P VG AP VP MG WAVE1 VG VG AG AG VG AG AG WAVE2 G G VG VG M G M WAVE3 MP P P P M VG AG WAVE4 G VG G AG MG AG G WiMAX1 AG VG AP VG G AG MG WiMAX2 MP MG AG MP MG G M service. Additionally, for vehicle 6 it is applied only for the Live Video service, whereas for vehicle 8 it is applied only for the Medical Images service. Table 3.20 presents the network classification performed by the proposed TFT, the ANST and the FAS algorithms, respectively. From the analysis of the results we conclude that the proposed method achieves better performance for the entire vehicles. Indicatively, the TFT results concerning vehicle 2 are better than the ones obtained from both ANST and FAS, due to the fact that TFT selects the LTE 1 network which offers AG packet loss, while the ANST selects the LTE 3 and the FAS select the WAVE that offer G and VG packet loss respectively. Additionally, TFT provides more reliable results for vehicle 10 by taking into account the criteria importance for the Medical Images, the Sensor Data and the Clinical Data services as
  • 105. 3.1 Related Methodologies 79 Table 3.15 The Simulated Vehicles for the Evaluation of the TFT Algorithm. Vehicle Medical Services Patient Health Status 1 Live Video Very urgent 2 Medical Images Urgent 3 Sensor Data Standard 4 Clinical Data Non urgent 5 Live Video & Sensor Data Very urgent 6 Live Video & Medical Images Immediate 7 Medical Images & Sensor Data Very urgent 8 Medical Images & Clinical Data Urgent 9 Sensor Data & Clinical Data Standard 10 Medical Images & Sensor Data & Clinical Data Immediate Table 3.16 Networks’ Classification in respect of TFT, ANST and FAS Results. Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10 ❵❵❵❵❵❵❵Networks Method TFT ANST FAS TFT ANST FAS TFT ANST FAS TFT ANST FAS TFT ANST FAS TFT ANST FAS TFT ANST FAS TFT ANST FAS TFT ANST FAS TFT ANST FAS LTE 1 1 2 1 1 8 3 3 9 7 4 8 9 2 3 7 2 3 1 2 8 7 3 8 3 4 8 7 2 8 7 LTE 2 3 4 2 3 2 10 5 7 5 2 4 4 4 7 5 3 2 2 4 5 5 1 2 10 3 2 5 4 2 5 LTE 3 2 1 4 2 1 9 1 2 1 3 5 1 1 1 1 1 1 4 1 1 1 2 1 9 1 4 1 1 1 1 LTE 4 6 9 7 6 10 2 7 4 10 6 1 6 8 9 10 5 8 7 6 10 10 6 10 2 8 1 10 6 10 10 WAVE 1 4 6 5 4 9 7 2 8 3 1 3 3 3 6 3 4 5 5 3 9 3 4 7 7 2 6 3 3 7 3 WAVE 2 10 10 10 9 5 6 8 1 4 8 6 8 10 10 4 10 9 10 8 4 4 8 5 6 9 3 4 7 4 4 WAVE 3 9 8 9 10 6 4 10 3 9 10 10 7 9 8 9 9 7 9 10 6 9 10 9 4 10 10 9 10 9 9 WAVE 4 7 7 6 5 4 1 4 6 2 5 7 2 5 4 2 7 6 6 5 2 2 5 4 1 5 5 2 5 5 2 WiMAX 1 5 3 3 8 7 5 9 5 8 7 2 10 6 2 8 6 3 3 9 7 8 7 6 5 6 7 8 8 6 8 WiMAX 2 8 5 8 7 3 8 6 3 6 9 9 5 7 5 6 8 4 8 7 3 6 9 3 8 7 9 6 9 3 6 well as the entire set of criteria, while ANST considers only the throughput criterion and FAS takes into account only the Sensor Data service. 3.1.5.3 Network Selection using the TF-AANP and the TFT-ACW Algorithms for sup- porting Medical Services 3.1.5.3.1 Simulation Setup : In our experiments, the 5G-VCC topology presented in Figure 3.21 is simulated. A mobility trace indicating the map of the Syntagma square in Athens along with road traffic data has been created using the Open Street Map (OSM) software [176]. Then, the mobility trace has been used as input in the Simulator of Urban Mobility (SUMO) simulator [177] allowing the production of a realistic mobility pattern for the simulated vehicles. Furthermore, the network topology is being built upon the map, using the Network Simulator 3 (NS3) simulator [178]. The network topology includes a heterogeneous access network environment and a Cloud infrastructure. The access network environment includes 1 LTE Macrocell, 4 LTE Femtocells, 1 WiMAX Macrocell and 4 WAVE RSUs. The Cloud infrastructure includes a set of Virtual Machines (VMs) providing Driver Assistance (DA), Passengers Entertainment and Information (PeNI) and Medical (MED) services. The DA services include Navigation Assistance (NAV) and Parking Assistance (PRK) services. Accordingly, the PEnI services include Conversational Video (CV), Voice over IP (VoIP), Buffered Streaming (BS) and Web Browsing (WB) services. Finally, the MED services include
  • 106. 80 Mobility Management Live Healthcare Video (LHVideo) [9], Medical Images (MedImages) [10], Health Monitoring (HMonitoring) [11] and Clinical Data Transmission (CData) [12] services. Furthermore, a Software Defined Network (SDN) controller provides a centralized control of the entire system. Table 3.17 Linguistic Terms and the corresponding Interval-Valued Trapezoidal Fuzzy Numbers used for the Criteria Attributes for the Evaluation of the TFT-ACW Algorithm. Linguistic term Interval-valued trapezoidal fuzzy number Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.0, 0.9), (0.0, 0.0, 0.0, 0.0, 1.0)] Very Poor (VP) [(0.01, 0.02, 0.03, 0.07, 0.9), (0.0, 0.01, 0.05, 0.08, 1.0)] Poor (P) [(0.04, 0.1, 0.18, 0.23, 0.9), (0.02, 0.08, 0.2, 0.25, 1.0)] Medium Poor (MP) [(0.17, 0.22, 0.36, 0.42, 0.9), (0.14, 0.18, 0.38, 0.45, 1.0)] Medium (M) [(0.32, 0.41, 0.58, 0.65, 0.9), (0.28, 0.38, 0.6, 0.7, 1.0)] Medium Good (MG) [(0.58, 0.63, 0.8, 0.86, 0.9), (0.5, 0.6, 0.9, 0.92, 1.0)] Good (G) [(0.72, 0.78, 0.92, 0.97, 0.9), (0.7, 0.75, 0.95, 0.98, 1.0)] Very Good (VG) [(0.93, 0.98, 1.0, 1.0, 0.9), (0.9, 0.95, 1.0, 1.0, 1.0)] Absolutely Good (AG) [(1.0, 1.0, 1.0, 1.0, 0.9), (1.0, 1.0, 1.0, 1.0, 1.0)]
  • 107. 3.1 Related Methodologies 81 Table 3.18 The Available Networks. Service SLA 1 SLA 2 SLA 3 Network Throughput Delay Jitter Packet Loss Service Reliability Security Price NavigationAssistance (NAV) LTE Macro G MG VG AG VG AG VG LTE Femto 1 VG AG VG VG AG MG P LTE Femto 2 AG G AG G VG G G LTE Femto 3 G MG G MG G AG P LTE Femto 4 AG AG MG AG G G AP WiMAX Macro G AG G VG AG VG VP WAVE 1 VG MG VG AG VG AG G WAVE 2 MG MG VG VG G G AP WAVE 3 MG MG G VG MG MG M WAVE 4 M M MG VG MG MG MP ParkingAssistance (PRK) LTE Macro MG M G VG VG AG MP LTE Femto 1 AG AG AG AG AG VG G LTE Femto 2 VG AG M VG AG G AG LTE Femto 3 G VG MG AG VG AG MG LTE Femto 4 MG G M G VG G G WiMAX Macro G M M AG MG M MP WAVE 1 M MP MG VG G G VG WAVE 2 MG M M AG M M M WAVE 3 AG G G AG MG MG P WAVE 4 G M AG AG MG G G ConversationVideo (CV) LTE Macro AG AG AG VG VG AG G LTE Femto 1 MP MG VG AG AG VG AP LTE Femto 2 G G MG VG AG MG M LTE Femto 3 AG VG AG G VG G P LTE Femto 4 G VG VG AG MG AG MG WiMAX Macro MP M MG G G G MP WAVE 1 G G VG VG G G M WAVE 2 MG MG AG VG G MG AG WAVE 3 MG MG G AG MG VG MP WAVE 4 MP MP MG AG MG G P VoiceoverIP (VoIP) LTE Macro VG VG AG AG VG AG AP LTE Femto 1 M G VG VG AG VG G LTE Femto 2 G VG MG AG VG G MG LTE Femto 3 MG G G VG G MG MP LTE Femto 4 VG AG VG AG VG VG P WiMAX Macro M G MG MG G G M WAVE 1 M MG AG AG G G VG WAVE 2 MG M VG AG MG M M WAVE 3 VG AG VG AG MG VG G WAVE 4 G VG G AG MG G AG BufferedStreaming (BS) LTE Macro G MG VG AG VG AG VG LTE Femto 1 VG AG AG VG AG VG P LTE Femto 2 AG VG VG MG MG AG G LTE Femto 3 G MG VG G VG G M LTE Femto 4 AG AG AG VG G G P WiMAX Macro G AG G VG AG VG VP WAVE 1 VG MG VG AG VG AG G WAVE 2 MG MG VG VG G G AP WAVE 3 MG MG G VG MG MG M WAVE 4 M M MG VG MG MG MP WebBrowsing (WB) LTE Macro MG M G VG VG AG MP LTE Femto 1 AG AG AG AG AG VG G LTE Femto 2 G G M G G VG G LTE Femto 3 AG AG MG AG VG MG M LTE Femto 4 VG G G VG MG G MG WiMAX Macro G VG MG G M VG M WAVE 1 M MP MG VG G G VG WAVE 2 MG M M AG M M M WAVE 3 AG G G AG MG MG AP WAVE 4 G M AG AG MG G G LiveHealthcareVideo (LHVideo) LTE Macro MG MG G VG MG VG MP LTE Femto 1 MP MG VG AG AG VG AP LTE Femto 2 G VG AG AG VG G G LTE Femto 3 VG AG G AG G MG M LTE Femto 4 MG G VG G AG AG G WiMAX Macro MP M MG G G G MP WAVE 1 G G VG VG G G M WAVE 2 MG MG AG VG G MG AG WAVE 3 AG AG AG AG VG AG G WAVE 4 MP MP MG AG MG G P MedicalImages (MedImages) LTE Macro M MG AG AG G AG VG LTE Femto 1 M G VG VG AG VG G LTE Femto 2 AG AG VG AG VG AG P LTE Femto 3 VG MG G MG G MG MP LTE Femto 4 G G VG G AG G MP WiMAX Macro M G MG VG G G M WAVE 1 VG VG AG AG VG AG AP WAVE 2 MG M VG AG MG M M WAVE 3 VG AG VG AG MG VG G WAVE 4 G VG G AG MG G MP HealthMonitoring (HMonitoring) LTE Macro G MG VG AG VG AG VG LTE Femto 1 VG AG AG VG AG VG P LTE Femto 2 AG G G G MG G VG LTE Femto 3 VG AG MG AG MG VG G LTE Femto 4 G VG VG G G G VG WiMAX Macro G AG G VG AG VG VP WAVE 1 VG MG VG AG VG AG G WAVE 2 MG MG VG VG G G AP WAVE 3 MG MG G VG MG MG M WAVE 4 M M MG VG MG MG MP ClinicalDataTransmission (CData) LTE Macro MG M G VG VG AG MP LTE Femto 1 AG AG AG AG AG VG P LTE Femto 2 AG VG MG VG VG G M LTE Femto 3 G AG M G G MG M LTE Femto 4 VG G G AG VG AG G WiMAX Macro G MG VG G VG MG AG WAVE 1 M MP MG VG G G AG WAVE 2 MG M M AG M M M WAVE 3 AG G G AG MG MG P WAVE 4 G M AG AG MG G G
  • 108. 82 Mobility Management Table 3.19 The Simulated Vehicles for the Evaluation of the TFT-ACW Algorithm. Vehicle SLA Vehicular Services Patient Health Status 1 1 PRK, CV, BS, WB, LHVideo Immediate 2 1 WB, MedImages, HMonitoring Non-Urgent 3 1 NAV, VoIP, HMonitoring Standard 4 1 NAV, WB, CData Urgent 5 2 CV, LHVideo, MedImages Non-Urgent 6 2 CV, WB, MedImages Immediate 7 2 WB, HMonitoring Very urgent 8 3 WB, MedImages, CData Standard 9 3 NAV, HMonitoring, CData Urgent 10 3 WB, MedImages, HMonitoring Immediate Table 3.20 The Classification of the Networks according to TFT-ACW, TFT and FSAW Results. Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10 ❵❵❵❵❵❵❵Networks Method TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW TFT-ACW TFT FSAW LTE Macro 4 3 3 2 2 2 1 1 1 2 2 1 2 2 1 2 1 1 1 2 2 1 1 2 2 3 4 3 2 3 LTE Femto 1 3 2 1 1 1 1 - - - - - - - - - - - - - - - - - - 3 1 1 2 1 1 LTE Femto 2 2 1 2 3 4 3 - - - - - - - - - - - - - - - - - - - - - - - - LTE Femto 3 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - LTE Femto 4 - - - - - - - - - 1 4 5 - - - - - - - - - - - - - - - - - - WiMAX Macro 7 7 8 6 7 7 3 3 2 4 5 3 4 4 4 4 4 4 3 3 3 3 3 3 4 2 3 4 5 5 WAVE 1 5 4 4 4 3 4 2 2 3 3 1 2 3 3 3 1 3 3 2 1 1 2 2 1 1 4 2 1 3 2 WAVE 2 6 6 7 8 8 8 5 5 5 6 7 7 - - - - - - - - - - - - - - - - - - WAVE 3 1 5 5 5 5 6 4 4 4 7 6 6 1 1 2 3 2 2 4 4 4 4 4 4 5 5 5 5 4 4 WAVE 4 8 8 6 7 6 5 6 6 6 5 3 4 - - - - - - - - - - - - - - - - - -
  • 109. 3.1 Related Methodologies 83 Vehicle 8Vehicle 8 Vehicle 7Vehicle 7 Vehicle 6Vehicle 6 Vehicle 5Vehicle 5 Vehicle 4Vehicle 4 Vehicle 3Vehicle 3 Vehicle 1Vehicle 1 Vehicle 10Vehicle 10 Vehicle 9Vehicle 9 LTE MacroLTE Macro WAVE RSU2 WAVE RSU3 WAVE RSU4 WAVE RSU1 LTE Femto1 LTE Femto3 LTE Femto2 LTE Femto2 LTE Femto4 WiMAX Macro WiMAX Macro Cloud VM Services VM Services VM Services VM ServicesVM Services VM Services ... ... ... SDN controller SDN controller Vehicle 2Vehicle 2 Heterogeneous Access Network Environment Figure 3.21 The Simulated Topology for the Evaluation of the TF-ANP and the TFT Algorithms. Three Service Level Agreements (SLAs) are defined. Each SLA determines the available networks for each service type. SLA1 supports all the available networks while SLA3 supports only a small subset of the available networks. Table 4.1 presents the lingustic terms and the corresponding interval-valued trapezoidal fuzzy numbers used for the criteria attributes of the available networks, while Table 3.18 presents the corresponding specifications per service and SLA of each network, in terms of throughput, delay, jitter, packet loss ratio, price, security and service reliability. We consider the case where 10 vehicles with patients are moving inside the network environment and need to be connected to a network which satisfies the requirements of their services and at the same time complies with their patient health status, as well as with their respective SLA agreements. The health status of each patient is evaluated using the Manchester Triage System (MTS) [173] healthcare classification system, which defines 5 health statuses, called Non-Urgent, Standard, Urgent, Very-Urgent and Immediate. The Non-Urgent status has the lower risk about patient’s life, while the Immediate status has the higher one. 3.1.5.3.2 Performance Evaluation : During the network selection process initially the relative importance ˜ω ˜ps of each service is considered with respect to the patient health status. Figure 3.22 presents the importance of each service per patient health status, as it is obtained
  • 110. 84 Mobility Management using the TF-AANP method. As it can be observed, the importance of the MED services depends on the patient health status. Indicatively, when the patient health status becomes immediate, the MED services obtain higher importance than the DA and the PEnI services. Accordingly, when the patient health status becomes Non-Urgent, the relative importance of the services is quite similar. Subsequently, the TF-AANP estimates the decision weights we per service type and patient health status, using the ANP network model proposed in [171]. The criteria weights per SLA for the DA and the PEnI services are presented in Figures 3.23 and 3.24, respectively. Also, for each possible health status, the criteria weights per healthcare service for the MED services are presented in Figure 3.25. As illustrated the weights are proportional to the constraints of each service as well as to the health status of each patient. In particular, the weight of the price criterion is low for Immediate health status, resulting in a weight value which is very close to 0. Accordingly, when the health status is evaluated as Non-Urgent, the medical risk for the patient is very low and the price criterion becomes more important. Considering the relative importance ˜ω ˜ps of each service and the criteria weights we for the DA, PEnI and MED services, the final criteria weights are estimated for each vehicle with respect to the health status of onboard patients, as well as to the SLA of each vehicle (Figure 3.26). The ranking of the network alternatives is performed using the TFT-ACW algorithm using the afforementioned criteria weights for each vehicle. Figure 3.22 The Importance of each Service per Patient Health Status. Subsequently, the experimental results of the TFT-ACW method are compared with the ones obtained using the TFT [171] and the FSAW [179] algorithms (Table 3.20). When the
  • 111. 3.1 Related Methodologies 85 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 SLA 1 SLA 2 SLA 3 SLA 1 SLA 2 SLA 3 Navigation Assistance Parking Assistance TF-AANPweight Criteria Weights for Driver Assistance services per SLA Throughput Delay Jitter Packet loss Service Reliability Security Price Figure 3.23 The TF-AANP Criteria Weights for the DA Services per SLA. 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 SLA 1 SLA 1 SLA 2 SLA 1 SLA 2 SLA 1 SLA 2 SLA 3 VoIP Conversational Video Buffered Streaming Web TF-AANPweight Criteria Weights for Passengers Entertainment and Information services per SLA Throughput Delay Jitter Packet loss Service Reliability Security Price Figure 3.24 The TF-AANP Criteria Weights for the PeNI Services per SLA. patient health status is Non-Urgent (vehicles 2 and 5) or Standard (vehicles 3 and 8) the results of TFT-ACW and TFT are similar, due to the similar relative importance considered by the TFT-ACW for each service. However, when the patient health status gets worse, the TFT-ACW assigns higher importance to the MED services and selects the most appropriate network to satisfy their strict constraints. Indicatively, in the case of vehicle 1, TFT-ACW selects the WAVE 3 network, which provides VG for service reliability, as well as AG for throughput, delay, jitter, packet loss and security, for the LHVideo medical service. On the contrary, the results of both TFT and FSAW are negatively affected by the existence of non medical services in the vehicle 1 ignoring the immediate health status of the patient. Specifically, TFT selects the LTE Femto 2 network, which provides worse specifications for the LHVideo service (e.g. G for throughput and VG for delay), while FSAW selects the LTE Femto 1 network, which also provides worse specifications for the aforementioned medical service (e.g. MP for throughput and MG for delay).
  • 112. 86 Mobility Management Figure 3.25 The TF-AANP Criteria Weights for the MED Services per SLA and Patient Health Status. 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10 TF-AANPweight The TF-AANP weights for each vehicle Throughput Delay Jitter Packet loss Service Reliability Security Price Figure 3.26 The TF-AANP Weights for each Vehicle.
  • 113. 3.2 Mobility Management Schemes for 5G Wireless Networks 87 3.2 Mobility Management Schemes for 5G Wireless Networks 3.2.1 Existing Mobility Management Schemes In this section an overview of the existing mobility management schemes is presented. The mobility management process consists of the handover (HO) initiation, the network selection and the HO execution subprocesses. The consideration of the subprocesses that each scheme implements provides a useful view about each scheme’s functionalities. Some schemes implement only the HO initiation subprocess. These schemes aim at the evaluation of the necessity to perform a handover, by avoiding either unnecessary or delayed HOs, in order to ensure the continuity of vehicular services. Several parameters can be considered. The most common ones include signal quality factors, criteria that affect the vehicular services, the vehicle’s velocity, the cells’ coverage area and the operators’ policies. Also, it should be noted that in these cases, the network selection and the HO execution must be performed using third party algorithms. The Street Specific Handover for Vehicular Terminals (SSHVeT) [180] algorithm considers street aware parameters to evaluate the necessity of performing a handover. Parameters such as vehicle velocity, road direction, Reference Signals Received Power (RSRP) [181] and radio propagation characteristics are considered for the HO initiation. The algorithm adapts the corresponding handover thresholds considering the obtained parameter values for each street, in order the ping-pong effect to be minimized. The Improved Inter-Network Handover (IINH) [182] estimates the necessity of performing a handover considering the cell size and the vehicle velocity, which affect the time that a vehicle will remain inside the coverage area of a cell. The vehicle makes the decision of performing a handover considering the aforementioned parameters. It should also be noted that the cell size is estimated considering the RSS, the path loss, the required transmission power from the vehicle to the base station, and the geographical terrain information. The scheme is implemented in the network layer using the functionalities offered by Mobile IP (MIP) to manipulate the vehicle mobility. The Decision Process for Vertical Handover in Vehicular Networks (DPVHO) [183] algo- rithm estimates the necessity to perform a HO when the vehicle moves from an area covered by a network to an area covered by another network. It aims at reducing the HOs failure rate and the unnecessary HOs using a utility function based mechanism where parameters such as RSS, vehicle trajectory, cell radius and path loss exponent of each place are considered. The Context Aware Handover Policy (CAHP) in [184] scheme considers an LTE network topology where both Macrocells and Femtocells exist. A load-aware algorithm is described, which determines two handover thresholds, namely the γM th and the γF th, for Macrocells and
  • 114. 88 Mobility Management Femtocells, respectively. Both of these thresholds are evaluated, considering the Reference Signal Received Power (RSRP) threshold defined in LTE [14], as well as network load infor- mation. When RSRP drops below the corresponding γth threshold, a Time-to-Trigger (TTT) timer is activated, which is initialized to a certain value T, considering parameters such as the cell transmission power, the distances between the available cells, the path loss, the carrier frequency, the network traffic load and the user velocity. During the countdown, if RSRP returns to values above the corresponding γth threshold, the timer is deactivated. Otherwise, when the timer becomes equal to zero, the handover is initiated and the user is transferred to the network with the highest RSRP. The Context Aware Load Balancing (HO-CALB) [185] is another HO initiation scheme. It considers the scenario where both WiFi and WiMAX networks coexist. A network load aware algorithm distributes the traffic load to the WiFi and the WiMAX networks considering the available bandwidth of each network. Each user has a set of services with strict QoS constraints. If the observed QoS drops below a threshold, a handover policy instructs the users to perform a handover. Several schemes implement only the network selection subprocess. These algorithms aim at the selection of the most appropriate access network for each vehicular user among a set of network alternatives. Similar to the HO initiation algorithms, several parameters can be considered, including Quality of Service (QoS) or Quality of Experience (QoE) factors, user preferences and operators’ policies. In these cases, the HO initiation and the HO execution must be performed using third party algorithms. The Mobility Aware Handover in Ultra Dense Vehicular Environment (MAH-UDVE) [186] scheme considers the direction of a vehicle’s mobility to select the most appropriate network. The vehicle movement is statistically analyzed in order to create a set of possible next cells. Subsequently, four different approaches can be applied to select the most appropriate cell from the aforementioned set. The first approach selects the nearest cell, while the second approach selects the next cell that exists in the same street in the same direction with the direction of vehicle movement. The third approach selects the next cell that exists in the same street, but in the opposite direction of the vehicle’s movement. Finally, the fourth approach selects the cell with the lowest load. The Intelligent Network Selection (INS) [187] scheme implements the network selection process for supporting audio and video streaming vehicular services in heterogeneous network access environments. A utility function which considers the SNR, the channel capacity and the connection life time parameters is used. For the estimation of the connection lifetime parameter the vehicle’s velocity and the cell radius are also considered. The candidate network which obtains the higher score from the proposed utility function is selected.
  • 115. 3.2 Mobility Management Schemes for 5G Wireless Networks 89 The Technique for Order Preference by Similarity to Ideal Solution (TOPSIS) [188][189] algorithm performs the selection of the best network access technology by considering contra- dictory selection criteria. The main concept of the TOPSIS algorithm is that the best alternative network should have the shortest distance from the positive ideal solution and the longest distance from the negative ideal solution. The criteria that could be considered include the network throughput, the delay, the jitter, the packet loss ratio, the network usage price, the security and the service reliability. Also, the importance of these criteria can be estimated either using the Analytic Hierarchy Process (AHP) [190] or the Analytic Network Process (ANP) [191] method. The Simple Additive Weighting (SAW) [188] considers multiple criteria to perform the network selection. Firstly, the criteria weights are estimated using a method such as AHP or ANP. Subsequently, for each network alternative, the criteria values are normalized. Then, each value is multiplied with the corresponding weight in order the weighted criteria values to be calculated. Finally, the weighted criteria values are summarized in order to estimate the overall rating of the network alternative. The network with the highest rate is finally selected. The Multiplicative Exponent Weighting (MEW) [188] method is similar to SAW. However, in MEW the weighted criteria values are multiplied with each other to estimate the overall rating of the network alternative. The Gray Relational Analysis (GRA) [192] analyzes the relationship grade between the network alternatives and the ideal solution to perform the network selection. The ideal solution is calculated first. Subsequently, the similarity of each alternative network with the ideal solution is estimated using the Grey Relational Coefficient (GRC) [193]. The network with the highest similarity to the ideal solution is selected. The concept of the Distance to Ideal Alternative (DIA)[188] algorithm is similar to the concept of TOPSIS. Firstly, DIA estimates the positive and the negative ideal solutions. Then, the Manhattan distance [194] of each network from the positive and from the negative solution is calculated. The network that has the shortest distance from the positive ideal solution and the longest distance from the negative ideal solution is selected. The Weighted Product Method (WPM) [195] for each alternative network raises the nor- malized criteria values to the corresponding criteria weights values. Subsequently, the method calculates the product of the weighted values. The network with the highest product is finally selected. In Quantum-inspired Immune Clonal Algorithm for Network Selection (QICA-NS) [196] two utility functions are used for network selection, one for the user and one for the network. The user utility function considers user related parameters, such as the user preferences, his moving velocity and his monetary budget. Accordingly, the network utility function considers
  • 116. 90 Mobility Management network related parameters, such as the network load, the price and the network QoS which is estimated using TOPSIS. Sometimes many users have similar trajectories as they move. This situation becomes more frequent in the case of vehicular networks, since each vehicle usually serves multiple passengers. Consequently, many users with similar positions and requirements need to perform a network selection, usually considering the same network alternatives. In such cases, increased computational overhead arises from the decision process, since this process runs independently for each user. To address this issue, algorithms for performing group handover have been proposed in the research literature. An algorithm of this category groups users with similar trajectories in order to perform the network selection once for the entire user group, thus releasing usable system resources. The Group Vertical Handover using Time Window (GVHO-TW) [197] distributes the MTs HO requests in a time sequence. Thus, each MT performs network selection using a utility function when its turn comes, considering the decision of all the previous MTs in order to select the most appropriate network not only to satisfy its requirements, but also to achieve a satisfactory load distribution to the available access networks. Although GVHO-TW avoids the calculation of simultaneous decisions of multiple MTs, ad- ditional handover delays occur since each MT waits for its turn in order to perform the network selection. To address this issue, the Group Vertical Handover with Probability Distribution (GVHO-PD) [197] scheme uses a probability distribution vector instead of a time window. This vector contains a value for each available network, which determines the probability of the network to be selected from the MTs, considering its performance. Subsequently, each MT generates a random MT probability value and compares it with the values of the aforementioned probability vector. The network with the closest probability to the random MT probability value is selected. Thus, the MTs are distributed to the available networks. Although the GVHO-PD scheme distributes probabilistic the workload to the available networks, it does not optimize the entire system performance. To address this issue the Network Assisted Group Vertical Handover (NA-GVHO) [197] scheme does not use a probability vector, but it collects information from both the networks and the MTs. Then, each MT performs the network selection using a Multi Attribute Decision Making (MADM) algorithm which considers both the MT’s requirements and the current workload of each network, in order to distribute the workload to the available networks. In general, there is a rate of uncertainty in characterizing performance measurements as well as rates of influence of performance metrics. Therefore, fuzzy MADM (FMADM) methods expressing uncertain quantities by fuzzy numbers have received the interest of many researchers in decision theory. In particular several FMADM network selection methods are suggested
  • 117. 3.2 Mobility Management Schemes for 5G Wireless Networks 91 utilizing linguistic variables, triangular fuzzy numbers, trapezoidal fuzzy numbers etc. to model network attributes and their respective weights. The use of fuzzy logic for network selection requires the definition of logic rules from specialists with thorough knowledge of the behavior of the available access networks in various conditions. The Trapezoidal Fuzzy TOPSIS (TFT) [171] deals with the network selection process. It is a fuzzy version of the TOPSIS algorithm. TFT uses linguistic values for evaluating the criteria attributes, while each linguistic value is represented by an Interval Valued Trapezoidal Fuzzy Number (IVTFN) [198]. The criteria considered for the candidate networks ranking include throughput, delay, jitter, packet loss, price, security and service reliability. The Analytic Network Process (ANP) [191] is used for the estimation of the criteria weights indicating the importance of each criterion. The network that accomplishes the higher TFT rank is selected. The Trapezoidal Fuzzy TOPSIS with Adaptive Criteria Weights (TFT-ACW) [66] is an improved version of the TFT algorithm. It deals with the satisfaction of the constraints of multiple vehicular services, in cases where MED services coexist with other service types in the vehicular environment. Specifically, DA services, PEnI services and MED services are considered that provided to vehicular users. The presence of MED services affects the importance of other services in situations where patients with immediate health status exist within the vehicle. The criteria used for network evaluation include throughput, delay, jitter, packet loss, service reliability, security and price. The Trapezoidal Fuzzy Adaptive Analytic Network Process (TF-AANP) is also proposed for the estimation of the services importance as well as of the corresponding criteria weights, which are adapted considering the health status of onboard patients and the Service Layer Agreement (SLA) of each vehicle. In Intelligent Access Selection using Fuzzy Neural Network (IAS-FNN) [199] the concepts of fuzzy logic, neural networks and utility functions are combined to perform network selection. The proposed method makes use of a fuzzy neural network which obtains network, user and terminal related input criteria and evaluates the performance of each access network. The attributes of the criteria are defined through utility functions and processed through the fuzzification, interference and defuzzification layers of the neural network. It should also be noted that some schemes implement only the HO execution. These algorithms determine the signaling that should be performed in order the HO to be successfully completed. A critical parameter that should be satisfied is the HO delay which is directly affected by the aforementioned signaling. Also, in the case of such algorithms, the HO initiation and the network selection must be performed using third party algorithms. In Bulk Fast PMIPv6-based Network Mobilty (BFP-NEMO) [200], one or more RSUs are controlled by a Mobility Management Entity (MME) [201], which is called Mobile Access Gateway (MAG). The vehicles that are inserted in a MAG domain are grouped. Then, the
  • 118. 92 Mobility Management corresponding MAG pre-establishes a bidirectional tunnel between the vehicles’ group and the candidate neighboring MAGs. Each neighboring MAG caches the data for each vehicle of the aforementioned group. Subsequently, when a vehicle of the group is connected to the next RSU, the corresponding MAG forwards the cached data to the vehicle. The Enhanced Proxy Fast-handover Mobile IPv6 for Vehicular Networks (ePFMIPv6) [202] scheme implements a proactive Layer 3 handover mechanism. The concept of Mobile Access Gateway (MAG) is considered in this scheme as well. The issue of the simple PFMIPv6 protocol, where the next MAG waits to receive a Handover Acknowledge (HAck) [203] message from the serving MAG (although the vehicle has arrived to it) to start the data forwarding to vehicles, is resolved. Specifically, when the serving MAG services the vehicle, it also establishes a tunnel with each neighboring MAG which is considered as a candidate next MAG for the vehicle according to its RSS. When the vehicle arrives to its next MAG, its data are immediately forwarded to it through the aforementioned tunnel, without waiting for the HAcK message. Finally, when the HAcK message is received by the next MAG, the tunnel is abolished and the data which follows are forwarded to the vehicle by the next MAG without the tunnel. In this case, the "next MAG" which is now considered as the serving MAG establishes a tunnel with each neighboring candidate next MAG and so on. Schemes that implement more than one mobility management subprocesses have also been proposed in the research literature. Many of these schemes implement both HO initiation and network selection. The Predictive Handover Mechanism for Video Streaming in Cloud Based Urban VANET (PHMVV) [204] scheme defines a list of available networks is created for each vehicle con- sidering its velocity, its distance from each network, as well as its moving direction. The assumption that the vehicle knows its geographical position, as well as the positions of the available networks, is made. Each vehicle monitors the link quality of the candidate networks, considering their Signal to Noise Ratio (SNR), Bit Error Rate (BER) and Packet Error Rate (PER) parameters. If a network alternative has higher link quality than the vehicle’s current network, the vehicle performs a handover to this alternative. Another scheme that implements both HO initiation and network selection is the Mobility Aware Handover for Smart Cities Environment (MAH-SCE) [205]. MAH-SCE uses traffic information that is gathered by sensors that are deployed in a Smart City [206] environment, to perform the HO initiation and the network selection. The scheme decides when to initiate a handover as a function of the aforementioned sensor data about the road traffic, as well as the perceived SNR. Subsequently, the vehicles with velocity up to 16 m/s consider both Macrocells and Femtocells as alternatives for performing a handover to them. In this case, if Femtocells exist inside the vehicle’s area, the scheme selects the Femtocell which has the higher estimated
  • 119. 3.2 Mobility Management Schemes for 5G Wireless Networks 93 time that the vehicle will remain connected without a need to perform a handover to another cell. On the contrary, if the vehicle velocity is higher than 16 m/s only the Macrocells are considered as alternatives and the one that maximizes the time that the vehicle will remain connected to it, is selected. The Speed-based Vertical Handover (S-VHO) [207] scheme also implements the HO initiation and the network selection subprocesses of the HO management. During the HO initiation, the algorithm considers the vehicle’s velocity, the ingress time of the vehicle to the current cell and the geographical position of the vehicle (using its GPS) to calculate the cell crossing time. Subsequently, considering both the estimated cell crossing time and the observed throughput, the algorithm decides when a HO must be initiated. Afterwards, the alternative network that maximizes the throughput is selected and, then, the algorithm is deactivated for a time period T in order the ping-pong effect to be reduced. Finally, when the algorithm is reactivated it estimates when the next HO must be initiated. The Media Independent Handover using Predictive Geographical Information (MIH-PGI) [208] defines a MIH-oriented HO mechanism for ensuring the continuity of the vehicular services and the minimal handover latency. During the HO initiation the vehicle estimates the appropriate time to perform a handover by predicting the behavior of its current network link quality based on the geographic information received from the Media Independent Information Services (MIIS) component of the MIH protocol, about the network access point position as well as the velocity of the vehicle. Subsequently, the vehicle lists the available candidate networks, while the next network is selected considering the estimated time duration that the vehicle will remail inside the coverage area of each candidate network. Thus, the network which maximizes this time is selected in order to minimize the number of future handovers. The Cognitive Vertical Handover for Vehicular Communication (CVHO) [209] scheme considers multiple criteria to perform mobility management in a cognitive radio vehicular environment. The handover initiation considers parameters such as the RSS, the available bandwidth, the delay, the network load, the usage cost, the vehicle velocity and the service type, to evaluate the necessity of performing a VHO. Subsequently, the network selection is performed using the Analytic Hierarchy Process (AHP) [190] method using the aforementioned criteria. An Artificial Neural Network (ANN) [210] is used to train the scheme to adapt its handover threshold in order to take the reflex action to avoid either unnecessary handovers or link-down situations. The ANN is trained considering the success or the failure of all the previous handover initiation and network selection decisions. The Auction Approach for Mobility Prediction (AAMP) [211] scheme defines a group based HO management mechanism which aims to maximize system throughput, while at the same time to minimize the network load when multiple vehicles perform simultaneous
  • 120. 94 Mobility Management handovers. It assumed that each vehicle is equipped with a GPS device. When a vehicle reaches the edge of its current network’s coverage, it triggers a VHO, while at the same time it reports its position to a Vertical Handover Decision (VHD) controller, which could be considered as an SDN controller for HO functionalities implementation. When a VHD controller receives a HO request from a vehicle, it creates a list with the candidate networks for the vehicle considering the vehicle’s position. Thus, considering the vehicle’s velocity and position, the VHD controller predicts the entrance time and the exit time of the vehicle from each candidate network. When multiple vehicles of similar positions trigger a handover, the VHD controller groups them. Subsequently, an auction based [212] algorithm selects the most appropriate network for the aforementioned group of vehicles in order the total throughput of the group to be maximized. Thus, the network selection is performed once for the entire group of vehicles and not once per vehicle, thus minimizing the network load occurring from the decision process. The Vertical Handover for Vehicular Cloud Computing Systems (VHO-VCC) [67] scheme takes into account the vehicle’s velocity as well as its current connection type. A two step HO algorithm that reduces operation costs and optimizes mobility management is applied. Initially, a HO initiation process evaluates the necessity to perform handover using a Mamdani inference system [213] which evaluates the user satisfaction grade. When the user satisfaction drops below a predefined threshold, which depends on the vehicle’s SLA, the network selection is performed using TFT in order to select the most appropriate network alternative considering both the vehicular service requirements and the operators’ policies. The Geolocation-based Multi ACcess network Handover algorithm for vehicUlar envi- ronments (GEO-MACHU) [214] algorithm implements three tasks, namely the Networking, the Neighborhooding and the Decision Making task. The Networking task performs the HO initiation considering context-aware information about the current network provided by the Media Independent Event Service (MIES) and by the Media Independent Command Service (MICS) [215] of the IEEE 802.21 MIH protocol (e.g. information about link-down events). The Neighborhooding task collects information about the available networks in the vehicle’s location using the Media Independent Information Service (MIIS) [216] of the MIH protocol . The gathered information is considered by the Decision Making task, which performs the network selection using the TOPSIS algorithm. The Hybrid Communication Approach (HCA) [217] scheme defines two network interface types, namely the IEEE 802.11p network access technology which is considered as the primary interface, while the 3GPP LTE is considered as the secondary. By default, a vehicle is connected to the primary interface. A QoS aware HO initiation algorithm is applied, which instructs the vehicle to perform handover to the secondary interface when the observed packet loss of the provided services exceeds a maximum acceptable threshold. Thereafter, a timer is activated
  • 121. 3.2 Mobility Management Schemes for 5G Wireless Networks 95 specifying the time interval that the user remains connected to a secondary interface. When the timer expires and the estimated packet loss ratio of the primary interface is lower than the maximum acceptable threshold, the vehicle performs a handover back to the primary interface. The Velocity Aware Handover (VAH) [218] HO management scheme defines two network tiers, namely the tier-1 consisting of Macrocells and the tier-2 consisting of Femtocells. Four vertical handover strategies are considered, namely the Best Connected (BC), the Femto Skipping (FS), the Femto Disregard (FD) and the Macro Skipping (MS). The BC strategy is applied to static users and to users with Low mobility, while both Macrocells and Femtocells are considered as alternatives. The user connects to a Macrocell if P1 ·B1 ·R−η 1 > P2 ·B2 ·R−η 2 is satisfied, or to the nearest Femtocell if P1 ·B1 ·R−η 1 < P2 ·B2 ·R−η 2 is satisfied, where P is the transmission power, B is the bias factor, R is the user distance and η is the pathloss exponent for each tier. The FS strategy considers users with Medium mobility. The Femtocells alternatives are skipped to reduce the handover rate, when P1 ·B1 ·R−η 1 < P2 ·B2 ·R−η 2 . In the FD strategy, which is applied to users with High mobility, the user always skips the available Femtocells and connects only to the available Macrocells. Finally, in the MS strategy, for users with extremely High mobility, the user skips the entire set of Femtocells as well as some of the Macrocells. Similarly to the FMADM network selection algorithms, some schemes that perform both HO initiation and network selection apply the operating principles of fuzzy logic. In these cases, as the number of selection criteria and the available networks increases, the rules become more complex, struggling to define effective policies either for evaluating the necessity to perform a handover or for selective the most appropriate network for the user. Accordingly, the use of fuzzy logic based solutions is limited to handover decision schemes with a reduced number of selection criteria and networks. In the Fuzzy Logic Based Vertical Handover (FLB-VHO) [219] scheme, the RSS-based handover initiation mechanism is applied initially. Then, during the second phase, a triangular fuzzy MADM algorithm that considers parameters such as the RSS, the delay, the network load and the battery utilization is used. In Fuzzy MADM for Vertical Handover (FMVHO) [220], an heterogeneous network environment that consists of LTE and WiMAX networks is considered. Firstly, the simple RSS based method is used for the network initiation. Thereafter, a triangular fuzzy version of the TOPSIS method is proposed for the network selection. Network parameters such as the offered data rate and the delay are considered during the network selection process. Several schemes implement both the network selection and the HO execution. The Inter- mediate Mobile Access Gateway Inter-Domain Handover (iMAG-IDH) [221] scheme deals with the network selection and the HO execution parts of the HO management procedure, considering the operating principles of Proxy Mobile IPv6 (PMIPv6). Concerning the network
  • 122. 96 Mobility Management selection process, a location tracking mechanism is used in order to estimate the vehicle’s moving direction. Thus, the most probable next RSU that the vehicle will pass through its coverage area is selected. Subsequently, the scheme proactively performs a Layer 3 handover where the appropriate signaling is exchanged in order to start the forwarding of the next data packets. Afterwards, a Layer 2 handover is performed where the vehicle is attached to the selected RSU. The Hidden Markov Model - Kalman Filter (HMM-KF) [222] scheme deals with the network selection and the HO execution subprocesses of the mobility management. The mobility of the vehicles is modeled by tracking their movement considering information from their GPS devices. Also, each network maintains a Hidden Markov Model (HMM) indicating the possibilities that each vehicle connected to the network has to handover to each neighboring network, which are estimated using the Kalman Filter (KF). Subsequently, considering the HMM each vehicle selects its next network. Afterwards, the appropriate signaling is exchanged between the vehicle and the selected network in order the handover to be performed. Finally, the HMM probabilities of the previous and the new vehicle’s network are updated. The QoS Aware Handover for Session Initiation Protocol services in Vehicular Networks (QAH-SIP) [223] scheme is implemented in the Application Layer of the OSI stack. QAH-SIP defines a HO execution process for supporting vehicular SIP services. Initially, the vehicle performs the network selection considering QoS aware information (such as the maximum acceptable delay and the packet loss, as well as the minimum required RSS) required to satisfy the SIP service constraints. Then, it performs a pre-registration to the selected RSU where the vehicle also sends information about its position and velocity. Then, the selected RSU reserves the required resources in order to be available to serve the incoming vehicle. Subsequently, the SIP signaling process [224] is performed in order the HO to be completed. It should also be noted that some schemes implement the entire mobility management subprocesses, including the HO initiation, network selection and HO execution. The Vertical Handover for VANET using Multiple Parameters (VHOMP) [225] algorithm considers multiple criteria to perform the mobility management. During the HO initiation the Received Signal Strength (RSS) parameter is turned into account. When it becomes lower than a predefined threshold the HO is initiated. Subsequently, the network selection is performed considering the network bandwidth and the vehicle’s velocity. Finally, the HO is executed using the appropriate signaling in order the vehicle to be connected to the selected network. The Navigation Assisted Seamless Handover (NASH) [226] uses a HO initiation algorithm which considers the vehicle velocity, as well as RSRP information, to evaluate the necessity to perform a handover. The navigation information about the vehicle is used in order the most probable trajectory to be estimated, while the next cell that exists in this trajectory is selected.
  • 123. 3.2 Mobility Management Schemes for 5G Wireless Networks 97 Finally, considering an LTE-A network infrastructure the scheme proposes the appropriate signaling that should be performed between the current RSU/BS, the next RSU/BS the MME and the SGW, in order seamless handover to be operated ensuring the continuity of the vehicle’s services. The Robust Handover in Vehicular Networks (RHVN) [227] scheme defines that in Layer 2 the HO initiation is performed when the RSS drops below a predefined threshold. Subsequently, the vehicle selects the RSU with the higher RSS and performs the HO execution. In Layer 3 the handover occurs when a Layer 2 handover is completed. In this case, the vehicle uses its Original Care of Address (OCoA) [228] for fast IP connectivity and then its data are forwarded from its new RSU by applying an improved version of MIPv6 protocol, which considers the permanent vehicle’s OCoA. The Intelligent Handover for Vehicular Networks (IHVN) [229] scheme aims at the sat- isfaction of the real-time services’ constraints during the vehicle’s movement across differ- ent networks. The FMIPv6 mobility management protocol is considered, while the use of 802.21 MIH ensures the interoperability between different network access technologies. Dur- ing the HO initiation process, when the link quality drops below a predefined threshold, a MIH_Link_Going_Down message is transmitted to the vehicle. This message triggers the vehicle to perform a VHO. Subsequently, a list of existing nearby networks is obtained, while link quality information (e.g. bandwidth) is obtained from each candidate network using MIH_MN/N2N_HO_Candidate_Query messages. Then, the link quality parameter is consid- ered in order the network with the higher link quality to be selected. Finally, during the HO execution the appropriate signaling is exchanged between the vehicle and the selected network, while the HO is completed using a MIH_Link_U p message indicating that now the vehicle has been connected to the selected network. In the VANET Backup Communication (VANBA) [230] scheme, the concept of the Com- munication Mediator (CM) is introduced. A CM is a vehicle that provides access to vehicular services through V2V communication. However, in a 5G-VCC systems, the CM could also be a RSU/BS or a pedestrian, that provides access to the services through V2I or V2P communi- cation, respectively. Two processes for accomplishing the mobility management are defined, namely the Link Monitoring and the HO process. The Link Monitoring process, implemented at OSI Layers 6 and 7, monitors which CMs in the vehicle’s area are available for providing access to vehicular applications (e.g. considering the coordinates of their positions). The HO process, implemented at OSI Layer 3, monitors the IP reachability to the services’ providers. When the reachability is lost or the link quality drops below a predefined QoS threshold, a handover should be performed. Subsequently, the candidate CMs are sorted using a utility function where the bandwidth and the monetary cost parameters are considered. Then, the first
  • 124. 98 Mobility Management CM in the sorted list is selected and the HO is executed. If the HO execution fails (e.g. due to topology changes) then the next CM in the aforementioned list is selected and so on. In Vehicular Fast Handover for Mobile IPv6 (VFMIPv6) [231] when the vehicle approaches the boundary of its current RSU (considering the RSS), it sends to the current RSU a request in order handover to be initiated. Along with the request, Handover Assist Information (HAI) is also sent from the vehicle to its current RSU, containing information about the candidate RSUs for the vehicle, considering the RSS of each RSU. The current RSU implements a utility function based mechanism where the HAI information is considered, in order to select the most appropriate next RSU for the vehicle, which is the one that minimizes the handover latency, the packet loss that occurs during the handover and the total communication overhead that is observed due to the handover latency and the corresponding packet loss. Thereafter, the appropriate signaling is exchanged between the current RSU, the selected next RSU, the Mobile IPv6 (MIP) Home Agent (HA) [232][233] and the MIP Correspondent Node (CN) [232] in order the vehicle to be connected to the selected next RSU. Table 3.21 summarizes the main functionalities of the discussed schemes.
  • 125. 3.2 Mobility Management Schemes for 5G Wireless Networks 99 Table 3.21 The Mobility Management Activities of each Scheme. Scheme VHO Initiation Network Selection VHO Execution VHOMP [225] SSHVeT [180] PHMVV [204] MAH-SCE [205] NASH [226] MAH-UDVE [186] RHVN [227] S-VHO [207] BFP-NEMO [200] IINH [182] IHVN [229] VANBA [230] iMAG-IDH [221] VFMIPv6 [231] MIH-PGI [208] CVHO [209] DPVHO [183] GVHO-TW [197] GVHO-PD [197] NA-GVHO [197] ePFMIPv6 [202] AAMP [211] INS [187] HMM-KF [222] QAH-SIP [223] CAHP [184] HO-CALB [185] TOPSIS [188][189] TFT [171] TFT-ACW [66] VHO-VCC [67] GEO-MACHU [214] SAW [188] MEW [188] GRA [192] DIA [188] WPM [195] QICA-NS [196] IAS-FNN [199] FLB-VHO [219] FMVHO [220] HCA [217] VAH [218]
  • 126. 100 Mobility Management Mobility Management Schemes Classification Message Exchange Models Information Centric Host Centric Control Entities Vehicle Controlled Mobility Management Network Controlled Mobility Management Hybrid Controlled Mobility Management Algorithm Categories Context aware Cost Function based MADM User Centric Fuzzy Logic based Neural Network based MIH based Probabilistic Group based Auction based Figure 3.27 Classification of Mobility Management Schemes. 3.2.2 Taxonomy of Existing Mobility Management Schemes In this section, the schemes described in Section III are classified. Firstly, the control entities that can implement each scheme are mentioned. Also, the OSI Layers with which each scheme is involved are considered. Thereafter, the supported message exchange models are described and, finally, the category of each scheme’s algorithm is determined completing an in-depth study about each scheme’s implementation. 3.2.2.1 Control Entities Considering the entities that control the mobility management the entire process could be categorized as Vehicle Controlled or as Network Controlled. Furthermore, some solutions combine both Vehicle and Network control. In these cases, the mobility management process is called as Hybrid Controlled. The following paragraphs describe the available solutions, considering the aforementioned control entities. 3.2.2.1.1 Vehicle Controlled Mobility Management : In the vehicle controlled mobility management schemes the entire process is controlled by the vehicle (or user) equipment, namely the vehicle’s OBU or the passengers’ devices. 3.2.2.1.2 Network Controlled Mobility Management : In the network controlled solu- tions, the mobility management is performed by devices located in the network infrastructure.
  • 127. 3.2 Mobility Management Schemes for 5G Wireless Networks 101 Considering the underling network architecture, the mobility management task can be im- plemented from a Mobility Management Entity (MME) or an SDN controller installed in a Cloud or a Fog infrastructure. Alternatively, a Mobile Access Gateway (MAG) could be used, namely a BS or a RSU enhanced with mobility management capabilities. In general, the entity that performs the mobility management collects the necessary information for evaluating the necessity to perform a HO initiation. Also, after each HO initiation this entity selects the most appropriate network for the vehicle, using the methods that each mobility scheme implements for the network selection process. Subsequently, it orchestrates the HO execution through the appropriate signaling in order the vehicle to be connected to the selected network. Compared to the vehicle controlled mobility management, the network controlled solutions succeed better performance since their functionalities are implemented to the network equip- ment. As a result, the mobility management workload is minimized for the vehicles, while at the same time their energy requirements are decreased. 3.2.2.1.3 Hybrid Controlled Mobility Management : Hybrid controlled solutions deter- mine that the control of the mobility management task is distributed to both the vehicle and the network infrastructure side. Indicatively, in a hybrid controlled HO initiation algorithm, both vehicle and network infrastructure cooperate in order the necessity of performing a han- dover to be evaluated. Accordingly, in a hybrid controlled network selection algorithm the aforementioned cooperation is performed in order the most appropriate network to be selected. In both cases, several vehicle and network parameters can be considered. Indicatively, vehicles parameters can include the perceived QoS, the signal quality, the vehicular users’ preferences or the used services. Also, regarding the network infrastructure side, network load or operator policy information obtained from the network infrastructure are indicative parameters that can be considered. Finally, in a hybrid controlled HO execution algorithm both vehicle’s equipment and network infrastructure cooperate to accomplish the handover. 3.2.2.1.4 Discussion on Mobility Management Control Entities : As it could be ob- served in Table 3.22 some schemes support only vehicle controlled mobility management (SSHVeT [180], DPVHO [183], CAHP [184] and HO-CALB [185]), while some other schemes support both vehicle and network control (TFT-ACW [66], VHO-VCC [67], GVHO-TW [197], GVHO-PD [197], NA-GVHO [197] and AAMP [211]). It should also be noted that although some schemes have not been proposed for supporting network control, it could be performed by implementing some of their functionalities to 5G-VCC components such as a Cloud or a Fog infrastructure (e.g. TFT [171], VHOMP [225], PHMVV [204], MAH-SCE [205] etc.). The implementation of such algorithms in a Cloud or a Fog infrastructure eliminates the mobility
  • 128. 102 Mobility Management management workload that the vehicles OBUs undertake, while at the same time their energy requirements are decreased. Furthermore, in cases where an SDN controller is used, the results of these scheme can be improved since the controller supervises the manipulation of the entire system. Finally, the BFP-NEMO [200] scheme implements only network controlled mobility management. Table 3.22 The Control Types that each Scheme supports. Scheme Vehicle Controlled Network Controlled Hybrid Controlled VHOMP [225] * * SSHVeT [180] PHMVV [204] * * MAH-SCE [205] * * NASH [226] * * MAH-UDVE [186] * * RHVN [227] * * S-VHO [207] * * BFP-NEMO [200] IINH [182] IHVN [229] * * VANBA [230] * * iMAG-IDH [221] * * VFMIPv6 [231] * * MIH-PGI [208] * * CVHO [209] * * DPVHO [183] GVHO-TW [197] GVHO-PD [197] NA-GVHO [197] ePFMIPv6 [202] AAMP [211] INS [187] * * HMM-KF [222] * * QAH-SIP [223] * * CAHP [184] HO-CALB [185] TOPSIS [188][189] * * TFT [171] * * TFT-ACW [66] VHO-VCC [67] GEO-MACHU [214] * * SAW [188] * * MEW [188] * * GRA [192] * * DIA [188] * * WPM [195] * * QICA-NS [196] * * IAS-FNN [199] * * FLB-VHO [219] * * FMVHO [220] * * HCA [217] * * VAH [218] * * : Directly supported , *: Could be supported to a 5G-VCC architecture
  • 129. 3.2 Mobility Management Schemes for 5G Wireless Networks 103 3.2.2.2 Message Exchange Models Message exchange models determine how the entities communicate each other in a VCC architecture. Two models are available in VCC, the host centric and the information centric. 3.2.2.2.1 Information Centric : The information centric model proposes messages’ de- livery considering the content semantics. The information centric model is also called as publish-subscribe model. Considering its operating principles, two entities interact each other, the publisher and the subscriber. Firstly, the publisher publishes the set of items. Then, the sub- scriber expresses its interests for items through subscriptions. When an item that is contained into the subscriber’s interests become available to the publisher, it is being sent to the subscriber. The use of the information centric model facilitates the vehicles of obtaining easily the required information, due to the fact that vehicles are usually interested for the information itself, ignor- ing its origin. The authors of [42] strengthen this opinion by describing two examples. In the first one, an autonomous vehicle travels in high speed on a highway. The vehicle must obtain contiguous information of surrounding vehicles that exist in short distance, in order to provide a safe course to its passengers. Using the information centric model, the vehicle regularly expresses its interests to the surrounding vehicles. Then, it periodically receives information about their position, speed and direction. Correspondingly, in the second example, the case of an accident ahead is considered. More specifically, the vehicle expresses the interest for retriev- ing information about the accident to the surrounding vehicles and RSUs. Vehicles or RSUs that become nearest to the accident provide the required information to the vehicle. Then, the vehicle’s driver is immediately alerted in order to be able to manipulate efficiently the situation (e.g. by selecting an alternative route to avoid the accident area and save time). Furthermore, in [43] the authors show that the information centric model enables the development of routing methods with enhanced scalability characteristics. More specifically, they demonstrate that this model provides many advantages to the routing functionality, due to the fact that it enables the network architecture manipulation in terms of “information connectivity” considering the context semantics, instead of considering the physical nodes connectivity. 3.2.2.2.2 Host Centric : The host centric model is also called as request-response or client- server model [234–236], where a client machine requests to receive items offered from a host (or server) machine. Specifically, when a client machine needs an item that belongs to this set, it sends a request to the host machine. The host machine receives the clients request, retrieves the required item and sends it to the client. The communication is performed using the IP protocol, while in large scale network architectures, thousand connections could exist. Furthermore, as described in [237], the use of the term “host centric” was started when the “information-centric”
  • 130. 104 Mobility Management term was introduced. Specifically, since the “information centric” has been proposed as an alternative message exchange model, the “host centric” term is used to represent the existing model for messages exchange in current network infrastructures, in order the fundamental difference between Information Centric Networking (ICN) [238] and Host Centric Networking (HCN) [239] to be clearly identified. Specifically, in order to explain the difference between the two models, the authors of [240] refer that in the ICN model the information itself obtains a specific identifier (or address), while in the traditional HCN model each host machine has an IP address assigned. Indicatively, regarding the host centric model operating principle, the authors of [241] have proposed the implementation of a Service Oriented Architecture (SOA) [242] for providing both information and entertainment services for vehicular clients. Specifically, each client interacts with the implemented web services to obtain access to real time information (e.g. about road traffic conditions) as well as to multimedia content. 3.2.2.2.3 Discussion on compatibility of each Mobility Management scheme with the available Message Exchange Models : The rapid evolve of content distribution services has led to host centric solutions such as overlay networks to address the increased needs for network scalability. However, performance bottlenecks persist resulting to the network inability of controlling the huge traffic load. In addition, the communication sessions could be interrupted when the IP address of a client device changes. Consequently, the host centric model cannot manipulate efficiently the increased needs for information. On the contrary, in information centric model, network nodes are considered as content segments, rather than as IP addressed endpoints. Thus, information centric model improves the network scalability and enhances the mobility support as well as the multihoming functionalities. Table 3.23 presents the applicability of each mobility management scheme to the available message exchange models. As it could be observed, since the message exchange is performed to Layer 3 (e.g. in IP-based host centric solutions), Layer 2 schemes (e.g. TFT [171], TFT-ACW [66], VHO-VCC [67], VHOMP [225] etc.) and Layer 7 schemes (QAH-SIP [223]) require the complementary use of a Layer 3 scheme (e.g. BFP-NEMO [200], IINH [182], VFMIPv6 [231] or ePFMIPv6 [202]) in order to support either the information centric or the host centric model. More specifically, only the Layer 3 schemes directly support the host centric model since it is based on the IP protocol of Layer 3. Also, in some cases the information centric model could not be directly supported, since some Layer 3 schemes support only IP based communication (e.g. RHVN [227], BFP-NEMO [200], IINH [182], IHVN [229] etc.), requiring an IP based architecture, while the information centric model does not use a such architecture. In such cases, the complementary use of an additional algorithm implemented to the upper layers is required for supporting the information centric model [243][244].
  • 131. 3.2 Mobility Management Schemes for 5G Wireless Networks 105 Table 3.23 The Applicability of each Scheme to the Available Message Exchange Models. Scheme Information Centric Host Centric VHOMP [225] * * SSHVeT [180] * * PHMVV [204] * * MAH-SCE [205] * * NASH [226] * * MAH-UDVE [186] * * RHVN [227] + S-VHO [207] * * BFP-NEMO [200] + IINH [182] + IHVN [229] + VANBA [230] + iMAG-IDH [221] + VFMIPv6 [231] + MIH-PGI [208] * CVHO [209] * * DPVHO [183] * * GVHO-TW [197] * * GVHO-PD [197] * * NA-GVHO [197] * * ePFMIPv6 [202] + AAMP [211] * * INS [187] * * HMM-KF [222] * * QAH-SIP [223] + * CAHP [184] * * HO-CALB [185] * * TOPSIS [188][189] * * TFT [171] * * TFT-ACW [66] * * VHO-VCC [67] * * GEO-MACHU [214] * SAW [188] * * MEW [188] * * GRA [192] * * DIA [188] * * WPM [195] * * QICA-NS [196] * * IAS-FNN [199] * * FLB-VHO [219] * * FMVHO [220] * * HCA [217] * * VAH [218] * * * Supported using third party algorithm for Layer 3 mobility management + Supported using third party algorithm implemented to the Upper Layers
  • 132. 106 Mobility Management 3.2.2.3 Mobility Management Algorithm Categories Several HO initiation and network selection approaches have been described considering network and user related parameters and can be classified into the following categories: 3.2.2.3.1 Context Aware : The decision is based on signal quality parameters. In this case, RSS, SNR or SINR are usually considered in order the signal quality of each network to be evaluated. Context aware HO initiation is performed when the signal quality of the current network drops below a threshold, while in case of context aware network selection the network with the best signal quality is selected. It should be noted that although several algorithms consider the signal quality to determine the set of network alternatives, in this category belong only the algorithms that make the final decision (e.g. the network ranking) considering such information. 3.2.2.3.2 Cost Function based : The cost of each network is estimated using a function. In the case of HO initiation, if the cost of the current network exceeds a maximum acceptable threshold, HO is initiated. Accordingly, in the case of a cost function network selection algorithm the cost of each candidate network is calculated and the network with the lowest cost is selected. The cost should refer to monetary cost, energy consumption aware cost, bandwidth etc. Each HO initiation or network selection algorithm could belong to more than one categories. 3.2.2.3.3 Multi Attribute Decision Making (MADM) : The decision is made considering multiple and conflicting network and user criteria. In the case of HO initiation, the current network is ranked, while HO is initiated when this rank drops below a predefined threshold. Also, in the case of a MADM network selection algorithm the entire network alternatives are ranked and the network with the higher rank is selected. 3.2.2.3.4 User Centric : The decision considers user preferences, which could be refer to parameters related to QoS, QoE, monetary costs and so on. In case of HO initiation the user satisfaction is evaluated considering his preferences. If the user satisfaction grade drops below a threshold the HO is initiated. Accordingly, in case of user centric network selection the utility of each network alternative is evaluated considering the user preferences and the network with the highest utility is selected. As it could be observed, this category can be considered as similar to the cost function based one. Specifically, the user centric schemes estimate the utility of each network alternative which is a positive parameter, while the cost based ones estimate
  • 133. 3.2 Mobility Management Schemes for 5G Wireless Networks 107 the cost of each alternative which is a negative parameter. Also, the schemes of this category are usually combined with MADM algorithms. 3.2.2.3.5 Fuzzy Logic based : They use fuzzy logic in order the decision uncertainty to be addressed, considering the related criteria to perform HO initiation or network selection. A fuzzy number is represented by a set of real values representing an uncertain quantity and a convex normalized continuous function which estimates the degree of membership for each value in the subset. Triangular, trapezoidal or pentagonal fuzzy numbers are frequently used to represent uncertain information. These algorithms are usually combined with MADM algorithms, while the HO initiation and the network selection are performed according to the MADM based networks ranking. 3.2.2.3.6 Neural Network based : A neural network is constructed determining a score for each candidate network. They are usually combined with MADM algorithms. Similar to the previous categories HO initiation and network selection are performed considering the score of each network. 3.2.2.3.7 MIH based : The algorithms of this category apply the operating principles of Media Indepentent Handover (MIH) []. In some cases, they are combined with algorithms of other categories, including context aware and MADM. 3.2.2.3.8 Probabilistic : They consider several probabilities to perform the mobility man- agement, including probabilities about user trajectory or velocity. Indicatively, considering the most probable user trajectory, the distribution of the signal strength of each network can be predicted. Thus, in case of HO initiation the most appropriate time to perform a HO can be estimated, or in case of network selection the most appropriate network for the user is selected, considering the aforementioned prediction. 3.2.2.3.9 Group based : They consider the fact that sometimes many users with similar trajectories and requirements need to perform a HO simultaneously. Thus, increased computa- tion requirements for performing the mobility management arise. In this case, the algorithms of this category group users with similar trajectories and perform the mobility management once for the entire group, decreasing the computational requirements of the entire process. 3.2.2.3.10 Auction based : The algorithms of this category perform the network selection using auctions. Each user makes an offer (e.g. according to his Service Level Agreement). Subsequently, users with higher offers obtain connectivity to better networks.
  • 134. 108 Mobility Management 3.2.2.3.11 Discussion on Mobility Management Algorithm Categories : As presented in table 3.24 the algorithm that each mobility management schemes combine more than one algorithm types. Specifically, most of the schemes belong to the MADM type (e.g. TFT [171], TFT-ACW [66], VHO-VCC [67], VHOMP [225] etc.), as well as to the context aware type (e.g. VHO-VCC [67], VHOMP [225], SSHVeT [180], PHMVV [204] etc.). It could be explained since the MADM algorithm could consider several (sometimes contradictory) parameters. On the other hand, context information (e.g. signal strength) could be considered as the most fundamental information for a mobility management scheme, since it is necessary for determining the candidate networks for a vehicle. Furthermore, many schemes belong to the cost function based type (e.g. VFMIPv6 [231], DPVHO [183], GVHO-TW [197], INS [187] etc.). In addition, although user preferences could be considered as a useful factor for performing the mobility management, only two of the discussed schemes belong to the user centric type (VHO-VCC [67] and QICA-NS [196]),while at the same time some schemes also belong to the fuzzy logic type (TFT [171], TFT-ACW [66], VHO-VCC [67] and IAS-FNN [199]).Also, there are schemes that belong to the MIH based (GEO-MACHU [214], IHVN [229] and MIH-PGI [208]), to the probabilistic (e.g. NASH [226], MAH-UDVE [186], iMAG- IDH [221], DPVHO [183] etc.) or to the group based (BFP-NEMO [200], GVHO-TW [197], GVHO-PD [197], NA-GVHO [197] and AAMP [211]) types. Finally, a few schemes belong to the neural network based (CVHO [209] and IAS-FNN [199]) or to the auction based (AAMP [211]) type.
  • 135. 3.2 Mobility Management Schemes for 5G Wireless Networks 109 Table 3.24 The Type of Algorithms used in each Scheme. Scheme Cost Function based User Centric MADM Fuzzy Logic based Neural Net- work based Context aware MIH based Probabilistic Group based Auction based VHOMP [225] SSHVeT [180] PHMVV [204] MAH-SCE [205] NASH [226] MAH-UDVE [186] RHVN [227] S-VHO [207] BFP-NEMO [200] IINH [182] IHVN [229] VANBA [230] iMAG-IDH [221] VFMIPv6 [231] MIH-PGI [208] CVHO [209] DPVHO [183] GVHO-TW [197] GVHO-PD [197] NA-GVHO [197] ePFMIPv6 [202] AAMP [211] INS [187] HMM-KF [222] QAH-SIP [223] CAHP [184] HO-CALB [185] TOPSIS [188][189] TFT [171] TFT-ACW [66] VHO-VCC [67] GEO-MACHU [214] SAW [188] MEW [188] GRA [192] DIA [188] WPM [195] QICA-NS [196] IAS-FNN [199] FLB-VHO [219] FMVHO [220] HCA [217] VAH [218]
  • 136. 110 Mobility Management 3.2.3 Mobility Management on 5G-VCC Systems In this section, the 5G-VCC architectures as well as the communication models that each mobility management scheme supports are mentioned. 3.2.3.1 Mobility Management schemes for supporting 5G-VCC Architectures The applicability and the performance of each mobility management scheme is affected of factors related to the implemented 5G-VCC architecture. Table 3.25 presents the factors that each 5G-VCC architecture satisfies, while table 3.26 presents the applicability of the discussed mobility management schemes to each 5G-VCC architecture. The applicability of each scheme depends on the existence of a backbone network infras- tructure. Specifically, the VC architecture as already mentioned has no backbone network infrastructure. It determines a complete ad-hoc topology, which consists of vehicles construct- ing the Cloud. Thus, only the VANBA [230] and the HCA [217] schemes can be applied to VC architectures, since in these cases the mobility management concerns the connectivity between the participating vehicles instead of the interaction between vehicles and a network infrastructure. This fact reinforces the need for further research since in some cases the VC architectures could support disaster management services [245] where the availability of access network infrastructures could be decreased. On the other hand, in the VuC, VuF, SDN-V and HVA architectures, a communication infrastructure providing access to cloud/fog resources, is implemented. Hence, the entire schemes can be applied to VuC, VuF, SDN-V and HVA architectures, since they have been designed to manipulate the user mobility in relation with an existing network infrastructure. Furthermore, architectural factors such as the network control type applied (centralized or decentralized) and which architectural components are virtualized, affect the performance of each mobility management scheme. Regarding the network control type applied, the discussed mobility management schemes could be adapted to perform either centralized or distributed control. Centralized control is optional in VC, SDN-V and HVA architectures. Such a configuration uses a central entity performing the mobility management, such as a single SDN controller or a central vehicle with increased responsibilities. Accordingly, decentralized control is performed when the network control process is distributed to more than one control entities. Decentralized control can be applied to the entire 5G-VCC architectures. Furthermore, both centralized and decentralized control can be combined. For instance, in some VC architectures clustering of vehicles is performed, where a vehicle is elected as the Cluster Head (CH) [246] implementing the
  • 137. 3.2 Mobility Management Schemes for 5G Wireless Networks 111 functionalities of a single SDN controller. In this case, centralized control is applied for intra- cluster communication, while distributed control is applied for inter-cluster communication. Finally, the considered mobility management schemes can be deployed to several virtualized resources of a 5G-VCC architecture. Specifically, in a VC architecture virtualization of resources is performed by the end-user devices. Also, in a VuC architecture virtualization is applied in the Cloud, while in a VuF architecture virtualization is applied in the Fog. Network as a Service (NaaS) [247–249] enables the configuration of network resources in either the Cloud or the Fog. Furthermore, in HVA architectures, virtualization is simultaneously performed in two or more architectural components. Indicatively, in the architecture discussed in [73] virtualization is applied to both Cloud and Fog nodes. Also, a fully virtualized HVA architecture [31][75], optimizes the performance of mobility management schemes, since it provides increased system reliability, resource utilization and performance isolation. Table 3.25 The Factors considered in each Architecture. Architecture Virtualization Centralization Infrastructure requirements Vehicular Cloud (VC) Yes Optional No Vehicles using Cloud (VuC) Yes No Yes Vehicles using Fog (VuF) Yes No Yes Software Defined Vehicu- lar Architectures (SDN-V) Yes Optional Yes Hybrid Vehicular Architec- tures (HVA) Yes Optional Yes
  • 138. 112 Mobility Management Table 3.26 The Applicability of each Scheme to the Available 5G-VCC Architectures. Scheme Vehicular Cloud (VC) Vehicles using Cloud (VuC) Vehicles using Fog (VuF) Software Defined Vehicular Architectures (SDN-V) Hybrid Vehicular Architectures (HVA) VHOMP [225] SSHVeT [180] PHMVV [204] MAH-SCE [205] NASH [226] MAH-UDVE [186] RHVN [227] S-VHO [207] BFP-NEMO [200] IINH [182] IHVN [229] VANBA [230] iMAG-IDH [221] VFMIPv6 [231] MIH-PGI [208] CVHO [209] DPVHO [183] GVHO-TW [197] GVHO-PD [197] NA-GVHO [197] ePFMIPv6 [202] AAMP [211] INS [187] HMM-KF [222] QAH-SIP [223] CAHP [184] HO-CALB [185] TOPSIS [188][189] TFT [171] TFT-ACW [66] VHO-VCC [67] GEO-MACHU [214] SAW [188] MEW [188] GRA [192] DIA [188] WPM [195] QICA-NS [196] IAS-FNN [199] FLB-VHO [219] FMVHO [220] HCA [217] VAH [218]
  • 139. 3.2 Mobility Management Schemes for 5G Wireless Networks 113 3.2.3.2 Mobility Management schemes for supporting 5G-VCC Communication Mod- els Each communication model could be applied to specific 5G-VCC architectures (Table 3.27). In general, V2V and V2P models can be applied in each 5G-VCC architecture, since the entire topologies can include both vehicular and pedestrian users. However, the V2I communication model requires a network infrastructure. Consequently, it cannot be applied to a VC architecture which is completely ad-hoc. On the other hand, V2I could be used in VuC and VuF topologies, since they provide access to network infrastructure through RSUs. Also, HVC could be applied to the entire topologies, since it combines multiple communication models. Table 3.27 The Applicability of each Communication Model to each Architecture. PPPPPPPPPP Communication Model 5G-VCC Architecture Vehicular Cloud (VC) Vehicles using Cloud (VuC) Vehicles using Fog (VuF) Software Defined Vehicular Architectures (SDN-V) Hybrid Vehicular Architectures (HVA) Vehicle to Vehicle (V2V) Vehicle to Infrastructure (V2I) Vehicle to Pedestrian (V2P) Hybrid Vehicular Communication (HVC) Table 3.28 presents the applicability of each mobility management scheme to the available communication models. As could be observed the entire mobility management schemes support V2I communications, since these schemes could be applied to 5G-VCC topologies where an access network infrastructure exists. However, only the HCA [217] scheme supports V2V and V2P communications since it could also be applied to VC architectures where no access network infrastructure exists. Thus, the design of mobility management algorithms for supporting V2V and V2P communications could be considered as a scientific field for further future research, since these communications are necessary for supporting several vehicular services in smart cities environments [95][250].
  • 140. 114 Mobility Management Table 3.28 The Applicability of each Scheme to each Communication Model. Scheme Vehicle to Vehicle (V2V) Vehicle to Infrastructure (V2I) Vehicle to Pedestrian (V2P) Hybrid Vehicular Communication (HVC) VHOMP [225] SSHVeT [180] PHMVV [204] MAH-SCE [205] NASH [226] MAH-UDVE [186] RHVN [227] S-VHO [207] BFP-NEMO [200] IINH [182] IHVN [229] VANBA [230] iMAG-IDH [221] VFMIPv6 [231] MIH-PGI [208] CVHO [209] DPVHO [183] GVHO-TW [197] GVHO-PD [197] NA-GVHO [197] ePFMIPv6 [202] AAMP [211] INS [187] HMM-KF [222] QAH-SIP [223] CAHP [184] HO-CALB [185] TOPSIS [188][189] TFT [171] TFT-ACW [66] VHO-VCC [67] GEO-MACHU [214] SAW [188] MEW [188] GRA [192] DIA [188] WPM [195] QICA-NS [196] IAS-FNN [199] FLB-VHO [219] FMVHO [220] HCA [217] VAH [218]
  • 141. Chapter 4 A Proposed Mobility Management Approach for 5G-VCC Systems 4.1 Mobility Management Requirements This section describes the requirements that must be satisfied by a mobility management scheme. In a 5G-VCC system, vehicles move in several trajectories, while at the same time have different velocities. Also, each vehicle could serve multiple passengers with different services. Thus several requirements need to be addressed by HO schemes. • Seamless mobility During the vehicles movement, their ability to remain connected while roaming across different access networks must be ensured, in order to avoid interruption of user’s services. • Minimization of handover latency Mobility management schemes should offer lightweight solutions to minimize the delay of the decision process as well as the signaling delays during the handover execution. Additionally, in urban environments multiple vehicles have similar trajectories requiring similar mobility management decisions and signaling- exchanges to be performed. For this reason, modern mobility management schemes cluster the vehicles with similar mobility and service requirements so that similar tasks are executed once for the entire cluster than for each vehicle. • Minimization of handovers count Even in cases where the handover latency has been reduced enough, more handovers will always occur to higher total latencies and network signaling overhead. In the modern 5G network access environment, where multiple cells coexist in the same place, a vehicle could perform a large number of handovers reducing the perceived Quality of Service (QoS) of vehicular services.
  • 142. 116 A Proposed Mobility Management Approach for 5G-VCC Systems • Support of heterogeneous network access environments Mobility management schemes for 5G networks should support the coexistence of multiple network access technologies. Thus, the utilization of the available spectrum will be maximized, since each technology operates to specific frequency bands, determined by its technical specifications. • Optimal network selection for satisfying QoS constraints of vehicular services Connec- tivity to the most appropriate network supporting the constraints of vehicular services must be ensured. Accordingly, the available network alternatives must be continuously evaluated considering vehicular services requirements, as well as changes in the radio environment and operators policies. 4.2 System Architecture The proposed HO management scheme uses some of the methods described in the previous section. Its design has been optimized to be applied in 5G network architectures where both Fog and Cloud infrastructures are available. The HO process includes the HO Initiation, the Velocity Monitoring, the Network Selection and the HO Execution subprocesses as presented in Figure 4.1. Initially, the HO Initiation is executed in the Fog considering the Quality of Service (QoS) and the Signal to Noise plus Interference Ratio (SINR) that the vehicle perceives from its current network to evaluate the necessity to perform a handover. Both the Fog and the Cloud cooperate to accomplish the Velocity Monitoring process. Finally, the Cloud performs the Network Selection among the available networks depending on the vehicle’s velocity. The vehicle is informed through the Fog infrastructure, to make a handover to the selected network. The following subsections describe in depth each one of the aforementioned subprocesses. 4.2.1 VHO Initiation During the HO initiation process the Su,i indicator is defined, determining the satisfaction grade of user u from his current network i. More specifically, the Su,i value is estimated considering as input the SINRu,i and the Qu,i parameters. The SINRu,i represents the Signal to Noice plus Interference, while the Qu,i represents the quality of the users’ services offered from the current network. Qu,i is calculated using formula 4.1, where thu,i,k, du,i,k, ju,i,k and plu,i,k represent the throughput, the delay, the jitter and the packet loss ratio respectively, obtained by user u for service k. Additionally, wth,k, wd,k ,wj,k and wp,kl represent the weights of the aforementioned parameters estimated using the PF-ANP method, while N represents the
  • 143. 4.2 System Architecture 117 number of the parameters considered and K the number of the available services. Qu,i = K ∑ k=1 (wth,k ·thu,i,k +wd,k · 1 du,i,k +wj,k · 1 ju,i,k +wpl,k · 1 plu,i,k )/N /K (4.1) The user’s equipment continuously monitors its perceived SINRu,i and Qu,i values. When either SINRu,i or Qu,i becomes less than a predefined threshold, the user equipment sends the obtained values to the Fog infrastructure. Subsequently, the Fog infrastructure uses the Mamdani satisfaction chart presented in Figure 4.2, in order to determine the Su,i satisfaction grade. If the satisfaction grade is less than a predefined Sth threshold value, then the network selection process is executed. The satisfaction indicators chart presents the Su,i values obtained for each possible SINRu,i and Qu,i combination. Indicatively, when the SINRu,i and Qu,i values are too low, the produced Su,i value is too low as well. On the contrary, when the SINRu,i and Qu,i values are close to 1, the produced Su,i value is also high, indicating that the user is fully satisfied. Furthermore, when only one of the SINRu,i or the Qu,i values is close to 0, the user satisfaction is in quite low levels. 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 at the Fog is minimal. Also, the method does not impose any significant overhead at the user equipment due to the monitoring of the SINRu,i and Qu,i parameters. 4.2.1.1 Evaluation of the Satisfaction Indicators The Mamdani satisfaction chart is evaluated once during the instantiation of the Fog services. Each satisfaction indicator Su,i of Figure 4.2 is obtained using the MPFIS method, considering the SINRu,i and the Qu,i as input parameters. Both SINRu,i and Qu,i are normalized in order to have values within the range [0, 1]. Also, the MFSINR, MFQ, MFS membership functions (MF) are defined using the EUM method, indicating the linguistic terms and the corresponding Interval Valued Pentagonal Fuzzy Numbers (I-VPFN) for the fuzzy representation of the SINRu,i, Qu,i and Su,i respectively. Thus, for each crisp value, two membership degrees are determined in the corresponding MF, one for the upper pentagon and one for the lower pentagon. Table 4.1 represents the linguistic terms and the corresponding interval-valued pentagonal fuzzy numbers of MFSINR, MFQ and MFS membership functions, which are equally distributed inside the domain [Umin,Umax] = [0, 1] as illustrated in Figures 4.3, 4.4 and 4.5, respectively. Table 4.2 shows the considered fuzzy rule base.
  • 144. 118 A Proposed Mobility Management Approach for 5G-VCC Systems Table 4.1 Linguistic Terms and the corresponding Interval-Valued Pentagonal Fuzzy Numbers used for MFSINR, MFQ and MFS. MFSINR membership functions. Linguistic term Interval-valued trapezoidal fuzzy number Absolute Bad (AB) [(0.0, 0.0, 0.0, 0.062, 0.093, 0.8, 0.6, 0.6),(0.0, 0.0, 0.0, 0.083, 0.125, 1.0, 0.8, 0.8)] Too Bad (TB) [(0.072, 0.104, 0.166, 0.229, 0.26, 0.8, 0.6, 0.6),(0.041, 0.083, 0.166, 0.25, 0.291, 1.0, 0.8, 0.8)] Bad (B) [(0.239, 0.27, 0.333, 0.395, 0.427, 0.8, 0.6, 0.6),(0.208, 0.25, 0.333, 0.416, 0.458, 1.0, 0.8, 0.8)] Enough (EN) [(0.406, 0.437, 0.5, 0.562, 0.593, 0.8, 0.6, 0.6),(0.375, 0.416, 0.5, 0.583, 0.625, 1.0, 0.8, 0.8)] More than Enough (ME) [(0.572, 0.604, 0.667, 0.729, 0.76, 0.8, 0.6, 0.6),(0.541, 0.583, 0.667, 0.75, 0.791, 1.0, 0.8, 0.8)] Almost Excellent (AE) [(0.739, 0.77, 0.833, 0.895, 0.927, 0.8, 0.6, 0.6),(0.708, 0.75, 0.833, 0.916, 0.958, 1.0, 0.8, 0.8)] Excellent (EX) [(0.906, 0.937, 1.0, 1.0, 1.0, 0.8, 0.6, 0.6),(0.875, 0.916, 1.0, 1.0, 1.0, 1.0, 0.8, 0.8)] MFQ membership functions. Linguistic term Interval-valued trapezoidal fuzzy number Absolutely Poor (AP) [(0.0, 0.0, 0.0, 0.046, 0.07, 0.8, 0.6, 0.6),(0.0, 0.0, 0.0, 0.062, 0.093, 1.0, 0.8, 0.8)] Very Poor (VP) [(0.054, 0.078, 0.125, 0.171, 0.195, 0.8, 0.6, 0.6),(0.031, 0.062, 0.125, 0.187, 0.218, 1.0, 0.8, 0.8)] Poor (P) [(0.179, 0.203, 0.25, 0.296, 0.32, 0.8, 0.6, 0.6),(0.156, 0.187, 0.25, 0.312, 0.343, 1.0, 0.8, 0.8)] Medium Poor (MP) [(0.304, 0.328, 0.375, 0.421, 0.445, 0.8, 0.6, 0.6),(0.281, 0.312, 0.375, 0.437, 0.468, 1.0, 0.8, 0.8)] Medium (M) [(0.429, 0.453, 0.5, 0.546, 0.57, 0.8, 0.6, 0.6),(0.406, 0.437, 0.5, 0.562, 0.593, 1.0, 0.8, 0.8)] Medium Good (MG) [(0.554, 0.578, 0.625, 0.671, 0.695, 0.8, 0.6, 0.6),(0.531, 0.562, 0.625, 0.687, 0.718, 1.0, 0.8, 0.8)] Good (G) [(0.679, 0.703, 0.75, 0.796, 0.82, 0.8, 0.6, 0.6),(0.656, 0.687, 0.75, 0.812, 0.843, 1.0, 0.8, 0.8)] Very Good (VG) [(0.804, 0.828, 0.875, 0.921, 0.945, 0.8, 0.6, 0.6),(0.781, 0.812, 0.875,0.937, 0.968, 1.0, 0.8, 0.8)] Absolutely Good (AG) [(0.929, 0.953, 1.0, 1.0, 1.0, 0.8, 0.6, 0.6),(0.906, 0.937, 1.0, 1.0, 1.0, 1.0, 0.8, 0.8)] MFS membership functions. Linguistic term Interval-valued trapezoidal fuzzy number Absolute Unsatisfactory (AU) [(0.0, 0.0, 0.0, 0.034, 0.051, 0.8, 0.6, 0.6),(0.0, 0.0, 0.0, 0.045, 0.068, 1.0, 0.8, 0.8)] Very Unsatisfactory (VU) [(0.039, 0.056, 0.09, 0.125, 0.142, 0.8, 0.6, 0.6),(0.022, 0.045, 0.09, 0.136, 0.159, 1.0, 0.8, 0.8)] Unsatisfactory (U) [(0.13, 0.147, 0.181, 0.215, 0.232, 0.8, 0.6, 0.6),(0.113, 0.136, 0.181, 0.227, 0.25, 1.0, 0.8, 0.8)] Slightly Unsatisfactory (SU) [(0.221, 0.238, 0.272, 0.306, 0.323, 0.8, 0.6, 0.6),(0.204, 0.227, 0.272, 0.318, 0.34, 1.0, 0.8, 0.8)] Less than Acceptable (LA) [(0.312, 0.329, 0.363, 0.397, 0.414, 0.8, 0.6, 0.6),(0.295, 0.318, 0.363, 0.409, 0.431, 1.0, 0.8, 0.8)] Slightly Acceptable (SA) [(0.403, 0.42, 0.454, 0.488, 0.505, 0.8, 0.6, 0.6),(0.386, 0.409, 0.454, 0.5, 0.522, 1.0, 0.8, 0.8)] Acceptable (A) [(0.494, 0.511, 0.545, 0.579, 0.596, 0.8, 0.6, 0.6),(0.477, 0.5, 0.545, 0.59, 0.613, 1.0, 0.8, 0.8)] More than Acceptable (MA) [(0.585, 0.602, 0.636, 0.67, 0.687, 0.8, 0.6, 0.6),(0.568, 0.59, 0.636, 0.681, 0.704, 1.0, 0.8, 0.8)] Slightly Satisfactory (SS) [(0.676, 0.693, 0.727, 0.761, 0.778, 0.8, 0.6, 0.6),(0.659, 0.681, 0.727, 0.772, 0.795, 1.0, 0.8, 0.8)] Satisfactory (S) [(0.767, 0.784, 0.818, 0.852, 0.869, 0.8, 0.6, 0.6),(0.75, 0.772, 0.818, 0.863, 0.886, 1.0, 0.8, 0.8)] Very Satisfactory (VS) [(0.857, 0.875, 0.909, 0.943, 0.96, 0.8, 0.6, 0.6),(0.84, 0.863, 0.909, 0.954, 0.977, 1.0, 0.8, 0.8)] Absolute Satisfactory (AS) [(0.948, 0.965, 1.0, 1.0, 1.0, 0.8, 0.6, 0.6),(0.931, 0.954, 1.0, 1.0, 1.0, 1.0, 0.8, 0.8)] 4.2.2 Velocity Monitoring During the entire vehicle movement, its velocity is monitored by the Fog-Cloud infrastructure. An enhanced version of the Mobility State Estimation (MSE) model defined in 3GPP LTE Release 11 [251] is used to estimate the vehicles’ velocity. The MSE considers the number of handovers or reselections (NCRu) performed by a vehicle during a sliding time window (TCRmax). The vehicle is categorized into one of three velocity states, namely the Normal, the Medium and the High, considering the NCRMedium and NCRHigh thresholds with NCRMedium < NCRHigh . The concept of this method is that the more handovers the vehicle performs during the TCRmax period, the faster the vehicle is moving. In heterogeneous network environments that include both Macrocells and Femtocells, the default TCRmax value is 120 seconds, while the default NCRMedium and NCRHigh values are equal to 10 and 16 handovers, respectively [251]. Furthermore, the estimated residence time tresidence u,i of vehicle u in each available cell i is estimated using
  • 145. 4.2 System Architecture 119 formula 4.2 defined in [252], where rf is the radius of femtocell i and vu is the velocity of the vehicle u. tresidence u,i = π ·ri 2·vu (4.2) Then, the vehicle velocity is obtained by formula 4.3 defined in [253]. vu = π ·NCRu 4·TCRmax · √ λu (4.3) The λu parameter, obtained by the SDN controller, denotes the cell’s density in the location of vehicle u. 4.2.3 Network Selection The mobility state of each vehicle is considered in order to select the set A = {A1,A2,...,An} of possible network alternatives based on the SINR perceived by each network. If the vehicle mobility state is Normal then the vehicle considers all the available networks as alternatives, including both Macrocells and Femtocells. On the contrary, if vehicle mobility state is Medium then the vehicle skips some Femtocells along its trajectory. In particular, the Femtocell i is considered as alternative if tresidence u,i tresidence u,mean , where tresidence u,mean is the average residence time of vehicle u considering all the available Femtocells in its current location. Finally, if the vehicle mobility state is High then only Macrocells are considered as alternatives. Thereafter the network selection is performed using the Pentagonal interval-valued Fuzzy TOPSIS (PFT), considering both QoS aware (throughput, delay, jitter and packet loss) and operator policies (service reliability, security and price) criteria. Since the list of network alternatives is constructed considering the vehicle’s velocity and, then, the network selection is performed using QoS and policy related parameters, the ping pong effect is eliminated. 4.2.4 Handover Execution During the handover execution, the vehicle is connected to the selected network. After each successfull handover of a vehicle, the number of handovers or reselections NCRu increases, in order the aforementioned handover to be considered for the estimation of the vehicle velocity. 4.2.5 Computational Complexity of the Proposed Approach Regarding the computational complexity of the proposed approach the HO initiation subprocess requires a constant time to complete its tasks by performing simple checks against predefined thresholds, resulting in O(1). Also, the network selection phase introduces an O(n2) complexity, due to the weighting and normalization of the n×m decision matrices. Similar complexities
  • 146. 120 A Proposed Mobility Management Approach for 5G-VCC Systems are introduced by other handover algorithms proposed in the research literature. The novelty in our approach is that most of the computational complexity is performed at the Cloud/Fog infrastructure. 4.3 Simulation Setup In our experiments, the Software Defined Vehicular Cloud topology presented in Figure 4.6 is considered. A mobility trace indicating the map of the city of Piraeus along with road traffic data has been created using the Open Street Map (OSM) software [176]. Then, the mobility trace has been used as input in the Simulator of Urban Mobility (SUMO) [177] allowing the production of a realistic mobility pattern for the simulated vehicles including 39807 vehicles in total, moving inside the Piraeus city in a 24 hours period. The average arrival rate of the vehicles into the map is equal to 0,460729167 vehicles per second, while their average departure rate is equal to 0,46 vehicles per second. Furthermore, the network topology is being built upon the map, using the Network Simulator 3 (NS3) [178]. It includes a Fog infrastructure and a Cloud infrastructure. The Fog infrastructure consists of 18 LTE Macrocell e-Node Bs (eNBs), 39 LTE Femtocell eNBs, 16 WiMAX Macrocell Base Stations (BSs), 26 WiMAX Femtocell BSs and 22 802.11p WAVE RSUs, equipped with additional computational and storage resources. The access networks have been located on the map, according to the Hellenic Telecommunications and Post Commission (EETT) [254] data about BSs’ positions in the city of Piraeus. The positions and the spectrum of the BSs are presented in A1 to A3 tables (Appendix A), for the LTE, WiMAX and WAVE technologies, respectively. The SDN controller has a global view of the entire network environment. The Cloud infrastructure includes a set of Virtual Machines (VMs) providing services such as Navigation Assistance (NAV), Voice over IP (VoIP), Conversational Video (CV), Buffered Streaming (BS) and Web Browsing (WB). Furthermore, a Software Defined Network (SDN) controller provides centralized control for the entire system. Each access network supports at least one of the aforementioned Cloud services, while four Service Level Agreements (SLAs) are defined. SLA1 has the higher service priority and SLA 4 has the lower service priority. SLA1 supports all the service types and provides the best values for QoS as well as policy decision criteria. SLA2 supports a smaller number of service types, by not providing support for the VoIP and NAV services. Additionally, it provides slightly worse decision criteria values than those offered by the SLA1. SLA3 supports only the BS and the WB services and satisfactory QoS characteristics and policies. Finally, SLA4 supports only the WB service while it provides acceptable decision criteria values.
  • 147. 4.3 Simulation Setup 121 Network specifications are expressed directly using linguistic terms (Appendix B). In particular, the crisp values of the network QoS characteristics are converted into linguistic terms which correspond to specific ranges of values per service type. Table 4.3 illustrates the mapping between ranges of network QoS characteristics values and the respective linguistic terms for the VoIP service. Table 4.4 summarizes the simulation parameters. 4.3.1 Study of a Simulation Snapshot In this subsection, a snapshot of the simulation at time equal to 3600 seconds is considered. Specifically, the case where 10 of the vehicles are monitored is studied, while each vehicle needs to connect to a network which satisfies the requirements of its services and at the same time complies with its respective SLA agreements. Table 4.5 presents the available networks in the location of each vehicle. 4.3.1.1 VHO Initiation During the HO initiation process, the user satisfaction Su,i is obtained using the MPFIS Satisfaction Chart, considering the estimated Qu,i and SINRu,i values. It should be noted that the services weights used for the Qu,i estimation are calculated using the PF-ANP method. The criteria used include throughput, delay, jitter and packet loss. Figure 4.7 depicts the estimated HO initiation weights for each service. Furthermore, the Sth,SLA thresholds given in Table 4.6 are estimated considering the minimum acceptable QSLA and SINRSLA values per SLA. If the Su,i becomes less than the respective Sth,SLA threshold then the vehicle should perform a handover to a new access network. The HO initiation results for each vehicle are presented in Table 4.7. As it can be observed, vehicle 8 will remain to its current network i, while the rest of the vehicles will procceed to handover. 4.3.1.2 Velocity Monitoring For each one of the monitored vehicles, Table 4.8 presents its SLA, the services used, its geographical position and its estimated velocity. 4.3.1.3 Network Selection During the network selection process the PF-ANP method is applied in order to estimate the weights of the network selection criteria per service type and SLA. Figure 4.8 depicts the PF-ANP network model. The criteria are classified into two groups, namely the Network QoS and the Network Policy characteristics. The Network QoS characteristics group contains
  • 148. 122 A Proposed Mobility Management Approach for 5G-VCC Systems network performance related criteria including throughput, delay, jitter and packet loss. The Network Policy characteristics group contains operator defined rules such as price, security and service reliability. Pairwise comparison decision matrices are created based on relations among the eight selection criteria depicted in Figure 4.9. Then, these pairwise comparison decision matrices are used to evaluate the priority vectors of the criteria and to form the supermatrix per service type and SLA. Subsequently, the weighted supermatrices and, finally, the limited supermatrices are obtained. Indicatively, for the SLA1 NAV service, the initial, the weighted and the limited supermatrices are presented in Tables 4.9, 4.10 and 4.11 respectively. The criteria weights per service and SLA obtained by the limit supermatrices are presented in Figures 4.10 - 4.13. As illustrated, the weights are proportional to the constraints of each service as well as to the agreements of each SLA. In particular, the weight of the price criterion is low for SLA1, in which the service reliability and the network QoS characteristics are considered as the most important factors. In SLA2 the price criterion is more important than in SLA1, thus the respective weight is greater than that of SLA1. Consequently, the weights of the service reliability and QoS characteristics criteria in SLA2 are lower compared to the relative weights of SLA1. In SLA3 the weights of price and service reliability criteria are balanced as they are almost of equivalent importance. Finally, in SLA4 the price is the most important criterion resulting in a high estimated weight value. The PFT algorithm selects the best network for each vehicle considering the vehicle service requirements. Figure 4.14 compares the results of the proposed scheme with the ones obtained using VAH [218], FAT [255], FAS [255], FAM [255] and FAE [172]. In this Figure, for each vehicle the PFT ranking of the current network as well as of the target network connection estimated by each of the six schemes are presented. From the obtained results it is clear that the suggested algorithm outperforms the existing schemes since it selects as target networks for vehicles the ones with the best ranks. Also, in special cases where the velocity of the vehicles is high (eg. for vehicle 7) the proposed scheme considers only the wide coverage candidate networks as alternatives avoiding the handovers to femtocell networks. Additionally, for a further evaluation of the proposed scheme, the user’s satisfaction grade Su,i after the HO completion is considered. Figure 4.15 presents the estimated Su,i after the execution of each HO scheme. As it can be observed, the results are similar to the aforementioned PFT rankings, while the proposed approach achieves higher satisfaction grades than the existing schemes.
  • 149. 4.3 Simulation Setup 123 4.3.2 24 Hours Simulation Results For the entire 24-hour simulation, Tables C1, C2 and C3 (Appendix C) present the number of vehicles that start their movement from each LTE, WiMAX and WAVE network, respectively, as well as their corresponding velocities. Table C4 presents the vehicle count per service and SLA. The entire service combinations per SLA are considered, in order all the possible use cases to be studied during the simulation. The number of possible service combinations (Sc) is estimated using formula 4.4 [256] where Sn represents the number of the considered services. In this experiment, 5 services are considered, namely the Navigation Assistance (NAV), Voice over IP (VoIP), Conversational Video (CV), Buffered Streaming (BS) and Web Browsing (WB) and, thus, Sc is equal to 31. It should be noted that SLA 1 supports all the services, while SLA 2 supports only the CV, BS and WB services. Also, SLA 3 supports only the BS and WB services, while SLA 4 supports only the WB service. Sc = 2Sn −1 (4.4) The average PFT rankings of each HO scheme are presented in Figure 4.16, where all the 39807 vehicles are considered. As it can be observed, the proposed scheme accomplishes higher ranking than the other schemes. On the contrary, the VAH scheme accomplishes the lower ranking, due to the fact that it does not consider neither QoS related parameters, nor operator policy related parameters. The other schemes accomplish intermediate results. The FAT results are slightly better than the ones achieved from the rest of the schemes. Also, Figure 4.17 presents the average satisfaction grade Su,i estimated for each HO scheme. The proposed approach accomplishes the highest average values, compared to the rest of the HO schemes. It should be noted that the number of HOs performed should be considered as a critical parameter for the evaluation of the proposed HO scheme efficiency, since a smaller number of HOs implies a lower network signaling overhead in both the user and the operator sides. Figure 4.18 presents the total number of HOs performed in each scheme, during the entire 24 hours simulation. As it is shown, the proposed scheme outperforms the other schemes, since it performs a smaller number of HOs. Also, the VAH scheme accomplishes an acceptable number of HOs, since it also considers the vehicle velocity for the handover process. However, it does not avoid useless HOs to femtocells providing worse results than the proposed scheme. The rest of the schemes accomplish similar HO numbers, since they are based on the perceived RSS per user for the HO initiation process.
  • 150. 124 A Proposed Mobility Management Approach for 5G-VCC Systems MMaaS Vehicle uVehicle u Cloud SDN Controller Cloud SDN Controller Execute PFT for Alternatives_Set_A(Macrocells) Obtain offered characteristics of Alternatives_Set_A(Macrocells) If Su,i < Sth: Result=Selected_Network Fog Current Network i Fog Current Network i If velocity = High: Obtain Su,i (Qu,i, SINRu,I) Result=Handover_not_required Else: ObtainVelocityu(NCRu, TCRmax, λu) Execute PFT for Alternatives_Set_A (Macrocells, Femtocells_subset) Obtain offered characteristics of Alternatives_Set_A (Macrocells, Femtocells_subset) Result=Selected_Network If velocity = Medium: Execute PFT for Alternatives_Set_A (Macrocells, Femtocells) Obtain offered characteristics of Alternatives_Set_A (Macrocells, Femtocells) Result=Selected_Network If velocity = Low: Obtain Femtocells_subset considering tresidence If Result=Selected_Network: D. VHO execution C. Network selection A. VHO initiation B.VelocityMonitoring Fog Selected_Network Fog Selected_Network Monitoring of Qu,i and SINRu,i When Qu,i < Qth or SINRu,i < SINRth: Figure 4.1 The Proposed Methodology.
  • 151. 4.3 Simulation Setup 125 Figure 4.2 The S Values Range as obtained using the FIS. Figure 4.3 MFSINR Membership Functions Balance. Figure 4.4 MFQ Membership Functions Balance. Figure 4.5 MFS Membership Functions Balance.
  • 152. 126 A Proposed Mobility Management Approach for 5G-VCC Systems Table 4.2 The Fuzzy Rule (or Knowledge) Base. Rule MFSINR Operator MFQ MFS 1 AB or AP AU 2 TB and VP AU 3 B and VP VU 4 EN and VP U 5 ME and VP U 6 AE and VP SU 7 EX and VP SU 8 TB and P AU 9 B and P VU 10 EN and P U 11 ME and P U 12 AE and P SU 13 EX and P SU 14 TB and MP AU 15 B and MP VU 16 EN and MP SU 17 ME and MP SU 18 AE and MP LA 19 EX and MP SA 20 TB and M AU 21 B and M VU 22 EN and M LA 23 ME and M SA 24 AE and M A 25 EX and M MA 26 TB and MG VU 27 B and MG U 28 EN and MG SA 29 ME and MG A 30 AE and MG MA 31 EX and MG SS 32 TB and G VU 33 B and G U 34 EN and G A 35 ME and G MA 36 AE and G SS 37 EX and G S 38 TB and VG U 39 B and VG SU 40 EN and VG MA 41 ME and VG SS 42 AE and VG S 43 EX and VG VS 44 TB and AG U 45 B and AG LA 46 EN and AG S 47 ME and AG VS 48 AE and AG AS 49 EX and AG AS
  • 153. 4.3 Simulation Setup 127 WAVE RSU WiMAX Femtocell WiMAX Macrocell LTE Femtocell LTE Macrocell Vehicle 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 a b c d e f g h ui vj wk l m n o p tq r s x ya b c d e f g h ui vj wk l m n o p tq r s x y a b c d e f g h ui vj wk l m n o p tq r s x ya b c d e f g h ui vj wk l m n o p tq r s x y Cloud VM Services VM Services VM Services VM Services VM Services VM Services VM Services VM Services ... ... ... ... ... ... ... ... Fog SDN controller MMaaS SDN controller MMaaS Fog WiMAX MacrocellsWiMAX Macrocells LTE MacrocellsLTE Macrocells LTE FemtocellsLTE Femtocells WiMAX FemtocellsWiMAX Femtocells WAVE RSUsWAVE RSUsWAVE RSUs Figure 4.6 The Simulated Topology for the Evaluation of the proposed Mobility Management Scheme. Table 4.3 Relation of the Network QoS Characteristics and Linguistic Terms for VoIP. Linguistic term Throughput range (Kbps) Delay range (ms) Jitter range (ms) Packet loss range AP ≤ 164 ≥ 116 ≥ 65 ≥ 0.4 VP 165 - 174 111-115 55 - 64 ≥ 0.2 - 0.4 P 175 - 184 106-110 45 - 54 >10−1 - <0.2 MP 185 - 194 100 - 105 40 - 44 10−1 M 195 - 204 95 - 99 35 - 49 10−2 MG 205 - 214 86 - 94 30 - 34 10−3 G 215 - 224 66 - 85 25 - 29 10−4 VG 225 - 239 41 - 65 20 - 24 10−5 AG ≥ 240 ≤ 40 ≤ 20 ≤ 10−6 0 0,1 0,2 0,3 0,4 0,5 Navigation Assistance VoIP Conversational Video Buffered Streaming Web Weight Network Initiation weights Throughput Delay Jitter Packet loss Figure 4.7 Criteria Weights per Service for the HO Initiation.
  • 154. 128 A Proposed Mobility Management Approach for 5G-VCC Systems Table 4.4 The Simulation Parameters for the Evaluation of the proposed Mobility Management Scheme. Parameter Value Simulation duration 86400 seconds (24 hours) Networks count LTE Macrocell BSs: 20 LTE Femtocell BSs: 37 WiMAX Macrocell BSs: 17 WiMAX Femtocell BSs: 25 WAVE RSUs: 22 Total: 121 Cells radius LTE/WiMAX Macrocells: 400 meters LTE/WiMAX Femtocells: 30 meters WAVE RSUs: 150 meters Networks positions According to the Hellenic Telecommu- nications and Post Commission (EETT) [254] data (see Appendix A) Networks frequencies See Appendix A Service Layer Agreements (SLA) count 4 Vehicles count 39807 Average vehicles arrival rate 0,460729167 vehicles per second Average vehicles departure rate 0,46 vehicles per second Vehicles per SLA SLA 1: 9952 vehicles (25,00062803 %) SLA 2: 9952 vehicles (25,00062803 %) SLA 3: 9952 vehicles (25,00062803 %) SLA 4: 9951 vehicles (24,99811591 %) Available networks per SLA See Appendix B Services Navigation Assistance (NAV) Voice over IP (VoIP) Conversational Video (CV) Buffered Streaming (BS) Web Browsing (WB) Distribution of services to vehicles See Appendix C Vehicles per velocity Normal: 13348 (33.53 %) Medium: 13348 (33.53 %) High: 13111 (32.94 %) Table 4.5 The available Networks for each Monitored Vehicle. Vehicle Available Networks in Current Location 1 LTE Macro 9, LTE Macro 11, LTE Femto 17, WiMAX Macro 8, WiMAX Macro 9, WiMAX Macro 11, WiMAX Femto 13, WAVE 14 2 LTE Macro 9, LTE Macro 11, LTE Femto 17, WiMAX Macro 8, WiMAX Macro 9, WiMAX Macro 11, WiMAX Femto 13, WAVE 14 3 LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Macro 18, LTE Femto 30, WiMAX Macro 8, WiMAX Macro 9, WiMAX Macro 11, WiMAX Macro 13 4 LTE Macro 4, LTE Macro 6, LTE Macro 7, LTE Macro 9, LTE Macro 11, LTE Macro 13, WiMAX Macro 6, WiMAX Macro 8, WiMAX Macro 11, WAVE 9, WAVE 11, WAVE 13 5 LTE Macro 4, LTE Macro 6, LTE Macro 7, WiMAX Macro 6, WAVE 9 6 LTE Macro 7, LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Femto 26, WiMAX Macro 6, WiMAX Macro 7, WiMAX Macro 8, WiMAX Macro 11, WiMAX Macro 13, WiMAX Femto 15, WAVE 11, WAVE 15 7 LTE Macro 10, LTE Macro 13, LTE Macro 17, LTE Macro 18, LTE Femto 29, WiMAX Macro 7, WiMAX Macro 13, WiMAX Macro 15, WAVE 19 8 LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Macro 18, LTE Femto 30, WiMAX Macro 8, WiMAX Macro 9, WiMAX Macro 11, WiMAX Macro 13 9 LTE Macro 3, LTE Macro 5, LTE Macro 9, WiMAX Macro 5, WiMAX Macro 8, WiMAX Macro 9 10 LTE Macro 9, LTE Macro 11, LTE Macro 13, LTE Macro 18, LTE Femto 30, WiMAX Macro 8, WiMAX Macro 9, WiMAX Macro 11, WiMAX Macro 13
  • 155. 4.3 Simulation Setup 129 Table 4.6 The QSLA, SINRSLA and Sth,SLA thresholds per SLA. SLA QSLA SINRSLA Sth,SLA 1 0.9 0.8 0.81675 2 0.8 0.7 0.70856 3 0.7 0.6 0.54440 4 0.6 0.5 0.42725 Table 4.7 The HO Initiation Results. Vehicle Current Network i Qu,i SINRu,i (SINRdB u,i ) Su,i Sth,SLAu Handover Required 1 WAVE 14 0.871 0.14 (-5.1 dB) 0.18157 0.81843 Yes 2 LTE Macro 11 0.912 0.17 (-4.05 dB) 0.18212 0.81843 Yes 3 WiMAX Macro 8 0.948 0.29 (0.15 dB) 0.32523 0.81843 Yes 4 LTE Macro 7 0.644 0.23 (-1.95 dB) 0.12122 0.66980 Yes 5 WAVE 9 0.990 0.14 (-5.1 dB) 0.18156 0.66980 Yes 6 WAVE 11 0.827 0.04 (-8.6 dB) 0.02539 0.66980 Yes 7 WiMAX Macro 7 0.999 0.21 (-2.65 dB) 0.18965 0.57767 Yes 8 WiMAX Macro 11 0.704 0.71 (14.85 dB) 0.61247 0.57767 No 9 WiMAX Macro 5 0.988 0.25 (-1.25 dB) 0.27297 0.45457 Yes 10 LTE Macro 18 0.990 0.29 (0.15 dB) 0.35622 0.45457 Yes Table 4.8 The Monitored Vehicles Status. Vehicle SLA Services Current Position (Latitude, Longitude) Velocity 1 1 VoIP, CV, BS 9n (37.942128, 23.650937) Medium 2 1 NAV, VoIP, WB 9m (37.942178, 23.650796) Normal 3 1 NAV 13j (37.938831, 23.647276) Medium 4 2 CV, BS 8i (37.942819, 23.647134) Normal 5 2 BS 7g (37.943935, 23.645180) High 6 2 CV, WB 10h (37.941048, 23.645664) Normal 7 3 BS 14e (37.938048, 23.642797) High 8 3 BS, WB 13j (37.988787, 23.647321) Medium 9 4 WB 8o (37.943331, 23.652023) High 10 4 WB 13j (37.938858, 23.647291) Normal Network Selection Weights per Service Network QoS Characteristics Network Policy Characteristics Troughput Delay Jitter Packet Loss Service Reliability Price Goal Criteria Groups Criteria Security Figure 4.8 The PF-ANP Network Model.
  • 156. 130 A Proposed Mobility Management Approach for 5G-VCC Systems Throughput Delay Jitter Packet loss Throughput Delay Jitter Packet loss Service Reliability Price Security Figure 4.9 The Relations of the Criteria considered by the PF-ANP Network Model. 0 0,05 0,1 0,15 0,2 0,25 Navigation Assistance VoIP Conversational Video Buffered Streaming Web Weight Network Selection weights for SLA 1 Throughput Delay Jitter Packet loss Service Reliability Security Price Figure 4.10 The Network Selection Weights per Service for SLA 1. 0 0,05 0,1 0,15 0,2 0,25 Conversational Video Buffered Streaming Web Weight Network Selection weights for SLA 2 Throughput Delay Jitter Packet loss Service Reliability Security Price Figure 4.11 The Network Selection Weights per Service for SLA 2. 0 0,05 0,1 0,15 0,2 0,25 Buffered Streaming Web Weight Network Selection weights for SLA 3 Throughput Delay Jitter Packet loss Service Reliability Security Price Figure 4.12 The Network Selection Weights per Service for SLA 3. 0 0,05 0,1 0,15 0,2 0,25 Web Weight Network Selection weights for SLA 4 Throughput Delay Jitter Packet loss Service Reliability Security Price Figure 4.13 The Network Selection Weights per Service for SLA 4.
  • 157. 4.3 Simulation Setup 131 Table 4.9 The PF-ANP Initial Supermatrix for the SLA 1 NAV Service. Throughput Delay Jitter Packet loss Service Reliability Security Price Throu- ghput [(0.37,0.36,0.34, 0.33,0.32,1,0.8,0.8), (0.36,0.36,0.34, 0.33,0.33,0.8,0.6,0.6)] [(0.37,0.36,0.34, 0.33,0.32,1,0.8,0.8), (0.36,0.36,0.34, 0.33,0.33,0.8,0.6,0.6)] [(0.37,0.36,0.34, 0.33,0.32,1,0.8,0.8), (0.36,0.36,0.34, 0.33,0.33,0.8,0.6,0.6)] [(0.37,0.36,0.34, 0.33,0.32,1,0.8,0.8), (0.36,0.36,0.34, 0.33,0.33,0.8,0.6,0.6)] [(0.37,0.36,0.349 0.33,0.32,1,0.8,0.8), (0.36,0.36,0.34, 0.33,0.33,0.8,0.6,0.6)] [(0.37,0.36,0.34, 0.33,0.32,1,0.8,0.8), (0.36,0.36,0.34, 0.33,0.33,0.8,0.6,0.6)] [(0.37,0.36,0.34, 0.33,0.32,1,0.8,0.8), (0.36,0.36,0.34, 0.33,0.33,0.8,0.6,0.6)] Delay [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6,0.6)] [(0.23,0.21,0.21 ,0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6,0.6)] Jitter [(0.16,0.2,0.22, 0.23,0.24,1,0.8,0.8), (0.19,0.2,0.22, 0.23,0.23,0.8,0.6,0.6)] [(0.16,0.2,0.22, 0.23,0.24,1,0.8,0.8), (0.19,0.2,0.22, 0.23,0.23,0.8,0.6,0.6)] [(0.16,0.2,0.22, 0.23,0.24,1,0.8,0.8), (0.19,0.2,0.22, 0.23,0.23,0.8,0.6,0.6)] [(0.16,0.2,0.22, 0.23,0.24,1,0.8,0.8), (0.19,0.2,0.22, 0.23,0.23,0.8,0.6,0.6)] [(0.16,0.2,0.22, 0.23,0.24,1,0.8,0.8), (0.19,0.2,0.22, 0.23,0.23,0.8,0.6,0.6)] [(0.16,0.2,0.22, 0.23,0.24,1,0.8,0.8), (0.19,0.2,0.22, 0.23,0.23,0.8,0.6,0.6)] [(0.16,0.2,0.22, 0.23,0.24,1,0.8,0.8), (0.19,0.2,0.22, 0.23,0.23,0.8,0.6,0.6)] Packet loss [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6)] [(0.23,0.21,0.21, 0.21,0.21,1,0.8,0.8), (0.21,0.21,0.21, 0.21,0.21,0.8,0.6)] Service Reliabil- ity [(0.52,0.47,0.42 ,0.4,0.4,1,0.8,0.8), (0.48,0.45,0.42, 0.41,0.4,0.8,0.6,0.6)] [(0.52,0.47,0.42, 0.4,0.4,1,0.8,0.8), (0.48,0.45,0.42, 0.41,0.4,0.8,0.6,0.6)] [(0.52,0.47,0.42, 0.4,0.4,1,0.8,0.8), (0.48,0.45,0.42, 0.41,0.4,0.8,0.6,0.6)] [(0.52,0.47,0.42, 0.4,0.4,1,0.8,0.8), (0.48,0.45,0.42, 0.41,0.4,0.8,0.6,0.6)] [(0.52,0.47,0.42, 0.4,0.4,1,0.8,0.8), (0.48,0.45,0.42, 0.41,0.4,0.8,0.6,0.6)] [(0.52,0.47,0.42, 0.4,0.4,1,0.8,0.8), (0.48,0.45,0.42, 0.41,0.4,0.8,0.6,0.6)] [(0.52,0.47,0.42, 0.4,0.4,1,0.8,0.8), (0.48,0.45,0.42, 0.41,0.4,0.8,0.6,0.6)] Security [(0.37,0.39,0.4, 0.4,0.4,1,0.8,0.8), (0.39,0.4,0.4, 0.4,0.4,0.8,0.6,0.6)] [(0.37,0.39,0.4, 0.4,0.4,1,0.8,0.8), (0.39,0.4,0.4, 0.4,0.4,0.8,0.6,0.6)] [(0.37,0.39,0.4, 0.4,0.4,1,0.8,0.8), (0.39,0.4,0.4, 0.405,0.4,0.8,0.6,0.6)] [(0.37,0.39,0.4, 0.4,0.4,1,0.8,0.8), (0.39,0.4,0.4, 0.4,0.403,0.8,0.6,0.6)] [(0.37,0.39,0.4, 0.4,0.4,1,0.8,0.8), (0.39,0.4,0.4, 0.4,0.4,0.8,0.6,0.6)] [(0.37,0.39,0.4, 0.4,0.4,1,0.8,0.8), (0.39,0.4,0.4, 0.4,0.4,0.8,0.6,0.6)] [(0.37,0.39,0.4, 0.4,0.4,1,0.8,0.8), (0.39,0.4,0.4, 0.4,0.4,0.8,0.6,0.6)] Price [(0.09,0.13,0.16, 0.18,0.19,1,0.8,0.8), (0.12,0.14,0.16, 0.18,0.18,0.8,0.6,0.6)] [(0.09,0.13,0.16, 0.18,0.19,1,0.8,0.8), (0.12,0.14,0.16, 0.18,0.18,0.8,0.6,0.6)] [(0.09,0.13,0.16, 0.18,0.19,1,0.8,0.8), (0.12,0.14,0.166, 0.18,0.18,0.8,0.6,0.6)] [(0.09,0.13,0.16, 0.18,0.19,1,0.8,0.8), (0.12,0.14,0.16, 0.18,0.18,0.8,0.6,0.6)] [(0.09,0.13,0.16, 0.18,0.19,1,0.8,0.8), (0.12,0.14,0.16, 0.18,0.18,0.8,0.6,0.6)] [(0.09,0.13,0.16, 0.18,0.19,1,0.8,0.8), (0.12,0.14,0.16, 0.18,0.18,0.8,0.6,0.6)] [(0.09,0.13,0.16, 0.18,0.19,1,0.8,0.8), (0.12,0.14,0.16, 0.18,0.18,0.8,0.6,0.6)] Table 4.10 The PF-ANP Weighted Supermatrix for the SLA 1 NAV Service. Throughput Delay Jitter Packet loss Service Reliability Security Price Throu- ghput [(0.18,0.18,0.17, 0.16,0.16,1,0.8,0.8), (0.18,0.18,0.17, 0.16,0.16,0.8,0.6,0.6)] [(0.18,0.18,0.17, 0.16,0.16,1,0.8,0.8), (0.18,0.18,0.17, 0.16,0.16,0.8,0.6,0.6)] [(0.18,0.18,0.17, 0.16,0.16,1,0.8,0.8), (0.18,0.18,0.17, 0.16,0.16,0.8,0.6,0.6)] [(0.18,0.18,0.17, 0.16,0.16,1,0.8,0.8), (0.18,0.18,0.17, 0.16,0.16,0.8,0.6,0.6)] [(0.18,0.18,0.17, 0.16,0.16,1,0.8,0.8), (0.18,0.18,0.17, 0.16,0.16,0.8,0.6,0.6)] [(0.18,0.18,0.17, 0.16,0.16,1,0.8,0.8), (0.18,0.18,0.17, 0.16,0.16,0.8,0.6,0.6)] [(0.18,0.18,0.17, 0.16,0.16,1,0.8,0.8), (0.18,0.18,0.17, 0.16,0.16,0.8,0.6,0.6)] Delay [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.106,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1,0.1, 0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] Jitter [(0.08,0.1,0.11, 0.11,0.12,1,0.8,0.8), (0.09,0.1,0.11, 0.11,0.11,0.8,0.6,0.6)] [(0.08,0.1,0.11, 0.11,0.12,1,0.8,0.8), (0.09,0.1,0.11, 0.11,0.11,0.8,0.6,0.6)] [(0.08,0.1,0.11, 0.11,0.12,1,0.8,0.8), (0.09,0.1,0.11, 0.11,0.11,0.8,0.6,0.6)] [(0.08,0.1,0.11, 0.11,0.12,1,0.8,0.8), (0.09,0.1,0.11, 0.11,0.11,0.8,0.6,0.6)] [(0.08,0.1,0.11, 0.11,0.12,1,0.8,0.8), (0.09,0.1,0.11, 0.11,0.11,0.8,0.6,0.6)] [(0.08,0.1,0.11, 0.11,0.12,1,0.8,0.8), (0.09,0.1,0.11, 0.11,0.11,0.8,0.6,0.6)] [(0.08,0.1,0.11, 0.11,0.12,1,0.8,0.8), (0.09,0.1,0.11, 0.11,0.11,0.8,0.6,0.6)] Packet loss [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.106,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.10,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] [(0.11,0.1,0.1, 0.1,0.1,1,0.8,0.8), (0.1,0.1,0.1, 0.1,0.1,0.8,0.6,0.6)] Service Reliabil- ity [(0.26,0.23,0.21, 0.2,0.2,1,0.8,0.8), (0.24,0.22,0.21, 0.2,0.2,0.8,0.6,0.6)] [(0.26,0.23,0.21, 0.2,0.2,1,0.8,0.8), (0.24,0.22,0.21, 0.2,0.2,0.8,0.6,0.6)] [(0.26,0.23,0.21, 0.2,0.2,1,0.8,0.8), (0.24,0.22,0.21, 0.2,0.2,0.8,0.6,0.6)] [(0.26,0.23,0.21, 0.2,0.2,1,0.8,0.8), (0.24,0.22,0.21, 0.2,0.2,0.8,0.6,0.6)] [(0.26,0.23,0.21, 0.2,0.2,1,0.8,0.8), (0.24,0.22,0.21, 0.2,0.2,0.8,0.6,0.6)] [(0.26,0.23,0.21, 0.2,0.2,1,0.8,0.8), (0.24,0.22,0.21, 0.2,0.2,0.8,0.6,0.6)] [(0.26,0.23,0.21, 0.2,0.2,1,0.8,0.8), (0.24,0.2,0.21, 0.2,0.2,0.8,0.6,0.6)] Security [(0.18,0.19,0.2, 0.2,0.2,1,0.8,0.8), (0.19,0.2,0.2, 0.2,0.2,0.8,0.6,0.6)] [(0.18,0.19,0.2, 0.2,0.2,1,0.8,0.8), (0.19,0.2,0.2, 0.2,0.2,0.8,0.6,0.6)] [(0.18,0.19,0.2, 0.2,0.2,1,0.8,0.8), (0.19,0.2,0.2, 0.2,0.2,0.8,0.6,0.6)] [(0.18,0.19,0.2, 0.2,0.2,1,0.8,0.8), (0.19,0.2,0.2, 0.2,0.2,0.8,0.6,0.6)] [(0.18,0.19,0.2, 0.2,0.2,1,0.8,0.8), (0.19,0.2,0.2, 0.2,0.2,0.8,0.6,0.6)] [(0.18,0.19,0.2, 0.2,0.2,1,0.8,0.8), (0.19,0.2,0.2, 0.2,0.2,0.8,0.6,0.6)] [(0.18,0.19,0.2, 0.2,0.2,1,0.8,0.8), (0.19,0.2,0.2, 0.2,0.2,0.8,0.6,0.6)] Price [(0.04,0.06,0.08, 0.09,0.09,1,0.8,0.8), (0.06,0.07,0.08, 0.09,0.09,0.8,0.6,0.6)] [(0.04,0.06,0.08, 0.09,0.09,1,0.8,0.8), (0.06,0.07,0.08, 0.09,0.09,0.8,0.6,0.6)] [(0.04,0.06,0.08, 0.09,0.09,1,0.8,0.8), (0.06,0.07,0.08, 0.09,0.09,0.8,0.6,0.6)] [(0.04,0.06,0.08, 0.09,0.09,1,0.8,0.8), (0.06,0.07,0.08, 0.09,0.09,0.8,0.6,0.6)] [(0.04,0.06,0.08, 0.09,0.09,1,0.8,0.8), (0.06,0.07,0.08, 0.09,0.09,0.8,0.6,0.6)] [(0.04,0.06,0.08, 0.09,0.09,1,0.8,0.8), (0.06,0.07,0.08, 0.09,0.09,0.8,0.6,0.6)] [(0.04,0.06,0.08, 0.09,0.09,1,0.8,0.8), (0.06,0.07,0.08, 0.09,0.09,0.8,0.6,0.6)] Table 4.11 The PF-ANP Limit Supermatrix for the SLA 1 NAV Service. Throughput Delay Jitter Packet loss Service Reliability Security Price Throughput 0.175346 0.175346 0.175346 0.175346 0.175346 0.175346 0.175346 Delay 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943 Jitter 0.104768 0.104768 0.104768 0.104768 0.104768 0.104768 0.104768 Packet loss 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943 0.109943 Service Reliability 0.195427 0.195427 0.195427 0.195427 0.195427 0.195427 0.195427 Security 0.188775 0.188775 0.188775 0.188775 0.188775 0.188775 0.188775 Price 0.115798 0.115798 0.115798 0.115798 0.115798 0.115798 0.115798
  • 158. 132 A Proposed Mobility Management Approach for 5G-VCC Systems 0 0,1 0,2 0,3 0,4 0,5 0,6 Vehicle 1 v=Medium Vehicle 2 v=Normal Vehicle 3 v=Medium Vehicle 4 v=Normal Vehicle 5 v=High Vehicle 6 v=Normal Vehicle 7 v=High Vehicle 8 v=Medium Vehicle 9 v=High Vehicle 10 v=Normal PFTrank PFT ranking of each VHO scheme Current Network Proposed Scheme VAH FAT FAS FAM FAE Figure 4.14 The PFT Ranking of each HO Scheme. 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10 Satisfactiongrade(Su,i) Satisfaction grade obtained from each VHO scheme Proposed VAH FAT FAS FAM FAE Figure 4.15 The Satisfaction Grade obtained from each HO Scheme. 0,43 0,44 0,45 0,46 0,47 0,48 0,49 Proposed VAH FAT FAS FAM FAE AveragePFTrank VHO scheme Average PFT ranking of each VHO scheme Figure 4.16 The Average PFT Ranking of each HO Scheme during the 24 Hours Simulation. 0,6 0,62 0,64 0,66 0,68 0,7 0,72 0,74 0,76 Proposed VAH FAT FAS FAM FAE Averagesatisfactiongrade(Su,i) VHO scheme Average satisfaction grade obtained from each VHO scheme Figure 4.17 The Average Satisfaction Grade obtained from each HO Scheme during the 24 Hours Simulation. 200000 250000 300000 350000 400000 450000 Proposed VAH FAT FAS FAM FAE VHOscount VHO scheme VHOs count of each VHO scheme Figure 4.18 The Total HOs Count of each HO Scheme during the 24 Hours Simulation.
  • 159. Chapter 5 Conclusion In this doctoral thesis, two key aspects of the 5G-VCC systems were studied, namely the allocation of network resources and the handling of the vehicles’ mobility. Regarding the allocation of the network resources, an overview of the available MAC schemes for vehicular networks has been performed [257]. These schemes can be applied in 5G-VCC systems in order optimal manipulation of communication resources to be performed. Some schemes organize the vehicles into clusters, while GPS receivers are used in some cases in order the vehicles to be synchronized with each other. The discussed schemes apply either distributed or centralized control. In a 5G-VCC system the centralized control could be enhanced using an SDN controller, while the distributed control could be easily configured using a Fog computing infrastructure. Furthermore, V2V communication is supported from most schemes, while some schemes support V2I communication. Finally, during the medium access, CRN could be applied to take advantage of free white spaces into the available spectrum. Subsequently, a QoS aware scheduler called FLSA [258][259] was proposed in order to improve the resource allocation for real time services in the LTE downlink. FLSA has been built on three distinct levels which cooperate with each other to allocate the network resources to users. In every TTI the upper level estimates the quota of the data that each real-time flow should transmit to satisfy its QoS constraints. Then, the middle level uses the M-LWDF algorithm to allocate RBs to real time flows in each TTI for transmitting their quota of data obtained by the upper level. Thereafter, if there are free RBs available in the current TTI, the lower level allocates them both to real time and to best effort flows, using the M-LWDF algorithm. The performance of FLSA for real time flows was compared against other scheduling algorithms in terms of PLR, attainable throughput and fairness. The simulation results showed that the FLSA scheduler outperforms the rest of the schemes by achieving better resource allocation for real time services.
  • 160. 134 Conclusion Furthermore, FLSA-CC [260], QoS aware cross carrier downlink scheduler has also been proposed as an extended version of the FLSA. FLSA-CC operates in an LTE-A network with relay nodes in a CA mode. The proposed scheduler has been built upon three distinct levels which cooperate with each other to allocate the network resources to users in a manner that the requirements of strict real times services are satisfied while a starvation of the best effort traffic is avoided. The performance of FLSA-CC is compared against other scheduling algorithms in terms of PLR, throughput and fairness index, in a cloud assisted software defined architecture. The simulation results showed that the FLSA-CC scheduler outperforms the rest of the scheduling schemes by achieving better resource allocation for both real time and best effort services. An overview of existing mobility management schemes has been made. These schemes can be applied to 5G-VCC systems in order an optimal manipulation of vehicles mobility to be performed. Each scheme implements one or more mobility management subprocesses, namely HO initiation, network selection and HO execution. The 5G-VCC topologies (e.g. VC, VuC, VuF, SDN-V and HVT) that each scheme supports were mentioned, while the communication models that could be applied in each scheme (V2V, V2I, V2P and HVC) were introduced. The control type of each scheme (vehicle or network controlled) was also described, while at the same time the OSI layer where each scheme was implemented indicate its mobility management capabilities. In addition, the supported message exchange mechanisms were considered, while the evaluation of each scheme considering the type of the implemented algorithms provided useful knowledge about its design. Novel mobility management algorithms for 5G networks were proposed. Specifically, firstly, we described a network selection method that takes into account the network QoS characteristics policies, application requirements and different types of user SLAs to select the optimal network that will satisfy simultaneously all the applications’ requirements and the users’ preferences running on a mobile user’s device [171]. The proposed method employed two MADM algorithms: the ANP for criteria weights calculation and the TFT for accomplishing the overall rating of the network technologies. ANP was selected to determine the relative importance and the dependence of the criteria. As selection criteria, we considered the network QoS parameters, service constraints, user requirements and provider policies. These criteria were represented by interval-valued trapezoidal fuzzy numbers. Then, the TFT algorithm was applied to calculate the overall rating of the available networks. The performance evaluation of TFT showed that when a user has only one service, it provides similar results to the original TOPSIS and FAE methods. However, when a user requires multiple services, TFT performs better by satisfying multiple groups of criteria per user since the original TOPSIS and FAE methods cannot support more than one services. Furthermore, according to the sensitivity
  • 161. 135 analysis of results it was shown that the described method doesn’t suffer from the ranking abnormality problem, thus, the results are normally adjusted to the heterogeneous network environment changes. Furthermore, we proposed a network selection scheme for supporting medical services in 5G-VCC systems [68][261]. The discussed scheme consists of the TF-ANP method to calculate the relative importance of the selection criteria and the TFT to accomplish the ranking of the candidate networks. The health status of each patient is considered, while the criteria used for network evaluation included throughput, delay, jitter, packet loss, service reliability, security and price. The performance evaluation showed that the proposed scheme outperforms existing network selection methods by satisfying multiple groups of criteria and medical services per user. Also, we proposed an improved version of this scheme [66]. In this case, the discussed scheme consists of two FMADM algorithms, namely the TF-AANP to calculate the relative importance of each service, as well as the weights of the selection criteria and the TFT-ACW to accomplish the ranking of the candidate networks. The health status of onboard patients and the SLA of each vehicle were considered, while the criteria used for network evaluation include throughput, delay, jitter, packet loss, service reliability, security and price. The performance evaluation showed that the proposed scheme outperforms existing network selection methods by satisfying the strict constraints of medical services, when the patient’s health status becomes immediate and multiple types of non-medical services coexist with medical services to the vehicle. Finally, we proposed a HO management scheme for 5G-VCC systems that takes into account the vehicle velocity, network’s QoS and policy characteristics, the vehicular services’ requirements and the various vehicle SLAs to select the optimal network that will satisfy simultaneously all the service requirements and onboard user preferences [67][262]. The HO management services are executed at the Cloud or the Fog infrastructure alleviating the vehicle’s processing load and reducing HO latency. IVPFNs are used for the representation of both HO Initiation and Network Selection criteria values, while the PF-ANP algorithm is used for the estimation of the criteria weights for both HO Initiation and Network Selection. During the HO Initiation, MPFIS evaluates the necessity to perform a handover, while during the Network Selection, the PFT algorithm selects the most appropriate network considering the vehicle’s velocity, the constraints of used vehicular services and the SLA of the vehicle. The performance evaluation showed that the Always Best Connected (ABC) principle is fully ensured, while at the same time the proposed scheme outperforms existing HO management algorithms in terms of the PFT ranks of the selected networks, the user satisfaction grade, as well as the VHOs count.
  • 162. 136 Conclusion 5.1 Directions for Future Work This section discusses some open issues arising from the study of the existing resource allo- cation and mobility management schemes. Although several schemes have been proposed to the research literature, some issues need to be resolved in cases where they resource allocation and/or mobility management concerns a 5G-VCC system. Specifically, although many algo- rithms can perform resource allocation and/or mobility management in 5G-VCC systems, the support for relay vehicles is limited. Vehicular relaying could be used in order vehicles with no access to RSUs/BSs to obtain this access through vehicles that already have it and could be called as relay vehicles. In these cases, vehicular relaying increases the coverage area of the 5G-VCC system providing access to an increased number of vehicles. Furthermore, in these cases Vehicle to Vehicle (V2V) routing issues must be addressed, since a vehicle should obtain access to RSUs/BSs through more than one relaying vehicles. However, the existing resource allocation algorithms are not optimized for distributing the communication resources of relay vehicles. Also, mobility management schemes do not address relay vehicles selection or routing issues. Furthermore, the resource allocation and/or mobility management functionalities of the 5G-VCC systems can be performed by a Cloud or a Fog infrastructure, as well as using SDN controllers, leading to solutions where both Host and Network control are combined. An open issue that arises from this situation is the need for the implementation of purely network controlled solutions, where components of the 5G-VCC infrastructure with fully knowledge about vehicles’ network status as well as with a complete view of the entire system, will perform the resource allocation and/or the mobility management releasing the vehicular equipment from this task, freeing up its resources and reducing its energy requirements.
  • 163. Publications 1. Emmanouil Skondras, Eirini Zoumi, Angelos Michalas, Dimitrios D. Vergados, “A Net- work Selection Algorithm for supporting Drone Services in 5G Network Architectures”, Wireless Telecommunications Symposium (WTS), New York, USA, April 9-12, 2019 2. Konstantina Siountri, Emmanouil Skondras, Theodoros Mavroeidakos, Dimitrios D. Vergados, “The Convergence of Blockchain, Internet of Things (IoT) and Building Information Modeling (BIM): The smart museum case”, Wireless Telecommunications Symposium (WTS), New York, USA, April 9-12, 2019 3. Emmanouil Skondras, Angelos Michalas, Dimitrios D. Vergados, “Mobility Manage- ment on 5G Vehicular Cloud Computing Systems”, Vehicular Communications Journal, Elsevier, vol. 16, pp. 15-44, April 2019 4. Emmanouil Skondras, Konstantina Siountri, Angelos Michalas, Dimitrios D. Vergados, “Personalized Real-Time Virtual Tours in Places with Cultural Interest”, International Journal of Computational Methods in Heritage Science (IJCMHS), IGI Global, vol. 3, issue 1, January 2019 5. Konstantina Siountri, Emmanouil Skondras, Dimitrios D. Vergados, Christos-Nikolaos Anagnostopoulos, “The Revival of Back-Filled Monuments through Augmented Reality (AR)”, Visual Heritage Congress, Vienna, Austria, November 12-15, 2018 6. Konstantina Siountri, Emmanouil Skondras, Dimitrios D. Vergados, “A Delivery Model for Cultural Heritage Services in Smart Cities Environments”, Euro-Mediterranean Conference (EUROMED), Springer, pp.279-288, Nicosia, Cyprus, October 29-November 3, 2018 7. Emmanouil Skondras, Angelos Michalas, Dimitrios D. Vergados, “A Survey on Medium Access Control Schemes for 5G Vehicular Cloud Computing Systems”, Global Informa- tion Infrastructure and Networking Symposium (GIIS), Thessaloniki, Greece, October 23-25, 2018
  • 164. 138 Conclusion 8. Emmanouil Skondras, Konstantina Siountri, Angelos Michalas, Dimitrios D. Vergados, “A Route Selection Scheme for supporting Virtual Tours in Sites with Cultural Interest using Drones”, International Conference on Information, Intelligence, Systems and Applications (IISA), Zakynthos, Greece, July 23-25, 2018 9. Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Dimitrios D. Vergados, “A Network Selection Scheme with Adaptive Criteria Weights for 5G Vehicular Systems”, International Conference on Information, Intelligence, Systems and Applications (IISA), Zakynthos, Greece, July 23-25, 2018 10. Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Dimitrios D. Vergados, “A VHO Scheme for supporting Healthcare Services in 5G Vehicular Cloud Computing Systems”, Wireless Telecommunications Symposium (WTS), Phoenix, Arizona, USA, April 18-20, 2018 11. Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Aggeliki Sgora, Dimitrios D. Vergados, “A Network Selection Scheme for Healthcare Vehicular Cloud Computing Sys- tems”, International Conference on Information, Intelligence, Systems and Applications (IISA), Larnaka, Cyprus, August 28-30, 2017 12. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “A Vertical Handover management scheme for VANET Cloud Computing systems”, IEEE Symposium on Computers and Communications (ISCC), Heraklion, Crete, Greece, July 3-6, 2017 13. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “QoS- aware scheduling in LTE-A networks with SDN control”, International Conference on Information, Intelligence, Systems and Applications (IISA), Chalkidiki, Greece, July 13-15, 2016 14. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “A downlink scheduler supporting real time services in LTE cellular networks”, Interna- tional Conference on Information, Intelligence, Systems and Applications (IISA), Ionian University, Corfu, Greece, July 6-8, 2015 15. Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, Dimitrios D. Vergados, “A QoS Aware Three Level Scheduler for the LTE Downlink”, Wireless Telecommunications Symposium (WTS), Poster Paper, New York, USA, April 15-17, 2015
  • 165. 5.1 Directions for Future Work 139 16. Emmanouil Skondras, Aggeliki Sgora, Angelos Michalas, Dimitrios D. Vergados, “An analytic network process and trapezoidal interval-valued fuzzy technique for order preference by similarity to ideal solution network access selection method”, International Journal of Communication Systems (IJCS), Wiley, September 2014 17. Emmanouil Skondras, Angelos Michalas, Malamati Louta, George Kouzas, “Personal- ized Multimedia Web Services in Peer to Peer Networks Using MPEG-7 and MPEG-21 Standards”, Studies in Computational Intelligence – Semantic Hyper/Multimedia Adapta- tion, Volume 418/2013 (book chapter), pp. 361-383, Springer-Verlag Berlin Heidelberg, 2013
  • 167. Bibliography [1] Ricard Vilalta, Victor Lopez, Alessio Giorgetti, Shuping Peng, Vittorio Orsini, Luis Velasco, Rene Serral-Gracia, Donal Morris, Silvia De Fina, Filippo Cugini, et al. Tel- cofog: A unified flexible fog and cloud computing architecture for 5g networks. IEEE Communications Magazine, 55(8):36–43, 2017. [2] Faqir Zarrar Yousaf, Michael Bredel, Sibylle Schaller, and Fabian Schneider. Nfv and sdn-key technology enablers for 5g networks. IEEE Journal on Selected Areas in Communications, 2017. [3] Hojjat Salehinejad, Hossein Nezamabadi-pour, Saeid Saryazdi, and Fereydoun Farrahi- Moghaddam. Combined a*-ants algorithm: a new multi-parameter vehicle navigation scheme. arXiv preprint arXiv:1504.07329, 2015. [4] Pietro Edoardo Carnelli, Joy Yeh, Mahesh Sooriyabandara, and Aftab Khan. Parkus: A novel vehicle parking detection system. In AAAI, pages 4650–4656, 2017. [5] Yang Li, Xiaoming Tao, and Jianhua Lu. Hybrid model-and-object-based real-time conversational video coding. Signal Processing: Image Communication, 35:9–19, 2015. [6] Toon De Pessemier, Isabelle Stevens, Lieven De Marez, Luc Martens, and Wout Joseph. Quality assessment and usage behavior of a mobile voice-over-ip service. Telecommuni- cation Systems, 61(3):417–432, 2016. [7] Henrik Klessig and Gerhard Fettweis. Impact of inter-cell interference on buffered video streaming startup delays. In Vehicular Technology Conference (VTC Fall), 2015 IEEE 82nd, pages 1–2. IEEE, 2015. [8] Verdes Pedras, Marco Sousa, Pedro Vieira, Maria-Paula Queluz, and Antonio Rodrigues. A no-reference user centric qoe model for voice and web browsing based on 3g/4g radio measurements. In Wireless Communications and Networking Conference (WCNC), 2018 IEEE, pages 1–6. IEEE, 2018. [9] Zinonas C Antoniou, Andreas S Panayides, Marios Pantziaris, Anthony G Constantinides, Constantinos S Pattichis, and Marios S Pattichis. Dynamic network adaptation for real- time medical video communication. In XIV Mediterranean Conference on Medical and Biological Engineering and Computing 2016, pages 1099–1104. Springer, 2016. [10] Luís FR Lucas, Nuno MM Rodrigues, Luis A da Silva Cruz, and Sérgio MM de Faria. Lossless compression of medical images using 3-d predictors. IEEE transactions on medical imaging, 36(11):2250–2260, 2017.
  • 168. 142 Bibliography [11] Gopi Krishna Garge, Chitra Balakrishna, and Soumya Kanti Datta. Consumer health care: Current trends in consumer health monitoring. IEEE Consumer Electronics Magazine, 7(1):38–46, 2018. [12] Qinghan Xue and Mooi Choo Chuah. Incentivising high quality crowdsourcing medical data for disease diagnose & survival prediction. Smart Health, 2017. [13] Tugce Bilen, Berk Canberk, and Kaushik R Chowdhury. Handover management in software-defined ultra-dense 5g networks. IEEE Network, 31(4):49–55, 2017. [14] TS 36.213 version 14.2.0: Evolved Universal Terrestrial Radio Access Network (E- UTRAN) (Release 14). Technical Specification, 3GPP, 2017. [15] P802.16/d4 - ieee draft standard for air interface for broadband wireless access systems (revision of ieee std 802.16-2012). IEEE Standard, 2017. [16] 1609.12-2016 - ieee standard for wireless access in vehicular environments (wave) – networking services. IEEE Standard, 2016. [17] Hucheng Wang, Shanzhi Chen, Ming Ai, and Hui Xu. Localized mobility management for 5g ultra dense network. IEEE Transactions on Vehicular Technology, 66(9):8535– 8552, 2017. [18] Daniel Calabuig, Sokratis Barmpounakis, Sonia Gimenez, Apostolos Kousaridas, Tilak R Lakshmana, Javier Lorca, Petteri Lunden, Zhe Ren, Pawel Sroka, Emmanuel Ternon, et al. Resource and mobility management in the network layer of 5g cellular ultra-dense networks. IEEE Communications Magazine, 55(6):162–169, 2017. [19] Tarik Taleb, Adlen Ksentini, and Riku Jantti. " anything as a service" for 5g mobile systems. IEEE Network, 30(6):84–91, 2016. [20] Rakibul Islam Rony, Akshay Jain, Elena Lopez-Aguilera, Eduard Garcia-Villegas, and Ilker Demirkol. Joint access-backhaul perspective on mobility management in 5g networks. In Standards for Communications and Networking (CSCN), 2017 IEEE Conference on, pages 115–120. IEEE, 2017. [21] Akshay Jain, Elena Lopez-Aguilera, and Ilker Demirkol. Mobility management as a service for 5g networks. arXiv preprint arXiv:1705.09101, 2017. [22] Ke Zhang, Yuming Mao, Supeng Leng, Yejun He, and Yan Zhang. Mobile-edge computing for vehicular networks: A promising network paradigm with predictive off-loading. IEEE Vehicular Technology Magazine, 12(2):36–44, 2017. [23] Binxu Yang, Wei Koong Chai, Zichuan Xu, Konstantinos V Katsaros, and George Pavlou. Cost-efficient nfv-enabled mobile edge-cloud for low latency mobile applications. IEEE Transactions on Network and Service Management, 2018. [24] Xumin Huang, Rong Yu, Jiawen Kang, Yejun He, and Yan Zhang. Exploring mobile edge computing for 5g-enabled software defined vehicular networks. IEEE Wireless Communications, 24(6):55–63, 2017.
  • 169. Bibliography 143 [25] Mehdi Sookhak, F Richard Yu, Ying He, Hamid Talebian, Nader Sohrabi Safa, Nan Zhao, Muhammad Khurram Khan, and Neeraj Kumar. Fog vehicular computing: Augmenta- tion of fog computing using vehicular cloud computing. IEEE Vehicular Technology Magazine, 12(3):55–64, 2017. [26] Cheng Huang, Rongxing Lu, and Kim-Kwang Raymond Choo. Vehicular fog computing: architecture, use case, and security and forensic challenges. IEEE Communications Magazine, 55(11):105–111, 2017. [27] Jiafu Wan, Daqiang Zhang, Shengjie Zhao, Laurence T Yang, and Jaime Lloret. Context- aware vehicular cyber-physical systems with cloud support: architecture, challenges, and solutions. IEEE Communications Magazine, 52(8):106–113, 2014. [28] A.R. Deepti G.Sasikala. Real time services for future cloud computing enabled vehicle networks. In IOSR Journal of Computer Engineering (IOSR-JCE), volume 11, pages 8–14, 2013. [29] Dipal Vashi Priyank Sharma, Sandip Vaniya. Communication as a service based cloud computing. IEEE International Conference on Emerging Technology Trends (ICETECT), Nagercoil, India, pages 15–17, 2011. [30] Quang Hieu Vu, Tran-Vu Pham, Hong-Linh Truong, Schahram Dustdar, and Rasool Asal. Demods: A description model for data-as-a-service. In 2012 IEEE 26th International Conference on Advanced Information Networking and Applications, pages 605–612. IEEE, 2012. [31] Fekri M Abduljalil. Video capture service in the intelligent transportation system based on cloud computing. International Journal of Computer Applications, 97(5), 2014. [32] Rasheed Hussain, Fizza Abbas, Junggab Son, and Heekuck Oh. Tiaas: Secure cloud- assisted traffic information dissemination in vehicular ad hoc networks. In Cluster, Cloud and Grid Computing (CCGrid), 2013 13th IEEE/ACM International Symposium on, pages 178–179. IEEE, 2013. [33] Mario Gerla, Jui-Ting Weng, and Giovanni Pau. Pics-on-wheels: Photo surveillance in the vehicular cloud. In Computing, Networking and Communications (ICNC), 2013 International Conference on, pages 1123–1127. IEEE, 2013. [34] Stefano Ferretti and Gabriele D’Angelo. Smart shires: The revenge of countrysides. In Computers and Communication (ISCC), 2016 IEEE Symposium on, pages 756–759. IEEE, 2016. [35] Rasheed Hussain and Heekuck Oh. Cooperation-aware vanet clouds: Providing secure cloud services to vehicular ad hoc networks. JIPS, 10(1):103–118, 2014. [36] Moustafa AbdelBaky, Manish Parashar, Kirk Jordan, Hyunjoo Kim, Hani Jamjoom, Zon-Yin Shae, Gergina Pencheva, Vipin Sachdeva, James Sexton, Mary Wheeler, et al. Enabling high-performance computing as a service. Computer, 45(10):72–80, 2012.
  • 170. 144 Bibliography [37] Steffen Kächele, Christian Spann, Franz J Hauck, and Jörg Domaschka. Beyond iaas and paas: An extended cloud taxonomy for computation, storage and networking. In Proceedings of the 2013 IEEE/ACM 6th International Conference on Utility and Cloud Computing, pages 75–82. IEEE Computer Society, 2013. [38] Khaleel Mershad and Hassan Artail. Finding a star in a vehicular cloud. IEEE Intelligent transportation systems magazine, 5(2):55–68, 2013. [39] Rasheed Hussain, Junggab Son, Hasoo Eun, Sangjin Kim, and Heekuck Oh. Rethinking vehicular communications: Merging vanet with cloud computing. In Cloud Computing Technology and Science (CloudCom), 2012 IEEE 4th International Conference on, pages 606–609. IEEE, 2012. [40] Alexander Stanik, Matthias Hovestadt, and Odej Kao. Hardware as a service (haas): Physical and virtual hardware on demand. In Cloud Computing Technology and Science (CloudCom), 2012 IEEE 4th International Conference on, pages 149–154. IEEE, 2012. [41] Monica Mandal, Chaitrali Landge, Pramila Gaikwad, Uma Nagaraj, and Ashwini Abhale. Implementing storage as a service in vanet using cloud environment. International Journal of Advance Foundation and Research in Computer (IJAFRC), 1, 2014. [42] Mario Gerla, Eun-Kyu Lee, Giovanni Pau, and Uichin Lee. Internet of vehicles: From intelligent grid to autonomous cars and vehicular clouds. In Internet of Things (WF-IoT), 2014 IEEE World Forum on, pages 241–246. IEEE, 2014. [43] Peyman Talebifard and Victor CM Leung. Towards a content-centric approach to crowd-sensing in vehicular clouds. Journal of Systems Architecture, 59(10):976–984, 2013. [44] Hajar Mousannif, Ismail Khalil, and Hassan Al Moatassime. Cooperation as a service in vanets. J. UCS, 17(8):1202–1218, 2011. [45] K Rajbhojsupriya and Pankaj R Ch. Implementation of enhanced security on vehic- ular cloud computing. International Journal of Computer Science and Information Technologies (IJCSIT), 5:1315–1318, 2014. [46] Jithrendra H. N. Jyoti Metan, Narasimha K. N. Murthy. Moving vanet to vehicular cloud. International Journal of Innovative Research in Computer and Communication Engineering (IJIRCCE), 2, 2014. [47] Mehmet Ali Ertürk, Muhammed Ali Aydin, Luca Vollero, and Roberto Setola. Ieee 802.11 s mesh network analysis for post disaster communication. In International Telecommunications Conference, pages 53–59. Springer, 2019. [48] Mehdi Sookhak, F Richard Yu, and Helen Tang. Secure data sharing for vehicular ad-hoc networks using cloud computing. In Ad Hoc Networks, pages 306–315. Springer, 2017. [49] Md Whaiduzzaman, Mehdi Sookhak, Abdullah Gani, and Rajkumar Buyya. A survey on vehicular cloud computing. Journal of Network and Computer Applications, 40:325–344, 2014.
  • 171. Bibliography 145 [50] Stephan Olariu, Tihomir Hristov, and Gongjun Yan. The next paradigm shift: from vehicular networks to vehicular clouds, 2013. [51] Benjamin Baron, Miguel Campista, Prométhée Spathis, Luís Henrique MK Costa, Marcelo Dias de Amorim, Otto Carlos MB Duarte, Guy Pujolle, and Yannis Viniotis. Virtualizing vehicular node resources: Feasibility study of virtual machine migration. Vehicular Communications, 4:39–46, 2016. [52] Tarek K Refaat, Burak Kantarci, and Hussein T Mouftah. Virtual machine migration and management for vehicular clouds. Vehicular Communications, 4:47–56, 2016. [53] Salim Bitam, Abdelhamid Mellouk, and Sherali Zeadally. Vanet-cloud: a generic cloud computing model for vehicular ad hoc networks. IEEE Wireless Communications, 22(1):96–102, 2015. [54] Neeraj Kumar, Rahat Iqbal, Sudip Misra, and Joel JPC Rodrigues. Bayesian coalition game for contention-aware reliable data forwarding in vehicular mobile cloud. Future Generation Computer Systems, 48:60–72, 2015. [55] Yen-Wen Lin, Jie-Min Shen, and Hao-Chun Weng. Gateway discovery in vanet cloud. In High Performance Computing and Communications (HPCC), 2011 IEEE 13th Inter- national Conference on, pages 951–954. IEEE, 2011. [56] Yen-Wen Lin, Jie-Min Shen, and Hao-Jun Weng. Cloud-assisted gateway discovery for vehicular ad hoc networks. In Information Science and Service Science (NISS), 2011 5th International Conference on New Trends in, volume 2, pages 237–240. IEEE, 2011. [57] Rasheed Hussain, Zeinab Rezaeifar, Yong-Hwan Lee, and Heekuck Oh. Secure and privacy-aware traffic information as a service in vanet-based clouds. Pervasive and Mobile Computing, 24:194–209, 2015. [58] Priya. V. Cloud service for best gateway in vanet. International Journal of Advanced Research in Computer Science and Software Engineering, 4, 2014. [59] Ms Madhuri H Badole and Mr Pritam Nikam. Performance evaluation of an efficient cloud-assisted gateway discovery for vehicular ad hoc network. Performance Evaluation, 1(7), 2014. [60] C Shravanthi and HS Guruprasad. Vanet using cloud [vuc]. 2:1–7, 2014. [61] China Mobile. C-ran: the road towards green ran. White Paper, ver, 2, 2011. [62] Diego Kreutz, Fernando MV Ramos, Paulo Esteves Verissimo, Christian Esteve Rothen- berg, Siamak Azodolmolky, and Steve Uhlig. Software-defined networking: A compre- hensive survey. Proceedings of the IEEE, 103(1):14–76, 2015. [63] Ievgen Volvach and Larysa Globa. Mobile networks disaster recovery using sdn-nfv. In Radio Electronics & Info Communications (UkrMiCo), 2016 International Conference, pages 1–3. IEEE, 2016. [64] Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De Turck, and Raouf Boutaba. Network function virtualization: State-of-the-art and research challenges. IEEE Communications Surveys & Tutorials, 18(1):236–262, 2015.
  • 172. 146 Bibliography [65] Sherif Abdelwahab, Bechir Hamdaoui, Mohsen Guizani, and Taieb Znati. Network function virtualization in 5g. IEEE Communications Magazine, 54(4):84–91, 2016. [66] Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, and Dimitrios D Vergados. A network selection scheme with adaptive criteria weights for 5g vehicular systems. In Information, Intelligence, Systems & Applications (IISA), 2018 9th International Conference on. IEEE, 2018. [67] Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, and Dimitrios D Vergados. A vertical handover management scheme for vanet cloud computing systems. In Computers and Communications (ISCC), 2017 IEEE Symposium on, pages 371–376. IEEE, 2017. [68] Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, and Dimitrios D Vergados. A vho scheme for supporting healthcare services in 5g vehicular cloud computing systems. In Wireless Telecommunications Symposium (WTS), 2018, pages 1–6. IEEE, 2018. [69] Mohammad A Salahuddin, Ala Al-Fuqaha, Mohsen Guizani, and Soumaya Cherkaoui. Rsu cloud and its resource management in support of enhanced vehicular applications. In 2014 IEEE Globecom Workshops (GC Wkshps), pages 127–132. IEEE, 2014. [70] Mohammad Ali Salahuddin. Opportunistic service differentiation and cloud resource management in support of enhanced vehicular applications. Thesis at Western Michigan University, 2014. [71] Md Faizul Bari, Arup Raton Roy, Shihabur Rahman Chowdhury, Qi Zhang, Mo- hamed Faten Zhani, Reaz Ahmed, and Raouf Boutaba. Dynamic controller provisioning in software defined networks. In Proceedings of the 9th International Conference on Network and Service Management (CNSM 2013), pages 18–25. IEEE, 2013. [72] Nguyen B Truong, Gyu Myoung Lee, and Yacine Ghamri-Doudane. Software defined networking-based vehicular adhoc network with fog computing. In 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM), pages 1202–1207. IEEE, 2015. [73] Nicola Cordeschi, Danilo Amendola, Mohammad Shojafar, and Enzo Baccarelli. Dis- tributed and adaptive resource management in cloud-assisted cognitive radio vehicular networks with hard reliability guarantees. Vehicular Communications, 2(1):1–12, 2015. [74] Joy Eze, Sijing Zhang, Enjie Liu, and Elias Eze. Cognitive radio-enabled internet of vehicles: a cooperative spectrum sensing and allocation for vehicular communication. IET Networks, 2018. [75] Rong Yu, Yan Zhang, Stein Gjessing, Wenlong Xia, and Kun Yang. Toward cloud-based vehicular networks with efficient resource management. IEEE Network, 27(5):48–55, 2013. [76] Md Ali Al Mamun, Khairul Anam, Md Fakhrul Alam Onik, and AM Esfar-E-Alam. Deployment of cloud computing into vanet to create ad hoc cloud network architecture. In Proceedings of the World Congress on Engineering and Computer Science, volume 1, pages 24–26, 2012.
  • 173. Bibliography 147 [77] Carl Bergenhem, Erik Coelingh, Rolf Johansson, and Ali Tehrani. V2v communica- tion quality: measurements in a cooperative automotive platooning application. SAE International Journal of Passenger Cars-Electronic and Electrical Systems, 7(2014-01- 0302):462–470, 2014. [78] Mohammed Abdulhakim Al-Absi, Ahmed Abdulhakim Al-Absi, Young-Jin Kang, and Hoon Jae Lee. Obstacles effects on signal attenuation in line of sight for different envi- ronments in v2v communication. In 2018 20th International Conference on Advanced Communication Technology (ICACT), pages 17–20. IEEE, 2018. [79] Juinn-Horng Deng, Su-Hua Chen, Chia-Fang Lee, Chorng-Ren Sheu, Hua-Lung Tsai, Shubhranshu Singh, and Jen-Shun Yang. Joint time-frequency dmrs design for high mobility lte-a v2v communication systems. In Microwaves, Antennas, Communications and Electronic Systems (COMCAS), 2017 IEEE International Conference on, pages 1–6. IEEE, 2017. [80] Hazem M Fahmy, Gerd Baumann, Mohamed A Abd El Ghany, and Hassan Mostafa. V2v-based vehicle risk assessment and control for lane-keeping and collision avoidance. In Microelectronics (ICM), 2017 29th International Conference on, pages 1–5. IEEE, 2017. [81] Wanlu Sun, Erik G Ström, Fredrik Brännström, Yutao Sui, and Kin Cheong Sou. D2d- based v2v communications with latency and reliability constraints. In 2014 IEEE Globecom Workshops (GC Wkshps), pages 1414–1419. IEEE, 2014. [82] Hao Ye and Geoffrey Ye Li. Deep reinforcement learning for resource allocation in v2v communications. In 2018 IEEE International Conference on Communications (ICC), pages 1–6. IEEE, 2018. [83] Yanbing Liu, Yuhang Wang, and Guanghui Chang. Efficient privacy-preserving dual authentication and key agreement scheme for secure v2v communications in an iov paradigm. IEEE Transactions on Intelligent Transportation Systems, 18(10):2740–2749, 2017. [84] Arindam Ghosh, Vishnu Vardhan Paranthaman, Glenford Mapp, Orhan Gemikonakli, and Jonathan Loo. Enabling seamless v2i communications: toward developing coop- erative automotive applications in vanet systems. IEEE Communications Magazine, 53(12):80–86, 2015. [85] Yuanguo Bi, Haibo Zhou, Weihua Zhuang, and Hai Zhao. Safety message dissemination in v2i communication networks. In Safety Message Broadcast in Vehicular Networks, pages 83–101. Springer, 2017. [86] Xiao-Feng Xie and Zun-Jing Wang. Siv-dss: Smart in-vehicle decision support system for driving at signalized intersections with v2i communication. Transportation Research Part C: Emerging Technologies, 90:181–197, 2018. [87] Michał Hoeft and Jacek Rak. How to provide fair service for v2i communications in vanets? Ad Hoc Networks, 37:283–294, 2016.
  • 174. 148 Bibliography [88] Gerard Aguilar Ubiergo and Wen-Long Jin. Mobility and environment improvement of signalized networks through vehicle-to-infrastructure (v2i) communications. Trans- portation Research Part C: Emerging Technologies, 68:70–82, 2016. [89] Ribal Atallah, Maurice Khabbaz, and Chadi Assi. Multihop v2i communications: A feasibility study, modeling, and performance analysis. IEEE Transactions on Vehicular Technology, 66(3):2801–2810, 2017. [90] Otilia Popescu, Sarwar Sha-Mohammad, Hussein Abdel-Wahab, Dimitrie C Popescu, and Samy El-Tawab. Automatic incident detection in intelligent transportation systems using aggregation of traffic parameters collected through v2i communications. IEEE Intelligent Transportation Systems Magazine, 9(2):64–75, 2017. [91] I Rashdan, F de Ponte Muller, Wei Wang, M Schmidhammer, and S Sand. Vehicle-to- pedestrian channel characterization: Wideband measurement campaign and first results. 2018. [92] Pooya Rahimian, Elizabeth E O’Neal, Shiwen Zhou, Junghum Paul Yon, Luke Franzen, Jodie M Plumert, and Joseph K Kearney. Vehicle-to-pedestrian (v2p) communications technology: Do cell phone warnings improve road-crossing safety for texting pedes- trians? AND30 Standing Committee on Simulation and Measurement of Vehicle and Operator Performance, 2018. [93] José Javier Anaya, Pierre Merdrignac, Oyunchimeg Shagdar, Fawzi Nashashibi, and José E Naranjo. Vehicle to pedestrian communications for protection of vulnerable road users. In Intelligent Vehicles Symposium Proceedings, 2014 IEEE, pages 1037–1042. IEEE, 2014. [94] Pooya Rahimian, Elizabeth E O’Neal, Shiwen Zhou, Jodie M Plumert, and Joseph K Kearney. Harnessing vehicle-to-pedestrian (v2p) communication technology: Sending traffic warnings to texting pedestrians. Human Factors, 2018. [95] Pierre Merdrignac, Oyunchimeg Shagdar, and Fawzi Nashashibi. Fusion of percep- tion and v2p communication systems for the safety of vulnerable road users. IEEE Transactions on Intelligent Transportation Systems, 18(7):1740–1751, 2017. [96] Ahmed Hussein, Fernando García, José María Armingol, and Cristina Olaverri-Monreal. P2v and v2p communication for pedestrian warning on the basis of autonomous vehicles. In Intelligent Transportation Systems (ITSC), 2016 IEEE 19th International Conference on, pages 2034–2039. IEEE, 2016. [97] Mehrdad Bagheri, Matti Siekkinen, and Jukka K Nurminen. Cellular-based vehicle to pedestrian (v2p) adaptive communication for collision avoidance. In Connected Vehicles and Expo (ICCVE), 2014 International Conference on, pages 450–456. IEEE, 2014. [98] Kai Liu, Joseph KY Ng, Victor CS Lee, Sang H Son, and Ivan Stojmenovic. Cooperative data scheduling in hybrid vehicular ad hoc networks: Vanet as a software defined network. 2015. [99] Yuanzhi Ni, Jianping He, Lin Cai, and Yuming Bo. Data uploading in hybrid v2v/v2i vehicular networks: Modeling and cooperative strategy. IEEE Transactions on Vehicular Technology, 67(5):4602–4614, 2018.
  • 175. Bibliography 149 [100] Norbert Bissmeyer, Jan-Felix van Dam, Christian Zimmermann, and Kurt Eckert. Secu- rity in hybrid vehicular communication based on its-g5, lte-v, and mobile edge computing. In AmE 2018-Automotive meets Electronics; 9th GMM-Symposium, pages 1–6. VDE, 2018. [101] Susumu Ishihara, Vince Rabsatt, and Mario Gerla. Secure autonomous platooning with hybrid vehicular communication. ACM HotMobile, 2015. [102] Kai Liu, Joseph KY Ng, Victor Lee, Sang H Son, and Ivan Stojmenovic. Cooperative data scheduling in hybrid vehicular ad hoc networks: Vanet as a software defined network. IEEE/ACM Transactions on Networking (TON), 24(3):1759–1773, 2016. [103] Nils Dreyer, Andreas Moller, Zeeshan Hameed Mir, Fethi Filali, and Thomas Kurner. A data traffic steering algorithm for ieee 802.11 p/lte hybrid vehicular networks. In Vehicular Technology Conference (VTC-Fall), 2016 IEEE 84th, pages 1–6. IEEE, 2016. [104] Nils Dreyer, Andreas Moeller, Johannes Baumgarten, Zeeshan Hameed Mir, Thomas Kuerner, and Fethi Filali. On building realistic reference scenarios for ieee 802.11 p/lte-based vehicular network evaluations. In 2018 IEEE 87th Vehicular Technology Conference (VTC Spring), pages 1–7. IEEE, 2018. [105] Wei-dong YANG, LI Pan, Hong-song ZHU, et al. Adaptive tdma slot assignment protocol for vehicular ad-hoc networks. The Journal of China Universities of Posts and Telecommunications, 20(1):11–25, 2013. [106] Tsang-Ling Sheu and Yu-Hung Lin. A cluster-based tdma system for inter-vehicle communications. J. Inf. Sci. Eng., 30(1):213–231, 2014. [107] Kazi Atiqur Rahman and Kemal E Tepe. Towards a cross-layer based mac for smooth v2v and v2i communications for safety applications in dsrc/wave based systems. In 2014 IEEE Intelligent Vehicles Symposium Proceedings, pages 969–973. IEEE, 2014. [108] Rui Zou, Zishan Liu, Lin Zhang, and Muhammad Kamil. A near collision free reservation based mac protocol for vanets. In 2014 IEEE Wireless Communications and Networking Conference (WCNC), pages 1538–1543. IEEE, 2014. [109] Hassan Aboubakr Omar, Weihua Zhuang, and Li Li. Vemac: A tdma-based mac protocol for reliable broadcast in vanets. IEEE Transactions on Mobile Computing, 12(9):1724–1736, 2013. [110] VanDung Nguyen, Duc Ngoc Minh Dang, Sungman Jang, and Choong Seon Hong. e- vemac: an enhanced vehicular mac protocol to mitigate the exposed terminal problem. In Network Operations and Management Symposium (APNOMS), 2014 16th Asia-Pacific, pages 1–4. IEEE, 2014. [111] Nurullah Shahin and Young-Tak Kim. An enhanced tdma cluster-based mac (etcm) for multichannel vehicular networks. In Selected Topics in Mobile & Wireless Networking (MoWNeT), 2016 International Conference on, pages 1–8. IEEE, 2016. [112] Xiaoxiao Jiang and David Du. Ptmac: A prediction-based tdma mac protocol for reducing packet collisions in vanet. 2015.
  • 176. 150 Bibliography [113] Rongqing Zhang, Xiang Cheng, Liuqing Yang, Xia Shen, and Bingli Jiao. A novel centralized tdma-based scheduling protocol for vehicular networks. IEEE Transactions on Intelligent Transportation Systems, 16(1):411–416, 2015. [114] Sailesh Bharati and Weihua Zhuang. Cah-mac: Cooperative adhoc mac for vehicular networks. IEEE Journal on Selected Areas in Communications, 31(9):470–479, 2013. [115] Lili Zheng, Yi Wu, Zhexin Xu, and Xiao Lin. A novel mac protocol for vanet based on improved generalized prime sequence. In Advanced Infocomm Technology (ICAIT), 2014 IEEE 7th International Conference on, pages 1–7. IEEE, 2014. [116] Hang Yu, Zhiqiang He, and Kai Niu. Stdma for vehicle-to-vehicle communication in a highway scenario. In Microwave, Antenna, Propagation and EMC Technologies for Wireless Communications (MAPE), 2013 IEEE 5th International Symposium on, pages 133–138. IEEE, 2013. [117] Mohammad S Almalag, Stephan Olariu, and Michele C Weigle. Tdma cluster-based mac for vanets (tc-mac). In World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2012 IEEE International Symposium on a, pages 1–6. IEEE, 2012. [118] Shanqiang Yi, Wuwen Lai, Di Tang, and Hua Wang. A context-aware mac protocol in vanet based on bayesian networks. In Communications and Networking in China (CHINACOM), 2014 9th International Conference on, pages 191–196. IEEE, 2014. [119] Xin Zhou, Changwen Zheng, Xiaoxin He, et al. Adaptive contention window tuning for ieee 802.11. In 22nd International Conference on Telecommunications: ICT 2015, page 74. Engineers Australia, 2015. [120] Peppino Fazio, Floriano De Rango, and Cesare Sottile. A predictive cross-layered interference management in a multichannel mac with reactive routing in vanet. 2015. [121] Hikmat El Ajaltouni, Richard W Pazzi, and Azzedine Boukerche. An efficient qos mac for ieee 802.11p over cognitive multichannel vehicular networks. In 2012 IEEE International Conference on Communications (ICC), pages 413–417. IEEE, 2012. [122] Celimuge Wu, Satoshi Ohzahata, Yusheng Ji, and Toshihiko Kato. A mac protocol for delay-sensitive vanet applications with self-learning contention scheme. In 2014 IEEE 11th Consumer Communications and Networking Conference (CCNC), pages 438–443. IEEE, 2014. [123] Weijie Guo, Liusheng Huang, Long Chen, Hongli Xu, and Jietao Xie. An adaptive collision-free mac protocol based on tdma for inter-vehicular communication. In Wireless Communications & Signal Processing (WCSP), 2012 International Conference on, pages 1–6. IEEE, 2012. [124] Rongqing Zhang, Jinsung Lee, Xia Shen, Xiang Cheng, Liuqing Yang, and Bingli Jiao. A unified tdma-based scheduling protocol for vehicle-to-infrastructure communications. In Wireless Communications & Signal Processing (WCSP), 2013 International Conference on, pages 1–6. IEEE, 2013.
  • 177. Bibliography 151 [125] Duc Ngoc Minh Dang, Hanh Ngoc Dang, Vandung Nguyen, Zaw Htike, and Choong Seon Hong. Her-mac: A hybrid efficient and reliable mac for vehicular ad hoc networks. In 2014 IEEE 28th International Conference on Advanced Information Networking and Applications, pages 186–193. IEEE, 2014. [126] Weijie Guo, Liusheng Huang, Long Chen, Hongli Xu, and Chenglin Miao. R-mac: Risk-aware dynamic mac protocol for vehicular cooperative collision avoidance system. International Journal of Distributed Sensor Networks, 2013, 2013. [127] Lin Zhang, Zishan Liu, Rui Zou, Jinjie Guo, and Yu Liu. A scalable csma and self- organizing tdma mac for ieee 802.11 p/1609. x in vanets. Wireless Personal Communi- cations, 74(4):1197–1212, 2014. [128] Alessandro Bazzi, Alberto Zanella, and Barbara Maví Masini. An ofdma-based mac protocol for next-generation vanets. IEEE Transactions on Vehicular Technology, 64(9):4088–4100, 2015. [129] Baozhu Li, Xuhui Zhao, Shiyuan Han, and Zhenxiang Chen. New sdn-based architecture for integrated vehicular cloud computing networking. In 2018 International Conference on Selected Topics in Mobile and Wireless Networking (MoWNeT), pages 1–4. IEEE, 2018. [130] Redowan Mahmud, Ramamohanarao Kotagiri, and Rajkumar Buyya. Fog computing: A taxonomy, survey and future directions. In Internet of everything, pages 103–130. Springer, 2018. [131] Behnam Khodapanah, Ahmad Awada, Ingo Viering, David Oehmann, Meryem Sim- sek, and Gerhard P Fettweis. Fulfillment of service level agreements via slice-aware radio resource management in 5g networks. In 2018 IEEE 87th Vehicular Technology Conference (VTC Spring), pages 1–6. IEEE, 2018. [132] Dizhi Zhou, Nicola Baldo, and Marco Miozzo. Implementation and Validation of LTE Downlink Schedulers for ns-3. In Simulation Tools and Techniques (SimuTools ’13), 6th International ICST Conference on, pages 211–218, 2013. [133] F. Capozzi, G. Piro, L. A. Grieco, G. Boggia, and P. Camarda. Downlink packet scheduling in LTE cellular networks: Key design issues and a survey. Communications Surveys and Tutorials, IEEE, 99, 2012. [134] Akhilesh Pokhariyal, Klaus I Pedersen, Guillaume Monghal, Istvan Z Kovacs, Claudio Rosa, Troels E Kolding, and Preben E Mogensen. HARQ aware frequency domain packet scheduler with different degrees of fairness for the UTRAN long term evolution. In Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th, pages 2761–2765. IEEE, 2007. [135] Dizhi Zhou, Wei Song, Nicola Baldo, and Marco Miozzo. Evaluation of TCP perfor- mance with LTE downlink schedulers in a vehicular environment. In Wireless Communi- cations and Mobile Computing Conference (IWCMC), 2013 9th International, pages 1064–1069. IEEE, 2013.
  • 178. 152 Bibliography [136] Huda Adibah Mohd Ramli, Kumbesan Sandrasegaran, Riyaj Basukala, Rachod Patacha- ianand, and Toyoba Sohana Afrin. Video Streaming Performance Under Well-Known Packet Scheduling Algorithms. International Journal of Wireless & Mobile Networks (IJWMN)l, 3:25–38, 2011. [137] Yasir Zaki, Thushara Weerawardane, Carmelita Gorg, and Andreas Timm-Giel. Multi- QoS-aware fair scheduling for LTE. In Vehicular technology conference (VTC spring), 2011 IEEE 73rd, pages 1–5. IEEE, 2011. [138] Li Chen, Bin Wang, Xiaohang Chen, Xin Zhang, and Dacheng Yang. Utility-based resource allocation for mixed traffic in wireless networks. In Computer Communications Workshops (INFOCOM WKSHPS), 2011 IEEE Conference on, pages 91–96. IEEE, 2011. [139] M Andrews, K. Kumaran, K. Ramanan, A. Stolyar, P. Whiting, and R. Vijayakumar. Providing quality of service over a shared wireless link. Communications Magazine, IEEE, 39(2):150–154, 2001. [140] K. Sandrasegaran R. Basukala, H. Mohd Ramli. Performance analysis of EXP/PF and M-LWDF in downlink 3GPP LTE system. In AH-ICI 2009. 1st Asian Himalayas International Conference on Internet, pages 1–5. IEEE, 2009. [141] Bilal Sadiq, Ritesh Madan, and Ashwin Sampath. Downlink scheduling for multi- class traffic in LTE. EURASIP Journal on Wireless Communications and Networking, 2009(14), 2009. [142] Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, Rossella Fortuna, and Pietro Camarda. Two-level downlink scheduling for real-time multimedia services in LTE networks. Multimedia, IEEE Transactions on, 13(5):1052–1065, 2011. [143] Huda Adibah Mohd Ramli, Riyaj Basukala, Kumbesan Sandrasegaran, and Rachod Patachaianand. Performance of well known packet scheduling algorithms in the downlink 3GPP LTE system. In Communications (MICC), 2009 IEEE 9th Malaysia International Conference on, pages 815–820. IEEE, 2009. [144] Sadiq Bilal, Madan Ritesh, and Sampath Ashwin. Downlink scheduling for multiclass traffic in LTE. EURASIP Journal on Wireless Communications and Networking, 2009, 2009. [145] Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, Francesco Capozzi, and Pietro Camarda. Simulating LTE cellular systems: An open-source framework. Vehicular Technology, IEEE Transactions on, 60(2):498–513, 2011. [146] TS 36.322 (V8.8.0): Evolved Universal Terrestrial Radio Access (E-UTRA), Radio Link Control (RLC) protocol specification(Release 8). Technical Specification, 3GPP, 2010. [147] Mohamed Hadi Habaebi Mohammed Abdul Jawad M. Al-Shibly and Md. Rafiqul Islam. Radio resource scheduling in LTE-Advanced system with Carrier Aggregation. ARPN Journal of Engineering and Applied Sciences, 10(22):17281–17285, 2015.
  • 179. Bibliography 153 [148] Sangchul Oh, JeeHyeon Na, and Dongseung Kwon. Performance Analysis of Cross Component Carrier Scheduling in LTE Small Cell Access Point System. In The Second International Conference on Electrical, Electronics, Computer Engineering and their Applications (EECEA2015), page 146, 2015. [149] Alberto Núñez, Jose L Vázquez-Poletti, Agustin C Caminero, Gabriel G Castañé, Jesus Carretero, and Ignacio M Llorente. iCanCloud: A flexible and scalable cloud infrastructure simulator. Journal of Grid Computing, 10(1):185–209, 2012. [150] Dominik Klein and Michael Jarschel. An OpenFlow extension for the OMNeT++ INET framework. In Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques, pages 322–329. ICST (Institute for Computer Sciences, Social- Informatics and Telecommunications Engineering), 2013. [151] András Varga and Rudolf Hornig. An overview of the OMNeT++ simulation envi- ronment. In Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems & workshops, page 60. ICST (In- stitute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2008. [152] TR 36.814 (V9.0.0): Further advancements for E-UTRA physical layer aspects (Release 9). Technical Specification Group Radio Access Network, 3GPP, 2010. [153] TR 36.942 (V10.2.0): Radio Frequency (RF) system scenarios (Release 10). Technical Specification, 3GPP, 2011. [154] Lotfi Asker Zadeh. Fuzzy sets. Information and control, 8(3):338–353, 1965. [155] Roland Sambuc. Fonctions and floues: application a l’aide au diagnostic en pathologie thyroidienne. Faculté de Médecine de Marseille, 1975. [156] Peide Liu and Fang Jin. A multi-attribute group decision-making method based on weighted geometric aggregation operators of interval-valued trapezoidal fuzzy numbers. Applied Mathematical Modelling, 36(6):2498–2509, 2012. [157] Chris Cornelis, Glad Deschrijver, and EE Kerre. Advances and challenges in interval- valued fuzzy logic. Fuzzy sets and systems, 157(5):622–627, 2006. [158] Behzad Ashtiani, Farzad Haghighirad, Ahmad Makui, et al. Extension of fuzzy topsis method based on interval-valued fuzzy sets. Applied Soft Computing, 9(2):457–461, 2009. [159] Shih-Hua Wei and Shyi-Ming Chen. Fuzzy risk analysis based on interval-valued fuzzy numbers. Expert Systems with Applications, 36(2):2285–2299, 2009. [160] Apurba Panda and Madhumangal Pal. A study on pentagonal fuzzy number and its corresponding matrices. Pacific Science Review B: Humanities and Social Sciences, Elsevier, 1(3):131–139, 2015. [161] Mu-Song Chen and Shinn-Wen Wang. Fuzzy clustering analysis for optimizing fuzzy membership functions. Fuzzy sets and systems, Elsevier, 103(2):239–254, 1999.
  • 180. 154 Bibliography [162] Marcos E Cintra, Heloisa A Camargo, and Maria Carolina Monard. Genetic generation of fuzzy systems with rule extraction using formal concept analysis. Information Sciences, Elsevier, 349:199–215, 2016. [163] Jin-Shyan Lee and Chih-Lin Teng. An enhanced hierarchical clustering approach for mobile sensor networks using fuzzy inference systems. IEEE Internet of Things Journal, 4(4):1095–1103, 2017. [164] Javier Andreu-Perez, Fan Cao, Hani Hagras, and Guang-Zhong Yang. A self-adaptive online brain machine interface of a humanoid robot through a general type-2 fuzzy inference system. IEEE Transactions on Fuzzy Systems, 2016. [165] Chengdong Li, Junlong Gao, Jianqiang Yi, and Guiqing Zhang. Analysis and design of functionally weighted single-input-rule-modules connected fuzzy inference systems. IEEE Transactions on Fuzzy Systems, 2016. [166] Thomas L Saaty. Decision making with dependence and feedback: The analytic network process. 1996. [167] ˙Ihsan Yüksel and Metin Dagdeviren. Using the analytic network process (anp) in a swot analysis–a case study for a textile firm. Information Sciences, 177(16):3364–3382, 2007. [168] Thomas L Saaty and Luis G Vargas. Diagnosis with dependent symptoms: Bayes theorem and the analytic hierarchy process. Operations Research, 46(4):491–502, 1998. [169] Tong Wu, Xin-Wang Liu, and Shu-Li Liu. A fuzzy anp with interval type-2 fuzzy sets approach to evaluate enterprise technological innovation ability. In Fuzzy Systems (FUZZ-IEEE), 2015 IEEE International Conference on, pages 1–8. IEEE, 2015. [170] Ching-Lai Hwang and Kwangsun Yoon. Multiple attribute decision making. Springer, 1981. [171] Emmanouil Skondras, Aggeliki Sgora, Angelos Michalas, and Dimitrios D Vergados. An analytic network process and trapezoidal interval-valued fuzzy technique for order preference by similarity to ideal solution network access selection method. International Journal of Communication Systems, 29(2):307–329, 2016. [172] Dimitris E Charilas, Ourania I Markaki, John Psarras, and Philip Constantinou. Appli- cation of fuzzy ahp and electre to network selection. In Mobile Lightweight Wireless Systems, pages 63–73. Springer, 2009. [173] Thereza Raquel Machado Azeredo, Helisamara Mota Guedes, Ricardo Alexandre Rebelo de Almeida, Tânia Couto Machado Chianca, and José Carlos Amado Martins. Efficacy of the manchester triage system: a systematic review. International emergency nursing, Elsevier, 23(2):47–52, 2015. [174] Hoe Tung Yew, Eko Supriyanto, Muhammad H Satria, and YW Hau. Adaptive network selection mechanism for telecardiology system in developing countries. In Biomedical and Health Informatics (BHI), 2016 IEEE-EMBS International Conference on, pages 94–97. IEEE, 2016.
  • 181. Bibliography 155 [175] Driss Aboutajdine Maroua Drissi, Mohammed Oumsis. A fuzzy ahp approach to network selection improvement in heterogeneous wireless networks. Networked Systems, pages 169–182. [176] Open street map (osm). https://www.openstreetmap.org, 2018. Accessed: 2018. [177] Michael Behrisch, Laura Bieker, Jakob Erdmann, and Daniel Krajzewicz. Sumo– simulation of urban mobility: an overview. In Proceedings of SIMUL 2011, The Third International Conference on Advances in System Simulation. ThinkMind, 2011. [178] Network simulator 3 (ns3). https://www.nsnam.org/, 2018. Accessed: 2018. [179] E Roszkowska and D Kacprzak. The fuzzy saw and fuzzy topsis procedures based on ordered fuzzy numbers. Information Sciences, 369:564–584, 2016. [180] Zhe Ren, Peter Fertl, Qi Liao, Federico Penna, and Slawomir Stanczak. Street-specific handover optimization for vehicular terminals in future cellular networks. In Vehicular Technology Conference (VTC Spring), 2013 IEEE 77th, pages 1–5. IEEE, 2013. [181] David González, Mario García-Lozano, Silvia Ruiz, and Dong Seop Lee. A metaheuristic-based downlink power allocation for lte/lte-a cellular deployments. Wire- less Networks, 20(6):1369–1386, 2014. [182] Soumaya Cherkaoui, Tarik Taleb, and Eugene David Ngangue Ndih. Improved inter- network handover for highly mobile users and vehicular networks. In Vehicular Technol- ogy Conference (VTC Spring), 2011 IEEE 73rd, pages 1–5. IEEE, 2011. [183] Suganthi Evangeline and Vinoth Babu Kumaravelu. Decision process for vertical handover in vehicular adhoc networks. In Microelectronic Devices, Circuits and Systems (ICMDCS), 2017 International conference on, pages 1–5. IEEE, 2017. [184] Francesco Guidolin, Irene Pappalardo, Andrea Zanella, and Michele Zorzi. Context- aware handover policies in hetnets. IEEE Transactions on Wireless Communications, 15(3):1895–1906, 2016. [185] Abhijit Sarma, Sandip Chakraborty, and Sukumar Nandi. Deciding handover points based on context-aware load balancing in a wifi-wimax heterogeneous network environ- ment. IEEE Transactions on Vehicular Technology, 65(1):348–357, 2016. [186] Shipra Kapoor, David Grace, and Tim Clarke. A base station selection scheme for handover in a mobility-aware ultra-dense small cell urban vehicular environment. In Personal, Indoor, and Mobile Radio Communications (PIMRC), 2017 IEEE 28th Annual International Symposium on, pages 1–5. IEEE, 2017. [187] Ali Safa Sadiq, Kamalrulnizam Abu Bakar, Kayhan Zrar Ghafoor, Jaime Lloret, and Rashid Khokhar. An intelligent vertical handover scheme for audio and video streaming in heterogeneous vehicular networks. Mobile Networks and Applications, 18(6):879–895, 2013. [188] Mohamed Lahby, Cherkaoui Leghris, and Abdellah Adib. New multi access selection method based on mahalanobis distance. Applied Mathematical Sciences, 6(53-56):2745– 2760, 2012.
  • 182. 156 Bibliography [189] Vishal Gupta. Network selection in 3g-wlan interworking environment using topsis. In Industrial and Information Systems (ICIIS), 2016 11th International Conference on, pages 512–517. IEEE, 2016. [190] Werner Toth and Harald Vacik. A comprehensive uncertainty analysis of the analytic hierarchy process methodology applied in the context of environmental decision making. Journal of Multi-Criteria Decision Analysis, 2018. [191] Mohamed Lahby, Cherkaoui Leghris, and Abdellah Adib. New multi access selection method using differentiated weight of access interface. In Communications and Infor- mation Technology (ICCIT), 2012 International Conference on, pages 237–242. IEEE, 2012. [192] KSS Anupama, S Sri Gowri, and B Prabakara Rao. Application of grey relational analysis to network selection: A case study. 2017. [193] Abudukeremu Kadier, Peyman Abdeshahian, Yibadatihan Simayi, Manal Ismail, Aidil Abdul Hamid, and Mohd Sahaid Kalil. Grey relational analysis for compara- tive assessment of different cathode materials in microbial electrolysis cells. Energy, 90:1556–1562, 2015. [194] Wei-Yu Chiu, Gary G Yen, and Teng-Kuei Juan. Minimum manhattan distance approach to multiple criteria decision making in multiobjective optimization problems. IEEE Transactions on Evolutionary Computation, 20(6):972–985, 2016. [195] Novi Sofia Fitriasari, Syifa Afifah Fitriani, and Rosa Ariani Sukamto. Comparison of weighted product method and technique for order preference by similarity to ideal solution method: Complexity and accuracy. In Science in Information Technology (ICSITech), 2017 3rd International Conference on, pages 453–458. IEEE, 2017. [196] Xingwei Wang, Dapeng Qu, Keqin Li, Hui Cheng, Sajal K Das, Min Huang, Renzheng Wang, and Shuliu Chen. A flexible and generalized framework for access network selection in heterogeneous wireless networks. Pervasive and Mobile Computing, 40:556– 576, 2017. [197] Lei Sun, Hui Tian, and Ping Zhang. Decision-making models for group vertical handover in vehicular communications. Telecommunication Systems, 50(4):257–266, 2012. [198] B Farhadinia. Sensitivity analysis in interval-valued trapezoidal fuzzy number linear programming problems. Applied Mathematical Modelling, 38(1):50–62, 2014. [199] Huiqiang Wang, Zhendong Wang, Guangsheng Feng, Hongwu LV, Xiaoming Chen, and Qiang Zhu. Intelligent access selection in cognitive networks: A fuzzy neural network approach. Journal of Computational Information Systems, 8(21):8877–8884, 2012. [200] Mun-Suk Kim and SuKyoung Lee. Group-based fast handover for pmipv6-based network mobility in vehicular networks. In Computer Communications Workshops (INFOCOM WKSHPS), 2015 IEEE Conference on, pages 113–114. IEEE, 2015.
  • 183. Bibliography 157 [201] Jonathan Prados-Garzon, Juan J Ramos-Munoz, Pablo Ameigeiras, Pilar Andres- Maldonado, and Juan M Lopez-Soler. Modeling and dimensioning of a virtualized mme for 5g mobile networks. IEEE Transactions on Vehicular Technology, 66(5):4383– 4395, 2017. [202] Mun-Suk Kim, SuKyoung Lee, and Nada Golmie. Enhanced fast handover for proxy mobile ipv6 in vehicular networks. Wireless Networks, 18(4):401–411, 2012. [203] Mun-Suk Kim, Sukyoung Lee, David Cypher, and Nada Golmie. Performance analysis of fast handover for proxy mobile ipv6. Information Sciences, 219:208–224, 2013. [204] Emna Bouzid Smida, Sonia Gaied Fantar, and Habib Youssef. Predictive handoff mechanism for video streaming in a cloud-based urban vanet. In Computer Systems and Applications (AICCSA), 2017 IEEE/ACS 14th International Conference on, pages 1170–1177. IEEE, 2017. [205] Massimo Dalla Cia, Federico Mason, Davide Peron, Federico Chiariotti, Michele Polese, Toktam Mahmoodi, Michele Zorzi, and Andrea Zanella. Mobility-aware handover strate- gies in smart cities. In Wireless Communication Systems (ISWCS), 2017 International Symposium on, pages 438–443. IEEE, 2017. [206] Ammar Gharaibeh, Mohammad A Salahuddin, Sayed Jahed Hussini, Abdallah Khreishah, Issa Khalil, Mohsen Guizani, and Ala Al-Fuqaha. Smart cities: A sur- vey on data management, security, and enabling technologies. IEEE Communications Surveys & Tutorials, 19(4):2456–2501, 2017. [207] Flavio Esposito, Anna Maria Vegni, Ibrahim Matta, and Alessandro Neri. On modeling speed-based vertical handovers in vehicular networks:“dad, slow down, i am watching the movie”. In GLOBECOM Workshops (GC Wkshps), 2010 IEEE, pages 11–15. IEEE, 2010. [208] Chi Ma, Enda Fallon, Yuansong Qiao, and Brian Lee. Optimizing media independent handover using predictive geographical information for vehicular based systems. In UKSim Fourth European Modelling Symposium on Computer Modelling and Simulation, pages 420–425. IEEE, 2010. [209] Sourav Dhar, Amitava Ray, and Rabindranath Bera. Cognitive vertical handover engine for vehicular communication. Peer-to-Peer Networking and Applications, 6(3):305–324, 2013. [210] Gul Muhammad Khan. Artificial neural network (anns). In Evolution of Artificial Neural Development, pages 39–55. Springer, 2018. [211] Guoxia Zhang and Fuqiang Liu. An auction approach to group handover with mobility prediction in heterogeneous vehicular networks. In ITS Telecommunications (ITST), 2011 11th International Conference on, pages 584–589. IEEE, 2011. [212] Rahul Garg and Sanjiv Kapoor. Auction algorithms for market equilibrium. Mathematics of Operations Research, 31(4):714–729, 2006.
  • 184. 158 Bibliography [213] Faisal Riaz, Rehana Asif, Hina Sajid, and Muaz A Niazi. Augmenting autonomous vehic- ular communication using the appreciation emotion: A mamdani fuzzy inference system model. In Frontiers of Information Technology (FIT), 13th International Conference on, pages 178–184. IEEE, 2015. [214] Johann Marquez-Barja, Carlos T Calafate, Juan-Carlos Cano, and Pietro Manzoni. A geolocation-based vertical handover decision algorithm for vehicular networks. In Local Computer Networks (LCN), 2012 IEEE 37th Conference on, pages 360–367. IEEE, 2012. [215] Johann M Marquez-Barja, Hamed Ahmadi, Sergio M Tornell, Carlos T Calafate, Juan- Carlos Cano, Pietro Manzoni, and Luiz A DaSilva. Breaking the vehicular wireless communications barriers: Vertical handover techniques for heterogeneous networks. IEEE Transactions on Vehicular Technology, 64(12):5878–5890, 2015. [216] Wei-Kuo Chiang and Shih-Chieh Chien. Deploying the media independent information service at the edge of next-generation network. In Electronics Information and Emer- gency Communication (ICEIEC), 2015 5th International Conference on, pages 182–185. IEEE, 2015. [217] Mohamed Ben Brahim, Zeeshan Hameed Mir, Wassim Znaidi, Fethi Filali, and Noured- dine Hamdi. Qos-aware video transmission over hybrid wireless network for connected vehicles. IEEE Access, 5:8313–8323, 2017. [218] Rabe Arshad, Hesham ElSawy, Sameh Sorour, Tareq Y Al-Naffouri, and Mohamed-Slim Alouini. Velocity-aware handover management in two-tier cellular networks. IEEE Transactions on Wireless Communications, 16(3):1851–1867, 2017. [219] Lu Zhang, Lu Ge, Xin Su, and Jie Zeng. Fuzzy logic based vertical handover algorithm for trunking system. In Wireless and Optical Communication Conference (WOCC), 2017 26th, pages 1–5. IEEE, 2017. [220] Aymen Ben Zineb, Mohamed Ayadi, and Sami Tabbane. Fuzzy madm based vertical handover algorithm for enhancing network performances. In Software, Telecommuni- cations and Computer Networks (SoftCOM), 2015 23rd International Conference on, pages 153–159. IEEE, 2015. [221] Kang-Won Lee, Won-Kyeong Seo, You-Ze Cho, Jong-Woo Kim, Jin-Soo Park, and Byoung-Sub Moon. Inter-domain handover scheme using an intermediate mobile access gateway for seamless service in vehicular networks. International Journal of Communication Systems, 23(9-10):1127–1144, 2010. [222] Alexander Magnano, Xin Fei, Azzedine Boukerche, and Antonio AF Loureiro. A novel predictive handover protocol for mobile ip in vehicular networks. IEEE Transactions on Vehicular Technology, 65(10):8476–8495, 2016. [223] Bayrem Triki, Slim Rekhis, and Noureddine Boudriga. Secure and qos-aware sip han- dover for voip communication in vehicular adhoc networks. In Wireless Communications and Mobile Computing Conference (IWCMC), 2011 7th International, pages 695–700. IEEE, 2011.
  • 185. Bibliography 159 [224] Ashraf A Ali and Khalid Al-Begain. Ip multimedia subsystem and sip signaling perfor- mance metrics. In Multimedia Services and Applications in Mission Critical Communi- cation Systems, pages 19–35. IGI Global, 2017. [225] U Kumaran and RS Shaji. Vertical handover in vehicular ad-hoc network using mul- tiple parameters. In Control, Instrumentation, Communication and Computational Technologies (ICCICCT), 2014 International Conference on, pages 1059–1064. IEEE, 2014. [226] Ming-Chin Chuang and Meng Chang Chen. Nash: Navigation-assisted seamless han- dover scheme for smart car in ultradense networks. IEEE Transactions on Vehicular Technology, 67(2):1649–1659, 2018. [227] Hayoung Oh and Chong-kwon Kim. A robust handover under analysis of unexpected vehicle behaviors in vehicular ad-hoc network. In Vehicular Technology Conference (VTC 2010-Spring), 2010 IEEE 71st, pages 1–7. IEEE, 2010. [228] Hayoung Oh. Mobility-aware video streaming in mimo-capable heterogeneous wireless networks. Mathematical Problems in Engineering, 2016, 2016. [229] André Almeida, Nuno Lopes, and Alexandre Santos. Intelligent handover for vehicular networks. In Software, Telecommunications and Computer Networks (SoftCOM), 2014 22nd International Conference on, pages 298–304. IEEE, 2014. [230] José Antonio Olivera, Ismael Cortázar, Carolina Pinart, Alberto Los Santos, and Iván Lequerica. Vanba: a simple handover mechanism for transparent, always-on v2v communications. In Vehicular Technology Conference, 2009. VTC Spring 2009. IEEE 69th, pages 1–5. IEEE, 2009. [231] Laurence Banda, Mjumo Mzyece, and Guillaume Nóel. Fast handover management in ip-based vehicular networks. In Industrial Technology (ICIT), 2013 IEEE International Conference on, pages 1279–1284. IEEE, 2013. [232] Jasmine P Valera and Sunguk Lee. Security measures in overcoming mobile ipv6 security issues. International Journal of Database Theory and Application, 9(7):297–304, 2016. [233] H. Takahashi and T. Minohara. Enhancing location privacy in mobile ipv6 by using redundant home agents. In 2012 IEEE International Conference on Pervasive Computing and Communications Workshops, pages 451–454, March 2012. [234] Yuqing Zhu, Weili Wu, and Deying Li. Efficient client assignment for client-server systems. IEEE Transactions on Network and Service Management, 13(4):835–847, 2016. [235] Luis Diego Briceno, Howard Jay Siegel, Anthony A Maciejewski, Ye Hong, Brad Lock, Charles Panaccione, Fadi Wedyan, Mohammad Nayeem Teli, and Chen Zhang. Resource allocation in a client/server system for massive multi-player online games. IEEE Transactions on Computers, 63(12):3127–3142, 2014. [236] Hiroshi Nishida and Thinh Nguyen. Optimal client-server assignment for internet distributed systems. IEEE Transactions on Parallel and Distributed Systems, 24(3):565– 575, 2013.
  • 186. 160 Bibliography [237] Farkhana Muchtar, Abdul Hanan Abdullah, Suhaidi Hassan, and Farhan Masud. Energy conservation strategies in host centric networking based manet: A review. Journal of Network and Computer Applications, 2018. [238] Christian Dannewitz, Dirk Kutscher, BöRje Ohlman, Stephen Farrell, Bengt Ahlgren, and Holger Karl. Network of information (netinf)–an information-centric networking architecture. Computer Communications, Elsevier, 36(7):721–735, 2013. [239] Hongbin Luo, Hongke Zhang, Moshe Zukerman, and Chunming Qiao. An incrementally deployable network architecture to support both data-centric and host-centric services. IEEE Network, 28(4):58–65, 2014. [240] Bengt Ahlgren, Christian Dannewitz, Claudio Imbrenda, Dirk Kutscher, and Borje Ohlman. A survey of information-centric networking. IEEE Communications Magazine, 50(7), 2012. [241] Haolin Guo, Dewan Tanvir Ahmed, and Abdulmotaleb El Saddik. Web services for vanet: a service oriented architecturefor infotainment system based on mashup using open apis. In Proceedings of the third ACM international symposium on Design and analysis of intelligent vehicular networks and applications, pages 61–68. ACM, 2013. [242] Wei-Tek Tsai, Xin Sun, and Janaka Balasooriya. Service-oriented cloud computing architecture. In Information Technology: New Generations (ITNG), 2010 Seventh International Conference on, pages 684–689. IEEE, 2010. [243] Xiang Sun and Nirwan Ansari. Dynamic resource caching in the iot application layer for smart cities. IEEE Internet of Things Journal, 5(2):606–613, 2018. [244] Jyoti Deogirikar and Amarsinh Vidhate. An improved publish-subscribe method in appli- cation layer protocol for iot. In 2017 International Conference On Smart Technologies For Smart Nation (SmartTechCon), pages 1070–1075. IEEE, 2017. [245] Zubaida Alazawi, Saleh Altowaijri, Rashid Mehmood, and Mohmmad B Abdljabar. Intelligent disaster management system based on cloud-enabled vehicular networks. In ITS Telecommunications (ITST), 2011 11th International Conference on, pages 361–368. IEEE, 2011. [246] Weijing Qi, Qingyang Song, Xiaojie Wang, Lei Guo, and Zhaolong Ning. Sdn-enabled social-aware clustering in 5g-vanet systems. IEEE Access, 6:28213–28224, 2018. [247] Hamada Alshaer. An overview of network virtualization and cloud network as a service. International Journal of Network Management, 25(1):1–30, 2015. [248] Navid Nikaein, Raymond Knopp, Lionel Gauthier, Eryk Schiller, Torsten Braun, Do- minique Pichon, Christian Bonnet, Florian Kaltenberger, and Dominique Nussbaum. Closer to cloud-ran: Ran as a service. In Proceedings of the 21st Annual International Conference on Mobile Computing and Networking, pages 193–195. ACM, 2015. [249] Rastin Pries, Hans-Jochen Morper, Nandor Galambosi, and Michael Jarschel. Network as a service-a demo on 5g network slicing. In Teletraffic Congress (ITC 28), 2016 28th International, volume 1, pages 209–211. IEEE, 2016.
  • 187. Bibliography 161 [250] Hiroki Nishiyama, Thuan Ngo, Shoki Oiyama, and Nei Kato. Relay by smart de- vice: Innovative communications for efficient information sharing among vehicles and pedestrians. IEEE Vehicular Technology Magazine, 10(4):54–62, 2015. [251] TS 36.839 version 11.1.0: Mobility enhancements in heterogeneous networks (Release 11). Technical Specification, 3GPP, 2012. [252] Jae-Wook Lee and Sang-Jo Yoo. Probabilistic path and data capacity based handover decision for hierarchical macro-and femtocell networks. Mobile Information Systems, 2016, 2016. [253] Arvind Merwaday and Ismail Güvenç. Handover count based velocity estimation and mo- bility state detection in dense hetnets. IEEE Transactions on Wireless Communications, 15(7):4673–4688, 2016. [254] Hellenic telecommunications and post commission (eett). http://keraies.eett.gr/, 2018. Accessed: 2018. [255] Raman Kumar Goyal, Sakshi Kaushal, and Arun Kumar Sangaiah. The utility based non-linear fuzzy ahp optimization model for network selection in heterogeneous wireless networks. Applied Soft Computing, 2017. [256] John Riordan. Introduction to combinatorial analysis. Courier Corporation, 2012. [257] Emmanouil Skondras, Angelos Michalas, and Dimitrios D Vergados. A survey on medium access control schemes for 5g vehicular cloud computing systems. In 2018 Global Information Infrastructure and Networking Symposium (GIIS), pages 1–5. IEEE, 2018. [258] Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, and Dimitrios D Vergados. A downlink scheduler supporting real time services in lte cellular networks. In 2015 6th International Conference on Information, Intelligence, Systems and Applications (IISA), pages 1–6. IEEE, 2015. [259] Emmanouil Skondras, Angelos Michalas, Angeliki Sgora, and Dimitrios D Vergados. A qos aware three level scheduler for the lte downlink. In 2015 Wireless Telecommunica- tions Symposium (WTS), Poster Session, pages 1–2. IEEE, 2015. [260] Emmanouil Skondras, Angelos Michalas, Aggeliki Sgora, and Dimitrios D Vergados. Qos-aware scheduling in lte-a networks with sdn control. In 2016 7th International Conference on Information, Intelligence, Systems & Applications (IISA), pages 1–6. IEEE, 2016. [261] Emmanouil Skondras, Angelos Michalas, Nikolaos Tsolis, Aggeliki Sgora, and Dim- itrios D Vergados. A network selection scheme for healthcare vehicular cloud computing systems. In 2017 8th International Conference on Information, Intelligence, Systems & Applications (IISA), pages 1–6. IEEE, 2017. [262] Emmanouil Skondras, Angelos Michalas, and Dimitrios D Vergados. Mobility manage- ment on 5g vehicular cloud computing systems. Vehicular Communications, 16:15–44, 2019.
  • 189. Appendix A The positions of the available networks In this appendix the positions and the spectrum of the available access networks are presented. Table A1 The positions of the available LTE Access Networks. Network Position Geographic Latitude Geographic Longitude Downlink & Uplink Spectrum in MHz (LTE Band) LTE Macro 1 2e 37.948056 23.643056 1805-1825 & 1710-1730 (3) LTE Macro 2 2l 37.947500 23.650278 2150-2170 & 1960-1980 (1) LTE Macro 3 3p 37.946667 23.653611 2130-2150 & 1940-1960 (1) LTE Macro 4 4i 37.946111 23.646389 2110-2130 & 1920-1940 (1) LTE Macro 5 5q 37.945556 23.654167 1805-1825 & 1710-1730 (3) LTE Macro 6 6f 37.945000 23.644444 1825-1845 & 1730-1750 (3) LTE Macro 7 8f 37.942778 23.643611 1845-1865 & 1750-1770 (3) LTE Macro 8 8t 37.942778 23.656944 1825-1845 & 1730-1750 (3) LTE Macro 9 9l 37.941944 23.649444 925-945 & 880-900 (8) LTE Macro 10 11c 37.940000 23.641111 1805-1825 & 1710-1730 (3) LTE Macro 11 11l 37.939722 23.648611 778-798 & 723-743 (28) LTE Macro 12 11t 37.939722 23.656111 2150-2170 & 1960-1980 (1) LTE Macro 13 12i 37.939722 23.645833 758-778 & 703-723 (28) LTE Macro 14 12y 37.938333 23.661389 1845-1865 & 1750-1770 (3) LTE Macro 15 14q 37.938056 23.653889 2110-2130 & 1920-1940 (1) LTE Macro 16 14v 37.937222 23.658333 2130-2150 & 1940-1960 (1) LTE Macro 17 16b 37.936667 23.640000 2110-2130 & 1920-1940 (1) LTE Macro 18 16h 37.936667 23.645556 1825-1845 & 1730-1750 (3) LTE Macro 19 18c 37.934722 23.640833 2130-2150 & 1940-1960 (1) LTE Macro 20 18f 37.934444 23.643889 2150-2170 & 1960-1980 (1) LTE Femto 1 4f 37.946944 23.644444 925-945 & 880-900 (8) LTE Femto 2 4j 37.946111 23.647222 758-778 & 703-723 (28) LTE Femto 3 4r 37.946389 23.655000 925-945 & 880-900 (8) LTE Femto 4 5d 37.945833 23.641944 758-778 & 703-723 (28) LTE Femto 5 5j 37.945556 23.647500 778-798 & 723-743 (28) LTE Femto 6 6h 37.944444 23.645833 2180-2200 & 2000-2020 (23) LTE Femto 7 6i 37.944444 23.646667 1475.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 8 7h 37.944167 23.645833 860-875 & 815-830 (18) LTE Femto 9 7i 37.943889 23.647222 2130-2150 & 1940-1960 (1) LTE Femto 10 7k 37.943889 23.648056 2180-2200 & 2000-2020 (23) LTE Femto 11 8k 37.942778 23.648611 1475.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 12 8m 37.942500 23.650556 2180-2200 & 2000-2020 (23) LTE Femto 13 9e 37.941667 23.643333 860-875 & 815-830 (18) LTE Femto 14 9g 37.942222 23.645000 2180-2200 & 2000-2020 (23) LTE Femto 15 9h 37.941944 23.645833 860-875 & 815-830 (18) LTE Femto 16 9j 37.942222 23.647778 2180-2200 & 2000-2020 (23) LTE Femto 17 9n 37.942222 23.651111 1475.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 18 10e 37.941944 23.643333 2130-2150 & 1940-1960 (1) LTE Femto 19 10f 37.941389 23.644167 2180-2200 & 2000-2020 (23) LTE Femto 20 10g 37.941111 23.644444 860-875 & 815-830 (18) LTE Femto 21 10h 37.941389 23.645833 2180-2200 & 2000-2020 (23) LTE Femto 22 10j 37.941389 23.647500 860-875 & 815-830 (18) LTE Femto 23 10l 37.941111 23.649722 1475.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 24 11e 37.940556 23.643056 1475.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 25 11f 37.940278 23.643611 860-875 & 815-830 (18) LTE Femto 26 11h 37.940833 23.645833 1475.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 27 12k 37.940000 23.648889 1180-2200 & 2000-2020 (23) LTE Femto 28 13c 37.939444 23.641111 1475.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 29 13e 37.938333 23.642778 925-945 & 880-900 (8) LTE Femto 30 13j 37.939444 23.648333 1175.9-1495.9 & 1427.9-1447.9 (11) LTE Femto 31 14d 37.938333 23.642222 1180-2200 & 2000-2020 (23) LTE Femto 32 14n 37.938333 23.650556 1805-1825 & 1710-1730 (3) LTE Femto 33 15b 37.937222 23.639722 925-945 & 880-900 (8) LTE Femto 34 15c 37.937222 23.640833 778-798 & 723-743 (28) LTE Femto 35 15u 37.936944 23.657778 925-945 & 880-900 (8) LTE Femto 36 16c 37.936389 23.641111 860-875 & 815-830 (18) LTE Femto 37 18h 37.934444 23.645278 925-945 & 880-900 (8)
  • 190. 164 The positions of the available networks Table A2 The positions of the available WiMAX Access Networks. Network Position Geographic Latitude Geographic Longitude Downlink & Uplink Spectrum in MHz (WiMAX 2 Band) WiMAX Macro 1 1e 37.949444 23.642500 3500-3510 & 3400-3410 (5L) WiMAX Macro 2 3e 37.947778 23.643333 3510-3520 & 3410-3420 (5L) WiMAX Macro 3 3j 37.947222 23.647500 3530-3540 & 3430-3440 (5L) WiMAX Macro 4 3o 37.947222 23.652778 3540-3550 & 3440-3450 (5L) WiMAX Macro 5 6r 37.944722 23.655000 3590-3600 & 3490-3600 (5L) WiMAX Macro 6 8g 37.943333 23.645278 3590-3600 & 3490-3600 (5L) WiMAX Macro 7 11d 37.940833 23.641944 3500-3510 & 3400-3410 (5L) WiMAX Macro 8 11l 37.940556 23.649722 3530-3540 & 3430-3440 (5L) WiMAX Macro 9 11n 37.940000 23.651389 3540-3550 & 3440-3450 (5L) WiMAX Macro 10 11r 37.940278 23.655278 3550-3560 & 3450-3460 (5L) WiMAX Macro 11 12j 37.939494 23.648333 3510-3520 & 3410-3420 (5L) WiMAX Macro 12 12u 37.939444 23.657778 3500-3510 & 3400-3410 (5L) WiMAX Macro 13 14e 37.938056 23.643333 3580-3590 & 3480-3490 (5L) WiMAX Macro 14 14v 37.937222 23.658611 3510-3520 & 3410-3420 (5L) WiMAX Macro 15 17b 37.935833 23.639722 3540-3550 & 3440-3450 (5L) WiMAX Macro 16 18c 37.934722 23.640833 3530-3540 & 3430-3440 (5L) WiMAX Macro 17 18i 37.934444 23.645278 2305-2315 & 2345-2355 (2) WiMAX Femto 1 3f 37.947500 23.644444 3520-3530 & 3420-3430 (5L) WiMAX Femto 2 5g 37.945278 23.644167 3550-3560 & 3450-3460 (5L) WiMAX Femto 3 6e 37.945000 23.642222 3560-3570 & 3460-3470 (5L) WiMAX Femto 4 6g 37.944444 23.645278 3570-3580 & 3470-3480 (5L) WiMAX Femto 5 6j 37.944444 23.647222 3580-3500 & 3480-3490 (5L) WiMAX Femto 6 7j 37.943889 23.647778 3520-3530 & 3420-3430 (5L) WiMAX Femto 7 8h 37.942222 23.646111 2305-2315 & 2345-2355 (2) WiMAX Femto 8 8k 37.942500 23.648056 3550-3560 & 3450-3460 (5L) WiMAX Femto 9 8n 37.942778 23.651389 3520-3530 & 3420-3430 (5L) WiMAX Femto 10 9g 37.942222 23.645278 2305-2315 & 2345-2355 (2) WiMAX Femto 11 9i 37.941667 23.646389 3550-3560 & 3450-3460 (5L) WiMAX Femto 12 9j 37.941944 23.647500 2305-2315 & 2345-2355 (2) WiMAX Femto 13 9m 37.942222 23.651111 2305-2315 & 2345-2355 (2) WiMAX Femto 14 10f 37.941389 23.644167 3520-3530 & 3420-3430 (5L) WiMAX Femto 15 10h 37.941389 23.645833 3520-3530 & 3420-3430 (5L) WiMAX Femto 16 10j 37.941389 23.647500 3550-3560 & 3450-3460 (5L) WiMAX Femto 17 10m 37.941389 23.650000 3520-3530 & 3420-3430 (5L) WiMAX Femto 18 10s 37.941389 23.655556 3520-3530 & 3420-3430 (5L) WiMAX Femto 19 11f 37.940278 23.643333 2305-2315 & 2345-2355 (2) WiMAX Femto 20 11h 37.940556 23.645556 2305-2315 & 2345-2355 (2) WiMAX Femto 21 11k 37.939722 23.648611 2305-2315 & 2345-2355 (2) WiMAX Femto 22 12k 37.929167 23.648056 3520-3530 & 3420-3430 (5L) WiMAX Femto 23 15b 37.937222 23.640000 2305-2315 & 2345-2355 (2) WiMAX Femto 24 15d 37.936944 23.641667 3520-3530 & 3420-3430 (5L) WiMAX Femto 25 15u 37.936944 23.657778 2305-2315 & 2345-2355 (2) Table A3 The positions of the available WAVE Access Networks. Network Position Geographic Latitude Geographic Longitude Spectrum in MHz (DSRC Europe Band) WAVE 1 2f 37.948056 23.644444 5915-5925 (SCH4) WAVE 2 2h 37.947500 23.646389 5905-5915 (SCH3) WAVE 3 3m 37.946667 23.650278 5895-5905 (SCH2) WAVE 4 4e 37.946111 23.642500 5895-5905 (SCH2) WAVE 5 4u 37.945556 23.658056 5875-5885 (SCH1) WAVE 6 5i 37.945000 23.646944 5915-5925 (SCH4) WAVE 7 6k 37.944167 23.648056 5905-5915 (SCH3) WAVE 8 7e 37.943056 23.643333 5875-5885 (SCH1) WAVE 9 7i 37.943889 23.646667 5895-5905 (SCH2) WAVE 10 7n 34.943889 23.651111 5875-5885 (SCH1) WAVE 11 9h 37.942222 23.646389 5915-5925 (SCH4) WAVE 12 10e 37.941667 23.643333 5895-5905 (SCH2) WAVE 13 10j 37.941667 23.647500 5875-5885 (SCH1) WAVE 14 10n 37.941111 23.651667 5905-5915 (SCH3) WAVE 15 11h 37.940556 23.645556 5905-5915 (SCH3) WAVE 16 12c 37.939444 23.641389 5875-5885 (SCH1) WAVE 17 12q 37.938889 23.654444 5875-5885 (SCH1) WAVE 18 14b 37.938056 23.640556 5915-5925 (SCH4) WAVE 19 14f 37.937778 23.644167 5905-5915 (SCH3) WAVE 20 17c 37.935000 23.641389 5895-5905 (SCH2) WAVE 21 17n 37.935278 23.651389 5895-5905 (SCH2) WAVE 22 18i 37.934722 23.645278 5875-5885 (SCH1)
  • 191. Appendix B The available networks per SLA In this appendix the available networks per SLA are presented.
  • 192. 166 The available networks per SLA TableB1TheavailableLTEnetworksofSLA1. SLA1 NAVVoIPCVBSWeb Network Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price LTEMacro1AGAGGVGMGGAPAGAGGVGGVGVPGVGGMGMGMAPMMGAGMGAGPAGAGGVGVGAGAP LTEMacro2VGAGGGAGAGAPMMGMGMGMPAGAGMVGMMGAPMGGMGMMGAGVPVGAGGGGAGP LTEMacro3VGAGMGMGVPMMGMGMMGVGVPMGGGMVGMGVPGVGMGMGVGMPVGAGGGMAGVP LTEMacro4MMGMMVGAGPMMGMGMGGPVGAGAGGVGAGPAGAGMVGMGGPMGGMGMGGVP LTEMacro5AGAGVGVGVGAGVPAGAGVGVGMVGAPGVGAGMGAGMAPMGGVGMGAGGVPGVGAGMGMGVP LTEMacro6MMGGMVGGPMGGMGMVGMGAPVGAGAGGGMGVPGGVGMGVGVGPAGAGVGVGVGAGVP LTEMacro7MGGMGMAGGVPMGGGMMVGVPMGGGMMMGPVGAGAGGGMGPAGAGGVGGVGP LTEMacro8MGGAGMGAGMPAGAGGVGAGAGAPAGAGAGVGAGGPGGMMGAGAGPGVGMGMGVGAGAP LTEMacro9MMGVGMAGMVPMMGAGMMGMAPGVGGMGMGVGPVGAGVGGVGVGPMMGVGMAGAGP LTEMacro10MGGAGMGMGMGAPAGAGMVGVGMPGVGGMGMAGVPGVGGMGAGAGPGVGMGMGGGVP LTEMacro11MMGVGMVGMGVPMMGMGMAGMGVPGVGGMGMVGAPMMGMGMGGPGGMGMGGVGAP LTEMacro12MMGMMVGGAPVGAGAGGGMGAPVGAGGGAGGVPAGAGMGVGGVGAPAGAGVGVGMGMGP LTEMacro13VGAGMGGGMGAPMMGMMMGMGPAGAGVGVGGMPAGAGVGVGMGGAPVGAGVGGVGAGAP LTEMacro14VGAGAGGMGMAPAGAGVGVGVGGPVGAGGGGAGVPVGAGGGGMAPGVGGMGGAGAP LTEMacro15MMGMGMGVGPAGAGGVGGMPMMGGMVGVGAPMMGAGMVGAGVPAGAGMVGVGGAP LTEMacro16AGAGMGVGAGVGVPVGAGVGGMGMGPVGAGAGGAGMGVPGGMGMGAGMPGVGMGMGGVGP LTEMacro17GVGMGMGMGMVPAGAGAGVGAGMPGVGVGMGMGAGPGVGVGMGGAGAPVGAGVGGGMGAP LTEMacro18MGGMGMGGVPVGAGGGVGVGVPGVGGMGAGMGAPMGGMGMVGMGAPMMGAGMGGVP LTEMacro19AGAGMGVGAGVGVPMGGMGMGMVPGVGAGMGGGPGVGMMGVGMGAPVGAGVGGVGVGP LTEMacro20MMGMGMAGAGVPMGGGMMGPMGGGMAGMGVPGVGGMGMGMAPMGGAGMVGVGP LTEFemto1MGGAGMMGMPVGAGMGVGMVPMGGVGMVGAGAPVGAGMGGVGVPGVGMGMGAGGVP LTEFemto2VGAGMGMMAPAGAGGVGMMAPMGGMMVGMGAPMGGMMVGMGPGVGMGMGGMGP LTEFemto3AGAGMGVGVGMGPAGAGGVGAGVGVPGVGGMGVGGPAGAGVGVGGGVPVGAGMGGMGVGAP LTEFemto4MGGAGMVGAGVPGVGVGMGVGAGVPGVGGMGAGMGVPMGGGMMAGAPAGAGGVGMGGVP LTEFemto5MGGMMGGVPMMGMGMAGMPVGAGAGGVGAGAPVGAGAGGGVGPGVGVGMGAGVGP LTEFemto6AGAGMVGVGVGAPAGAGAGVGMGMPMMGAGMGVGAPMMGMGMVGAGAPMGGGMMGAGP LTEFemto7MGGMMMMGAPVGAGVGGVGMVPAGAGGVGMGMGAPMGGMGMVGVGPAGAGGVGAGGP LTEFemto8MMGAGMMGMVPAGAGMVGMMVPAGAGAGVGGAGPGVGGMGMGMPAGAGAGVGVGGAP LTEFemto9GVGMMGAGVGVPMGGGMMMGAPGVGMGMGMGMGAPMGGGMMGAGPMMGMGMMGAGAP LTEFemto10VGAGAGGGMAPVGAGVGGVGVGVPAGAGVGVGMGAGAPVGAGMGAGMGAPVGAGVGGGAGAP LTEFemto11AGAGGVGVGAGPAGAGGVGMMGAPGGMMGMMPAGAGGVGMGMPAGAGGVGMGVGVP LTEFemto12MGGMMVGMGPMMGVGMVGAGAPMGGAGMGGAPAGAGMGVGGGAPMMGGMVGVGP LTEFemto13MGGMGMMMPVGAGMGMMVPAGAGMVGAGGVPMGGAGMGMGVPAGAGGVGGMGAP LTEFemto14GVGMMGMAGVPMGGGMAGGVPVGAGVGGVGMGVPAGAGMVGMGGVPGVGMGMGGAGAP LTEFemto15MGGGMGGAPMGGGMAGMGPMMGAGMAGMVPMGGMGMGAGAPVGAGMGGMGMGVP LTEFemto16VGAGMGVGMGVPAGAGMVGAGGVPGVGMGMGGMGPGGMGGAGVGVPAGAGMVGMAGAP LTEFemto17VGAGMGAGVGPVGAGAGGVGMGVPMGGAGMVGVGPAGAGVGVGGMAPGGMGMGGVGAP LTEFemto18MGGMMVGGPGVGMMGMGGVPVGAGMGGAGMGPGVGMGMGVGMGAPGVGVGMGVGAGVP LTEFemto19VGAGGGAGMPVGAGAGGGAGAPAGAGMVGVGMAPVGAGGGGGPVGAGMGGMGGP LTEFemto20GVGGMGMGAGAPMMGMGMMGMVPVGAGAGGMGMGAPVGAGVGGGGVPMGGGMGMGVP LTEFemto21MMGGMVGAGVPMMGMMMGAGAPGVGGMGMGVGAPMMGGMMGMAPVGAGMGGVGMGP LTEFemto22AGAGMGVGVGAGVPGVGMGMGAGVGVPAGAGAGVGVGAGPMMGVGMGGPMGGVGMMMVP LTEFemto23MMGGMMAGPAGAGMVGMGAGAPAGAGMGVGGMGPGVGAGMGVGGAPMMGMMAGGP LTEFemto24MGGMGMAGAGAPAGAGMGVGMMVPMGGMGMGGAPMMGVGMMGPVGAGMGGAGGP LTEFemto25GVGAGMGGMGAPGVGGMGMGMGVPAGAGAGVGVGVGPVGAGAGGGGAPAGAGAGVGVGAGVP LTEFemto26GVGGMGMGVPMGGAGMGGVPAGAGMVGGGVPGVGGMGVGGVPMMGVGMGVGAP LTEFemto27MGGGMGMAPVGAGGGVGAGPMGGGMGAGAGVPGVGAGMGGVGPAGAGAGVGVGGAP LTEFemto28MMGGMMGGVPMGGGMGGVPMGGAGMGGAPGGVGMGGMGVPGVGVGMGGMGP LTEFemto29VGAGMGMMGAPAGAGVGVGVGAGPGVGMGMGMGMVPAGAGAGVGMGMGVPMMGVGMMGGAP LTEFemto30AGAGAGVGMAGVPGVGMMGMGMGAPMGGGMGGVPAGAGGVGGAGPMMGMMGGVP LTEFemto31VGAGAGGAGMGPAGAGVGVGVGAGAPMGGGMGMAPMMGMGMMGMAPAGAGGVGAGGAP LTEFemto32VGAGAGGVGMGAPGVGMMGGMGVPVGAGVGGMMGVPMGGMMMGGAPMMGMMVGMGVP LTEFemto33AGAGMGVGAGMGPGVGMMGMVGVPVGAGAGGGAGPVGAGGGVGVGVPGVGVGMGGVGP LTEFemto34AGAGGVGMGMGVPVGAGMGGMGMGPVGAGMGGMGVPMMGVGMAGAGVPMGGVGMGMP LTEFemto35VGAGGGMGMVPGVGMMGAGVGPVGAGVGGMGMGPVGAGGGMGAGPGVGGMGVGMP LTEFemto36GVGMMGMGGAPMGGVGMMGAGVPVGAGGGAGMGAPMGGVGMAGMGPGVGMGMGMGAP LTEFemto37GVGAGMGMMGPAGAGVGVGVGAGAPAGAGVGVGMGAPAGAGAGVGMGMGAPGVGVGMGVGMGP
  • 193. 167 TableB2TheavailableWiMAXandWAVEnetworksofSLA1. SLA1 NAVVoIPCVBSWeb Network Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price WiMAXMacro1MGGGMGVGPGVGVGMGVGGPMMGMMVGMPGGVGMGGMGAPMGGMMAGGAP WiMAXMacro2MGGMMMGGPMGGVGMMGGPAGAGGVGAGMGAPAGAGVGVGMGMAPGVGAGMGAGMP WiMAXMacro3GVGMGMGGGVPMGGMMVGMPVGAGMGGGMPMMGGMMGMVPVGAGMGGAGMVP WiMAXMacro4MGGMMAGVGVPMGGMMAGMGAPVGAGMGGVGMVPAGAGAGVGMGGPGVGMMGGAGAP WiMAXMacro5AGAGAGVGMGMVPVGAGGGMGAGPVGAGMGAGMAPMGGVGMGGPAGAGGVGMGVP WiMAXMacro6MMGMGMGMPMGGVGMVGVGAPVGAGGGVGMPGVGMGMGVGVGAPGVGGMGVGVGVP WiMAXMacro7AGAGGVGMVGAPAGAGMGVGVGGPGVGMGMGVGMAPGVGMMGAGGAPMGGMMAGGAP WiMAXMacro8MMGVGMAGMGVPVGAGMGGMGVGAPMMGVGMGGVPMGGGMGAGVPGVGMGMGMMGP WiMAXMacro9AGAGMVGMMGPMMGMMAGVGAPAGAGGVGGMVPMGGMGMGMAPMMGMGMAGGVP WiMAXMacro10MGGMMVGGPAGAGAGVGMGGVPAGAGGVGGMGVPGVGMMGMVGAPVGAGAGGGVGVP WiMAXMacro11MMGGMVGMGAPMGGAGMGMGPGVGMMGGMAPGVGVGMGVGGPMMGVGMVGGVP WiMAXMacro12GVGAGMGGMPAGAGVGVGGGPVGAGMGGAGAPVGAGGGGMGPVGAGGGMMGP WiMAXMacro13GVGMGMGAGMVPMMGVGMMGPAGAGVGVGVGGVPMMGAGMAGGAPGVGGMGAGAGVP WiMAXMacro14AGAGAGVGGMPMMGMMMVGPVGAGGGAGVGPMGGGMMVGAPMGGMGMGMGVP WiMAXMacro15VGAGVGGMGGAPAGAGGVGGMVPMGGVGMVGMGPMMGMMAGGPGVGGMGVGMGAP WiMAXMacro16MMGMMVGMGAPVGAGMGGMVGAPMMGMMMGMGAPGGVGMGVGGPAGAGAGVGGAGAP WiMAXMacro17MMGGMGAGAPMMGMGMAGAGVPMGGGMAGVGVPAGAGVGVGGMGAPVGAGVGGVGMGVP WiMAXFemto1VGAGAGGGMGAPMMGMMVGMGPMGGMGMGMGAPVGAGGGAGGAPGVGVGMGVGGP WiMAXFemto2MMGGMMGAGVPGVGAGMGAGAGPMMGMGMVGVGVPGVGMMGMVGVPMGGVGMGVGP WiMAXFemto3MMGGMAGGAPMMGAGMGMAPVGAGVGGGGAPMGGVGMMAGVPMMGMGMAGAGAP WiMAXFemto4MGGVGMMGVGPAGAGAGVGVGMGPGVGGMGMGMGVPMMGMMMMGPGGGMGGMAP WiMAXFemto5AGAGGVGGMVPVGAGMGGMGAGVPVGAGAGGAGVGVPVGAGMGVGVGPMGGMMMGMAP WiMAXFemto6MMGMGMGVGAPMGGAGMMMGPVGAGGGMGMAPMGGVGMGGVPAGAGGVGVGVGVP WiMAXFemto7MGGGMMGMVPMMGMMVGVGPGVGVGMGGVGPMMGGMGVGPAGAGVGVGGAGP WiMAXFemto8GVGGMGGMGAPVGAGMGGVGPAGAGMGVGAGGPVGAGAGGMGAGVPAGAGVGVGVGMGAP WiMAXFemto9MGGMGMVGMPMMGMMAGGAPMGGGMGMGVPMMGVGMAGMAPMGGMGMGGAP WiMAXFemto10AGAGAGVGMAGAPGVGAGMGMMGAPGVGMMGGAGVPVGAGGGVGGPAGAGAGVGMGMGP WiMAXFemto11MGGGMGAGPVGAGAGGVGGPAGAGAGVGMGGPAGAGVGVGGVGAPAGAGAGVGVGAGVP WiMAXFemto12GVGGMGAGVGPMMGMGMMMGAPMGGMGMVGGPGVGGMGVGAGVPGVGMGMGGMP WiMAXFemto13AGAGMGVGVGVGVPMMGAGMGMAPGVGVGMGGVGPAGAGVGVGGVGVPVGAGMGGMGMAP WiMAXFemto14AGAGVGVGMGAPAGAGMVGMMAPVGAGMGGMGGVPAGAGVGVGVGGAPMGGGMVGGAP WiMAXFemto15AGAGGVGGMGVPMGGVGMGMGVPGGMGMGGAGAPAGAGMVGMGGPGVGMMGMGMGP WiMAXFemto16MMGMMMGMVPGVGMMGGMAPVGGMGGGAGPVGAGMGGAGVGPAGAGAGVGAGGP WiMAXFemto17MMGGMMGMAPGVGVGMGMMAPGVGAGMGAGVGPMGGVGMVGAGVPVGAGAGGAGMGP WiMAXFemto18GVGAGMGMVGVPAGAGVGVGVGMVPVGAGGGMGGPMMGAGMGVGPVGAGVGGAGMVP WiMAXFemto19MMGMMGMVPAGAGMVGAGMVPAGAGGVGGMAPGVGMGMGGMGAPVGAGMGGVGP WiMAXFemto20GVGAGMGGAGVPMMGMMMMGAPGVGMGMGMAGPMGGGMVGGPMMGAGMVGVGAP WiMAXFemto21MGGMMMGAGPMMGMMMAGPMMGAGMMAGPGVGMMGVGGAPVGAGGGGGAP WiMAXFemto22VGAGAGGMGMAPGVGMMGMAGVPGVGGMGVGMAPMMGVGMMVGVPMGGMMGMGAP WiMAXFemto23MGGGMMGMAPVGAGAGGAGMVPMGGMGMGMGAPMGGGMGAGAPVGAGGGVGAGVP WiMAXFemto24GVGMMGVGGVPAGAGAGVGMGMGAPGVGMGMGMGMVPGVGAGMGGMGAPVGAGVGGGGP WiMAXFemto25MGGVGMMGVGAPVGAGGGVGGPMGGGMAGMGPVGAGAGGMGMGAPMGGAGMVGMGAP WAVE1AGAGGVGVGVGVPGVGVGMGAGAGPMGGMMVGGPMGGGMVGAGPVGAGGGAGMVP WAVE2VGAGMGGAGMGVPMGGMGMGMPVGAGAGGGMVPMMGVGMGVGAPMMGVGMVGMGP WAVE3VGAGMGMVGAPMMGGMVGVGVPAGAGMGVGVGMGVPMGGMMVGGPMGGGGMVGVP WAVE4AGAGAGVGAGAGPGVGMMGMGMGVPGGMMGAGGVPAGAGGVGAGMGVPGVGMGMGGVGAP WAVE5MMGMMAGVGAPMGGVGMVGAGAPGVGVGMGMGMGAPAGAGGVGMGMGPMMGAGMMGAP WAVE6MMGVGMGMGMVPGVGAGMGAGVGAPMMGGMMGGVPAGAGMVGGVGAPMGGGMGMGAP WAVE7MMGAGMMGVGVPVGAGMGGMGPVGAGVGGAGGVPAGAGVGVGGGPVGAGGGAGVGAP WAVE8MGGGMGMGMGVPMMGMMAGMGPVGAGAGGMMGAPAGAGGVGMMGPVGAGAGGGVGAP WAVE9MGGGMGGMPMMGMMVGMGVPMMGMMVGVGPAGAGMVGVGGAPMMGGMAGGP WAVE10MGGGMAGVGPMMGVGMAGMVPAGAGMVGMGGVPMMGGMMGGVPMGGVGMGAGAP WAVE11MMGGMGAGAPVGAGGGMMVPGVGGMGMGMGVPAGAGGVGAGMGVPVGAGGGVGMP WAVE12AGAGMGVGMVGVPAGAGVGVGVGGVPMMGVGMGVGVPVGAGMGGMGVGAPAGAGMVGGAGAP WAVE13MMGGMGMVPMGGVGMVGMGPAGAGGVGVGGVPVGAGMGGAGGAPAGAGVGVGVGVGP WAVE14AGAGAGVGGVGAPGVGVGMGGMAPGGGMGVGAGPMMGGMGMGPMGGMGMAGGVP WAVE15GVGGMGMMGVPAGAGVGVGGMGAPAGAGGVGAGMVPMMGVGMGMGPMGGGMGAGVP WAVE16VGAGMGMVGGVPGVGMGMGVGAGVPGVGAGMGGGAPVGAGAGGMGGAPGVGGMGAGGAP WAVE17MMGVGMVGVGPVGAGAGGMMGVPMMGGMAGMGVPVGAGMGGMGMAPVGAGGGAGVGP WAVE18GVGGMGMGAGAPMGGMMVGVGAPMGGMMVGGVPAGAGGVGAGGPMMGAGMVGGP WAVE19VGAGMGGMGMPGVGAGMGVGGAPVGAGGGAGGPMGGAGMMGVGAPAGAGAGVGMAGAP WAVE20MMGMMGGAPMGGAGMGMGVPVGAGMGGAGAGAPMMGMGMVGAGPMMGVGMAGAGVP WAVE21MMGVGMVGAGPGVGAGMGMGGAPGVGMMGMGMGPGVGGMGAGVGVPGVGMMGMGGP WAVE22MGGGMGMGGVPMGGGMGAGAPAGAGMGVGMGAGVPVGAGGGGMGVPAGAGGVGGAGAP
  • 194. 168 The available networks per SLA TableB3TheavailableLTEnetworksofSLA2,SLA3andSLA4. SLA2SLA3SLA4 CVBSWebBSWebWeb Network Throughput Delay Jitter PacketLoss ServiceReliability Secutiy Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price LTEMacro1GGGMGMGPPMPMMGPGMPPGGGMGGMPPMPMMGPMMPMPMPMGPMGMPMVPPVPAPVPPVG LTEMacro2MMGPMPMMPMMGGMMPMGMGGMPMGMPMGPPMPMPPPMPMMMGMPMPMPMGMGMMAPMPMPPG LTEMacro3MGGGMGMGMPPMPMPPPMMGGPMMPMPMPPPPPMMGMGPMMPGAPVPVPAPMVPAG LTEMacro4MMGPMPPMPMPGGPMGPGPMGGMMGMPMPMPPPPMMGMGMPMMGPMMMMPMPVPPAG LTEMacro5MPMMPPMMMGGGMMGGMMGGPMMGMMGMGMGMPMPMMMGPMPMMPMAPVPPAPAPPAG LTEMacro6MPMMPPGMGMGGGMGMPGMMMGGMPMGMPMPMGMGMPMMPPMMMGMPMPMPPGPMPMPVPVPPG LTEMacro7MGGGMPMPMMGMGMPMPMMMGPMPGMPMPMPPMPPMGMPMPPPPMAPVPVPAPAPVPVG LTEMacro8GGPMGPMPMGGPMGMGGMPMMGMMPGMPPMPPMPPMGMMGPMPMPMPMPMPAPVPVPMPAG LTEMacro9MGGPMMGMPMPMMGPGMPPMMGMGMPMGMGPPMPMPVPMPGPMPMVPPMPGPMPPVPPVPAG LTEMacro10GGGMGMMMMGGGMMPMGMPMPPPGMMPMPMPPMPPGPMPPPMMPMGPMPVPPAPMPVG LTEMacro11MMGMPMPPMGMPPMPMGPGPMGGPMGGGMPMPMGPPPMGMMGPMPMPPGPMPVPVPMPPAG LTEMacro12MPMGPMPGMMPMMGPMMGMPMPMPPMGMGPMPMMGPMMPMGMPMPPMPMMMPMVPPVPAPVG LTEMacro13GGGMGGMPMPPMPMGPMGGMPMPPMPPPMPPMPMGPMPMMPMPPVPPPGPMPPVPPVPVG LTEMacro14MMGMGMPGPMGGGMGPMMPPMPGPGGPMMGMMPPMPMPMPMGPMPPGPMPMVPMPAPG LTEMacro15MMGMGMPGMPPPMPMPMGMPMPMGGPMPPPPMPMPPPMMPMPPPVPGMPMPPPVPVG LTEMacro16MGGMPMPMGPGGMGMGMGPMMMGMGMPMMPMPMPMPPPMMMGPMPMPMMMPMPMPPG LTEMacro17MPMPPPGMPMPPPPMGPMMGPMPMPMGPPMPPPPMGPMPPPMPMMGPMPAPVPVPVPG LTEMacro18MGGMMMPMMPMGGMGMPMPMMMGGMPMGPPMPPPPMPGPMPPVPMPPGAPVPPAPPAPVG LTEMacro19MPMMPPMPMGGMPMGMGPMMPMMGPMPMGMMPMMPMPMPPMMPMMPPMPMPGMPMPPPMPAG LTEMacro20MGGMGMMMGMMMGGMPMGMMPMGGGMGMMMPMPPPMGMPMMPPMMGPMPAPPAPAPAG LTEFemto1PMPGPGMMPGGMMGMGPPMPMPPMPPPMPPPMGPMGMPMPPMPMMPMVPPAPVPG LTEFemto2PMPMPPMMGMPMMGPMPPMGMPMPMPMPGMMMMGPMPPMPGPMPPVPPPGPMPAPVPAPVPG LTEFemto3GGMGMGMGMMGGGMMPPPMPMMPPPMMPMPPPMPPMGMPMMPPPPMVPPMPAPPAPVG LTEFemto4GGPMGGMPMGGMGMPMPPMGGMMPGMPMPMMGPPPGMPMMPPPPGMPMMPPVPPVG LTEFemto5GGMMGPMPMMGGMGMMGPMPMPGPGMPPMPPPMPPGPMPMPPMGPGPMPMPVPPVPVG LTEFemto6PMPMPGPPPMPMGPMGMPMPMGPPMMPPMPMGPPPMGMPMMGPPMPMGMPMAPPVPMPG LTEFemto7MMGPMPMMMPMGGMGMMPPPMGGGMMPMMMMGMPMPPPMPMPPPPPGPMPPVPVPPVG LTEFemto8GGMPMGMPMPPMPGPMGMPPGGMPMGGMPPMPPPMPPGMGMGMPMPPGMMPMPPVPVG LTEFemto9MGGMMMGMPMGGMMMGMPMMMGMMPMPMGMPMPMPMPMPGMMGMMPMPMGMPMMPPMPMPG LTEFemto10PMPMGPMPMGMGGPMGMPMPMPMPMGPGGPMPMPPMPMPMMPMPPMMGGPMPPPPPAG LTEFemto11GGPMGPMPMMPMGPMGMPMGGMMMMGPMPMPPPMMPMPMPPPMGPPPPVPVPAG LTEFemto12PMPMPMPPMPMPMMGPGPMPMPMGPMGMMPMPMPMPMGPMPPVPMPMPMPMPVPVPVPMPG LTEFemto13MMGPMPMPMMPMGGGMMPPMPMPMMGPGMGPMGMGMGMMPPGMPMMPMGMPMPMPVPVPVPVPVG LTEFemto14MGGGMMGMPMPMGGPMMGMPPMPMPPMPGPPMPPPMMPGPMPMPPMPMPMVPPVPPVPMPVG LTEFemto15PMPGPGPMPMGGMMMGMPMGGMGMMPMMMGMGPMMPMPMGPMPMPPMPMMPMPVPVPVPMVG LTEFemto16MMGPMPGMGPMGGMGMMGMGGMMGMPMPPMPMPPPPMMGMGMPMMPMPMMPMMPPMPAPVG LTEFemto17MGGMGMGMGMMGGPMMGMGPPMPPPMGMPMGMGPMMGMPMGPMPPVPMPMGGPMPAPVPMPMG LTEFemto18MPMPPGMGMPMPMGPMGMPMMGGMMMGMMPMPMPPMMPGMGMGMMMGPMGMMAPMPMVPAG LTEFemto19GGMMGGPMPMPMMPPGMGMPGGMMGPMGMPMPMPPMMGMGMGMGMMPMPMMMMMPAPMPAG LTEFemto20MMGMMPMGPMPMPMMPGMPMPMGGMGMMGMGMMPMMPPMPGPMPMPMPMVPPAPAPMVPG LTEFemto21PMPPPPMPPMPGPMGMPMPMGGMMGMMPMPMPVPMPMPMGMGMGMMMMMMMMPMPPAPG LTEFemto22MGGGMMPMGPPMPMGPGMPMPMGGGMMMMPPMPMPPPPMGMGMGMMMMGAPVPMAPAPPAG LTEFemto23MGGMMMMMPMGGGMMMMMMGMMPGPPMPMMPMPGMMGPMPMPMGMPMVPPPPAG LTEFemto24MMGMMPGGMMPMMPPMGMMGGPMMPPMMPMMPPPGMMGPMPPPMMMVPMPPVPG LTEFemto25GGGMGGMGMPPMPMGPMGMGMPMMGMGMPGGPPMPMPVPMGPGMMGMMPMPMGMPMPMVPVPVPVG LTEFemto26MGGMMMGPMMGGMGMMPMPMPGGMPMGMMMPMPMGPPMPMMMGMMPPMPGMMMMPPPG LTEFemto27MGGGMGGMPPMPPPMGPMPGGMMGPPMVPPPVPMPMMMGMMPPPMGMPMAPPVPVPAG LTEFemto28PMPMPPMPPGGMPMGMPPMPMMGPMPMGMMPMGMGPMPPMMMGPMPPMMPMPAPVPAPAPG LTEFemto29GGPMGPPMPGGGMGMMPMPMPMPPMMMPMGMGMMMGMMMPMPPMMMMPMPPPVPAG LTEFemto30GGMMGMGPPPMPMPMGMMPMPGPMMPMMPMMGPMMPMGMMGMGMPMPMPMGMPMMPMPMPVG LTEFemto31MMGGMPGPPMMGPMPPMPMPMPMGPMPMPPMPMPPPMPMGMPMPPMPPMVPPAPVPVPPG LTEFemto32MMGGMPMPMGMMPMMPPPMGMPMMGMPMPMGPPMPMMPPPMPMGMPMPPMPGPMPAPVPMPAPAG LTEFemto33MGGPMMPMPPMMGPMPMGPMMPMGPMGMPMPMPPMPPMMPMMPMMGMPMMPVPMAG LTEFemto34PMPPPPMMPMMGGMPMMPMPMPMMGPGMPMPMPMMMPMPMGPMPPVPMMPGVPPPAPMPVG LTEFemto35PMPPPMPMPPGGGMGPMPPMGGGMGMPMPMPMGMPPPMPMPMPPMPPGPMPMPVPMPPAG LTEFemto36MMGGMPMGPPMMGMPMPMPMPMPMPMPPGMPMPPPMPMVPPPMPPMMVPPVPPPAPVG LTEFemto37PMPGPMMPMGGMPMMMGPPMPMPPMPMGMMMGMPMPMMGGPMPMPPMPMMGPMPVPPAPVPVG
  • 195. 169 TableB4TheavailableWiMAXandWAVEnetworksofSLA2,SLA3andSLA4. SLA2SLA3SLA4 CVBSWebBSWebWeb Network Throughput Delay Jitter PacketLoss ServiceReliability Secutiy Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price Throughput Delay Jitter PacketLoss ServiceReliability Security Price WiMAXMacro1MPMMPPPPGGGMGGMPMMGMPMPMGMGPMMGMGMPPMPGMMGMPMPMPGAPVPAPAPMVPG WiMAXMacro2GGMGMGGMGPPMPPPMMPPMMGMPMPMPMPPMPPPPMPMMMGMPMPMPMMMAPMPPPAG WiMAXMacro3MGGMGMGMPPPMPPPPPMPMPPPMMMPMPPPPPMGPMPPPMPMGVPPVPAPAPMPG WiMAXMacro4MMGPMPPPMPMPMMGPMGGMPMGGMPMMPGMPMPMMGPMPMMMGMGMPMPMGAPVPVPAPPMPG WiMAXMacro5MPMMPPGPMPMPMPPMGGMPMGGMMMMPPMPMPPMPMPMGPMPMPMPPMAPVPPAPAPVPAG WiMAXMacro6MPMGPGMMGGMMGPMPMMMGMPMPMGPMPMGMMMPMPMGMMGMPMPPPMVPPMPAPPAPVG WiMAXMacro7MMGMGMPMGMPPMGGMMMGMGMPMPMPPMGMPMPMPPMPMPMMPMPPPPMGPMPAPVPMPAPAG WiMAXMacro8MMGMMPGMPMPMMGGMPMPMPMPMMPPPMGPMMMMPMPPMMPMMPPPPMGPMPMPVPPVPAG WiMAXMacro9MMGMMPGMMMPMPPMPPPMPMMPPMPGPMPMPPMPPGMPMPPPMPMGMPMVPPAPAPVG WiMAXMacro10PMPMGPMGMMPMPMMPMPMPPPMPMGPGMPMPMPMMPMPMPMPMPMGPPPMGPMPAPVPPPG WiMAXMacro11MPMPPGMMPPMPGPGMPMMMGMGMPPMGMPMMGMMPMPMPGPMPMPPMPPMVPPVPAPMPPAG WiMAXMacro12MGGMMPMGMPMPGPGMGPPMPGPPMPMPMPMPPMPMGVPPPPPMPMAPVPPAPAPVPG WiMAXMacro13MPMMPPGMPMMGGMPPMGPMPMMPPGMGMPMPMPPMGGPMPMPPMPMGPMPMPVPMVPVG WiMAXMacro14MPMMGPMGMPMPGPMGMPMGGMPMGMPMVPPMGPMPMMMGPMPMPMPMGPMPVPVPMPAPG WiMAXMacro15MGGPMPPMPMPPPMGMMPPMPGPMMPMPPMPPPPMPGPMPMPPMPGVPPVPAPPAPAG WiMAXMacro16MPMPPMGMGMPGGMPMGGGMMGGMMMPMMPMMGMPMPMPMPMMGMGMMPMGPMPAPVPPMPVG WiMAXMacro17MGGMPMPMPMGGMGMGMMPMPMMGMGMPMGMGMPMMGMPMPMMPGPMPPVPMGMGMGPMPAPVPPVPG WiMAXFemto1MPMMGPGMGPMMGMMPMGMGMPGGMMGGMGPMMGMPMPPMGMMPMMPMPMPMGAPVPMAPVPPAG WiMAXFemto2MMGMPMPMPMPMGGMMMPMPMPMGGPMPMGPPMPMPPMPMPMMPMPPPPGMPMAPPVPAPVG WiMAXFemto3PMPMPPGMMMGGMMPMPMPMPMMPMMMPPMPMPPPPGMPMMPMMMVPPPAPAPPAG WiMAXFemto4GGPMGMPPMPPMPMPPPMGPGGGMGPMPPPMPPPPMPMMMGMPMPPMPMMPMPPAPPVG WiMAXFemto5GGMPMGMGMMMGPMPMPPPMPMMPPPMMPMMGPMPPPMMPMMPPPMGPMPAPPAPVPG WiMAXFemto6MMGMMPMPMPMMGMGMPPMGMMPMGPMMPMMMGMPMPPMMGMPMMPPMPGAPVPVPAPMPPVG WiMAXFemto7MMGMGMPMGMMPMPPPMGPMMGGMPMMGMMPMPPPPPGMPMMPPMMGVPPMPAPPVPVG WiMAXFemto8GGMMGPMPMPMGGMMMPGMPPMPMPMPMMPPMPPPMPPMPMPPPMPMMGPMPVPVPMPPAG WiMAXFemto9MGGGMPMPPMPMMGPMGPPPMPMPGGPMPMPPMPPGPMPMVPMGPMAPVPMAPMPVPG WiMAXFemto10MGGMPMMPMPMMPMGPMMPMPPMPPPMGMGMMPMMPMMPGPMPPPMGMMVPPAPAPPPAG WiMAXFemto11MMGMMPMGMPGGPMGMPMPPMPMMPMMPMPMGMGPMMPMPMGMPMMPMPMPGAPVPMAPVPVPAG WiMAXFemto12MPMMGPGGPMMGGMPGMGPMPMMPMMPMPMPMPPMPMGGMPMMPMPPMAPVPMPAPMPPAG WiMAXFemto13GGMGMGGPMPGGPMGGMGPMPMMGPMPMPPMMGPMPPMGGMPMPPMPMPMPMPPVPMPAPVG WiMAXFemto14MPMPPMGPMMGMPMPMPGMPMPMMPPGPMMGMPMPPMGMGPMPMPPPMVPPAPVPAPAPAG WiMAXFemto15GGMMGMPMPMMPMPPMGMPPGGMPMGMGPMMPMPPMGMPGMMGMPMPMPPGMMMPMPMPVPG WiMAXFemto16GGMGMGGMGMPPMPMPMGPPMMGMGMPMMPMPMPMPPPMMMGMGMPMMPMGVPPMPAPAPAPVG WiMAXFemto17MGGPMGMPPMPMPPPPMPGGMPMGMPPMMPMPPVPPGPMPMPPMPPMVPPAPAPPVPG WiMAXFemto18GGGMGPMPPMMGMPMPPMPMGGMGMGMMMPPMPVPPPPMPMPMPPMPMGPMPVPPVPPAG WiMAXFemto19MGGMPMMGMPPMPMGPMMPMMPMMPPGMPMPMPMGPMMPMPMPPPPPMPMPPVPPPVG WiMAXFemto20MGGMGMMMGPMPMMPPGPMPMPMPPPMPMPMPMMPPMGPMPMPPPPMPMGPMPPPVPAPG WiMAXFemto21PMPPPMPMGGMMGPMPMMGMPMPMGMPMGMGPMPMPGMMGMPMPMPMMMMVPMPMPPAG WiMAXFemto22PMPPPGPMPMPGPPGMPMMGPMPPPMPPMPMPPMGMGPMPPPPPMGPMPAPVPVPAPAG WiMAXFemto23MGGMGMGMGPMGGMPMMMPMGGMMMGMGMMMGMPMPMPMGMMGMPMPMMGMGPMPPVPAPAPVG WiMAXFemto24MGGMPMMMPMMPMMGPPPMMMGPMPGMMMPMMGPPPMGMPMPPMGMGMPMPPAPMPAG WiMAXFemto25MGGMMGPMPMGGMMMGMGPMPMMPGMGMMGMPMMGMPMPMPMPMGMMGVPPPAPAPMPAG WAVE1MGGMPMMGGMPPMPMPPMPMPMPMMPMGPMPMPMPPMPMMGPMPMVPMPPGPMPMVPVPPG WAVE2MMGPMPPMMPMPGPGGPMMGMGMPPMPMPPMPMPVPMPMPGMPMMPPMPMGVPPMPAPAPMPAG WAVE3MMGMPMPGMPMPMPMMPMGGPMPMGPMPMGPMPMMPPMPMMGMPMMPPMGMAPVPMAPVPPAG WAVE4GGMMGMMGPMPMGPGPMPMMGMMPGGPMPMPMPPPMPMPMPMPMPMVPPMAPAPAPAG WAVE5MGGMPMMGPPPMPGPMPMGMMPMMGPMPPPMPMPPMPPGMPMMPPPGVPPPAPPAPVG WAVE6MMGGMPMGPMMGMMPMGGMPPMPGPMPPMMPMPPMGMGPMPMGPMPPGPMPPVPVPVPAG WAVE7PMPMGPPMPPMGGMGMMMPMPMPMMGPMGMPPMMGMGMPPMPGPMPPVPMGMPMVPPVPVPMPMPG WAVE8GGPMGPMMPMGGMMPMMPGGGMGPMPMPMMMPMPPMGPMPMVPPMPGPMPPVPAPMPG WAVE9MPMPPMPMMGGPMGMPGPPMPMPPPMGMMGMPMMPMMPMPMPPPPGVPPAPPVPPAG WAVE10GGMPMGMGMPMMPMMPPMGGPPMPGPGMPPMPMMPPMGMPGPMPMPPPMPMGPMPVPVPPAPVG WAVE11MPMPPMPMGMMPMMGPMPMGGMMGGMPMPMMPPPMGMGMGMMMPMPGMMMMPPVPG WAVE12MMGMGMPGPMPMMGMGMPMGGPMGGMPMGGMMMMPMPMMGGMMGMPMPMGMPMMMMPMPVPMPVG WAVE13GGGMGMPGPGGMGMGMGGPGGMMGMGMPPMGMGPMMGMPGPMPMPMPPMVPPMAPMPPAG WAVE14GGMPMGMMGMPPMPGPGPPMMGMPMPPGMPMPPPMGPMGMPMMPPPPMGVPPVPAPAPVPAG WAVE15PMPGPMPMMPMGPPMPMPPMPMGPGMPMPMPMMPPMPMGPMPPPMPMPMPMPVPVPAPVPAG WAVE16GGPMGMGMGMMPMMPMGPPMMGMPMPPGMMPMPPMGPGMPMMPPPMMMPMVPPAPVPG WAVE17PMPPPMGMMMMGMGMPMMPMMGGMGMMPMPMPMPMMPPMMPMGMPMMPMPMPGPMPPVPAPAPAG WAVE18MGGMPMGGMPMGGMGMMPMPMPMPMPMPGMPMPMGPPMPMPMPPPMPMPMAPVPPAPAPMPAG WAVE19MMGMMPMGMPMMPMMPPMPPMGGGMPMPPMPMPPMPPMMPMMPPPMPMGAPVPMPAPAPVPG WAVE20MMGPMPMPPPMPMPPGMMPMMGGMPGMPPPMPPPMGMPMGMMGPMPMPMPMPMPAPVPVPPAG WAVE21GGMMGMPMGMPMMGPMPGGPMPMPPMMMPPPPMMMMPMPPMMGMPMVPPVPPVG WAVE22GGMMGMGMGMMGGGMGMMMPMMGPGMGPPMPPPMGMPMMPMMPMMMGVPPAPAPPMVG
  • 197. Appendix C The distribution of vehicles during the 24 hours simulation In this appendix the distribution of vehicles across velocity categories, access networks, services and SLAs, during the 24 hours simulation is presented.
  • 198. 172 The distribution of vehicles during the 24 hours simulation Table C1 Number of vehicles that start from each LTE network and their corresponding velocities. Network Number of vehi- cles (%) Normal velocity Medium velocity High velocity LTE Macro 1 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 2 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 3 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 4 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 5 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 6 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 7 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 8 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 9 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 10 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 11 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 12 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 13 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 14 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 15 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 16 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 17 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 18 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 19 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Macro 20 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 1 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 2 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 3 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 4 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 5 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 6 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 7 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 8 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 9 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 10 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 11 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 12 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 13 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 14 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 15 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 16 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 17 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 18 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 19 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 20 329 (0,82648%) 109 (0,27382%) 111 (0,27884%) 109 (0,27382%) LTE Femto 21 329 (0,82648%) 110 (0,27633%) 110 (0,27633%) 109 (0,27382%) LTE Femto 22 329 (0,82648%) 110 (0,27633%) 110 (0,27633%) 109 (0,27382%) LTE Femto 23 329 (0,82648%) 110 (0,27633%) 110 (0,27633%) 109 (0,27382%) LTE Femto 24 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 25 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 26 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 27 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 28 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 29 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 30 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 31 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 32 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 33 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 34 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 35 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 36 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) LTE Femto 37 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%)
  • 199. 173 Table C2 Number of vehicles that start from each WiMAX network and their corresponding velocities. Network Number of vehi- cles (%) Normal velocity Medium velocity High velocity WiMAX Macro 1 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 2 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 3 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 4 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 5 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 6 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 7 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 8 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 9 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 10 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 11 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 12 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 13 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 14 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 15 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 16 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Macro 17 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 1 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 2 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 3 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 4 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 5 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 6 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 7 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 8 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 9 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 10 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 11 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 12 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 13 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 14 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 15 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 16 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 17 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 18 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 19 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 20 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 21 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 22 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 23 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 24 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WiMAX Femto 25 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) Table C3 Number of vehicles that start from each WAVE network and their corresponding velocities. Network Number of ve- hicles (%) Normal velocity Medium velocity High velocity WAVE 1 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 2 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 3 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 4 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 5 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 6 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 7 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 8 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 9 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 10 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 11 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 12 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 13 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 14 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 15 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 16 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 17 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 18 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 19 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 20 329 (0,82648%) 111 (0,27884%) 110 (0,27633%) 108 (0,27130%) WAVE 21 328 (0,82397%) 111 (0,27884%) 109 (0,27382%) 108 (0,27130%) WAVE 22 328 (0,82397%) 111 (0,27884%) 109 (0,27382%) 108 (0,27130%)
  • 200. 174 The distribution of vehicles during the 24 hours simulation Table C4 Vehicles count per service and SLA. Services SLA 1 vehicles (%) SLA 2 vehicles (%) SLA 3 vehicles (%) SLA 4 vehicles (%) Sum NAV 322 (0,808902%) - - - 322 (0,808902%) VoIP 321 (0,806390%) - - - 321 (0,806390%) CV 321 (0,806390%) 1422 (3,572236%) - - 1743 (4,378626%) BS 321 (0,806390%) 1422 (3,572236%) 3318 (8,335217%) - 5061 (12,71384%) WB 321 (0,806390%) 1422 (3,572236%) 3317 (8,332705%) 9951 (24,99811%) 15011 (37,70944%) NAV, VoIP 321 (0,806390%) - - - 321 (0,806390%) NAV, CV 321 (0,806390%) - - - 321 (0,806390%) NAV, BS 321 (0,806390%) - - - 321 (0,806390%) NAV, WB 321 (0,806390%) - - - 321 (0,806390%) VoIP, CV 321 (0,806390%) - - - 321 (0,806390%) VoIP, BS 321 (0,806390%) - - - 321 (0,806390%) VoIP, WB 321 (0,806390%) - - - 321 (0,806390%) CV, BS 321 (0,806390%) 1422 (3,572236%) - - 1743 (4,378626%) CV, WB 321 (0,806390%) 1422 (3,572236%) - - 1743 (4,378626%) BS, WB 321 (0,806390%) 1421 (3,569723%) 3317 (8,332705%) - 5059 (12,7088%) NAV, VoIP, CV 321 (0,806390%) - - - 321 (0,806390%) NAV, VoIP, BS 321 (0,806390%) - - - 321 (0,806390%) NAV, VoIP, WB 321 (0,806390%) - - - 321 (0,806390%) NAV, CV, BS 321 (0,806390%) - - - 321 (0,806390%) NAV, CV, WB 321 (0,806390%) - - - 321 (0,806390%) NAV, BS, WB 321 (0,806390%) - - - 321 (0,806390%) VoIP, CV, BS 321 (0,806390%) - - - 321 (0,806390%) VoIP, CV, WB 321 (0,806390%) - - - 321 (0,806390%) VoIP, BS, WB 321 (0,806390%) - - - 321 (0,806390%) CV, BS, WB 321 (0,806390%) 1421 (3,569723%) - - 1742 (4,376114%) NAV, VoIP, CV, BS 321 (0,806390%) - - - 321 (0,806390%) NAV, VoIP, CV, WB 321 (0,806390%) - - - 321 (0,806390%) NAV, VoIP, BS, WB 321 (0,806390%) - - - 321 (0,806390%) NAV, CV, BS, WB 321 (0,806390%) - - - 321 (0,806390%) VoIP, CV, BS, WB 321 (0,806390%) - - - 321 (0,806390%) NAV, VoIP, CV, BS, WB 321 (0,806390%) - - - 321 (0,806390%) Sum: 9952 (25,00062%) 9952 (25,00062%) 9952 (25,00062%) 9951 (24,99811%) 39807 (100%)