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

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

 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.
 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.
 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

βελτιστοποιεί τη διαχείριση της κινητικότητας των χρηστών ξεπερνώντας τις υπάρχουσες

λύσεις που περιγράφονται στη βιβλιογραφία.
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
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
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 Platform as a Infrastructure as a

Service (SaaS) Service (PaaS) Service (IaaS)
User Framework as a Discovery as a
Communication as Service (FaaS) Service (DISCaaS)
a Service (UCaaS)
Runtime Network as a
Data as a Service Environment as a
(DaaS) Service (NaaS)
Service (RaaS)
Entertainment as a Hardware as a
Service (EaaS) Service (HaaS)

Information as a Computing as a
Service (INaaS) Service (COaaS)

Pictures as a Storage as a Service

Service (PICaaS) (STaaS)

Sensing as a Service
(SEaaS)

Warning as a
Service (WaaS)

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

Communication
Architectures
Models

Vehicular Cloud Vehicle to Vehicle

(VC) (V2V)
Software Defined
Networking Hybrid Hybrid
Vehicle to
Vehicular Vehicles using Vehicular Vehicular
Infrastructure
Architectures Cloud (VuC) Architectures Communication
(V2I)
(SDN-V) (HVA) (HVC)

Vehicles using Fog Vehicle to

(VuF) Pedestrian (V2P)

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

Service Layer

Vehicular Cloud Network Layer

Device Layer

Figure 1.4 The Vehicular Cloud (VC) architecture.

Service Layer
Network Layer
Device Layer

Cloud

RSU/BS RSU/BS

Vehicular Environment

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

Service Layer
Network Layer
Fog Device Layer

micro-datacenter micro-datacenter
RSU/BS RSU/BS
micro-datacenter
RSU/BS micro-datacenter
RSU/BS

Vehicular Environment

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

Service Layer
Network Layer
Device Layer

Cloud

Fog
micro-datacenter
micro-datacenter RSU/BS
RSU/BS
micro-datacenter
micro-datacenter
RSU/BS
RSU/BS

Vehicular Cloud

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

Vehicle to Vehicle (V2V)

Vehicle to Infrastructure (V2I)
Vehicle to Pedestrian (V2P)

RSU/BS RSU/BS

Pedestrian
Vehicular
Environment
Pedestrian

Pedestrian

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.
ATSA CFR-MAC PTMAC UTSP
TDMA CAH-MAC
ETCM STDMA VeMAC
based CBT
IGPS-MAC TC-MAC e-VeMAC
CESFRA
MAC Schemes for
CSMA/CA CA-MAC MQOG
5G-VCC
based MMAC-CL QL-MAC

ACFM HER-MAC
Hybrid CBRC-MAC OBV
CS-TDMA R-MAC

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.

Positioning Centralized
Multiple Cluster CRN
MAC Scheme System /Distributed Communication
Access based Support
Required control
FDMA,
ACFM [123] No No Centralized No V2I
TDMA
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
FDMA,
CBRC-MAC [124] Yes No Centralized No V2I
TDMA
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
CSMA/CA,
CS-TDMA [127] SDMA, No Yes Distributed No V2V
TDMA
ETCM [111] TDMA Yes Yes Centralized No V2V
CSMA/CA,
HER-MAC [125] No Yes Distributed No V2V
TDMA
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
CSMA/CA,
OBV [128] No Yes Distributed No V2V, V2I
OFDMA
PTMAC [112] TDMA No Yes Distributed No V2V
QL-MAC [122] CSMA/CA No Yes Distributed No V2V
CSMA/CA,
R-MAC [126] Yes Yes Centralized No V2V, V2I
TDMA
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 dki (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
R̄i (t − 1) denotes the past average throughput. Finally, the TTA metric is calculated using
formula 2.3 where d i (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
i,k = dk (t) (2.1)

dki (t)
mPF
i,k = (2.2)
R̄i (t − 1)

dki (t)
mTi,kTA = (2.3)
d i (t)
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.

1
mBET
i,k = (2.4)
R̄i (t − 1)
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−LW
i,k
DF
= ai · DHOL,i · mPF
i,k (2.5)
24 Resource Allocation - Scheduling

EXP/PF ai · DHOL,i − X
mi,k = exp( √ ) · mPF
i,k (2.6)
1− X

logδi
αi = − (2.7)
τi

1 Nrt
X= · ∑ ai · DHOL,i (2.8)
Nrt i=1
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 Γik 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 ) · Γik (2.9)

ai · DHOL,i
mEXPRULE
i,k = bi · exp( q ) · Γik (2.10)
c + (1/Nrt ) ∑ j DHOL, j

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.

Mi
ui (k) = qi (k) + ∑ [qi · (k − n + 1)
n=2
(2.11)
− qi · (k − n + 2) − ui · (k − n + 1)] · ci (n)

τi = (Mi + 1) · T f (2.12)
2.3 The Proposed FLS Advanced (FLSA) Scheduler 25

Real-time queues

Upper Level (FLSA)

Compute data to be transmitted ui(t)

ui(t)

Link ds Middle Level (M-LWDF)

Adaptation Schedule RBs in TTI for ui(t)
data
CQI Best-effort
queue
ds Free RBs?

YES

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.


0 , when n = 0


ci (n) = 1 , when n = 1 (2.13)


ci (n − 1)/2 , when n ≥ 2


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.

HOL Max. Max. Queue

Scheduler SINR Throughput
Delay Delay PLR 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
Real time traffics:
H264 video at 440 kbps,
Traffic models 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. n
(∑i=1 xi )2
Jain_Fairness = (2.14)
n · ∑ni=1 xi2
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.

n , when 0 ≤ n ≤ 1
ci (n) = (2.15)
ci (n − 1)/(2 · N) , when n ≥ 2

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.
dki (t)
mPF−CC
i,k = (2.16)
∑Nj=1 R̄i, j (t − 1)
2.4 The Proposed FLS Advanced - Cross Carrier (FLSA-CC) Scheduler 33

Figure 2.12 The FLSA-CC Scheduler Design.

mMLW
i,k
DF−CC PF−CC
= ai · DHOL,i · mi,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

PCC: 1805 MHz − 1825 MHz (band 3)
DeNB0
SCC: 760 MHz − 780 MHz (band 28)
PCC: 1825 MHz − 1845 MHz (band 3)
DeNB1,3,5
SCC: 870 MHz − 890 MHz (band 5)
PCC: 2110 MHz − 2130 MHz (band 1)
DeNB2,4,6
( MHz − 960 MHz (band 8)
SCC: 940
PCC: 2620 MHz − 2640 MHz (band 7)
Case 1
Relay nodes SCC: 780 MHz − 800 MHz (band 28)
(
PCC: 2640 MHz − 2660 MHz (band 7)
Case 2
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).
NLOS
PLDeNB→UE = 37.6 · log10 (d) + 58.94 + 21 · log10 ( fc ) (2.18)
NLOS
PLRN→UE = 36.7 · log10 (d) + 22.7 + 26 · log10 ( fc ) (2.19)
LOS
PLDeNB→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.

HOL Max. Max. Queue

Scheduler SINR Throughput CCS
Delay Delay PLR Length
PF X X
MLWDF X X X X X
EXP/PF X X X X X
FLS X X X X
FLSA X X X X X X
FLSA-CC X X X X X X X
EXP
X X X X
RULE
LOG
X X X X
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
H264 video at 440 kbps
Real time:
Traffic models 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 ) with a membership function µ(x):

x−x1
x2 −x1 , if x1 ≤ x < x2 ;




if x2 ≤ x ≤ x3 ;

v ,
Â
µ(x) = (3.1)
x−x
x −x , if x3 < x ≤ x4 ;
 4

 3 4


0, otherwise.


where x1 < x2 < x3 < x4 and v ∈ [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, [µAL (x), µAU (x)])} (3.2)

µAL (x), µAU (x) :X → [0, 1]∀x ∈ X, µAL (x) < µAU (x) (3.3)
µ̂A (x) = [µAL (x), µAU (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 ] =
[(x1L , x2L , x3L , x4L , vAL ), (xU U U U L L L L U U
1 , x2 , x3 , x4 , vAU ))] where: 0 ≤ x1 ≤ x2 ≤ x3 ≤ x4 ≤ 1, 0 ≤ x1 ≤ x2 ≤
xU U L U
3 ≤ x4 ≤ 1, 0 ≤ vAL ≤ vAU ≤ 1 and A ⊂ A . 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 , vÂ1 , vÂ2 ) with
membership function:



vÂ1 · xx−x
2 −x1
1
, if x1 6 x < x2 ;

v − (v − v ) · x−x2 ,

if x2 6 x < x3 ;
x3 −x2

 Â Â Â1



v ,
 if x = x3 ;
µ(x) = (3.6)
v − (v − v ) · x−x3 , if x3 < x 6 x4 ;


 Â Â Â2 x4 −x3
 x−x5
vÂ2 · x4 −x5 , if x4 < x 6 x5 ;





0, otherwise.

where x1 6 x2 6 x3 6 x4 6 x5 and v , vA1 ˆ ∈ [0, 1].

ˆ , vA2
3.1 Related Methodologies 41

The interval-valued pentagonal fuzzy number is a general IVFN case (Figure 3.2) defined
as: A = [AL , AU ] = [(x1L , x2L , x3L , x4L , x5L , vLA , vLA1 , vLA2 ), (xU U U U U U
1 , x2 , x3 , x4 , x5 , vA ,
vU U L U L L L L L
A1 , vA2 ))] where: A ⊂ A , 0 6 x1 6 x2 6 x3 6 x4 6 x5 6 1, 0 6 x1 6 x2 6 x3 6 x4 6 x5 6 1,
U U U U U

vLA 6 vU L L L U U U L L L U U U
A , vA1 6 vA2 6 vA , vA1 6 vA2 6 vA and vA , vA1 , vA2 , vA , vA1 , vA2 ∈ [0, 1]. The operational
rules of the interval-valued pentagonal fuzzy numbers are defined in [160].

1
uAU AU
U
uA1, uAU
2
uAL AL
uAL1, uAL2

xU1 xU2 xU3 xU4 xU5

0
xL1 xL2 xL3 xL4 xL5 1

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 vLA1 , vU L U
A1 , vA2 and vA2 are defined by the user.

Umax −Umin L


xU U U L U
i,1 = xi,2 − 4·(c−1) , xi,1 = xi,1 · (vA1 /vA1 )

Umax −Umin L
xU = xU U L U
i,3 − 2·(c−1) , xi,2 = xi,2 · (vA1 /vA1 )


 i,2


IV PFNi = xU,L Umax −Umin (3.7)
i,3 = Umin + c−1 · (i − 1)

Umax −Umin L

xi,4 = xi,3 + 2·(c−1) , xi,4 = xU
U U L U
i,4 · (vA2 /vA2 )





Umax −Umin L

 U
xi,5 = xU U L U
i,4 + 4·(c−1) , xi,5 = xi,5 · (vA2 /vA2 )

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 Out put. Both Input1 and Input2 have normalized values
within the range [0, 1]. Also, the MFInput1 , MFInput2 , MFOut put 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 Out put, 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 Out put 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 MFOut put membership function.

Step 3. Fuzzification: The Input1 and Input2 crisp values are converted to degrees of member-
ship indicated as Input1′ and Input2′ by a lookup in MFInput1 and MFInput2 membership
functions respectively.

Step 4. Combination of the fuzzified inputs (Fuzzy Operations): A Zr′ 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.
′
Zu,i,r = Input1′ ˆ·Input2′ = Input1′ · Input2′ (3.8)

′
Zu,i,r = (Input1′ + Input2′ ) − (Input1′ · Input2′ ) (3.9)

Step 5. Implication method: The implication method estimates the consequence MFOut putrc of
the rule conclusion, considering both the rule conclusion MFOut putr and the rule strength
Zr′ . The MFOut putr height is trimmed with respect to the Zr′ degree, using formula 3.10,
which applies the Min method.

MFOut putrc = min{MFOut putrHeight , Zr′ } (3.10)

Height

Step 6. Aggregation method: The aggregation method combines the R rules’ consequences to
calculate the Out put A fuzzy set, using formula 3.11, which applies the Max method.

Out put A = MFOut put1c ∪ MFOut put2c ∪ ... ∪ MFOut putRc

(3.11)
 3.1 Related Methodologies 43

Step 7. Defuzzification: During the defuzzification, the Out put A fuzzy set is transformed to the
crisp value Out put. 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 Out put A . Also,
symbols U and L represent the upper and the lower pentagon of each rule respectively .
R
∑ (µrU · hUr + µrL · hLr )
r=1
Out put = R
(3.12)
∑ (hUr + hLr )
r=1

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:

C1 ... Ck ... Cn
e11 . . . e1m1 ... ek1 . . . ekmk ... en1 . . . enmn
 
e11
..  
C1 . 
 W11 ... W1k ... W1n 

e1m1
 
 
.. .. .. .. .. ..
 
 
. 
 . . . . . 

ek1  
W= (3.13)
 
..  
Ck . 
 Wk1 ... Wkk ... Wkn 

 
ekmk 



..  .. .. .. .. .. 
. 
 . . . . . 

en1 



..  
. ... ...
 
Cn  Wn1 Wnk Wnn 
enmn

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 à 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 à matrix is expressed as follows:
 
1 ... ã1 j ... ã1n
 .. .. .. 
 . . . 
 
1/ã1i ... 1 ... ãin 
 
à =
 . (3.14)
 . .. .. 

 . . . 
1/ã1n ... 1/ã jn ... 1

where n denotes the number of the cluster elements. Subsequently, the geometric mean
rÃi of each row i in à is estimated according to formula 3.34, where ⊗ denotes the
multiplication operator of two fuzzy numbers as defined in [169].
1
rÃi = (ãi1 ⊗ ãi2 ⊗ ... ⊗ ãin ) n (3.15)

Then, the priority vector Ω̃i of cluster elements is constructed as follows:

Ω̃i = [ ω̃1 ω̃2 ... ω̃n ] (3.16)

where each ω̃i = (ω1U , ω2U , ω3U , ω4U , vU L , ω L , ω L , ω L , vL ) is calculated using for-
 
i ); (ω 1 2 3 4 i
mula 3.36. The ⊕ indicates the addition operator of two fuzzy numbers as defined in
[169].

ω̃i = rÃi /(rÃ1 ⊕ rÃ2 ⊕ ... ⊕ rÃi ⊕ ... ⊕ rÃn ) (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:
C1 ... Ck ... Cq
e11 ...e1n1 ... ek1 ...eknk ... eq1 ...eqnq
 
e11
..  
C1 . 
 W̃11 ... W̃1 j ... W̃1q 

e1n1
 
 
.. .. .. .. .. ..
 
 
. 
 . . . . . 

ek1  
W̃ = (3.18)
 
..  
Ck . 
 W̃k1 ... W̃k j ... W̃kq 

 
eknk 



..  .. .. .. .. .. 
. 
 . . . . . 

eq1 



..  
. ... ...
 
Cq  W̃q1 W̃q j W̃qq 
eqnq

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 = W̃k, 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.
vU · dU + vL · d L
Wk, j = (3.20)
dU + d L

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:
 
1 ... p̃1 j ... p̃1S
 .. .. .. 
 . . . 
 
1/ p̃1s ... 1 ... p̃sS 
 
P̃ =
 . (3.21)
 . .. .. 
 . . . 
1/ p̃1S ... 1/ p̃ jS ... 1
where S denotes the number of the services. Subsequently, the geometric mean rP̃s 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].
1
rP̃s = ( p̃s1 ⊗ p̃s2 ⊗ ... ⊗ p̃sS ) S (3.22)
Then, the priority vector Ω̃P̃s of services is constructed as follows:
Ω̃P̃s = [ ω̃ p̃1 ω̃ p̃2 ... ω̃ p̃S ] (3.23)
h i
where each ω̃ p̃s = (ω U
p̃1 , ω U , ω U , ω U , vU ); (ω L , ω L , ω L , ω L , vL ) is calculated us-
p̃2 p̃3 p̃4 ps p̃1 p̃2 p̃3 p̃4 ps
ing formula 3.24. The ⊕ indicates the addition operator of two fuzzy numbers as defined
in [169].
ω̃ p̃s = rP̃s /(rP̃1 ⊕ rP̃2 ⊕ ... ⊕ rP̃s ⊕ ... ⊕ rP̃S ) (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 Ãs is derived for each TF-AANP cluster using the
linguistic terms presented in Table 3.2. The standard form of the à matrix is expressed as
follows:  
1 ... ãs1 j ... ãs1n
 .. .. .. 
 . . . 
 
1/ãs1i ... 1 ... ãsin 
 
Ãs =
 . (3.25)
 . .. .. 
 . . . 
1/ã1sn ... 1/ãs jn ... 1
 48 Mobility Management

where n denotes the number of the cluster elements. Subsequently, the geometric mean
rÃsi of each row i in Ãs is estimated according to formula 3.26.
1
rÃs i = (ãsi1 ⊗ ãsi2 ⊗ ... ⊗ ãsin ) n (3.26)

Then, the priority vector Ω̃si of the cluster elements is constructed as follows:
Ω̃si = [ ω̃s1 ω̃s2 ... ω̃sn ] (3.27)
 U U U U U L , ω L , ω L , ω L , vL ) is calculated using

where each ω̃si = (ωs1 , ωs2 , ωs3 , ωs4 , vsi ); (ωs1 s2 s3 s4 si
formula 3.36. The ⊕ indicates the addition operator of two fuzzy numbers as defined in
[169].

ω̃si = rÃsi /(rÃs1 ⊕ rÃs2 ⊕ ... ⊕ rÃsi ⊕ ... ⊕ rÃsn ) (3.28)

Step 4. Construction of the Supermatrices: In this step, the fuzzy supermatrix W̃s 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:
C1 ... Ck ... Cq
e11 ...e1n1 ... ek1 ...eknk ... eq1 ...eqnq
 
e11
..  
C1 . 
 W̃s11 ... W̃s1 j ... W̃s1q 

e1n1
 
 
.. .. .. .. .. ..
 
 
. 
 . . . . . 

ek1  
W̃s = (3.29)
 
..  
Ck . 
 W̃sk1 ... W̃sk j ... W̃skq 

 
eknk 



..  .. .. .. .. .. 
. 
 . . . . . 

eq1 



..  
. ... ...
 
Cq  W̃sq1 W̃sq j W̃sqq 
eqnq

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 = W̃s,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.
vUs · dsU + vLs · dsL
Ws,k, j = (3.31)
dsU + dsL

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.
S
we = ∑ ω̃P̃,s ∗ Ls,e (3.32)
s=1

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 à 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 à matrix is expressed as follows:
 
1 ... ã1 j ... ã1n
 .. .. .. 
 . . . 
 
1/ã1i ... 1 ... ãin 
 
à =
 . (3.33)
 . .. .. 

 . . . 
1/ã1n ... 1/ã jn ... 1

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Ãi of each row i in à is calculated according to formula 3.34, where ⊗ denotes the
multiplication operator of two fuzzy numbers as defined in [169].
1
rÃi = (ãi1 ⊗ ãi2 ⊗ ... ⊗ ãin ) 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 = [(ω1U , ω2U , ω3U , ω4U , ω5U , vU U U L

i , vi1 , vi2 ); (ω1 ,
ω2L , ω3L , ω4L , ω5L , vLi , vLi1 , vLi2 )] is calculated using formula 3.36. The ⊕ indicates the addi-
tion operator of two fuzzy numbers as defined in [169].
ω̃i = rÃi /(rÃ1 ⊕ rÃ2 ⊕ ... ⊕ rÃi ⊕ ... ⊕ rÃn ) (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:

C1 ... Ck ... Cq
e11 ...e1n1 ... ek1 ...eknk ... eq1 ...eqnq
 
e11
..  
C1 . 
 W̃11 ... W̃1 j ... W̃1q 

e1n1
 
 
.. .. .. .. .. ..
 
 
. 
 . . . . . 

ek1  
W̃ = (3.37)
 
..  
Ck . 
 W̃k1 ... W̃k j ... W̃kq 

 
eknk 



..  .. .. .. .. .. 
. 
 . . . . . 

eq1 



..  
. ... ...
 
Cq  W̃q1 W̃q j W̃qq 
eqnq

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 = W̃k, 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.
vU · dU + vL · d L
Wk, j = (3.39)
dU + d L
 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 xi j 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

C1 . . . Cm
A1 x11 . . . x1m
D= .. .. .. .. (3.40)
. . . .
An xn1 . . . xnm
h i
L L L L L U U U U U
where: xi j = (xi j1 , xi j2 , xi j3 , xi j4 , vi j ), (xi j1 , xi j2 , xi j3 , xi j4 , vi j )
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 xi jk is the performance of
alternative i for criterion j, and w jk is the importance weight for criterion j, the average
of the performance values and weights are given by
" !
1 Q 1 Q L 1 Q L 1 Q L 1 Q L L
xi j = ∑ xi jk = ∑ xi jk1 , Q ∑ xi jk2 , Q ∑ xi jk3 , Q ∑ xi jk4 , vi jk ,
Q k=1 Q k=1 k=1 k=1 k=1
!#
1 Q U 1 Q U 1 Q U 1 Q U
∑ xi jk1 , Q ∑ xi jk2 , Q ∑ xi jk3 , Q ∑ xi jk4 , vUijk
Q k=1
(3.41)
k=1 k=1 k=1

and
1 Q
wj = ∑ w jk . (3.42)
Q k=1

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) " ! !#
xiLj1 xiLj2 xiLj3 xiLj4 L xU U U U
i j1 xi j2 xi j3 xi j4 U
ri j = , , , ,v , , , , ,v (3.43)
bj bj bj bj ij bj bj bj bj ij

where b j = maxi xU
i j4 for each j ∈ Ω b and
b) " ! !#
cj cj cj cj L cj cj cj cj U
ri j = , , , ,v , , U , U , U , vi j (3.44)
xiLj4 xiLj3 xiLj2 xiLj1 i j xU
i j4 xi j3 xi j2 xi j1

where c j = mini xiLj4 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 ri j with the respective weight w j according to the formula

riLj1 · w j , riLj2 · w j , riLj3 · w j , riLj4 · w j , vLij , rU U U U U




ui j = i j1 · w j , ri j2 · w j , ri j3 · w j , ri j4 · w j , vi j (3.45)

Step 4. Determination of the positive and negative ideal solution: The positive ideal solution X +
is defined as follows:
h   i
X+ = xi+L , x +L +L +L +L
, x , x , v
j1 i j2 i j3 i j4 i j , x +U +U +U +U +U
i j1 , xi j2 , xi j3 , x i j4 , vij =
" ! !#
^ ^ ^ ^ ^ ^ ^ ^
uLij1 , uLij2 , uLij3 , uLij4 , vLij , uUij1 , uUij2 , uUij3 , uUij4 , vUij (3.46)
i i i i i i i i

≡ maxi in case j ∈ Ωb and ≡ mini in case j ∈ Ωc .

V V
where
i i

The negative ideal solution X − is defined as follows:

h   i
X− = xi−L −L −L −L −L
j1 , xi j2 , xi j3 , xi j4 , vi j , xi−U −U −U −U −U
j1 , xi j2 , xi j3 , xi j4 , vi j
(3.47)
" ! !#
_ _ _ _ _ _ _ _
= uLij1 , uLij2 , uLij3 , uLij4 , vLij , uUij1 , uUij2 , uUij3 , uUij4 , vUij
i i i i i i i i

≡ mini in case j ∈ Ωb and ≡ maxi in case j ∈ Ωc .

W W
where i i

Step 5. Measurement of the distance of each alternative from the ideal solutions: The distances
+ +
di1 and di2 of each alternative from the positive ideal solution are evaluated as follows:

m  
1 2  2  2  2  21
+ L +L L +L L +L L +L
di1 = ∑ ui j1 − xi j1 + u i j2 − xi j2 + u i j3 − x i j3 + ui j4 − x i j4 (3.48)
j=1 4

 
1 m 2  2  2  2  21
+ U +U U +U U +U U +U
di2 =∑ ui j1 − xi j1 + ui j2 − xi j2 + ui j3 − xi j3 + ui j4 − xi j4 (3.49)
j=1 4
 54 Mobility Management

− −
Likewise, the distances di1 and di2 of each alternative from the negative ideal solution
are estimated as follows:
m
 
1 2  2  2  2  21
− L −L L −L L −L L −L
di1 =∑ ui j1 − xi j1 + ui j2 − xi j2 + ui j3 − xi j3 + ui j4 − xi j4 (3.50)
j=1 4

m 
1 2  2  2  2  21
− U −U U −U U −U U −U
di2 =∑ ui j1 − xi j1 + ui j2 − xi j2 + ui j3 − xi j3 + ui j4 − xi j4 (3.51)
j=1 4

Consequently, similarly to [158] the distance of the alternatives from the positive and the
+ + − −
negative ideal solutions are expressed by intervals such as [di1 , di2 ] and [di1 , di2 ], 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:
−
di1
RCi1 = + − (3.52)
di1 + di1
and −
di2
RCi2 = + − (3.53)
di2 + di2

The compound relative closeness RCi is obtained from the average of the above values:
RCi1 + RCi2
RCi = (3.54)
2

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 g̃ie of the z × n decision matrix D̃ is
an IVTFN number expressing the performance of alternative i for criterion e. Thus,

CR1 ... CRn

AL1 g̃11 ... g̃1n
D̃ = .. .. .. .. (3.55)
. . . .
ALz g̃z1 ... g̃zn

where g̃ie = (gLie1 , gLie2 , gLie3 , gLie4 , vLie ), (gUie1 , gUie2 , gUie3 , gUie4 , vUie ) .
 

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 g̃iex is
the performance of alternative i for criterion (element) e, the average of the performance
values is given by formula 3.56.
S
g̃ie = ∑ (g̃ies · ω̃ p̃s ) (3.56)
s=1

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 L
ie4 for each e ∈ Γb and ce = mini gie4
for each e ∈ Γc .
gU gU gU
  U
gLie1 gLie2 gLie3 gLie4 L
 
g
g̃′ie = , , , , vie , ie1 , ie2 , ie3 , ie4 , vUie (3.57)
be be be be be be be be
   
ce ce ce ce L ce ce ce ce U
g̃′ie = , , , , v , , , , , v (3.58)
gLie4 gLie3 gLie2 gLie1 ie gUie4 gUie3 gUie2 gUie1 ie

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.
h 
ũie = g′L ′L ′L ′L ′L
ie1 · we , gie2 · we , gie3 · we , gie4 · we , vie ,
 i (3.59)
g′U
ie1 · we , g′U
ie2 · we , g′U
ie3 · we , g′U
ie4 · we , vU
ie

Step 4. Determination of the positive and negative ideal solution: The positive ideal solution
is defined in formula 3.60, where ≡ maxi in case e ∈ Γb and ≡ mini in case e ∈ Γc .
V V
i i
≡ mini
W
Correspondingly, the negative ideal solution is defined in formula 3.61, where i
 56 Mobility Management

in case e ∈ Γb and ≡ maxi in case e ∈ Γc .

W
i
h  i
G̃+ = g+L +L +L +L +L +U +U +U +U +U
ie1 , gie2 , gie3 , gie4 , vie , gie1 , gie2 , gie3 , gie4 , vie
 
^ ^ ^ ^
L L L L L
= uie1 , uie2 , uie3 , uie4 , vie ,
(3.60)
i i i i
 
^ ^ ^ ^
uUie1 , uUie2 , uUie3 , uUie4 , vUie
i i i i
h  i
G̃− = g−L −L −L −L −L −U −U −U −U −U
ie1 , gie2 , gie3 , gie4 , vie , gie1 , gie2 , gie3 , gie4 , vie
 
_ _ _ _
L L L L L
= uie1 , uie2 , uie3 , uie4 , vie ,
(3.61)
i i i i
 
_ _ _ _
uUie1 , uUie2 , uUie3 , uUie4 , vUie
i i i i

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.
n 
1 2  2  2  2  12
p+
i1 =∑ L +L L +L L +L L +L
uie1 − gie1 + uie2 − gie2 + uie3 − gie3 + uie4 − gie4 (3.62)
e=1 4

n  
1 2  2  2  2  12
p+
i2 = ∑ uU
ie1 − g+U
ie1 + uU
ie2 − g+U
ie2 + uU
ie3 − g+U
ie3 + uU
ie4 − g+U
ie4
(3.63)
e=1 4

Likewise, the distances of each alternative from the negative ideal solution are estimated using formulas
3.64 and 3.65.

n  
1 2  2  2  2  12
p−
i1 = ∑ uL
ie1 − g−L
ie1 + uL
ie2 − g−L
ie2 + u L
ie3 − g−L
ie3 + u L
ie4 − g−L
ie4
(3.64)
e=1 4

n 
1 2  2  2  2  12
p−
i2 =∑ U −U U −U U −U U −U
uie1 − gie1 + uie2 − gie2 + uie3 − gie3 + uie4 − gie4 (3.65)
e=1 4

Consequently, the alternative distance from the positive and from the negative ideal
− −
solutions are expressed by intervals such as [p+ +
i1 , pi2 ] and [pi1 , pi2 ], 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.
p−
i1
RCi1 = (3.66)
p+
i1 + p−
i1

p−
i2
RCi2 = − (3.67)
p+
i2 + pi2
 3.1 Related Methodologies 57

Subsequently, the compound relative closeness is obtained using formula 3.68

RCi1 + RCi2
RCi = (3.68)
2

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 xi j 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

C1 . . . Cm
A1 x11 . . . x1m
D= .. .. .. .. (3.69)
. . . .
An xn1 . . . xnm

where: xi j = [(xiLj1 , xiLj2 , xiLj3 , xiLj4 , xiLj5 , vLij , vLij1 , vLij2 ), (xUij1 , xUij2 , xUij3 , xUij4 , xUij5 , vUij , vUij1 , vUij2 )]. 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 xi jk is the performance of alternative
i for criterion j, and w jk is the importance weight for criterion j, the average of the
performance values and weights are given by:

1 Q
xi j = ∑ xi jk (3.70)
Q k=1

and
1 Q
wj = ∑ w jk . (3.71)
Q k=1

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:
U
xiLj1 xiLj2 xiLj3 xiLj4 xiLj5 L L L xU U U U
i j1 xi j2 xi j3 xi j4 xi j5 U U
ri j = [( , , , , , vi j , vi j1 , vi j2 ), ( , , , , , v , v , vU )] (3.72)
bj bj bj bj bj b j b j b j b j b j i j i j1 i j2

where b j = maxi xU
i j4 for each j ∈ Ω b , or

cj cj cj cj cj L L L cj cj cj cj cj U U U
ri j = [( , , , , , v , v , v ), ( , U , U , U , U , vi j , vi j2 , vi j1 )] (3.73)
xiLj5 xiLj4 xiLj3 xiLj2 xiLj1 i j i j2 i j1 xUi j5 xi j4 xi j3 xi j2 xi j1

where c j = mini xiLj4 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 ri j with the respective weight w j according to:

ui j = [(riLj1 · w j , riLj2 · w j , riLj3 · w j , riLj4 · w j , riLj5 · w j , vLij , vLij1 ,

vLij2 ), (rU U U U U U U U
i j1 · w j , ri j2 · w j , ri j3 · w j , ri j4 · w j , ri j5 · w j , vi j , vi j1 , vi j2 )] (3.74)

Step 4. Determination of the positive and negative ideal solutions: The positive ideal solution is
given by:

X + = [(xi+L +L +L +L +L +L +L +L +U +U +U +U +U +U +U +U
j1 , xi j2 , xi j3 , xi j4 , xi j5 , vi j , vi j1 , vi j2 ), (xi j1 , xi j2 , xi j3 , xi j4 , xi j5 , vi j , vi j1 , vi j2 )] =
^ ^ ^ ^ ^ ^ ^ ^ ^ ^
[( uLij1 , uLij2 , uLij3 , uLij4 , uLij5 , vLij , vLij1 , vLij2 ), ( uUij1 , uUij2 , uUij3 , uUij4 , uUij5 , vUij , vUij1 , vUij2 )]
i i i i i i i i i i
(3.75)

≡ maxi in case j ∈ Ωb and ≡ mini in case j ∈ Ωc .

V V
where
i i
The negative ideal solutions is given by:

X − = [(xi−L −L −L −L −L −L −L −L −U −U −U −U −U −U −U −U
j1 , xi j2 , xi j3 , xi j4 , xi j5 , vi j , vi j1 , vi j2 ), (xi j1 , xi j2 , xi j3 , xi j4 , xi j5 , vi j , vi j1 , vi j2 )] =
_ _ _ _ _ _ _ _ _ _
[( uLij1 , uLij2 , uLij3 , uLij4 , uLij5 , vLij , vLij1 , vLij2 ), ( uUij1 , uUij2 , uUij3 , uUij4 , uUij5 , vUij , vUij1 , vUij2 )]
i i i i i i i i i i
(3.76)

≡ mini in case j ∈ Ωb and ≡ maxi in case j ∈ Ωc .

W W
where i i

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:
m
+ 1 1
di1 = ∑ { 5 [(uLij1 − xi+Lj1 )2 + (uLij2 − xi+Lj2 )2 + (uLij3 − xi+Lj3 )2 + (uLij4 − xi+Lj4 )2 + (uLij5 − xi+Lj5 )2 ]} 2 (3.77)
j=1

m
+ 1 1
di2 = ∑ { 5 [(uUij1 − xi+U 2 U +U 2 U +U 2 U +U 2 U +U 2 2
j1 ) + (ui j2 − xi j2 ) + (ui j3 − xi j3 ) + (ui j4 − xi j4 ) + (ui j5 − xi j5 ) ]} (3.78)
j=1
 3.1 Related Methodologies 59

Likewise the distances of each alternative from the negative ideal solution are estimated
by:
m 1
−
di1 = ∑ {15[(uLij1 − xi−Lj1 )2 + (uLij2 − xi−Lj2 )2 + (uLij3 − xi−Lj3 )2 + (uLij4 − xi−Lj4 )2 + (uLij5 − xi−Lj5 )2 ]} 2 (3.79)
j=1

m
− 1 1
di2 = ∑ { 5 [(uUij1 − xi−U 2 U −U 2 U −U 2 U −U 2 U −U 2 2
j1 ) + (ui j2 − xi j2 ) + (ui j3 − xi j3 ) + (ui j4 − xi j4 ) + (ui j5 − xi j5 ) ]} (3.80)
j=1

Consequently, similarly to [158] the distance of the alternatives from the positive and
+ + − −
negative ideal solutions are expressed by intervals such as [di1 , di2 ] and [di1 , di2 ], 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:
−
di1
RCi1 = + − (3.81)
di1 + di1

and −
di2
RCi2 = + − (3.82)
di2 + di2
The compound relative closeness RCi is obtained from the average of the above values
RCi1 + RCi2
RCi = (3.83)
2

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 WiMAX IEEE 802.11e Required Required Required Required

Services
(Type/ Priority) QoS class QoS class Throughput Packet loss Delay Jitter
VoIP, CVideo,
UGS/ ertPS −2 BStreaming,
1 (GBR/ 2) AC_VO 200 Kbps 10 100ms 50ms
(802.16e- RTGaming,
802.16m) Web
CVideo,
BStreaming,
3 (GBR/ 3) UGS AC_VO 250 Kbps 10−3 50ms 40ms
RTGaming,
Web
CVideo,
2 (GBR/ 4) UGS AC_VI 8 Mbps 10−3 65ms 50ms BStreaming,
Web
CVideo,
4 (GBR/ 5) rtPS AC_VI 8 Mbps 10−5 65ms 60ms BStreaming,
Web
BStreaming,
6 (Non-GBR/ 6) nrtPS AC_BE 2.5 Mbps 10−5 200ms N/A
Web
BStreaming,
7 (Non-GBR/ 7) nrtPS AC_BE 2 Mbps 10−5 160ms 100ms
Web
8 (Non-GBR/ 8) BE AC_BE 1.5 Mbps −3 300ms N/A
10
Web
9 (Non-GBR/ 9) BE AC_BE 1.5 Mbps 10−5 300ms N/A

Network selection weights

Goal per service & SLA

Criteria Groups
Network QoS Network Policy
Characteristics Characteristics

Criteria
Throughput Price

Delay Service Reliability

Jitter
Security
Packet Loss

Figure 3.3 The ANP Network Model.

Throughput Price

Service
Delay Jitter
Reliability

Packet loss 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.
SLA1
0.8
Throughput
Delay
Jitter
0.7 Packet Loss
Price
Reliability
Security
0.6

0.5
Weight

0.4

0.3

0.2

0.1

0
VoIP ConversationalVideo BufferedStreaming RealTimeGaming Web

Figure 3.5 Criteria Weights for SLA1.

 3.1 Related Methodologies 63

SLA2
0.45
Throughput
Delay
Jitter
0.4
Packet Loss
Price
Reliability
0.35 Security

0.3

0.25
Weight

0.2

0.15

0.1

0.05

0
ConversationalVideo BufferedStreaming Web

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

SLA3
0.5
Throughput
Delay
Jitter
Packet Loss
Price
0.4 Reliability
Security

0.3
Weight

0.2

0.1

0
BufferedStreaming Web

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

SLA4
0.45
Throughput
Delay
Jitter
0.4
Packet Loss
Price
Reliability
0.35 Security

0.3

0.25
Weight

0.2

0.15

0.1

0.05

0
Web

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

Trapezoidal Fuzzy Topsis Results

0.2
LTE 1
LTE 2
WiMAX 1
WiMAX 2
WiFi 1
WiFi 2
WiFi 3
0.15
Network Score

0.1

0.05

0
User1 User2 User3 User4 User5 User6 User7 User8 User9

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

7
Scenario 1
Scenario 2
Scenario 3
6

5
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

Figure 3.10 The TFT’s Network Ranking for User 1 in case of Network Environment Changes.

7
Scenario 1
Scenario 2
Scenario 3
6

5
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

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.

Packet Service
SLA Service Network Throughput Delay Jitter Price Security
Loss Reliability
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
VoIP 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
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
CVideo 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
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
SLA1 BStreaming 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
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
RTGaming 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
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
Web 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
LTE 1 MG G VG AG MP G G
LTE 2 MP M MG VG M G G
CVideo 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
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
SLA2 BStreaming 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
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
Web
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.

Packet Service Re-

SLA Service Network Throughput Delay Jitter Price Security
Loss liability
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
BStreaming
WiFi 1 G G MG AG G VP P
WiFi 2 G AG G VG MG VP P
SLA3 WiFi 3 MG VG MG AG G VP P
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
Web
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
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
SLA4 Web
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.
User 1

User 2

User 3

User 4

User 5

User 6

User 7

User 8

User 9
FAE

FAE

FAE

FAE

FAE

FAE

FAE

FAE

FAE
TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT

❵❵ Method
❵❵❵
T

Networks ❵❵❵❵❵
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

7
Scenario 1
Scenario 2
Scenario 3
6

5
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

Figure 3.12 The TFT’s Network Ranking for User 3 in case of Network Environment Changes.

7
Scenario 1
Scenario 2
Scenario 3
6

5
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

Figure 3.13 The TFT’s Network Ranking for User 4 in case of Network Environment Changes.
72 Mobility Management

6
Scenario 1
Scenario 2
Scenario 3

4
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

Figure 3.14 The TFT’s Network Ranking for User 5 in case of Network Environment Changes.

7
Scenario 1
Scenario 2
Scenario 3
6

5
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

Figure 3.15 The TFT’s Network Ranking for User 6 in case of Network Environment Changes.
3.1 Related Methodologies 73

5
Scenario 1
Scenario 2
Scenario 3

3
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

Figure 3.16 The TFT’s Network Ranking for User 7 in case of Network Environment Changes.

6
Scenario 1
Scenario 2
Scenario 3

4
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

Figure 3.17 The TFT’s Network Ranking for User 8 in case of Network Environment Changes.
74 Mobility Management

7
Scenario 1
Scenario 2
Scenario 3
6

5
Network Score

0
LTE1 LTE2 WiMAX1 WiMAX2 WiFi1 WiFi2 WiFi3
Available Networks

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)]

Trapezoidal Fuzzy Topsis results

0,14
0,12
Network Score

0,1
0,08
0,06
0,04
0,02
0
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
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 Network Throughput Delay Jitter Packet Service Security Price

Service Loss Reliability
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
Live WAVE1 MG MG G VG MG MG AG
Video 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
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
Medical WAVE1 MG MG AG MG MG G AG
Images 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
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
Sensor WAVE1 MP MG VG MG AG VG AG
Data 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
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
Clinical WAVE1 VG VG AG AG VG AG AG
Data 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
ANST

ANST

ANST

ANST

ANST

ANST

ANST

ANST

ANST

ANST
TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT
FAS

FAS

FAS

FAS

FAS

FAS

FAS

FAS

FAS

FAS
❵❵❵
Networks
❵❵Method
❵❵
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
X X X LTE Macro G MG VG AG VG AG VG
X X X VG AG VG VG AG MG P
Navigation Assistance

LTE Femto 1
X X LTE Femto 2 AG G AG G VG G G
X LTE Femto 3 G MG G MG G AG P
X LTE Femto 4 AG AG MG AG G G AP
X X X WiMAX Macro G AG G VG AG VG VP
X X X WAVE 1 VG MG VG AG VG AG G
(NAV)

X WAVE 2 MG MG VG VG G G AP
X X X WAVE 3 MG MG G VG MG MG M
X WAVE 4 M M MG VG MG MG MP
X X X LTE Macro MG M G VG VG AG MP
X X X LTE Femto 1 AG AG AG AG AG VG G
Parking Assistance

X X LTE Femto 2 VG AG M VG AG G AG
X LTE Femto 3 G VG MG AG VG AG MG
X LTE Femto 4 MG G M G VG G G
X X X WiMAX Macro G M M AG MG M MP
(PRK)

X X X WAVE 1 M MP MG VG G G VG
X WAVE 2 MG M M AG M M M
X X X WAVE 3 AG G G AG MG MG P
X WAVE 4 G M AG AG MG G G
X X LTE Macro AG AG AG VG VG AG G
X X LTE Femto 1 MP MG VG AG AG VG AP
Conversation Video

X X LTE Femto 2 G G MG VG AG MG M
X LTE Femto 3 AG VG AG G VG G P
X LTE Femto 4 G VG VG AG MG AG MG
X X WiMAX Macro MP M MG G G G MP
X X WAVE 1 G G VG VG G G M
(CV)

X WAVE 2 MG MG AG VG G MG AG
X X WAVE 3 MG MG G AG MG VG MP
X WAVE 4 MP MP MG AG MG G P
X LTE Macro VG VG AG AG VG AG AP
X LTE Femto 1 M G VG VG AG VG G
X LTE Femto 2 G VG MG AG VG G MG
Voice over IP

X LTE Femto 3 MG G G VG G MG MP
X LTE Femto 4 VG AG VG AG VG VG P
(VoIP)

X WiMAX Macro M G MG MG G G M
X WAVE 1 M MG AG AG G G VG
X WAVE 2 MG M VG AG MG M M
X WAVE 3 VG AG VG AG MG VG G
X WAVE 4 G VG G AG MG G AG
X X LTE Macro G MG VG AG VG AG VG
X X LTE Femto 1 VG AG AG VG AG VG P
Buffered Streaming

X X LTE Femto 2 AG VG VG MG MG AG G
X LTE Femto 3 G MG VG G VG G M
X LTE Femto 4 AG AG AG VG G G P
X X WiMAX Macro G AG G VG AG VG VP
X X WAVE 1 VG MG VG AG VG AG G
(BS)

X WAVE 2 MG MG VG VG G G AP
X X WAVE 3 MG MG G VG MG MG M
X WAVE 4 M M MG VG MG MG MP
X X X LTE Macro MG M G VG VG AG MP
X X X LTE Femto 1 AG AG AG AG AG VG G
X X LTE Femto 2 G G M G G VG G
Web Browsing

X LTE Femto 3 AG AG MG AG VG MG M
X LTE Femto 4 VG G G VG MG G MG
X X X WiMAX Macro G VG MG G M VG M
(WB)

X X X WAVE 1 M MP MG VG G G VG
X WAVE 2 MG M M AG M M M
X X X WAVE 3 AG G G AG MG MG AP
X WAVE 4 G M AG AG MG G G
X X X LTE Macro MG MG G VG MG VG MP
X X X MP MG VG AG AG VG AP
Live Healthcare Video

LTE Femto 1
X X LTE Femto 2 G VG AG AG VG G G
X LTE Femto 3 VG AG G AG G MG M
X LTE Femto 4 MG G VG G AG AG G
X X X MP M MG G G G MP
(LHVideo)

WiMAX Macro
X X X WAVE 1 G G VG VG G G M
X WAVE 2 MG MG AG VG G MG AG
X X X WAVE 3 AG AG AG AG VG AG G
X WAVE 4 MP MP MG AG MG G P
X X X LTE Macro M MG AG AG G AG VG
X X X LTE Femto 1 M G VG VG AG VG G
X X LTE Femto 2 AG AG VG AG VG AG P
Medical Images

X VG MG G MG G MG MP
(MedImages)

LTE Femto 3
X LTE Femto 4 G G VG G AG G MP
X X X WiMAX Macro M G MG VG G G M
X X X WAVE 1 VG VG AG AG VG AG AP
X WAVE 2 MG M VG AG MG M M
X X X WAVE 3 VG AG VG AG MG VG G
X WAVE 4 G VG G AG MG G MP
X X X LTE Macro G MG VG AG VG AG VG
X X X LTE Femto 1 VG AG AG VG AG VG P
Health Monitoring

X X LTE Femto 2 AG G G G MG G VG
X VG AG MG AG MG VG G
(HMonitoring)

LTE Femto 3
X LTE Femto 4 G VG VG G G G VG
X X X WiMAX Macro G AG G VG AG VG VP
X X X WAVE 1 VG MG VG AG VG AG G
X WAVE 2 MG MG VG VG G G AP
X X X WAVE 3 MG MG G VG MG MG M
X WAVE 4 M M MG VG MG MG MP
X X X LTE Macro MG M G VG VG AG MP
Clinical Data Transmission

X X X LTE Femto 1 AG AG AG AG AG VG P
X X LTE Femto 2 AG VG MG VG VG G M
X LTE Femto 3 G AG M G G MG M
X LTE Femto 4 VG G G AG VG AG G
X X X WiMAX Macro G MG VG G VG MG AG
X X X WAVE 1 M MP MG VG G G AG
(CData)

X WAVE 2 MG M M AG M M M
X X X WAVE 3 AG G G AG MG MG P
X 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
TFT-ACW

TFT-ACW

TFT-ACW

TFT-ACW

TFT-ACW

TFT-ACW

TFT-ACW

TFT-ACW

TFT-ACW

TFT-ACW
FSAW

FSAW

FSAW

FSAW

FSAW

FSAW

FSAW

FSAW

FSAW

FSAW
TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT

TFT

❵❵❵
Networks
❵❵Method
❵❵
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

Cloud
...
VM
... Services VM
VM Services
Services
...
SDN
controller

Heterogeneous Access Network Environment

Vehicle 1
Vehicle 2 Vehicle 3

Vehicle 10
LTE LTE
Femto1 Femto2
Vehicle 9 WAVE RSU1

WAVE RSU2

WiMAX
Macro

LTE Macro

Vehicle 4
Vehicle 8
LTE
Femto4
WAVE RSU4
LTE
Femto3 WAVE RSU3
Vehicle 7
Vehicle 6
Vehicle 5

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 ω̃ p̃s 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 ω̃ p̃s 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

Criteria Weights for Driver Assistance services per SLA

0,35

TF-AANP weight
0,3
0,25
0,2
0,15
0,1
0,05
0
SLA 1 SLA 2 SLA 3 SLA 1 SLA 2 SLA 3
Navigation Assistance Parking Assistance
Throughput Delay Jitter Packet loss Service Reliability Security Price

Figure 3.23 The TF-AANP Criteria Weights for the DA Services per SLA.

Criteria Weights for Passengers Entertainment and Information services per SLA
0,35
TF-AANP weight

0,3
0,25
0,2
0,15
0,1
0,05
0
SLA 1 SLA 1 SLA 2 SLA 1 SLA 2 SLA 1 SLA 2 SLA 3
VoIP Conversational Video Buffered Streaming Web
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.

The TF-AANP weights for each vehicle

0,35
0,3
TF-AANP weight

0,25
0,2
0,15
0,1
0,05
0
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
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 γth M and the γ F , for Macrocells and
th
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 · R2
−η

is satisfied, or to the nearest Femtocell if P1 · B1 · R−η −η

1 < P2 · B2 · R2 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 · R2 . 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] X X X
SSHVeT [180] X
PHMVV [204] X X
MAH-SCE [205] X X
NASH [226] X X X
MAH-UDVE [186] X
RHVN [227] X X X
S-VHO [207] X X
BFP-NEMO [200] X
IINH [182] X
IHVN [229] X X X
VANBA [230] X X X
iMAG-IDH [221] X X
VFMIPv6 [231] X X X
MIH-PGI [208] X X
CVHO [209] X X
DPVHO [183] X
GVHO-TW [197] X
GVHO-PD [197] X
NA-GVHO [197] X
ePFMIPv6 [202] X
AAMP [211] X X
INS [187] X
HMM-KF [222] X X
QAH-SIP [223] X X
CAHP [184] X
HO-CALB [185] X
TOPSIS
X
[188][189]
TFT [171] X
TFT-ACW [66] X
VHO-VCC [67] X X
GEO-MACHU [214] X X
SAW [188] X
MEW [188] X
GRA [192] X
DIA [188] X
WPM [195] X
QICA-NS [196] X
IAS-FNN [199] X
FLB-VHO [219] X X
FMVHO [220] X X
HCA [217] X X
VAH [218] X X
100 Mobility Management

Mobility Management Schemes Classification

Message Algorithm
Control Entities
Exchange Models Categories

Vehicle Controlled Information Context aware

Mobility Centric
Management Hybrid Controlled Cost Function
Mobility Host Centric based
Network Management
Controlled MADM
Mobility
Management 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] X * *
SSHVeT [180] X
PHMVV [204] X * *
MAH-SCE [205] X * *
NASH [226] X * *
MAH-UDVE [186] X * *
RHVN [227] X * *
S-VHO [207] X * *
BFP-NEMO [200] X
IINH [182] X
IHVN [229] X * *
VANBA [230] X * *
iMAG-IDH [221] X * *
VFMIPv6 [231] X * *
MIH-PGI [208] X * *
CVHO [209] X * *
DPVHO [183] X
GVHO-TW [197] X X X
GVHO-PD [197] X X X
NA-GVHO [197] X X X
ePFMIPv6 [202] X X X
AAMP [211] X X X
INS [187] X * *
HMM-KF [222] X * *
QAH-SIP [223] X * *
CAHP [184] X
HO-CALB [185] X
TOPSIS [188][189] X * *
TFT [171] X * *
TFT-ACW [66] X X X
VHO-VCC [67] X X X
GEO-MACHU [214] X * *
SAW [188] X * *
MEW [188] X * *
GRA [192] X * *
DIA [188] X * *
WPM [195] X * *
QICA-NS [196] X * *
IAS-FNN [199] X * *
FLB-VHO [219] X * *
FMVHO [220] X * *
HCA [217] X * *
VAH [218] X * *
X: 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] + X
S-VHO [207] * *
BFP-NEMO [200] + X
IINH [182] + X
IHVN [229] + X
VANBA [230] + X
iMAG-IDH [221] + X
VFMIPv6 [231] + X
MIH-PGI [208] * X
CVHO [209] * *
DPVHO [183] * *
GVHO-TW [197] * *
GVHO-PD [197] * *
NA-GVHO [197] * *
ePFMIPv6 [202] + X
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] * X
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 User MADM Fuzzy Logic Neural Net- Context MIH Probabilistic Group Auction
based Centric based work based aware based based based
VHOMP [225] X X
SSHVeT [180] X X
PHMVV [204] X X
MAH-SCE [205] X X
NASH [226] X X
MAH-UDVE [186] X
RHVN [227] X
S-VHO [207] X
BFP-NEMO [200] X
IINH [182] X
IHVN [229] X
VANBA [230] X
iMAG-IDH [221] X
VFMIPv6 [231] X X
MIH-PGI [208] X X
CVHO [209] X X X
DPVHO [183] X X X
GVHO-TW [197] X X
GVHO-PD [197] X X
NA-GVHO [197] X X
ePFMIPv6 [202] X
AAMP [211] X X
INS [187] X
HMM-KF [222] X
QAH-SIP [223] X X
CAHP [184] X
HO-CALB [185] X
TOPSIS [188][189] X
TFT [171] X X
TFT-ACW [66] X X
VHO-VCC [67] X X X X
GEO-MACHU [214] X X X
SAW [188] X
MEW [188] X
GRA [192] X
DIA [188] X
WPM [195] X
QICA-NS [196] X X X
IAS-FNN [199] X X X
FLB-VHO [219] X X
FMVHO [220] X X
HCA [217] X
VAH [218] X
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
Yes No Yes
(VuC)
Vehicles using Fog (VuF) Yes No Yes
Software Defined Vehicu-
Yes Optional Yes
lar Architectures (SDN-V)
Hybrid Vehicular Architec-
Yes Optional Yes
tures (HVA)
112 Mobility Management

Table 3.26 The Applicability of each Scheme to the Available 5G-VCC Architectures.

Vehicles Vehicles Software Hybrid

Vehicular
Scheme using using Defined Vehicular
Cloud (VC)
Cloud Fog Vehicular Architectures
(VuC) (VuF) Architectures (HVA)
(SDN-V)
VHOMP [225] X X X X
SSHVeT [180] X X X X
PHMVV [204] X X X X
MAH-SCE [205] X X X X
NASH [226] X X X X
MAH-UDVE [186] X X X X
RHVN [227] X X X X
S-VHO [207] X X X X
BFP-NEMO [200] X X X X
IINH [182] X X X X
IHVN [229] X X X X
VANBA [230] X X X X X
iMAG-IDH [221] X X X X
VFMIPv6 [231] X X X X
MIH-PGI [208] X X X X
CVHO [209] X X X X
DPVHO [183] X X X X
GVHO-TW [197] X X X X
GVHO-PD [197] X X X X
NA-GVHO [197] X X X X
ePFMIPv6 [202] X X X X
AAMP [211] X X X X
INS [187] X X X X
HMM-KF [222] X X X X
QAH-SIP [223] X X X X
CAHP [184] X X X X
HO-CALB [185] X X X X
TOPSIS [188][189] X X X X
TFT [171] X X X X
TFT-ACW [66] X X X X
VHO-VCC [67] X X X X
GEO-MACHU [214] X X X X
SAW [188] X X X X
MEW [188] X X X X
GRA [192] X X X X
DIA [188] X X X X
WPM [195] X X X X
QICA-NS [196] X X X X
IAS-FNN [199] X X X X
FLB-VHO [219] X X X X
FMVHO [220] X X X X
HCA [217] X X X X X
VAH [218] X X X X
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.

5G-VCC Vehicles Vehicles Software Hybrid

PP Vehicular
P
Architecture using using Defined Vehicular
PP
Communication Cloud (VC)
PP Cloud Fog Vehicular Architectures
Model PP
(VuC) (VuF) Architectures (HVA)
(SDN-V)
Vehicle to X X X X X
Vehicle (V2V)
Vehicle to
X X X X
Infrastructure
(V2I)
Vehicle to X X X X X
Pedestrian (V2P)
Hybrid Vehicular
X X X X X
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.

Vehicle to Vehicle to Vehicle to Hybrid

Scheme Vehicular
Vehicle Infrastructure Pedestrian
(V2V) (V2I) (V2P) Communication
(HVC)
VHOMP [225] X
SSHVeT [180] X
PHMVV [204] X
MAH-SCE [205] X
NASH [226] X
MAH-UDVE [186] X
RHVN [227] X
S-VHO [207] X
BFP-NEMO [200] X
IINH [182] X
IHVN [229] X
VANBA [230] X X X X
iMAG-IDH [221] X
VFMIPv6 [231] X
MIH-PGI [208] X
CVHO [209] X
DPVHO [183] X
GVHO-TW [197] X
GVHO-PD [197] X
NA-GVHO [197] X
ePFMIPv6 [202] X
AAMP [211] X
INS [187] X
HMM-KF [222] X
QAH-SIP [223] X
CAHP [184] X
HO-CALB [185] X
TOPSIS [188][189] X
TFT [171] X
TFT-ACW [66] X
VHO-VCC [67] X
GEO-MACHU [214] X
SAW [188] X
MEW [188] X
GRA [192] X
DIA [188] X
WPM [195] X
QICA-NS [196] X
IAS-FNN [199] X
FLB-VHO [219] X
FMVHO [220] X
HCA [217] X X X X
VAH [218] X
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 ,w j,k and w p,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.
 K 
 1 1 1
Qu,i = ∑ (wth,k · thu,i,k + wd,k · du,i,k + w j,k · ju,i,k + w pl,k · plu,i,k )/N /K (4.1)
k=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 tu,iresidence of vehicle u in each available cell i is estimated using
4.2 System Architecture 119

formula 4.2 defined in [252], where r f is the radius of femtocell i and vu is the velocity of the
vehicle u.
residence π · ri
tu,i = (4.2)
2 · vu
Then, the vehicle velocity is obtained by formula 4.3 defined in [253].
π · NCRu
vu = √ (4.3)
4 · TCRmax · λu

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
residence > t residence , where t residence is the average residence time of
considered as alternative if tu,i u,mean u,mean
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

Fog MMaaS
Vehicle u Cloud
Current SDN Controller
Network i

A. VHO initiation
Monitoring of
Qu,i and SINR u,i
When Qu,i < Qth or
SINRu,i < SINR th:

Obtain Su,i (Qu,i, SINRu,I)

If Su,i < Sth:

C. Network selection
ObtainVelocity u(NCRu, TCRmax, λu)

If velocity = High:
Obtain offered characteristics of
Alternatives_Set_A(Macrocells)
Execute PFT for
Alternatives_Set_A(Macrocells)

Result=Selected_Network

If velocity = Medium:
Obtain Femtocells_subset
considering tresidence

B. Velocity Monitoring
Obtain offered characteristics of
Alternatives_Set_A
(Macrocells, Femtocells_subset)
Execute PFT for
Alternatives_Set_A
(Macrocells, Femtocells_subset)
Result=Selected_Network

If velocity = Low:
Obtain offered characteristics of
Alternatives_Set_A
(Macrocells, Femtocells)
Execute PFT for Alternatives_Set_A
(Macrocells, Femtocells)

Result=Selected_Network

Else:
Result=Handover_not_required

If Result=Selected_Network:

Fog
Selected_Network

D. VHO execution

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

Cloud
...
VM ...
VM Services
Services
... VM
... Services
...
VM Fog
Services
... a b c d e f g h i j k l m n o p q r s t u v w x y
... SDN controller 1 1
...
MMaaS
2 2
3 3
4 4
5 5
Fog 6 6 LTE Macrocell
7 7
LTE Femtocell
8 8
9 9 WiMAX Macrocell
WiMAX Macrocells
LTE Macrocells
10 10 WiMAX Femtocell
11 11
WAVE RSU
WiMAX Femtocells
12 12
Vehicle
LTE Femtocells 13 13
WAVE RSUs
14 14
15 15
16 16
17 17
18 18
19 19
a b c d e f g h i j k l m n o p q r s t u v w x y

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 Throughput Delay Jitter Packet

term range (Kbps) range (ms) range (ms) 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

Network Initiation weights

0,5
0,4
Weight

0,3
0,2
0,1
0
Navigation Assistance VoIP Conversational Video Buffered Streaming Web

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)
LTE Macrocell BSs: 20
Networks count LTE Femtocell BSs: 37
WiMAX Macrocell BSs: 17
WiMAX Femtocell BSs: 25
WAVE RSUs: 22
Total: 121
LTE/WiMAX Macrocells: 400 meters
Cells radius
LTE/WiMAX Femtocells: 30 meters
WAVE RSUs: 150 meters
According to the Hellenic Telecommu-
Networks positions nications and Post Commission (EETT)
[254] data (see Appendix A)
Networks frequencies See Appendix A
Service Layer Agreements
4
(SLA) count
Vehicles count 39807
Average vehicles arrival rate 0,460729167 vehicles per second
Average vehicles departure rate 0,46 vehicles per second
SLA 1: 9952 vehicles (25,00062803 %)
Vehicles per SLA 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
Navigation Assistance (NAV)
Services Voice over IP (VoIP)
Conversational Video (CV)
Buffered Streaming (BS)
Web Browsing (WB)
Distribution of services to See Appendix C
vehicles
Normal: 13348 (33.53 %)
Vehicles per velocity
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 (SINRdBu,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

Goal Network Selection Weights per Service

Criteria Groups

Network QoS Network Policy

Characteristics Characteristics

Criteria
Troughput Service Reliability

Delay Security

Jitter Price

Packet Loss

Figure 4.8 The PF-ANP Network Model.

130 A Proposed Mobility Management Approach for 5G-VCC Systems

Throughput

Price

Delay Jitter
Service
Security
Reliability
Packet loss

Figure 4.9 The Relations of the Criteria considered by the PF-ANP Network Model.

Network Selection weights for SLA 1

0,25
0,2
Weight

0,15
0,1
0,05
0
Navigation Assistance VoIP Conversational Video Buffered Streaming Web

Throughput Delay Jitter Packet loss Service Reliability Security Price

Figure 4.10 The Network Selection Weights per Service for SLA 1.

Network Selection weights for SLA 2

0,25
0,2
Weight

0,15
0,1
0,05
0
Conversational Video Buffered Streaming Web

Throughput Delay Jitter Packet loss Service Reliability Security Price

Figure 4.11 The Network Selection Weights per Service for SLA 2.

Network Selection weights for SLA 3

0,25
0,2
Weight

0,15
0,1
0,05
0
Buffered Streaming Web

Throughput Delay Jitter Packet loss Service Reliability Security Price

Figure 4.12 The Network Selection Weights per Service for SLA 3.

Network Selection weights for SLA 4

0,25
0,2
Weight

0,15
0,1
0,05
0
Web

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 Security Price

Reliability
[(0.37,0.36,0.34, [(0.37,0.36,0.34, [(0.37,0.36,0.34, [(0.37,0.36,0.34, [(0.37,0.36,0.349 [(0.37,0.36,0.34, [(0.37,0.36,0.34,
Throu-
0.33,0.32,1,0.8,0.8), 0.33,0.32,1,0.8,0.8), 0.33,0.32,1,0.8,0.8), 0.33,0.32,1,0.8,0.8), 0.33,0.32,1,0.8,0.8), 0.33,0.32,1,0.8,0.8), 0.33,0.32,1,0.8,0.8),
ghput
(0.36,0.36,0.34, (0.36,0.36,0.34, (0.36,0.36,0.34, (0.36,0.36,0.34, (0.36,0.36,0.34, (0.36,0.36,0.34, (0.36,0.36,0.34,
0.33,0.33,0.8,0.6,0.6)] 0.33,0.33,0.8,0.6,0.6)] 0.33,0.33,0.8,0.6,0.6)] 0.33,0.33,0.8,0.6,0.6)] 0.33,0.33,0.8,0.6,0.6)] 0.33,0.33,0.8,0.6,0.6)] 0.33,0.33,0.8,0.6,0.6)]
[(0.23,0.21,0.21, [(0.23,0.21,0.21 [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21,
Delay 0.21,0.21,1,0.8,0.8), ,0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21,
0.21,0.21,0.8,0.6,0.6)] 0.21,0.21,0.8,0.6,0.6)] 0.21,0.21,0.8,0.6,0.6)] 0.21,0.21,0.8,0.6,0.6)] 0.21,0.21,0.8,0.6,0.6)] 0.21,0.21,0.8,0.6,0.6)] 0.21,0.21,0.8,0.6,0.6)]
[(0.16,0.2,0.22, [(0.16,0.2,0.22, [(0.16,0.2,0.22, [(0.16,0.2,0.22, [(0.16,0.2,0.22, [(0.16,0.2,0.22, [(0.16,0.2,0.22,
Jitter 0.23,0.24,1,0.8,0.8), 0.23,0.24,1,0.8,0.8), 0.23,0.24,1,0.8,0.8), 0.23,0.24,1,0.8,0.8), 0.23,0.24,1,0.8,0.8), 0.23,0.24,1,0.8,0.8), 0.23,0.24,1,0.8,0.8),
(0.19,0.2,0.22, (0.19,0.2,0.22, (0.19,0.2,0.22, (0.19,0.2,0.22, (0.19,0.2,0.22, (0.19,0.2,0.22, (0.19,0.2,0.22,
0.23,0.23,0.8,0.6,0.6)] 0.23,0.23,0.8,0.6,0.6)] 0.23,0.23,0.8,0.6,0.6)] 0.23,0.23,0.8,0.6,0.6)] 0.23,0.23,0.8,0.6,0.6)] 0.23,0.23,0.8,0.6,0.6)] 0.23,0.23,0.8,0.6,0.6)]
Packet [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21, [(0.23,0.21,0.21,
loss 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8), 0.21,0.21,1,0.8,0.8),
(0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21, (0.21,0.21,0.21,
0.21,0.21,0.8,0.6)] 0.21,0.21,0.8,0.6)] 0.21,0.21,0.8,0.6)] 0.21,0.21,0.8,0.6)] 0.21,0.21,0.8,0.6)] 0.21,0.21,0.8,0.6)] 0.21,0.21,0.8,0.6)]
Service [(0.52,0.47,0.42 [(0.52,0.47,0.42, [(0.52,0.47,0.42, [(0.52,0.47,0.42, [(0.52,0.47,0.42, [(0.52,0.47,0.42, [(0.52,0.47,0.42,
Reliabil- ,0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8),
ity (0.48,0.45,0.42, (0.48,0.45,0.42, (0.48,0.45,0.42, (0.48,0.45,0.42, (0.48,0.45,0.42, (0.48,0.45,0.42, (0.48,0.45,0.42,
0.41,0.4,0.8,0.6,0.6)] 0.41,0.4,0.8,0.6,0.6)] 0.41,0.4,0.8,0.6,0.6)] 0.41,0.4,0.8,0.6,0.6)] 0.41,0.4,0.8,0.6,0.6)] 0.41,0.4,0.8,0.6,0.6)] 0.41,0.4,0.8,0.6,0.6)]
[(0.37,0.39,0.4, [(0.37,0.39,0.4, [(0.37,0.39,0.4, [(0.37,0.39,0.4, [(0.37,0.39,0.4, [(0.37,0.39,0.4, [(0.37,0.39,0.4,
Security 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8), 0.4,0.4,1,0.8,0.8),
(0.39,0.4,0.4, (0.39,0.4,0.4, (0.39,0.4,0.4, (0.39,0.4,0.4, (0.39,0.4,0.4, (0.39,0.4,0.4, (0.39,0.4,0.4,
0.4,0.4,0.8,0.6,0.6)] 0.4,0.4,0.8,0.6,0.6)] 0.405,0.4,0.8,0.6,0.6)] 0.4,0.403,0.8,0.6,0.6)] 0.4,0.4,0.8,0.6,0.6)] 0.4,0.4,0.8,0.6,0.6)] 0.4,0.4,0.8,0.6,0.6)]
[(0.09,0.13,0.16, [(0.09,0.13,0.16, [(0.09,0.13,0.16, [(0.09,0.13,0.16, [(0.09,0.13,0.16, [(0.09,0.13,0.16, [(0.09,0.13,0.16,
Price 0.18,0.19,1,0.8,0.8), 0.18,0.19,1,0.8,0.8), 0.18,0.19,1,0.8,0.8), 0.18,0.19,1,0.8,0.8), 0.18,0.19,1,0.8,0.8), 0.18,0.19,1,0.8,0.8), 0.18,0.19,1,0.8,0.8),
(0.12,0.14,0.16, (0.12,0.14,0.16, (0.12,0.14,0.166, (0.12,0.14,0.16, (0.12,0.14,0.16, (0.12,0.14,0.16, (0.12,0.14,0.16,
0.18,0.18,0.8,0.6,0.6)] 0.18,0.18,0.8,0.6,0.6)] 0.18,0.18,0.8,0.6,0.6)] 0.18,0.18,0.8,0.6,0.6)] 0.18,0.18,0.8,0.6,0.6)] 0.18,0.18,0.8,0.6,0.6)] 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 Security Price

Reliability
[(0.18,0.18,0.17, [(0.18,0.18,0.17, [(0.18,0.18,0.17, [(0.18,0.18,0.17, [(0.18,0.18,0.17, [(0.18,0.18,0.17, [(0.18,0.18,0.17,
Throu-
0.16,0.16,1,0.8,0.8), 0.16,0.16,1,0.8,0.8), 0.16,0.16,1,0.8,0.8), 0.16,0.16,1,0.8,0.8), 0.16,0.16,1,0.8,0.8), 0.16,0.16,1,0.8,0.8), 0.16,0.16,1,0.8,0.8),
ghput
(0.18,0.18,0.17, (0.18,0.18,0.17, (0.18,0.18,0.17, (0.18,0.18,0.17, (0.18,0.18,0.17, (0.18,0.18,0.17, (0.18,0.18,0.17,
0.16,0.16,0.8,0.6,0.6)] 0.16,0.16,0.8,0.6,0.6)] 0.16,0.16,0.8,0.6,0.6)] 0.16,0.16,0.8,0.6,0.6)] 0.16,0.16,0.8,0.6,0.6)] 0.16,0.16,0.8,0.6,0.6)] 0.16,0.16,0.8,0.6,0.6)]
[(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1,
Delay 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)] 0.106,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)] 0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)]
[(0.08,0.1,0.11, [(0.08,0.1,0.11, [(0.08,0.1,0.11, [(0.08,0.1,0.11, [(0.08,0.1,0.11, [(0.08,0.1,0.11, [(0.08,0.1,0.11,
Jitter 0.11,0.12,1,0.8,0.8), 0.11,0.12,1,0.8,0.8), 0.11,0.12,1,0.8,0.8), 0.11,0.12,1,0.8,0.8), 0.11,0.12,1,0.8,0.8), 0.11,0.12,1,0.8,0.8), 0.11,0.12,1,0.8,0.8),
(0.09,0.1,0.11, (0.09,0.1,0.11, (0.09,0.1,0.11, (0.09,0.1,0.11, (0.09,0.1,0.11, (0.09,0.1,0.11, (0.09,0.1,0.11,
0.11,0.11,0.8,0.6,0.6)] 0.11,0.11,0.8,0.6,0.6)] 0.11,0.11,0.8,0.6,0.6)] 0.11,0.11,0.8,0.6,0.6)] 0.11,0.11,0.8,0.6,0.6)] 0.11,0.11,0.8,0.6,0.6)] 0.11,0.11,0.8,0.6,0.6)]
Packet [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1, [(0.11,0.1,0.1,
loss 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.10,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8), 0.1,0.1,1,0.8,0.8),
(0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1, (0.1,0.1,0.1,
0.1,0.1,0.8,0.6,0.6)] 0.106,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)] 0.1,0.1,0.8,0.6,0.6)]
Service [(0.26,0.23,0.21, [(0.26,0.23,0.21, [(0.26,0.23,0.21, [(0.26,0.23,0.21, [(0.26,0.23,0.21, [(0.26,0.23,0.21, [(0.26,0.23,0.21,
Reliabil- 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8),
ity (0.24,0.22,0.21, (0.24,0.22,0.21, (0.24,0.22,0.21, (0.24,0.22,0.21, (0.24,0.22,0.21, (0.24,0.22,0.21, (0.24,0.2,0.21,
0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)]
[(0.18,0.19,0.2, [(0.18,0.19,0.2, [(0.18,0.19,0.2, [(0.18,0.19,0.2, [(0.18,0.19,0.2, [(0.18,0.19,0.2, [(0.18,0.19,0.2,
Security 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8), 0.2,0.2,1,0.8,0.8),
(0.19,0.2,0.2, (0.19,0.2,0.2, (0.19,0.2,0.2, (0.19,0.2,0.2, (0.19,0.2,0.2, (0.19,0.2,0.2, (0.19,0.2,0.2,
0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)] 0.2,0.2,0.8,0.6,0.6)]
[(0.04,0.06,0.08, [(0.04,0.06,0.08, [(0.04,0.06,0.08, [(0.04,0.06,0.08, [(0.04,0.06,0.08, [(0.04,0.06,0.08, [(0.04,0.06,0.08,
Price 0.09,0.09,1,0.8,0.8), 0.09,0.09,1,0.8,0.8), 0.09,0.09,1,0.8,0.8), 0.09,0.09,1,0.8,0.8), 0.09,0.09,1,0.8,0.8), 0.09,0.09,1,0.8,0.8), 0.09,0.09,1,0.8,0.8),
(0.06,0.07,0.08, (0.06,0.07,0.08, (0.06,0.07,0.08, (0.06,0.07,0.08, (0.06,0.07,0.08, (0.06,0.07,0.08, (0.06,0.07,0.08,
0.09,0.09,0.8,0.6,0.6)] 0.09,0.09,0.8,0.6,0.6)] 0.09,0.09,0.8,0.6,0.6)] 0.09,0.09,0.8,0.6,0.6)] 0.09,0.09,0.8,0.6,0.6)] 0.09,0.09,0.8,0.6,0.6)] 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 Security Price

Reliability
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 0.195427 0.195427 0.195427 0.195427 0.195427 0.195427 0.195427
Reliability
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

PFT ranking of each VHO scheme

0,6

0,5

0,4

PFT rank
0,3

0,2

0,1

0
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10
v=Medium v=Normal v=Medium v=Normal v=High v=Normal v=High v=Medium v=High v=Normal
Current Network Proposed Scheme VAH FAT FAS FAM FAE

Figure 4.14 The PFT Ranking of each HO Scheme.

Satisfaction grade obtained from each VHO scheme

1
0,9
Satisfaction grade (Su,i)

0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Vehicle 7 Vehicle 8 Vehicle 9 Vehicle 10

Proposed VAH FAT FAS FAM FAE

Figure 4.15 The Satisfaction Grade obtained from each HO Scheme.

Average PFT ranking of each VHO scheme

0,49
0,48
Average PFT rank

0,47
0,46
0,45
0,44
0,43
Proposed VAH FAT FAS FAM FAE
VHO scheme

Figure 4.16 The Average PFT Ranking of each HO Scheme during the 24 Hours Simulation.

Average satisfaction grade obtained from each VHO scheme

0,76
Average satisfaction grade (Su,i)

0,74

0,72

0,7

0,68

0,66

0,64

0,62

0,6
Proposed VAH FAT FAS FAM FAE
VHO scheme

Figure 4.17 The Average Satisfaction Grade obtained from each HO Scheme during the 24
Hours Simulation.

VHOs count of each VHO scheme

450000

400000
VHOs count

350000

300000

250000

200000
Proposed VAH FAT FAS FAM FAE
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
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] İhsan 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.
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.

 Table B1 The available LTE networks of SLA 1.

SLA 1
NAV VoIP CV BS Web 166
Network

Price
Price
Price
Price
Price

Jitter
Jitter
Jitter
Jitter
Jitter

Delay
Delay
Delay
Delay
Delay

Security
Security
Security
Security
Security

Packet Loss
Packet Loss
Packet Loss
Packet Loss
Packet Loss

Throughput
Throughput
Throughput
Throughput
Throughput

Service Reliability
Service Reliability
Service Reliability
Service Reliability
Service Reliability
LTE Macro 1 AG AG G VG MG G AP AG AG G VG G VG VP G VG G MG MG M AP M MG AG M G AG P AG AG G VG VG AG AP
LTE Macro 2 VG AG G G AG AG AP M MG MG M G M P AG AG M VG M MG AP MG G MG M MG AG VP VG AG G G G AG P
LTE Macro 3 VG AG M G M G VP M MG MG M MG VG VP MG G G M VG MG VP G VG MG MG VG M P VG AG G G M AG VP
LTE Macro 4 M MG M M VG AG P M MG MG M G G P VG AG AG G VG AG P AG AG M VG MG G P MG G MG M G G VP
LTE Macro 5 AG AG VG VG VG AG VP AG AG VG VG M VG AP G VG AG MG AG M AP MG G VG MG AG G VP G VG AG MG M G VP
LTE Macro 6 M MG G M VG G P MG G MG M VG MG AP VG AG AG G G MG VP G G VG MG VG VG P AG AG VG VG VG AG VP
LTE Macro 7 MG G MG M AG G VP MG G G M M VG VP MG G G M M MG P VG AG AG G G MG P AG AG G VG G VG P
LTE Macro 8 MG G AG MG AG M P AG AG G VG AG AG AP AG AG AG VG AG G P G G M MG AG AG P G VG MG MG VG AG AP
LTE Macro 9 M MG VG M AG M VP M MG AG M MG M AP G VG G MG MG VG P VG AG VG G VG VG P M MG VG M AG AG P
LTE Macro 10 MG G AG MG MG MG AP AG AG M VG VG M P G VG G MG M AG VP G VG G MG AG AG P G VG MG MG G G VP
LTE Macro 11 M MG VG M VG MG VP M MG MG M AG MG VP G VG G MG M VG AP M MG MG M G G P G G MG MG G VG AP
LTE Macro 12 M MG M M VG G AP VG AG AG G G MG AP VG AG G G AG G VP AG AG MG VG G VG AP AG AG VG VG MG MG P
LTE Macro 13 VG AG MG G G MG AP M MG M M MG MG P AG AG VG VG G M P AG AG VG VG MG G AP VG AG VG G VG AG AP
LTE Macro 14 VG AG AG G MG M AP AG AG VG VG VG G P VG AG G G G AG VP VG AG G G G M AP G VG G MG G AG AP
LTE Macro 15 M MG MG M G VG P AG AG G VG G M P M MG G M VG VG AP M MG AG M VG AG VP AG AG M VG VG G AP
LTE Macro 16 AG AG MG VG AG VG VP VG AG VG G MG MG P VG AG AG G AG MG VP G G MG MG AG M P G VG MG MG G VG P
LTE Macro 17 G VG MG MG MG M VP AG AG AG VG AG M P G VG VG MG MG AG P G VG VG MG G AG AP VG AG VG G G MG AP
LTE Macro 18 MG G MG M G G VP VG AG G G VG VG VP G VG G MG AG MG AP MG G MG M VG MG AP M MG AG M G G VP
LTE Macro 19 AG AG MG VG AG VG VP MG G MG M G M VP G VG AG MG G G P G VG M MG VG MG AP VG AG VG G VG VG P
LTE Macro 20 M MG MG M AG AG VP MG G G M M G P MG G G M AG MG VP G VG G MG MG M AP MG G AG M VG VG P
LTE Femto 1 MG G AG M MG M P VG AG M G VG M VP MG G VG M VG AG AP VG AG M G G VG VP G VG MG MG AG G VP
LTE Femto 2 VG AG M G M M AP AG AG G VG M M AP MG G M M VG MG AP MG G M M VG MG P G VG MG MG G MG P
LTE Femto 3 AG AG MG VG VG MG P AG AG G VG AG VG VP G VG G MG VG G P AG AG VG VG G G VP VG AG MG G MG VG AP
LTE Femto 4 MG G AG M VG AG VP G VG VG MG VG AG VP G VG G MG AG MG VP MG G G M M AG AP AG AG G VG MG G VP
LTE Femto 5 MG G M M G G VP M MG MG M AG M P VG AG AG G VG AG AP VG AG AG G G VG P G VG VG MG AG VG P
LTE Femto 6 AG AG M VG VG VG AP AG AG AG VG MG M P M MG AG M G VG AP M MG MG M VG AG AP MG G G M MG AG P
LTE Femto 7 MG G M M M MG AP VG AG VG G VG M VP AG AG G VG MG MG AP MG G MG M VG VG P AG AG G VG AG G P
LTE Femto 8 M MG AG M MG M VP AG AG M VG M M VP AG AG AG VG G AG P G VG G MG MG M P AG AG AG VG VG G AP
LTE Femto 9 G VG M MG AG VG VP MG G G M M MG AP G VG MG MG MG MG AP MG G G M MG AG P M MG MG M MG AG AP
LTE Femto 10 VG AG AG G G M AP VG AG VG G VG VG VP AG AG VG VG MG AG AP VG AG M G AG MG AP VG AG VG G G AG AP
LTE Femto 11 AG AG G VG VG AG P AG AG G VG M MG AP G G M MG M M P AG AG G VG MG M P AG AG G VG MG VG VP
LTE Femto 12 MG G M M VG MG P M MG VG M VG AG AP MG G AG M G G AP AG AG MG VG G G AP M MG G M VG VG P
LTE Femto 13 MG G MG M M M P VG AG M G M M VP AG AG M VG AG G VP MG G AG M G MG VP AG AG G VG G MG AP
LTE Femto 14 G VG M MG M AG VP MG G G M AG G VP VG AG VG G VG MG VP AG AG M VG MG G VP G VG MG MG G AG AP
LTE Femto 15 MG G G M G G AP MG G G M AG MG P M MG AG M AG M VP MG G MG M G AG AP VG AG MG G MG MG VP
LTE Femto 16 VG AG M G VG MG VP AG AG M VG AG G VP G VG MG MG G MG P G G MG G AG VG VP AG AG M VG M AG AP
LTE Femto 17 VG AG M G AG VG P VG AG AG G VG MG VP MG G AG M VG VG P AG AG VG VG G M AP G G MG MG G VG AP
LTE Femto 18 MG G M M VG G P G VG M MG MG G VP VG AG MG G AG MG P G VG MG MG VG MG AP G VG VG MG VG AG VP
LTE Femto 19 VG AG G G AG M P VG AG AG G G AG AP AG AG M VG VG M AP VG AG G G G G P VG AG MG G MG G P
LTE Femto 20 G VG G MG MG AG AP M MG MG M MG M VP VG AG AG G MG MG AP VG AG VG G G G VP MG G G M G MG VP
LTE Femto 21 M MG G M VG AG VP M MG M M MG AG AP G VG G MG MG VG AP M MG G M MG M AP VG AG MG G VG MG P
LTE Femto 22 AG AG MG VG VG AG VP G VG MG MG AG VG VP AG AG AG VG VG AG P M MG VG M G G P MG G VG M M M VP
LTE Femto 23 M MG G M M AG P AG AG M VG MG AG AP AG AG MG VG G MG P G VG AG MG VG G AP M MG M M AG G P
LTE Femto 24 MG G MG M AG AG AP AG AG MG VG M M VP MG G MG M G G AP M MG VG M M G P VG AG MG G AG G P
LTE Femto 25 G VG AG MG G MG AP G VG G MG MG MG VP AG AG AG VG VG VG P VG AG AG G G G AP AG AG AG VG VG AG VP
LTE Femto 26 G VG G MG M G VP MG G AG M G G VP AG AG M VG G G VP G VG G MG VG G VP M MG VG M G VG AP
LTE Femto 27 MG G G M G M AP VG AG G G VG AG P MG G G MG AG AG VP G VG AG MG G VG P AG AG AG VG VG G AP
LTE Femto 28 M MG G M MG G VP MG G G M G G VP MG G AG M G G AP G G VG MG G MG VP G VG VG MG G MG P
LTE Femto 29 VG AG M G M MG AP AG AG VG VG VG AG P G VG MG MG MG M VP AG AG AG VG MG MG VP M MG VG M MG G AP
LTE Femto 30 AG AG AG VG M AG VP G VG M MG MG MG AP MG G G M G G VP AG AG G VG G AG P M MG M M G G VP
LTE Femto 31 VG AG AG G AG MG P AG AG VG VG VG AG AP MG G G M G M AP M MG MG M MG M AP AG AG G VG AG G AP
LTE Femto 32 VG AG AG G VG MG AP G VG M MG G MG VP VG AG VG G M MG VP MG G M M MG G AP M MG M M VG MG VP
The available networks per SLA

LTE Femto 33 AG AG MG VG AG MG P G VG M MG M VG VP VG AG AG G G AG P VG AG G G VG VG VP G VG VG MG G VG P
LTE Femto 34 AG AG G VG MG MG VP VG AG MG G MG MG P VG AG M G G MG VP M MG VG M AG AG VP MG G VG M G M P
LTE Femto 35 VG AG G G MG M VP G VG M MG AG VG P VG AG VG G MG MG P VG AG G G MG AG P G VG G MG VG M P
LTE Femto 36 G VG M MG MG G AP MG G VG M MG AG VP VG AG G G AG MG AP MG G VG M AG MG P G VG MG MG M G AP
LTE Femto 37 G VG AG MG M MG P AG AG VG VG VG AG AP AG AG VG VG M G AP AG AG AG VG MG MG AP G VG VG MG VG MG P
 Table B2 The available WiMAX and WAVE networks of SLA 1.
SLA 1
NAV VoIP CV BS Web

Network

Price
Price
Price
Price
Price

Jitter
Jitter
Jitter
Jitter
Jitter

Delay
Delay
Delay
Delay
Delay

Security
Security
Security
Security
Security

Packet Loss
Packet Loss
Packet Loss
Packet Loss
Packet Loss

Throughput
Throughput
Throughput
Throughput
Throughput

Service Reliability
Service Reliability
Service Reliability
Service Reliability
Service Reliability
WiMAX Macro 1 MG G G M G VG P G VG VG MG VG G P M MG M M VG M P G G VG MG G MG AP MG G M M AG G AP
WiMAX Macro 2 MG G M M MG G P MG G VG M MG G P AG AG G VG AG MG AP AG AG VG VG MG M AP G VG AG MG AG M P
WiMAX Macro 3 G VG MG MG G G VP MG G M M VG M P VG AG MG G G M P M MG G M MG M VP VG AG MG G AG M VP
WiMAX Macro 4 MG G M M AG VG VP MG G M M AG MG AP VG AG MG G VG M VP AG AG AG VG MG G P G VG M MG G AG AP
WiMAX Macro 5 AG AG AG VG MG M VP VG AG G G MG AG P VG AG M G AG M AP MG G VG M G G P AG AG G VG M G VP
WiMAX Macro 6 M MG MG M G M P MG G VG M VG VG AP VG AG G G VG M P G VG MG MG VG VG AP G VG G MG VG VG VP
WiMAX Macro 7 AG AG G VG M VG AP AG AG MG VG VG G P G VG MG MG VG M AP G VG M MG AG G AP MG G M M AG G AP
WiMAX Macro 8 M MG VG M AG MG VP VG AG MG G MG VG AP M MG VG M G G VP MG G G M G AG VP G VG MG MG M MG P
WiMAX Macro 9 AG AG M VG M MG P M MG M M AG VG AP AG AG G VG G M VP MG G MG M G M AP M MG MG M AG G VP
WiMAX Macro 10 MG G M M VG G P AG AG AG VG MG G VP AG AG G VG G MG VP G VG M MG M VG AP VG AG AG G G VG VP
WiMAX Macro 11 M MG G M VG MG AP MG G AG M G MG P G VG M MG G M AP G VG VG MG VG G P M MG VG M VG G VP
WiMAX Macro 12 G VG AG MG G M P AG AG VG VG G G P VG AG M G G AG AP VG AG G G G MG P VG AG G G M MG P
WiMAX Macro 13 G VG MG MG AG M VP M MG VG M M G P AG AG VG VG VG G VP M MG AG M AG G AP G VG G MG AG AG VP
WiMAX Macro 14 AG AG AG VG G M P M MG M M M VG P VG AG G G AG VG P MG G G M M VG AP MG G MG M G MG VP
WiMAX Macro 15 VG AG VG G MG G AP AG AG G VG G M VP MG G VG M VG MG P M MG M M AG G P G VG G MG VG MG AP
WiMAX Macro 16 M MG M M VG MG AP VG AG MG G M VG AP M MG M M MG MG AP G G VG MG VG G P AG AG AG VG G AG AP
WiMAX Macro 17 M MG G M G AG AP M MG MG M AG AG VP MG G G M AG VG VP AG AG VG VG G MG AP VG AG VG G VG MG VP
WiMAX Femto 1 VG AG AG G G MG AP M MG M M VG MG P MG G MG M G MG AP VG AG G G AG G AP G VG VG MG VG G P
WiMAX Femto 2 M MG G M MG AG VP G VG AG MG AG AG P M MG MG M VG VG VP G VG M MG M VG VP MG G VG M G VG P
WiMAX Femto 3 M MG G M AG G AP M MG AG M G M AP VG AG VG G G G AP MG G VG M M AG VP M MG MG M AG AG AP
WiMAX Femto 4 MG G VG M MG VG P AG AG AG VG VG MG P G VG G MG MG MG VP M MG M M M MG P G G G MG G M AP
WiMAX Femto 5 AG AG G VG G M VP VG AG MG G MG AG VP VG AG AG G AG VG VP VG AG M G VG VG P MG G M M MG M AP
WiMAX Femto 6 M MG MG M G VG AP MG G AG M M MG P VG AG G G MG M AP MG G VG M G G VP AG AG G VG VG VG VP
WiMAX Femto 7 MG G G M MG M VP M MG M M VG VG P G VG VG MG G VG P M MG G M G VG P AG AG VG VG G AG P
WiMAX Femto 8 G VG G MG G MG AP VG AG M G G VG P AG AG MG VG AG G P VG AG AG G MG AG VP AG AG VG VG VG MG AP
WiMAX Femto 9 MG G MG M VG M P M MG M M AG G AP MG G G M G MG VP M MG VG M AG M AP MG G MG M G G AP
WiMAX Femto 10 AG AG AG VG M AG AP G VG AG MG M MG AP G VG M MG G AG VP VG AG G G VG G P AG AG AG VG MG MG P
WiMAX Femto 11 MG G G M G AG P VG AG AG G VG G P AG AG AG VG MG G P AG AG VG VG G VG AP AG AG AG VG VG AG VP
WiMAX Femto 12 G VG G MG AG VG P M MG MG M M MG AP MG G MG M VG G P G VG G MG VG AG VP G VG MG MG G M P
WiMAX Femto 13 AG AG MG VG VG VG VP M MG AG M G M AP G VG VG MG G VG P AG AG VG VG G VG VP VG AG MG G MG M AP
WiMAX Femto 14 AG AG VG VG M G AP AG AG M VG M M AP VG AG MG G MG G VP AG AG VG VG VG G AP MG G G M VG G AP
WiMAX Femto 15 AG AG G VG G MG VP MG G VG M G MG VP G G MG MG G AG AP AG AG M VG MG G P G VG M MG MG MG P
WiMAX Femto 16 M MG M M MG M VP G VG M MG G M AP VG G MG G G AG P VG AG MG G AG VG P AG AG AG VG AG G P
WiMAX Femto 17 M MG G M MG M AP G VG VG MG M M AP G VG AG MG AG VG P MG G VG M VG AG VP VG AG AG G AG MG P
WiMAX Femto 18 G VG AG MG M VG VP AG AG VG VG VG M VP VG AG G G MG G P M MG AG M G VG P VG AG VG G AG M VP
WiMAX Femto 19 M MG M M G M VP AG AG M VG AG M VP AG AG G VG G M AP G VG MG MG G MG AP VG AG M G G VG P
WiMAX Femto 20 G VG AG MG G AG VP M MG M M M MG AP G VG MG MG M AG P MG G G M VG G P M MG AG M VG VG AP
WiMAX Femto 21 MG G M M MG AG P M MG M M M AG P M MG AG M M AG P G VG M MG VG G AP VG AG G G G G AP
WiMAX Femto 22 VG AG AG G MG M AP G VG M MG M AG VP G VG G MG VG M AP M MG VG M M VG VP MG G M M G MG AP
WiMAX Femto 23 MG G G M MG M AP VG AG AG G AG M VP MG G MG M G MG AP MG G G M G AG AP VG AG G G VG AG VP
WiMAX Femto 24 G VG M MG VG G VP AG AG AG VG MG MG AP G VG MG MG MG M VP G VG AG MG G MG AP VG AG VG G G G P
WiMAX Femto 25 MG G VG M MG VG AP VG AG G G VG G P MG G G M AG MG P VG AG AG G MG MG AP MG G AG M VG MG AP
WAVE 1 AG AG G VG VG VG VP G VG VG MG AG AG P MG G M M VG G P MG G G M VG AG P VG AG G G AG M VP
WAVE 2 VG AG MG G AG MG VP MG G MG M G M P VG AG AG G G M VP M MG VG M G VG AP M MG VG M VG MG P
WAVE 3 VG AG M G M VG AP M MG G M VG VG VP AG AG MG VG VG MG VP MG G M M VG G P MG G G G M VG VP
WAVE 4 AG AG AG VG AG AG P G VG M MG MG MG VP G G M MG AG G VP AG AG G VG AG MG VP G VG MG MG G VG AP
WAVE 5 M MG M M AG VG AP MG G VG M VG AG AP G VG VG MG MG MG AP AG AG G VG MG MG P M MG AG M M G AP
WAVE 6 M MG VG MG MG M VP G VG AG MG AG VG AP M MG G M MG G VP AG AG M VG G VG AP MG G G M G MG AP
WAVE 7 M MG AG M MG VG VP VG AG MG G M G P VG AG VG G AG G VP AG AG VG VG G G P VG AG G G AG VG AP
WAVE 8 MG G G MG MG MG VP M MG M M AG MG P VG AG AG G M MG AP AG AG G VG M MG P VG AG AG G G VG AP
WAVE 9 MG G G MG G M P M MG M M VG MG VP M MG M M VG VG P AG AG M VG VG G AP M MG G M AG G P
WAVE 10 MG G G M AG VG P M MG VG M AG M VP AG AG M VG MG G VP M MG G M MG G VP MG G VG M G AG AP
WAVE 11 M MG G M G AG AP VG AG G G M M VP G VG G MG MG MG VP AG AG G VG AG MG VP VG AG G G VG M P
WAVE 12 AG AG MG VG M VG VP AG AG VG VG VG G VP M MG VG M G VG VP VG AG MG G MG VG AP AG AG M VG G AG AP
WAVE 13 M MG G M G M VP MG G VG M VG MG P AG AG G VG VG G VP VG AG MG G AG G AP AG AG VG VG VG VG P
167

WAVE 14 AG AG AG VG G VG AP G VG VG MG G M AP G G G MG VG AG P M MG G M G MG P MG G MG M AG G VP
WAVE 15 G VG G MG M MG VP AG AG VG VG G MG AP AG AG G VG AG M VP M MG VG M G MG P MG G G M G AG VP
WAVE 16 VG AG MG M VG G VP G VG MG MG VG AG VP G VG AG MG G G AP VG AG AG G MG G AP G VG G MG AG G AP
WAVE 17 M MG VG M VG VG P VG AG AG G M MG VP M MG G M AG MG VP VG AG MG G MG M AP VG AG G G AG VG P
WAVE 18 G VG G MG MG AG AP MG G M M VG VG AP MG G M M VG G VP AG AG G VG AG G P M MG AG M VG G P
WAVE 19 VG AG MG G MG M P G VG AG MG VG G AP VG AG G G AG G P MG G AG M MG VG AP AG AG AG VG M AG AP
WAVE 20 M MG M M G G AP MG G AG M G MG VP VG AG MG G AG AG AP M MG MG M VG AG P M MG VG M AG AG VP
WAVE 21 M MG VG M VG AG P G VG AG MG MG G AP G VG M MG MG MG P G VG G MG AG VG VP G VG M MG MG G P
WAVE 22 MG G G MG MG G VP MG G G M G AG AP AG AG MG VG MG AG VP VG AG G G G MG VP AG AG G VG G AG AP
 Table B3 The available LTE networks of SLA 2, SLA 3 and SLA 4.

SLA 2 SLA 3 SLA 4

CV BS Web BS Web Web 168
Network

Price
Price
Price
Price
Price
Price

Jitter
Jitter
Jitter
Jitter
Jitter
Jitter

Delay
Delay
Delay
Delay
Delay
Delay

Secutiy
Security
Security
Security
Security
Security

Packet Loss
Packet Loss
Packet Loss
Packet Loss
Packet Loss
Packet Loss

Throughput
Throughput
Throughput
Throughput
Throughput
Throughput

Service Reliability
Service Reliability
Service Reliability
Service Reliability
Service Reliability
LTE Macro 1 G G G MG MG P P MP M MG P G MP P G G G MG G MP P MP M MG P M MP M P MP MG P MG MP M VP P VP AP Service Reliability
VP P VG
LTE Macro 2 M MG P MP M MP M MG G M M P MG M G G MP MG MP MG P P MP MP P P MP M M MG MP MP MP MG MG M M AP MP MP P G
LTE Macro 3 MG G G M G MG MP P MP M P P P M MG G P M M P M P MP P P P P M MG MG P M M P G AP VP VP AP M VP AG
LTE Macro 4 M MG P MP P MP MP G G P MG P G P MG G M M G M P MP M P P P P M MG MG MP M MG P M M M MP MP VP P AG
LTE Macro 5 MP M M P P M M MG G G M MG G M MG G P M M G M MG MG MG M P MP M M MG P MP M MP M AP VP P AP AP P AG
LTE Macro 6 MP M MP P G MG M G G G MG MP G M M MG G MP MG MP MP MG MG MP M MP P M M MG MP MP MP P G P MP MP VP VP P G
LTE Macro 7 MG G G M P M P M MG MG MP M P M M MG P MP G M P MP M P P MP P MG MP M P P P P M AP VP VP AP AP VP VG
LTE Macro 8 G G P MG P MP M G G P MG MG G MP M MG M MP G M P P MP P MP P M G M MG P MP MP MP M P MP AP VP VP MP AG
LTE Macro 9 MG G P M M G MP MP M MG P G MP P M MG MG MP MG MG P P MP MP VP M P G P MP M VP P MP G P MP P VP P VP AG
LTE Macro 10 G G G MG M M M MG G G M MP MG M P MP P P G M MP MP M P P MP P G P MP P P M MP MG P MP VP P AP MP VG
LTE Macro 11 M MG MP MP P MG MP P MP MG P G P M G G P MG G G M P MP MG P P P MG M MG P MP MP P G P MP VP VP MP P AG
LTE Macro 12 MP M G P MP G M MP M MG P M MG MP MP M P P MG MG P MP M MG P M MP MG MP M P P MP M M MP M VP P VP AP VG
LTE Macro 13 G G G MG G MP MP P MP MG P MG G M P MP P MP P P MP P MP MG P MP M M P MP P VP P P G P MP P VP P VP VG
LTE Macro 14 M MG MG MP G P M G G G MG P M MP P MP G P G G P M MG M MP P MP M P MP MG P MP P G P MP M VP MP AP G
LTE Macro 15 M MG MG MP G MP P P MP M P MG MP MP MG G P M P P P P MP M P P P M MP M P P P VP G MP M P P P VP VG
LTE Macro 16 MG G MP M P MG P G G MG MG MG P M M MG MG MP M MP M P MP M P P P M M MG P MP M P M M M P MP MP P G
LTE Macro 17 MP M P P P G M P MP P P P MG P M MG P MP MP MG P P MP P P P M G P MP P P MP M MG P MP AP VP VP VP G
LTE Macro 18 MG G M M MP M MP MG G MG M P MP M M MG G MP M G P P MP P P P MP G P MP P VP MP P G AP VP P AP P AP VG
LTE Macro 19 MP M MP P M P M G G MP MG MG P M MP M MG P MP MG M MP M MP MP MP P M MP M MP P MP MP G MP M P P P MP AG
LTE Macro 20 MG G MG M M MG M M MG G MP MG M MP MG G G M G M M MP M P P P M G MP M M P P M MG P MP AP P AP AP AG
LTE Femto 1 P MP G P G M MP G G M MG MG P P MP M P P M P P P MP P P MG P MG MP M P P M P M MP M VP P AP VP G
LTE Femto 2 P MP MP P M MG MP M MG P MP P MG MP MP M P MP G M M M MG P MP P MP G P MP P VP P P G P MP AP VP AP VP G
LTE Femto 3 G G MG MG M G M MG G G M MP P P MP M MP P P M M P MP P P MP P MG MP M MP P P P M VP P MP AP P AP VG
LTE Femto 4 G G P MG G M P MG G MG M P MP P MG G M M P G MP MP M MG P P P G MP M MP P P P G MP M MP P VP P VG
LTE Femto 5 G G M MG P MP M MG G MG M MG P M P MP G P G M P P MP P P MP P G P MP MP P MG P G P MP MP VP P VP VG
LTE Femto 6 P MP M P G P P P MP MG P M G MP MP M G P P M MP P MP MG P P P MG MP M MG P P MP MG MP M AP P VP MP G
LTE Femto 7 M MG P MP M M MP MG G MG M MP P P MG G G M MP M M M MG MP MP P P M P MP P P P P G P MP P VP VP P VG
LTE Femto 8 G G MP MG MP M P P MP G P MG MP P G G MP MG G M P P MP P P MP P G MG MG MP M P P G M M P MP P VP VG
LTE Femto 9 MG G M M MG M P MG G M M MG MP M M MG M MP MP MG M P MP M P MP MP G M MG M MP MP M G MP M MP P MP MP G
LTE Femto 10 P MP MG P MP MG M G G P MG MP MP MP MP M G P G G P MP M P P MP MP M MP M P P M MG G P MP P P P P AG
LTE Femto 11 G G P MG P MP M MP M G P MG M P MG G M M M MG P MP M P P P M M P MP M P P P MG P P P P VP VP AG
LTE Femto 12 P MP M P MP P MP MP M MG P G P MP MP M G P MG M M P MP M P M P MG P MP P VP MP MP M P MP VP VP VP MP G
LTE Femto 13 M MG P MP MP M MP MG G G M MP P MP MP M MG P G MG P MG MG MG M MP P G MP M M P MG MP M P MP VP VP VP VP VG
LTE Femto 14 MG G G M MG MP MP MG G P M MG M P P MP MP P MP G P P MP P P M MP G P MP MP P MP MP M VP P VP P VP MP VG
LTE Femto 15 P MP G P G P MP MG G M M MG M P MG G MG M MP M M MG MG P M MP MP MG P MP MP P MP M M P MP VP VP VP M VG
LTE Femto 16 M MG P MP G MG P MG G MG M M G M G G M MG MP M P P MP MP P P P M MG MG MP M MP MP M MP M MP P MP AP VG
LTE Femto 17 MG G MG M G MG M MG G P M MG MG P P MP P P M G MP MG MG P M MG MP MG P MP P VP MP MG G P MP AP VP MP M G
LTE Femto 18 MP M P P G MG M P MP MG P MG MP M MG G M M MG M M P MP MP P M MP G MG MG M M MG P MG M M AP MP M VP AG
LTE Femto 19 G G M MG G P MP MP M MP P G MG MP G G M MG P MG MP MP M P P M MG MG MG MG M M P MP M M M M MP AP MP AG
LTE Femto 20 M MG M MP MG P MP MP M M P G MP MP MG G MG M MG MG M MP M M P P MP G P MP M P M P M VP P AP AP M VP G
LTE Femto 21 P MP P P P M P P MP G P MG MP MP MG G M M G M M P MP MP VP MP MP MG MG MG M M M M M M M MP MP P AP G
LTE Femto 22 MG G G M MP MG P P MP MG P G MP MP MG G G M M M MP P MP MP P P P MG MG MG M M M M G AP VP M AP AP P AG
LTE Femto 23 MG G M M M M MP MG G G M M M M M MG M MP G P P MP M M P M P G M MG P MP M P MG MP M VP P P P AG
LTE Femto 24 M MG M MP G G M MP M M P P MG M MG G P M MP P M MP M M P P P G M MG P MP P P M M M VP MP P VP G
LTE Femto 25 G G G MG G MG MP P MP MG P MG MG MP M MG MG MP G G P P MP MP VP MG P G M MG M MP MP MG M P MP M VP VP VP VG
LTE Femto 26 MG G M M MG P M MG G MG M MP MP MP G G MP MG M M M P MP MG P P MP M M MG M MP P MP G M M M MP P P G
LTE Femto 27 MG G G M G G MP P MP P P MG P MP G G M MG P P M VP P P VP M P M M MG M MP P P MG MP M AP P VP VP AG
LTE Femto 28 P MP MP P M P P G G MP MG MP P MP M MG P MP MG M MP MG MG P M P P M M MG P MP P M M P MP AP VP AP AP G
LTE Femto 29 G G P MG P P MP G G G MG M MP MP MP M P P M M MP MG MG M M MG M M MP M P P M M M MP M P P P VP AG
LTE Femto 30 G G M MG MG P P P MP M P MG M M P MP G P M MP M MP M MG P M MP MG M MG MG MP MP MP MG MP M M P MP MP VG
LTE Femto 31 M MG G MP G P P M MG P MP P MP MP MP M G P MP MP P MP M P P P MP MG MP M P P MP P M VP P AP VP VP P G
LTE Femto 32 M MG G MP MP MG M MP M MP P P MG MP M MG MP MP MG P P MP M MP P P MP MG MP M P P M P G P MP AP VP MP AP AG
LTE Femto 33 MG G P M MP MP P M MG P MP MG P M MP M G P M G MP MP M P P MP P M MP M M P M M G MP M M P VP M AG
The available networks per SLA

LTE Femto 34 P MP P P P M MP M MG G MP M MP MP MP M MG P G MP MP MP M M MP M P MG P MP P VP M MP G VP P P AP M P VG
LTE Femto 35 P MP P P MP MP P G G G MG P MP P MG G G M G MP M P MP MG MP P P M P MP MP P MP P G P MP MP VP MP P AG
LTE Femto 36 M MG G MP MG P P M MG MP MP M P M P MP MP MP P G M P MP P P M P M VP P P MP P M M VP P VP P P AP VG
LTE Femto 37 P MP G P M M P MG G MP M M MG P P MP MP P MP MG M M MG MP MP M MG G P MP MP P MP M MG P MP VP P AP VP VG
 Table B4 The available WiMAX and WAVE networks of SLA 2, SLA 3 and SLA 4.
SLA 2 SLA 3 SLA 4
CV BS Web BS Web Web

Network

Price
Price
Price
Price
Price
Price

Jitter
Jitter
Jitter
Jitter
Jitter
Jitter

Delay
Delay
Delay
Delay
Delay
Delay

Secutiy
Security
Security
Security
Security
Security

Packet Loss
Packet Loss
Packet Loss
Packet Loss
Packet Loss
Packet Loss

Throughput
Throughput
Throughput
Throughput
Throughput
Throughput

Service Reliability
Service Reliability
Service Reliability
Service Reliability
Service Reliability
Service Reliability
WiMAX Macro 1 MP M M P P P P G G G MG G M P M MG MP MP MG MG P M MG MG MP P MP G M MG MP MP M P G AP VP AP AP M VP G
WiMAX Macro 2 G G MG MG G MG P P MP P P M MP P M MG MP MP M P MP P MP P P P MP M M MG MP MP M P M M M AP MP P P AG
WiMAX Macro 3 MG G MG M G MP P P MP P P P P M P MP P P M M M P MP P P P P MG P MP P P MP M G VP P VP AP AP MP G
WiMAX Macro 4 M MG P MP P P MP MP M MG P MG G MP MG G MP M MP G MP MP M MG P MP M M MG MG MP M P M G AP VP VP AP P MP G
WiMAX Macro 5 MP M MP P G P MP MP M P P MG G MP MG G M M M MP P MP M P P MP MP MG P MP M P MP P M AP VP P AP AP VP AG
WiMAX Macro 6 MP M G P G M M G G M MG P MP M M MG MP MP MG P MP MG M M M P MP MG M MG MP MP P P M VP P MP AP P AP VG
WiMAX Macro 7 M MG MG MP MG MP P MG G M M MG MG MP MP M P P M G MP MP M P P MP MP M MP M P P P P MG P MP AP VP MP AP AG
WiMAX Macro 8 M MG M MP G MP MP M MG G MP M P MP MP M MP P P MG P M M M MP MP P M MP M MP P P P MG P MP MP VP P VP AG
WiMAX Macro 9 M MG M MP G M M MP M P P MP P P MP M MP P MP G P MP M P P MP P G MP M P P P MP MG MP M VP P AP AP VG
WiMAX Macro 10 P MP MG P MG M MP MP M M P MP MP P P MP MG P G MP MP MP M M P MP MP M P MP MG P P P MG P MP AP VP P P G
WiMAX Macro 11 MP M P P G M MP P MP G P G MP M M MG MG MP P MG MP M MG M MP MP MP G P MP MP P MP P M VP P VP AP MP P AG
WiMAX Macro 12 MG G M M P MG M P MP G P G MG P P MP G P P MP M P MP MP P M P MG VP P P P P MP M AP VP P AP AP VP G
WiMAX Macro 13 MP M MP P G M P M MG G MP P MG P MP M MP P G MG M P MP M P P MG G P MP MP P M P MG P MP MP VP M VP VG
WiMAX Macro 14 MP M MG P M G M P MP G P M G MP MG G MP M G MP M VP P MG P M P M M MG P MP MP MP MG P MP VP VP MP AP G
WiMAX Macro 15 MG G P M P P M P MP P P MG M MP P MP G P M MP MP P MP P P P MP G P MP M P P MP G VP P VP AP P AP AG
WiMAX Macro 16 MP M P P MG MG MP G G MP MG G G M MG G M M MP M MP M MG MP MP MP MP M MG MG M M P M G P MP AP VP P MP VG
WiMAX Macro 17 MG G MP M P MP M G G MG MG M MP MP M MG MG MP MG MG MP M MG MP MP M MP G P MP P VP MG MG MG P MP AP VP P VP G
WiMAX Femto 1 MP M MG P G MG P M MG M MP MG MG MP G G M MG G MG P M MG MP MP P MG M MP M M P MP MP MG AP VP M AP VP P AG
WiMAX Femto 2 M MG MP MP M P MP MG G M M MP MP MP MG G P M P MG P P MP MP P MP MP M MP M P P P P G MP M AP P VP AP VG
WiMAX Femto 3 P MP MP P G M M MG G M M P MP MP MP M M P M M MP P MP MP P P P G MP M M P M M M VP P P AP AP P AG
WiMAX Femto 4 G G P MG MP P MP P MP MP P P MG P G G G MG P MP P P MP P P P MP M M MG MP MP P MP M MP M P P AP P VG
WiMAX Femto 5 G G MP MG M G M M MG P MP MP P P MP M MP P P M MP M MG P MP P P M MP M MP P P M G P MP AP P AP VP G
WiMAX Femto 6 M MG M MP MP M P M MG MG MP P MG M MP M G P M MP M M MG MP MP P M MG MP M MP P M P G AP VP VP AP MP P VG
WiMAX Femto 7 M MG MG MP MG M M P MP P P MG P M MG G MP M MG M M P MP P P P P G MP M MP P M M G VP P MP AP P VP VG
WiMAX Femto 8 G G M MG P MP MP MG G M M MP G MP P MP M P MP M MP P MP P P MP P M P MP P P MP M MG P MP VP VP MP P AG
WiMAX Femto 9 MG G G M P MP P MP M MG P MG P P P MP M P G G P MP M P P MP P G P MP M VP MG P M AP VP M AP MP VP G
WiMAX Femto 10 MG G MP M MP MP M MP M G P M MP MP P MP P P MG MG M MP M M P M MP G P MP P P MG M M VP P AP AP P P AG
WiMAX Femto 11 M MG M MP M G MP G G P MG MP MP P MP M M P M MP MP MG MG P M MP MP MG MP M M P MP MP G AP VP M AP VP VP AG
WiMAX Femto 12 MP M MG P G G P M MG G MP G MG P MP M M P M MP MP MP M P P MP MG G MP M M P MP P M AP VP MP AP MP P AG
WiMAX Femto 13 G G MG MG G P MP G G P MG G MG P MP M MG P MP MP P M MG P MP P MG G MP M P P MP MP M P MP P VP MP AP VG
WiMAX Femto 14 MP M P P M G P M MG MP MP MP G MP MP M M P P G P M MG MP MP P MG MG P MP M P P P M VP P AP VP AP AP AG
WiMAX Femto 15 G G M MG MP MP M MP M P P MG MP P G G MP MG MG P M MP M P P MG MP G M MG MP MP MP P G M M MP MP MP VP G
WiMAX Femto 16 G G MG MG G MG MP P MP M P MG P P M MG MG MP M MP M P MP M P P P M M MG MG MP M MP MG VP P MP AP AP AP VG
WiMAX Femto 17 MG G P M G MP P MP M P P P P MP G G MP MG MP P M MP M P P VP P G P MP MP P MP P M VP P AP AP P VP G
WiMAX Femto 18 G G G MG P MP P M MG MP MP P MP M G G MG MG M M MP P MP VP P P P M P MP MP P M P MG P MP VP P VP P AG
WiMAX Femto 19 MG G MP M MG M P P MP MG P M MP M MP M MP P G MP M P MP MG P M MP M P MP P P P P M P MP P VP P P VG
WiMAX Femto 20 MG G MG M M MG P MP M MP P G P MP MP M P P P MP MP MP M MP P MG P M P MP P P P MP MG P MP P P VP AP G
WiMAX Femto 21 P MP P P M P M G G M MG P M P M MG MP MP M G MP MG MG P M P MP G M MG MP MP MP M M M M VP MP MP P AG
WiMAX Femto 22 P MP P P G P M P MP G P P G MP M MG P MP P P MP P MP M P P MG MG P MP P P P P MG P MP AP VP VP AP AG
WiMAX Femto 23 MG G MG M G MG P MG G MP M M M P MG G M M MG MG M M MG MP MP M P MG M MG MP MP M MG MG P MP P VP AP AP VG
WiMAX Femto 24 MG G MP M M MP M MP M MG P P P M M MG P MP G M M MP M MG P P P MG MP M P P MG M G MP M P P AP MP AG
WiMAX Femto 25 MG G M M G P MP MG G M M MG MG P MP M M P G MG M MG M P M MG MP M P MP M P MG M MG VP P P AP AP MP AG
WAVE 1 MG G MP M MG G MP P MP MP P MP M P MP M M P MG P M P MP MP P MP M MG P MP M VP MP P G P MP M VP VP P G
WAVE 2 M MG P MP P M M P MP G P G G P M MG MG MP P MP MP P MP MP VP MP MP G MP M M P P MP MG VP P MP AP AP MP AG
WAVE 3 M MG MP MP G MP MP MP M M P MG G P MP M G P MP MG P MP M MP P MP M MG MP M M P P MG M AP VP M AP VP P AG
WAVE 4 G G M MG M MG P MP M G P G P MP M MG M MP G G P MP MP M P P P M P MP M P MP MP M VP P M AP AP AP AG
WAVE 5 MG G MP M MG P P P MP G P MP MG M MP M MG P M P P P MP MP P MP P G MP M M P P P G VP P P AP P AP VG
WAVE 6 M MG G MP M G P M MG M MP MG G MP P MP G P MP P M MP M P P MG M G P MP MG P MP P G P MP P VP VP VP AG
WAVE 7 P MP MG P P MP P MG G MG M M MP MP MP M MG P MG MP P M MG MG MP P MP G P MP P VP MG MP M VP P VP VP MP MP G
WAVE 8 G G P MG P M MP MG G M M P M MP G G G MG P MP MP M M MP MP P M G P MP M VP P MP G P MP P VP AP MP G
WAVE 9 MP M P P MP M M G G P MG MP G P P MP MP P P MG M MG M P M MP M M P MP MP P P P G VP P AP P VP P AG
WAVE 10 G G MP MG MG MP M MP M MP P MG G P P MP G P G MP P MP M MP P MG MP G P MP MP P P MP MG P MP VP VP P AP VG
WAVE 11 MP M P P MP MG M MP M MG P M P M G G M MG G M P MP M M P P P MG MG MG M M MP MP G M M M MP P VP G
WAVE 12 M MG MG MP G P MP M MG MG MP MG G P MG G MP M G G M M M MP MP M MG G M MG MP MP MG MP M M M MP MP VP MP VG
WAVE 13 G G G MG MP G P G G MG MG MG G P G G M MG MG MP P MG MG P M MG MP G P MP M P MP P M VP P M AP MP P AG
169

WAVE 14 G G MP MG M MG MP P MP G P G P P M MG MP MP P G M P MP P P MG P MG MP M MP P P P MG VP P VP AP AP VP AG
WAVE 15 P MP G P M P M MP M G P P MP MP P MP MG P G MP MP MP M M P P MP MG P MP P P MP MP M P MP VP VP AP VP AG
WAVE 16 G G P MG MG MG M MP M M P MG P P M MG MP MP P G M MP M P P MG P G MP M MP P P M M MP M VP P AP VP G
WAVE 17 P MP P P MG M M M MG MG MP M MP M MG G MG M MP MP MP MP M MP P M MP MG MP M M P MP MP G P MP P VP AP AP AG
WAVE 18 MG G MP M G G MP MG G MG M MP MP M P MP M P MP G M P MP MG P P MP M P MP P P MP MP M AP VP P AP AP MP AG
WAVE 19 M MG M MP MG MP M MP M MP P M P P MG G G M P MP P MP M P P MP P M MP M MP P P MP MG AP VP MP AP AP VP G
WAVE 20 M MG P MP MP P P MP M P P G M MP M MG G MP G MP P P MP P P MG MP MG M MG P MP MP MP M P MP AP VP VP P AG
WAVE 21 G G M MG MP MG MP M MG P MP G G P MP M P P M M M P P P P M M M MP M P P M M G MP M VP P VP P VG
WAVE 22 G G M MG MG MG M MG G G M G M M MP M MG P G MG P P MP P P MG MP M MP M M P M M MG VP P AP AP P M VG
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- Normal Medium High
cles (%) velocity velocity 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- Normal Medium High

cles (%) velocity velocity 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.

Number of ve- Normal Medium High

Network
hicles (%) velocity velocity 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 SLA 2 SLA 3 SLA 4 Sum

vehicles (%) vehicles (%) vehicles (%) vehicles (%)
NAV 322 - - - 322
(0,808902%) (0,808902%)
VoIP 321 - - - 321
(0,806390%) (0,806390%)
CV 321 1422 - - 1743
(0,806390%) (3,572236%) (4,378626%)
BS 321 1422 3318 - 5061
(0,806390%) (3,572236%) (8,335217%) (12,71384%)
WB 321 1422 3317 9951 15011
(0,806390%) (3,572236%) (8,332705%) (24,99811%) (37,70944%)
NAV, 321 - - - 321
VoIP (0,806390%) (0,806390%)
NAV, CV 321 - - - 321
(0,806390%) (0,806390%)
NAV, BS 321 - - - 321
(0,806390%) (0,806390%)
NAV, WB 321 - - - 321
(0,806390%) (0,806390%)
VoIP, CV 321 - - - 321
(0,806390%) (0,806390%)
VoIP, BS 321 - - - 321
(0,806390%) (0,806390%)
VoIP, WB 321 - - - 321
(0,806390%) (0,806390%)
CV, BS 321 1422 - - 1743
(0,806390%) (3,572236%) (4,378626%)
CV, WB 321 1422 - - 1743
(0,806390%) (3,572236%) (4,378626%)
BS, WB 321 1421 3317 - 5059
(0,806390%) (3,569723%) (8,332705%) (12,7088%)
NAV, 321 - - - 321
VoIP, CV (0,806390%) (0,806390%)
NAV, 321 - - - 321
VoIP, BS (0,806390%) (0,806390%)
NAV, 321 - - - 321
VoIP, WB (0,806390%) (0,806390%)
NAV, 321 - - - 321
CV, BS (0,806390%) (0,806390%)
NAV, 321 - - - 321
CV, WB (0,806390%) (0,806390%)
NAV, 321 - - - 321
BS, WB (0,806390%) (0,806390%)
VoIP, 321 - - - 321
CV, BS (0,806390%) (0,806390%)
VoIP, 321 - - - 321
CV, WB (0,806390%) (0,806390%)
VoIP, 321 - - - 321
BS, WB (0,806390%) (0,806390%)
CV, BS, 321 1421 - - 1742
WB (0,806390%) (3,569723%) (4,376114%)
NAV, 321 321
- - -
VoIP, CV, (0,806390%) (0,806390%)
BS
NAV, 321 321
- - -
VoIP, CV, (0,806390%) (0,806390%)
WB
NAV, 321 321
- - -
VoIP, BS, (0,806390%) (0,806390%)
WB
NAV, 321 321
- - -
CV, BS, (0,806390%) (0,806390%)
WB
VoIP, 321 321
- - -
CV, BS, (0,806390%) (0,806390%)
WB
NAV, 321 321
- - -
VoIP, CV, (0,806390%) (0,806390%)
BS, WB
Sum: 9952 9952 9952 9951 39807
(25,00062%) (25,00062%) (25,00062%) (24,99811%) (100%)
 ProQuest Number: 29297510

INFORMATION TO ALL USERS

The quality and completeness of this reproduction is dependent on the quality
and completeness of the copy made available to ProQuest.

Distributed by ProQuest LLC ( 2022 ).

Copyright of the Dissertation is held by the Author unless otherwise noted.

This work may be used in accordance with the terms of the Creative Commons license
or other rights statement, as indicated in the copyright statement or in the metadata
associated with this work. Unless otherwise specified in the copyright statement
or the metadata, all rights are reserved by the copyright holder.

This work is protected against unauthorized copying under Title 17,

United States Code and other applicable copyright laws.

Microform Edition where available © ProQuest LLC. No reproduction or digitization

of the Microform Edition is authorized without permission of ProQuest LLC.

ProQuest LLC
789 East Eisenhower Parkway
P.O. Box 1346
Ann Arbor, MI 48106 - 1346 USA