A Software Defined Networking based Adaptive Multimode
Decentralized Mobility Architecture for 5G(MEng (Research) Thesis)
A THESIS SUBMITTED TO
THE SCIENCE AND ENGINEERING FACULTY
OF QUEENSLAND UNIVERSITY OF TECHNOLOGY
IN FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF
MENG (RESEARCH)
Muhammad Mohtasim Sajjad
School of Electrical Engineering and Computer Science
Science and Engineering Faculty
Queensland University of Technology
2018
Copyright in Relation to This Thesis
c� Copyright 2018 by Muhammad Mohtasim Sajjad. All rights reserved.
Statement of Original Authorship
The work contained in this thesis has not been previously submitted to meet requirements for an
award at this or any other higher education institution. To the best of my knowledge and belief,
the thesis contains no material previously published or written by another person except where
due reference is made.
Signature:
Date:
i
QUT Verified Signature
ii
To my family
iii
iv
Abstract
The fifth generation (5G) of wireless networks are characterized by huge data surge owing to an
estimated 1000-fold increase in traffic demand over the next few years. The existing IP mobility
solutions which rely on a centralized anchor for mobility management, cannot sustain such high
traffic loads. In this context, the distributed mobility management (DMM) paradigm which
promises decentralized handover and traffic management, has recently emerged as a promising
approach for handling mobility in 5G networks.
The existing DMM solutions are primarily designed based on the network-based Proxy
Mobile IPv6 (PMIPv6) protocol and some of them have gradually evolved towards Software-
Defined Networking (SDN) principles. However, such solutions lack flexibility features and
thus incur high handover latencies and signaling costs under high mobility and session activity
scenarios. Addressing this problem, we have proposed a novel SDN-based Adaptive Multimode
Mobility (AMM) mechanism in which the IP handover support services such as buffering,
bicasting and path optimization are controlled by the SDN controller. A new Handover Mode
Selection phase among the traditional handover phases is introduced, in which the SDN con-
troller evaluates the mobility services a MN currently requires, and correspondingly enables or
disables them per application/flow. This makes the handover protocol more flexible and can
thus operate in multiple modes of operation.
We have developed analytical models to evaluate the performance of the AMM scheme for
high mobility and session activity scenarios. The performance evaluation in comparison to the
PMIPv6-based DMM solution, currently being standardized at the Internet Engineering Task
Force (IETF), shows significant reduction in session disruption delay and packet loss. The
signaling cost is also reduced if the handover support services are provided only to the chosen
flows.
v
We have also implemented the proposed AMM scheme in ns-3 network simulator for com-
parative handover latency evaluation. The AMM is implemented based on an existing ns-
3 implementation of the OpenFlow v1.3.5 protocol. We have also implemented the IETFs
PMIPv6-based DMM solution in ns-3 for comparison. Simulation results have shown min-
imized handover latency of the AMM scheme under high mobility with multiple ongoing
sessions, compared to the PMIPv6-based DMM.
vi
Keywords
Distributed Mobility Management (DMM), 5G, Software Defined Networking (SDN), Open-
Flow protocol, ns-3, Adaptive Mobility
vii
viii
Acknowledgments
During my research journey at QUT, I was fortunate enough to have the guidance of esteemed
Supervisors, and a highly conducive research environment.
First and foremost, I would like to express my sincere gratitude to my Principal Supervisor
Dr. Dhammika Jayalath for this guidance, support and patience. I have received invaluable
advice throughout this Masters program from his side, and have had enormous learning experi-
ence under his supervision. I would also like to thank my Associate Supervisor Prof. Glen Tian
who not only provided me useful advice and insights into my research, but also encouraged and
supported me in numerous ways.
I would also like to gratefully acknowledge Dr. Carlos J. Bernardos from UC3M Spain, for
agreeing to work with me, committing his time and guiding me through this research in a highly
professional manner. I greatly acknowledge his contributions, ideas as well as critical feedback
to improve the overall quality of this research.
I would also like to thank all my friends and colleagues at EECS for their friendship and
support. I also acknowledge the support staff at QUT for providing all the necessary facilities.
Last, but not the least, I would like to thank my family for their support, care and encour-
agement during this research journey.
ix
x
Table of Contents
Abstract v
Keywords vii
Acknowledgments ix
Nomenclature xv
List of Figures xxii
List of Tables xxiii
1 Introduction 1
1.1 Introduction and Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Research Objectives and Contributions . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Literature Review 7
2.1 The IP Mobility Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 An overview of the centralized IP Mobility Schemes . . . . . . . . . . 8
2.1.2 Shortcomings in the Centralized IP Mobility Solutions . . . . . . . . . 10
xi
2.2 Distributed Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Distributed Mobility Management at IETF . . . . . . . . . . . . . . . 11
2.2.2 DMM in Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 SDN-based DMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Adaptive Mobility Management in IP-based Networks . . . . . . . . . . . . . 20
2.3.1 Existing Proposals for Adaptive Mobility in IP Networks . . . . . . . . 20
2.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Adaptive Multimode Decentralized Mobility Solution 25
3.1 The Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 An overview of the OpenFlow Protocol . . . . . . . . . . . . . . . . . 26
3.2 Network-based IP Mobility handover sub-processes . . . . . . . . . . . . . . . 27
3.2.1 The Handover sub-processes in the proposed scheme . . . . . . . . . . 28
3.2.2 A Classification of the Network-based Handover Sub-processes . . . . 29
3.3 Overview of the Proposed Mobility Architecture . . . . . . . . . . . . . . . . . 31
3.4 The Proposed Signaling Messages . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Proposed Extensions to the OpenFlow Protocol . . . . . . . . . . . . . 34
3.4.2 The Proposed Signaling Messages . . . . . . . . . . . . . . . . . . . . 35
3.5 Handover Process of AMM Scheme . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1 The Handover Information Gathering phase . . . . . . . . . . . . . . . 39
3.5.2 The Handover Mode Selection phase . . . . . . . . . . . . . . . . . . 40
3.5.3 The Handover Execution phase . . . . . . . . . . . . . . . . . . . . . 46
3.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4 Analytical Evaluation for the Proposed Scheme 55
4.1 pDMM Schemes Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Analytical Modelling for High Mobility/Session Activity . . . . . . . . . . . . 62
4.2.1 Modelling PMIPv6-DMM for High Mobility/Session activity . . . . . 64
xii
4.2.2 Modelling AMM for High Mobility/Session activity . . . . . . . . . . 66
4.3 Comparative Numerical Analysis of PMIPv6-DMM and AMM . . . . . . . . . 72
4.3.1 Session Disruption Delay Comparison . . . . . . . . . . . . . . . . . . 73
4.3.2 Packet Loss Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.3 Signaling Costs Comparison . . . . . . . . . . . . . . . . . . . . . . . 78
4.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5 Performance Analysis through ns-3 Simulations 85
5.1 Implementation of PMIPv6-DMM and AMM Schemes in ns-3 . . . . . . . . . 85
5.1.1 Implementation of PMIPv6-DMM in ns-3 . . . . . . . . . . . . . . . . 86
5.1.2 Implementation of the proposed AMM Scheme in ns-3 . . . . . . . . . 90
5.2 Handover Delay Analysis of PMIPv6-DMM and the AMM Scheme . . . . . . 91
5.2.1 The Simulation Set-up . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.2 Experiment Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.3 Comparative Analysis of PMIPv6-DMM and AMM Schemes . . . . . 101
5.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6 Conclusions and Future Work 107
6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
References 116
xiii
xiv
Nomenclature
Abbreviations
5G 5th Generation (of Mobile Networks)
AMM Adaptive Multimode Mobility
AP Access Point
API Application Programming Interface
AP-ID Access Point Identifier
AR Access Router
BC Binding Cache
BCE Binding Cache Entry
BU Binding Update
CMD Central Mobility Database
CN Correspondent Node
CoA/nCoA Care-of Address/new CoA
CSMA Carrier Sense Multiple Access
CTR Controller (an SDN Controller)
DMM Distributed Mobility Management
FE Forwarding Entity
FMIPv6 Fast Mobile IPv6
FPMIPv6 Fast Proxy Mobile IPv6
GW Gateway
HA Home Agent
xv
HMIPv6 Hierarchical Mobile IPv6
HoA Home Address
IETF Internet Engineering Task Force
ITU International Telecommunication Union
L2 Layer 2/Link layer
L3 Layer 3/Network layer
LMA Local Mobility Anchor
MA Mobility Anchor
MAAR Mobility Anchor and Access Router
MAC Medium Access Control layer
MADM Multiple Attributes Decision Making
MAG Media Access Gateway
MAP Mobility Anchor Point
MIPv6 Mobile IPv6
MN Mobile Node
MN-ID Mobile Node Identifier
MR Mobile Router
NAI Network Access Identifier
NEMO Network Mobility
n-FE New Forwarding Entity
ONF Open Networking Foundation
PBA Proxy Binding Acknowledgement
PBA* Proxy Binding Acknowledgement with new pDMM Mobility Option
PBU Proxy Binding Update
PBU* Proxy Binding Update with new pDMM Mobility Option
pDMM Partially Distributed Mobility Management
p-FE Previous Forwarding Entity
xvi
pMAAR previous Mobility Anchor and Access Router
PMIPv6 Proxy Mobile IPv6
PO Path Optimization
RFC Request For Comments
RSS Received Signal Strength
SDN Software-Defined Networking
sMAAR serving Mobility Anchor and Access Router
SMR Session-to-Mobility Ratio
WiFi Wireless Fidelity
xvii
xviii
List of Figures
2.1 A PMIPv6 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Signaling Sequence for PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 A PMIPv6-based DMM Domain . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Signaling Sequence for pDMM-I (CMD as PBU/PBA relay) . . . . . . . . . . 15
2.5 Signaling Sequence for pDMM-II (CMD as MAAR Locator) . . . . . . . . . . 16
2.6 Signaling Sequence for pDMM-III (CMD as MAAR Proxy) . . . . . . . . . . 16
3.1 Main Components of an OpenFlow switch [1] . . . . . . . . . . . . . . . . . . 27
3.2 Demonstrating the Path Optimization Process in an SDN Domain . . . . . . . 30
3.3 Classifying the Handover Subprocesses . . . . . . . . . . . . . . . . . . . . . 31
3.4 The Handover Mode Selection phase among traditional handover phases . . . . 32
3.5 A typical Mobility Database Entry in the proposed AMM scheme . . . . . . . 33
3.6 Demonstrating the Path Optimization process in the proposed scheme . . . . . 42
3.7 Message flow of the Proposed Predictive Operation . . . . . . . . . . . . . . . 49
3.8 Message flow of the Proposed Reactive Operation . . . . . . . . . . . . . . . . 51
4.1 Impact of processing delay at MAAR (PDmaar) on total handover delay on
pDMM schemes (Case - 1a) . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Impact of transmission delay between MAAR and CMD (Tmaar,cmd) on total
handover delay on pDMM schemes (Case - 1b) . . . . . . . . . . . . . . . . . 57
4.3 Impact of packet arrival rate (�p) on total packet loss of pDMM schemes (w.r.t.
Case - 1a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
xix
4.4 Impact of packet arrival rate (�p) on total packet loss of pDMM schemes (w.r.t.
Case - 1b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Impact of transmission cost (TCmaar,cmd) on signaling cost of pDMM Schemes 61
4.6 Impact of processing cost PC on signaling cost of pDMM Schemes . . . . . . 61
4.7 Network Model for performance comparison . . . . . . . . . . . . . . . . . . 63
4.8 The impact of n on session disruption delay . . . . . . . . . . . . . . . . . . . 74
4.9 The impact of average per-byte processing delay (P ) on session disruption delay 74
4.10 The impact of average per-byte transmission delay (U) on session disruption
delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.11 The impact of average per-byte processing delay (P ) on Packet Loss . . . . . . 76
4.12 The impact of average per-byte transmission delay (U) on packet loss . . . . . 76
4.13 The impact of packet arrival rate (�p) on packet loss . . . . . . . . . . . . . . . 77
4.14 The impact of selected sessions with active handover support services (k) on
packet loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.15 The impact of total active sessions (n) on comparative signaling costs with no
handover support services are enabled . . . . . . . . . . . . . . . . . . . . . . 80
4.16 The impact of processing cost per byte (�) on comparative signaling costs with
no handover support services are enabled . . . . . . . . . . . . . . . . . . . . 80
4.17 The impact of transmission cost per byte (U) on comparative signaling costs
with no handover support services are enabled . . . . . . . . . . . . . . . . . . 81
4.18 The impact of selected sessions (k) on comparative signaling costs with all
handover support services enabled . . . . . . . . . . . . . . . . . . . . . . . . 81
4.19 The impact of processing cost per byte (�) on comparative signaling costs with
all Handover Support Services enabled . . . . . . . . . . . . . . . . . . . . . . 82
4.20 The impact of transmission cost per byte (u) on comparative signaling costs
with all handover support services enabled . . . . . . . . . . . . . . . . . . . . 82
5.1 Software organization of ns-3 [2] . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Binding Update List implementation for PmipDmm in ns-3 . . . . . . . . . . . 88
xx
5.3 A Flowchart demonstrating the handover signaling exchange for PmipDmm in
ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4 The ofswitch13 module structure [3] . . . . . . . . . . . . . . . . . . . . . 91
5.5 The simulation setup for PMIPv6-DMM Experiments . . . . . . . . . . . . . . 93
5.6 The simulation setup for an SDN domain for the proposed AMM Experiments . 94
5.7 Impact of Traffic Generation Rate = 64 Kb/s on total service disruption interval
in PMIPv6-DMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.8 Impact of Traffic Generation Rate = 64 Kb/s on total service disruption interval
in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.9 Impact of Traffic Generation Rate = 128 Kb/s on total service disruption inter-
val in PMIPv6-DMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.10 Impact of Traffic Generation Rate = 128 Kb/s on total service disruption inter-
val in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.11 Impact of Traffic Generation Rate = 256 Kb/s on total service disruption inter-
val in PMIPv6-DMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.12 Impact of Traffic Generation Rate = 256 Kb/s on total service disruption inter-
val in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.13 Impact of Traffic Generation Rate = 512 Kb/s on total service disruption inter-
val in PMIPv6-DMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.14 Impact of Traffic Generation Rate = 512 Kb/s on total service disruption inter-
val in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.15 Impact of MN’s Velocity Range = 1�14 m/s on total service disruption interval
in PMIPv6-DMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.16 Impact of MN’s Velocity Range = 15 � 28 m/s on total service disruption
interval in PMIPv6-DMM scheme . . . . . . . . . . . . . . . . . . . . . . . . 99
5.17 Impact of MN’s Velocity Range = 29 � 42 m/s on total service disruption
interval in PMIPv6-DMM scheme . . . . . . . . . . . . . . . . . . . . . . . . 99
5.18 Impact of MN’s Velocity Range = 1�14 m/s on total service disruption interval
in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
xxi
5.19 Impact of MN’s Velocity Range = 15 � 28 m/s on total service disruption
interval in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.20 Impact of MN’s Velocity Range = 29 � 42 m/s on total service disruption
interval in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.21 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes
for Traffic Generation rate = 64 Kbps . . . . . . . . . . . . . . . . . . . . . . . 102
5.22 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes
for Traffic Generation rate = 128 Kbps . . . . . . . . . . . . . . . . . . . . . . 102
5.23 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes
for Traffic Generation rate = 256 Kbps . . . . . . . . . . . . . . . . . . . . . . 103
5.24 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes
for Traffic Generation rate = 512 Kbps . . . . . . . . . . . . . . . . . . . . . . 103
5.25 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes
for Velocity range = 1 - 14 m/s . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.26 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes
for Velocity range = 15 - 28 m/s . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.27 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes
for Velocity range = 29 - 42 m/s . . . . . . . . . . . . . . . . . . . . . . . . . 105
xxii
List of Tables
3.1 The Proposed Signaling Messages for the AMM Protocol . . . . . . . . . . . . 35
4.1 Parameter notations with description and default values for three PMIPv6-DMM
Schemes Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Parameter notations with description and default values for PMIPv6-DMM and
AMM Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1 Simulation Setup for Case-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2 Simulation Setup for Case-1 - Traffic Generation Rates for Individual Sessions 98
5.3 Simulation Setup for Case-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4 Simulation Setup for Case-2 - Traffic Generation Rates for Individual Sessions 101
xxiii
xxiv
Chapter 1
Introduction
1.1 Introduction and Background
Providing seamless mobility to mobile nodes (MNs) is one of the most significant challenges
in 5G networks. The mobility environment in 5G networks is characterized by high traffic
loads and frequent handovers owing to the modern data-intensive applications and network
architectures with smaller cells.
The 5G wireless networks are envisioned to work on millimetre wave spectrum [4], which
would push the network designers to deploy smaller cells. The smaller cell sizes would also
be needed since the network operators would be looking for efficient utilization of the available
spectrum. As a result, frequent handovers between neighbouring cells will be common. On the
other hand, with the modern applications such as high definition video streaming, 3D gaming,
cloud computing etc. becoming commonplace, the 5G networks are expected to trigger huge
data surge.
The existing mobility solutions represent a centralized paradigm where all traffic in the
domain has to pass through a centralized node. These solutions thus impose several mobility
management bottlenecks such as sub-optimal routing, single point of failure, scalability issues
and high signaling overheads [5]. These are thus not suitable to handle frequent handover
requests and the consequent traffic management in the 5G networks.
The standardization forums including the IETF recognize these problems and have pro-
posed distributed mobility management (DMM) solutions, wherein the mobility management
functions are placed at the edge of the network, closer to the mobile node (MN) [5, 6, 7]. In
1
2 CHAPTER 1. INTRODUCTION
such mobility solutions, the decentralized flatter network architectures are considered, in which
the functionality of edge nodes (e.g. base stations, eNodeBs, access routers, etc.) is enhanced
to allow the localized traffic and handover management for MNs. The decentralized mobility
solutions do not rely on a central network node, thus relieving the core network from processing
heavy traffic loads, as well as providing a localized mobility solution for recurrent handovers.
Among the key requirements defined for DMM by the IETF, these solutions must be based
on existing IPv6 mobility protocols [5] to ensure a seamless evolution towards DMM paradigm.
The majority of the proposed DMM solutions have thus been designed based primarily on IP
mobility principles. Recently, several DMM solutions based on Software Defined Networking
(SDN) principles have also been proposed. Some of these solutions take the IP mobility prin-
ciples into account to achieve the decentralized mobility. Others rely entirely on the OpenFlow
protocol [1], which is a popular standard SDN protocol.
1.2 Problem Statement
The Distributed Mobility Management (DMM) is now considered as a promising approach for
handling mobility in 5G networks. The majority of existing DMM solutions provide equivalent
mobility services to every MN regardless of its mobility profile, and thus cannot optimally han-
dle the handover event in varying mobility conditions i.e. under dynamic handover frequencies
and session activities.
Recent studies have shown that the current DMM solutions incur high handover latencies if
the handovers are recurrent, or the ongoing sessions are long-lasting. In [8], the performance
evaluations of the existing DMM solutions through simulations as well as analytical modelling
has shown that these proposals, among other inefficiencies, cause high handover delays and
signaling overheads in handover scenarios when the MN has high velocity or runs long-lasting
applications. Another study performed through analytical models has shown that the existing
DMM solutions are suitable only for those MNs which have lower velocity and shorter applica-
tion sessions [9].
In this research, we aim to improve the handover performance in DMM by minimizing
the handover latency and signaling costs under high mobility and session activity scenarios.
Keeping in view the diverse handover scenarios, requiring stringent QoS demands, it is a timely
1.3. MOTIVATIONS 3
concern to design intelligent and robust yet flexible mobility management protocols for DMM
for the upcoming 5G networks.
1.3 Motivations
The Software-defined networking paradigm has introduced the idea that networks can be treated
more like the flexible software rather than inflexible hardware-based infrastructure [10]. It intro-
duces the concept of control and data plane separation, and allows network management through
a centralized controller, thereby allowing flexibility to introduce novel services and protocols in
the network. This has encouraged network researchers to deploy novel and advanced network
protocols in the SDN control plane. The SDN concepts are currently being actively utilized for
designing novel solutions for different network services and protocols.
SDN is also seen as a key enabler for handling substantial challenges posed due to high
traffic loads in the prospective 5G network architectures [11]. Accordingly, it has been utilized
in several DMM proposals. Many of these solutions are primarily based on OpenFlow protocol,
while they also conform to IP mobility principles. However, none of the existing solutions
have so far fully capitalized on the SDN features to address the limitations identified in DMM.
Bringing flexibility to the currently available protocols through software defined networking
could help in making them adaptable to the varying environments in order to achieve their
increased functionality.
1.4 Research Objectives and Contributions
The existing DMM solutions are at very early stages of development and are evolving gradually
according to the ITU 5G performance requirements[12]. They operate in a particular mode
of operation and thus incur high handover latencies as the MN moves with high velocities with
high session activity. This research aims to find solutions to the limitations in the current DMM-
based handover process. The specific objectives of this research are:
• Enhancing the DMM process by SDN technology to provide optimized handover perfor-
mance in dynamic mobility scenarios.
4 CHAPTER 1. INTRODUCTION
• Performance evaluation of the proposed protocol based on different handover perfor-
mance metrics under high mobility and session activity scenarios through analytical mod-
els.
• Modelling and simulation of the proposed protocol on the ns-3 network simulator for
performance evaluation and validation under different scenarios
In this thesis, a novel SDN-based handover management protocol, termed as Adaptive
Multimode Mobility (AMM) protocol, is presented. The proposed scheme is based on the
network-based Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocol [13], and proposes
the conditional coupling of the different handover sub-processes (or handover support services),
which according to MN’s current mobility requirements, are adaptively enabled or disabled by
the SDN Controller (CTR). The proposed protocol thus flexibly operates in multiple modes of
operation unlike the traditional mobility solutions which represent a rigid mobility procedure.
The handover process in this scheme consequently incorporates a novel Handover Mode Selec-
tion phase in which the CTR evaluates the mode of operation for the next handover event which
best suits the mobility needs of the MN. The proposed protocol thus provides disparate mobility
support to MNs with different handover frequency and session activities.
For the performance evaluation of the proposed scheme in comparison to the IETF’s PMIPv6-
based DMM proposal, we first develop analytical models which characterize the high mobility
and session activity scenarios. We then modelled the PMIPv6-based DMM protocol on the ns-3
network simulator. The proposed AMM scheme is then implemented on an ns-3 ofswitch13
module [3], which implements the OpenFlow protocol v1.3.5 [1]. New handover signaling
messages based on OpenFlow protocol are proposed for communication between the SDN
controller and the underlying forwarding entity (FE).
Performance analysis of the proposed scheme through analytical models as well as ns-3
simulations under different experiment setups shows improved handover performance in terms
of handover delay, session disruption delay, packet loss, and signaling costs as compared to
the baseline PMIPv6-based DMM solution. The session disruption delay in this case relates to
the delay associated to resume all ongoing sessions of the MN, unlike handover latency, which
simply defines traffic resumption after handover.
The main contributions of this thesis are thus, summarized below:
1.5. THESIS OUTLINE 5
• Design of a novel handover management protocol which can flexibly operate in multiple
modes of operation according to the MN’s prevailing mobility requirements.
• Performance comparison of the proposed protocol with PMIPv6-DMM through analytical
models.
• Implementation of the IETF’s PMIPv6 based DMM proposal as a new ns-3 module.
• Performance analysis of the proposed AMM scheme in comparison to the IETF’s PMIPv6-
based DMM proposal through ns-3 simulations.
1.5 Thesis Outline
The rest of this thesis is organized as follows:
• Chapter 2 presents a detailed literature review of the existing DMM solutions. Both IP-
based and SDN-based DMM solutions are discussed. In addition, certain approaches for
the adaptive mobility management in the IP-based mobility protocols are also explored.
• Chapter 3 presents the proposed solution in detail. The design principles of the proposed
solution are first established, along with a discussion of evolution of IP mobility towards
SDN. This is followed by the description of different algorithms which constitute the
handover process of the proposed solution.
• Chapter 4 first presents an analytical study of the three PMIPv6-based DMM solutions pro-
posed by the IETF. It then presents analytical models developed to study the performance
of AMM and PMIPv6-DMM for MN with several ongoing sessions undergoing frequent
handovers.
• Chapter 5 presents the implementation of the PMIPv6-based DMM solution as well as the
implementation of the proposed AMM scheme in ns-3. This is followed by the simulation
evaluation of both these schemes, under different scenarios.
• Chapter 6 draws the conclusions of the thesis, and identifies the research areas which can be
further pursued to supplement the work presented in this thesis.
6 CHAPTER 1. INTRODUCTION
1.6 Publications
To be submitted:
• Muhammad Mohtasim Sajjad, Dhammika Jayalath, Glen Tian, Carlos Jesus Bernardos
Cano, ”An SDN-based Adaptive Multimode Decentralized Mobility Architecture for 5G”,
in IEEE International Symposium on Personal, Indoor and Mobile Radio Communica-
tions (IEEE PIMRC 2018)
• Muhammad Mohtasim Sajjad, Dhammika Jayalath, Glen Tian, Carlos Jesus Bernardos
Cano, ”An Implementation of PMIPv6-based Partially Distributed Mobility Management
in ns-3”, Workshop on ns-3 (WNS), 2018
Chapter 2
Literature Review
Chapter Outline
This chapter provides an overview of the current mobility management approaches proposed for
5G networks, which are based on the distributed mobility management (DMM) paradigm. The
adaptive mobility management schemes proposed for IP mobility protocols are also reviewed
in this chapter.
In Section 2.1, a brief overview of the centralized IP Mobility schemes is provided. This
section also describes the inherent shortcomings of these schemes due to their centralized
design approach, which is the motivation behind the need for distributed mobility management
schemes. Section 2.2 first provides an overview of the standardization efforts for DMM at
IETF. It then reviews the existing literature on DMM. Section 2.3 explores the adaptive IP
mobility schemes in the literature. Section 2.4 summarizes the literature review, and highlights
the limitations in the existing DMM proposals and argues that flexible design considerations of
DMM operations could be a prospective approach to overcome these limitations. Section 2.5
provides a summary of this chapter.
2.1 The IP Mobility Solutions
Several mobility management schemes for IP networks have been proposed in the past, and
many of them have matured into internet standards [14]. These standard solutions are now
required as a baseline for proposing any future mobility management mechanisms [5]. This
7
8 CHAPTER 2. LITERATURE REVIEW
section provides a brief overview of the major IP mobility mechanisms, along with their key
design features.
2.1.1 An overview of the centralized IP Mobility Schemes
The primary IP mobility mechanism is Mobile IPv6 protocol [15], which aims at providing
a global mobility solution. The MN updates its location to the Home Agent (HA) and the
Correspondent Nodes (CNs) every time it changes its Layer 3 (L3) network, through a process
named Binding Update (BU). It was soon realized that such an approach is inefficient since
it requires updating the HA and CN at each network layer handoff. The repeated BU process
becomes rather inefficient in scenarios if the MN has several active CNs.
Therefore, a trend was started for proposing the handover protocols which were capable of
providing both global as well as localized mobility support. The local mobility support repre-
sents a scenario when a MN undergoes handover within a limited domain, which is managed
by a local anchor node. The Binding Update (BU) process thus takes place to the local anchor
node instead of the Home Agent (HA) as is the case in Mobile IPv6. In case the MN has to
update its Home Agent (HA) of its new location e.g. if it moves out of current localized domain
and enters a new localized domain, it would have to update the CN(s) about its new location as
well.
The localized handover protocols which have been standardized by the IETF include Hi-
erarchical Mobile IPv6 (HMIPv6) [16], Fast Mobile IPv6 (FMIPv6) [17] and Proxy Mobile
IPv6 (PMIPv6) [18]. The combination of FMIPv6 and PMIPv6 named the Fast Handovers for
Proxy Mobile IPv6 (FPMIPv6) [13] has also been standardized by the IETF. Network Mobility
(NEMO) [19] is another significant IETF standard. All these protocols are enhancements of the
baseline MIPv6 protocol, and function on same mobility principles set by MIPv6.
The HMIPv6 and FMIPv6, like MIPv6, are host-based mobility management protocols,
while PMIPv6 and FPMIPv6 are network-based mobility management protocols. The host-
based mobility management protocols involve mobile node in handover operation i.e. the key
handover signaling is carried out by the MN. The network-based mobility management proto-
cols, on the other hand, relieve MN from any such handover signaling. The handover process is
entirely carried out by network nodes in network-based mobility management protocols.
2.1. THE IP MOBILITY SOLUTIONS 9
The HMIPv6 introduces hierarchy in MIPv6 by introducing a new protocol entity named
Mobility Anchor Point (MAP). The MAP functions as a local anchor to which the MN carries
out binding update until it stays in its domain. If the MN moves out of a MAP’s domain, it
carries out BU with the HA. The primary aim of HMIPv6 is to reduce the BU interval during
the MN’s handoff. It also relieves the burden of repetitive BUs with HA during handovers.
The FMIPv6 introduced several new features to the baseline MIPv6 protocol. These mainly
include, (a), enabling MN to detect its new access network, while still connected to its current
network, (b). enabling packet forwarding from previous access network to new network by
establishing an IP tunnel between them, and (c) enabling buffering at previous network as the
MN updates its about its prospective handover. This protocol was primarily aimed at reducing
latency as well as packet losses during handover.
The PMIPv6 is the baseline network-based mobility management protocol. It introduces
two key protocol entities, (a), the Mobile Access Gateway (MAG), and (b) Local Mobility
Anchor (LMA). The MAG is responsible for carrying out the handover signaling on behalf of
MN. The LMA, like MAP in HMIPv6, acts as a localized anchor which handle both traffic and
binding update for a MN. Its primarily aim is to relieve the MN from handover signaling and
provide a complete network-based mobility management mechanism which could stimulate the
deployment of IP mobility in real networks.
The FPMIPv6, being the combination of PMIPv6 and FMIPv6, draws benefits of both
protocols. These include (a) enabling MN to detect its new access network from previous
network’s link, (b) establishing an IP tunnel between the previous network and the new network
to enable packet forwarding, and (c) providing a network-based mobility solution. This protocol
was also primarily aimed at providing a network-based mobility solution which incurs reduced
handover latency. Among all above mobility protocols, the FPMIPv6 has been shown to have
achieved the most optimal handover performance [20].
The NEMO protocol is another significant enhancement of MIPv6, which provides mobility
support to a group of mobile users moving together as a mobile network e.g. in a vehicle or a
train. This protocol introduces a new protocol entity named Mobile Router (MR). Each mobile
network has at least one MR which is a gateway node for the mobile network, and connects it
to the HA.
10 CHAPTER 2. LITERATURE REVIEW
2.1.2 Shortcomings in the Centralized IP Mobility Solutions
The mobility management process in IP-based wireless networks relies on a centralized anchor
node for mobility as well as traffic management for MN. The traffic destined to the MN is sent
to the centralized anchor node, which forwards this traffic to MN to its current location. This
approach, among several other drawbacks under high traffic load conditions [5], incurs several
bottlenecks which include single point of failure, congestion, non-optimal routes and scalability
issues.
The centralized anchor node represents a single point of failure, which may occur due to
several reasons including traffic overload or security issues such as Denial-of-service attacks.
In such an event, not only the service availability is affected to the end-users, but also costly
corrective measures would be required to restore the services. Likewise, the centralized anchors
are also prone to congestion issues which result in service degradation for end-users.
The centralized anchor nodes, like any other network node, have limited capacity. There-
fore, they are unlikely to sustain the requirement to handle the increasing mobile subscribers
base. Thus they incur significant scalability issues for mobile networks.
Another drawback of centralized anchor nodes is that they result in non-optimal routes. This
is because, all traffic for a MN in the domain is directed towards the centralized anchor, which
sends traffic to its new location through IP tunnelling.
2.2 Distributed Mobility Management
The existing IP mobility schemes are deemed unsuitable for handling mobility in 5G networks
due to their reliance on a centralized anchor node. The Distributed Mobility Management
paradigm, which aims at decentralized and distributed mobility anchoring as well as localized
handover management, is thus identified as a favourable approach to overcome the challenges
imposed due to centralized mobility proposals.
The primary design approaches for DMM are based on the principles of MIPv6 and its
enhancements. As a result, both localized and global solutions for DMM are available. More-
over, client-based and network-based solutions for DMM have also been conceived. However,
the localized and network-based solutions for DMM have been preferred over host-based and
2.2. DISTRIBUTED MOBILITY MANAGEMENT 11
global mobility solutions for DMM, both at the IETF and by the general research community.
In this section, we first briefly discuss the standardization efforts being carried out at IETF
for DMM solutions. We then discuss some key DMM proposals in the literature. These
solutions are listed under two major categories of IP-based DMM approaches and SDN-based
DMM approaches.
2.2.1 Distributed Mobility Management at IETF
Several efforts for developing standardized Distributed Mobility Management (DMM) spec-
ifications are currently being carried out at the IETF. An active dmm working group under
the Internet Area of IETF has formulated two informational RFC documents that specify the
requirements for distributed mobility management [5] and provide overview of current practices
along with their shortcomings [6]. Two baseline approaches to achieve DMM are currently been
studied at IETF which are based on MIPv6 and PMIPv6 respectively. Both these solutions are
briefly described in the below subsections.
MIPv6-based DMM Proposal at IETF
One of the early distributed mobility management proposals was proposed in [21], and is now
being studied at IETF [22]. It proposes a Flat Access and Mobility Architecture (FAMA) based
on the Mobile IPv6 protocol, which is a host based mobility management protocol.
In this proposal, a new protocol entity named Distributed Anchor Router (DAR) is intro-
duced which is deployed at the edge of network and essentially replaces the centralized home
agent of Mobile IPv6. When a MN first connects to a DAR, it is assigned a network prefix
to configure the IPv6 address which would be its Home Address (HoA). As it further moves
around the domain, and attaches to other DAR’s links, it configures its CoAs and carries out
the binding updates with the home DAR for its newly configured CoAs. A bidirectional tunnel
between MN and its home DAR is established to resume the ongoing communication session.
This scheme however inherits some well-known flaws of the MIPv6 as pointed out in [23].
These include inefficient use of wireless resources due to tunneled packets over the wireless
link, and the need to update the MN’s protocol stack for deploying this solution. And since, a
MN in FAMA architecture can have several IPv6 addresses which could be anchored at different
12 CHAPTER 2. LITERATURE REVIEW
DARs, it can have several tunnels established with several DARs for different mobility sessions.
This, in addition to inducing high signaling overheads, would also result in higher utilization of
wireless resources. The host based mobility schemes thus prove to be highly inefficient from
distributed mobility management perspective and are expected to provide lesser gain for very
high costs. These issues therefore push towards the network based DMM solutions, and thus
the PMIPv6-based DMM solutions are being actively explored at IETF as discussed in the next
sub-section.
PMIPv6-based DMM Proposal at IETF
The network-based baseline DMM solution currently being designed within the IETF’s dmm
working group is based on PMIPv6 principles [7]. In PMIPv6 protocol, the network entities
perform the handover signaling on behalf of MN. The new protocol entities introduced by
the PMIPv6 protocol are the Mobile Access Gateway (MAG) and the Local Mobility Anchor
(LMA). The MAG functionality is performed by the access router, and on detecting the MN’s
attachment to its link, it performs handover signaling on behalf of MN. The LMA on the other
hand, maintains the Binding Cache Entry for the MN which contains MN’s current location
information. It plays the role of an anchor for MN’s traffic, and directs its traffic towards its
new location. A typical PMIPv6 domain showing MAG and LMA entities is shown in Figure
2.1.
During the handover, as soon as the MN attaches to the MAG and performs authentication,
the MAG sends a Proxy Binding Update (PBU) to the LMA. The LMA updates the BCE
for MN, according to its new location, and sends a Proxy Binding Acknowledgement (PBA)
message to MAG. The PBU/PBA signaling exchange also establishes the tunnel between the
LMA and MAG, through which the traffic is sent to the MN’s new MAG. This process is
depicted in Figure 2.2.
In the PMIPv6 based DMM proposal by IETF, the primary focus is on defining the partially
distributed mobility solutions in which the MAG entity also performs anchoring functionality
of LMA, and is thus named Mobility Anchor and Access Router (MAAR). The LMA entity on
the other hand is relieved from the data forwarding role and only maintains the binding cache.
It is also renamed as Central Mobility Database (CMD). These entities are shown in Figure 2.3.
Three approaches for partially distributed mobility management have been suggested thus
2.2. DISTRIBUTED MOBILITY MANAGEMENT 13
Figure 2.1: A PMIPv6 Domain
Figure 2.2: Signaling Sequence for PMIPv6
far in the current draft. On the other hand, the lack of information about the previous MAARs
14 CHAPTER 2. LITERATURE REVIEW
Figure 2.3: A PMIPv6-based DMM Domain
and the prefixes advertised by them is identified as major obstacle for designing a fully dis-
tributed mobility management scheme [7]. Although certain methods to circumvent this issue
are highlighted, no concrete solution is provided yet.
Although, the approaches for partially distributed mobility management currently being
studied at the IETF can achieve the decentralized anchoring, the major downside is that now the
PBU message has to be sent to two entities i.e. the CMD and the previous MAAR. The CMD
in each of these cases acts either as a relay for PBU/PBA, MAAR locator, or MAAR’s proxy.
The corresponding schemes are addressed in this thesis as pDMM-I, pDMM-II, and pDMM-III
respectively.
CMD as PBU/PBA relay (pDMM-I) When an MAAR detects a new MN moving into its
domain, it reserves an IPv6 prefix, stores a temporal binding cache entry (BCE) for it, and
sends a PBU message to CMD. The CMD performs the binding cache (BC) lookup to learn the
2.2. DISTRIBUTED MOBILITY MANAGEMENT 15
previous location of the MN. It then forwards the PBU* (i.e. PBU with new mobility options)
to the p-MAAR. The p-MAAR updates routes for the previous prefix of the MN and sends the
PBA* (i.e. a PBA with new mobility option) to the CMD. The CMD updates the p-MAAR
list in the BCE, and sends the PBA* to sMAAR that contains the previous proxy-CoA and the
prefix anchored to it. Thus the sMAAR can establish a bidirectional tunnel with the pMAAR,
to enable the tunneling of packets from pMAAR to sMAAR. This process is shown in Figure
2.4.
Figure 2.4: Signaling Sequence for pDMM-I (CMD as PBU/PBA relay)
CMD as MAAR Locator (pDMM-II) In the previous approach, the nMAAR can only re-
ceive a PBA message when the CMD receives it and updates the BCE. In case the pMAAR is
allowed to send PBA directly to the nMAAR as it sends one to the CMD, significant latency
can be reduced since the nMAAR will no longer have to wait for CMD to update the binding
cache and then send the PBA to the nMAAR. This process is shown in Figure 2.5.
CMD as MAAR Proxy (pDMM-III) In this approach, the PBA message to nMAAR does not
rely on the PBA that is sent to CMD. The CMD sends the PBA* message to nMAAR rightaway
as it receives the PBU. It is possible since the CMD can lookup for pMAAR’s information for
the MN-ID in the binding cache it maintains. It then sends a PBU* message to the pMAAR.
The pMAAR performs route update and sends the PBA* message to the CMD. This process is
16 CHAPTER 2. LITERATURE REVIEW
Figure 2.5: Signaling Sequence for pDMM-II (CMD as MAAR Locator)
shown in Figure 2.6.
Figure 2.6: Signaling Sequence for pDMM-III (CMD as MAAR Proxy)
2.2.2 DMM in Literature
The DMM solutions proposed in the literature have also been predominantly based on the
PMIPv6 protocol, just like standardization efforts at the IETF. This section reviews some of
these approaches and highlights their major features, as well as their shortcomings.
2.2. DISTRIBUTED MOBILITY MANAGEMENT 17
The simplest approach for achieving the distributed mobility management is to replicate the
forwarding and location information over a number of nodes scattered throughout the domain.
For example in [24], it is suggested that all MAGs within a domain are arranged as a virtual
ring with each of them functioning as an LMA. The MN’s mapping information with its LMA
is distributed throughout each MAG via consistent hashing. Similarly, in [25], a distributed
network of small-cell gateways is considered. These gateways aggregate a WiFi AP and a
cellular BS control functionalities in a single entity, the Converged Gateway (CGW). All CGWs
also incorporate the MAG & LMA functionality for DMM support. Another solution in [26]
argues to support the host-based mobility management for inter-domain routing along with
network-based PMIPv6. A protocol entity named Mobile Access Router (MAR) is defined
which can function as a normal AR, HA, LMA and MAG on a per address basis. In [27],
the resource availability information of the target MAARs for MN is obtained through MIH
signaling. This process assists MN to take appropriate decision for choosing the best MAAR.
However, this procedure requires a lot of time from the MN to stay connected with current
MAAR, which is inefficient and is prone to latencies and packet losses.
All these solutions avoid reliance on any centralized entity, and thus aim to achieve fully
distributed mobility management solutions. However, in such cases, the lack of timely synchro-
nization among nodes causes extra overhead and latency.
One approach to avoid this drawback is to distribute the handover functions among the
forwarding entities. In [28], the functions of mobility anchors are distributed among home
mobility anchor (H-MA) and visited mobility anchor (V-MA). The H-MA is responsible for
location management (LM) and the V-MA is responsible for mobility routing i.e. every time
the MN enters in new MA’s domain (which becomes its current V-MA), it informs its H-MA
about its new location, however, the packet forwarding is done by the CN’s MA towards the
V-MA and it does not require to route packets via H-MA.
Several schemes consider decoupling of control and data planes and define a separate control
plane entity. In [29], the data and control planes of the LMA are split into Data LMA (DLMA)
and Control LMA (CLMA) respectively. The CLMA is responsible for binding registration,
home network prefix (HNP) allocation and maintains binding cache entry (BCE). The CLMA
allocates DLMA adaptively to the MN based on its current location, and network traffic. The
proposals in [30, 31, 32] use database entities at control plane which in addition to managing
18 CHAPTER 2. LITERATURE REVIEW
the underlying data plane processes such as tunnelling and encapsulations, also store certain
information such as binding caches.
In [33], the dynamic mobility management is considered wherein the mobility support is
provided only to those nodes which are currently mobile, thus reducing the overhead associated
to the mobility support extended to the non-mobile users. The mobility anchor is different for
sessions the MN started at different subnets i.e. if a MN undergoes several handovers after
initiating a particular session, the data will be anchored to its current location from its older
mobility anchor. It is possible since the IPv6 allows an MN to use multiple IPv6 addresses
simultaneously.
Several solutions also optimize other handover aspects which include reduction of overheads
in tunnel establishment. Majority of the IP-based DMM solutions rely on tunnelling process
to resume MN’s traffic at its new network, which may continue over several hops according
to previous locations of the MN. In [34], a dynamic tunnelling scheme based on Session-to-
Mobility Ratio (SMR) is proposed in which tunnel establishment between Access Mobility
Agents (AMAs), and between AMA & the LMA takes place according to the current SMR. If
the SMR is below a predefined threshold, packet forwarding or tunnelling takes place between
AMAs. In case it is above that threshold, a tunnel between an AMA and the LMA is established.
This helps in reduction of forwarding or tunnelling overheads.
2.2.3 SDN-based DMM
Integrating SDN in DMM simplifies mobility management, and removes complexity and work-
load associated especially with routing and tunnelling process. The Software-Defined Net-
working (SDN) paradigm decouples control and data planes, thus allowing more flexibility
in network control and management [35]. The communication between the control and data
planes in SDN is enabled by a standardized OpenFlow [1] protocol. Among the existing SDN-
based DMM solutions, several solutions are based entirely on OpenFlow protocol. However,
conforming to the key IETF requirements for DMM, several SDN-based DMM solutions are
designed on IP principles as well.
The mobility management procedures can be implemented within a centralized SDN con-
troller as an SDN application [35]. This can help in offloading the underlying entities like access
routers (ARs) from functions such as maintaining the binding cache, IP prefix assignment,
2.2. DISTRIBUTED MOBILITY MANAGEMENT 19
detection of MN’s handoffs, path reconfiguration for MN at its new location etc., and thus
makes them merely the traffic forwarding entities.
An SDN-based IP mobility management scheme is proposed in [36] in which the SDN
controller stores the binding cache for mapping the MN’s HoA to CoA in the form of flow
bindings. The OpenFlow switches download these bindings from the controller. At handoff,
when the controller learns that the MN has changed its point of attachment and learns its new
location, it updates the binding cache, defines the new path and downloads the flow entries
on the respective switch along the new path. The CoA representing the MN is owned by the
first-hop OpenFlow switch instead of the MN itself. The path reconfiguration process among
these functions, is prone to incur high latencies for fast moving users, as complete path inside
the SDN domain has to be recomputed and then installed in the underlying entities at each
handover of MN.
Another approach in [37] considers Border Controller among several controllers distributed
over a domain, for maintaining the mobility related information for MNs. When the MN moves
into another domain, the data plane entity Access Gateway (AGW) detects attachment and
assigns new prefix to it. The AGW then requests information about CN’s ID and HNP which is
searched by the Border Controller (B-CTR) of the domain. Eventually, the Border Controllers
at MN & CN’s domains update the flow tables at the respective AGWs. A similar approach is
utilized in [38] in which the control plane, instead of coordinating the previous controller of the
MN, coordinates with CN’s controller through a potential broadcasting approach and making
its respective switch to redirect the ongoing MN’s flow on to it by downloading the respective
flow entry on it. Both these schemes are also prone to high session interruptions in case the MN
has multiple ongoing sessions with disparate CNs, or undergoes frequent handovers.
The inefficiencies due to multiple flows are partially addressed in [39], in which, virtual
Mobility Anchor (VMA) functions are proposed which are implemented on SDN controllers
and realize the dynamic anchor point selection for each flow. While, like other schemes,
the SDN Controller sends forwarding rules to SDN switches which in turn implement them,
at handover, however, the dynamic anchor selection mechanism is performed by the SDN
controller only after the Foreign (or new) attachment point informs it of the MN’s attachment
to it. It is unclear in this scheme as well, that how the communication interruption would be
handled before the OpenFlow forwarding rules are installed on both the new Anchor and the
20 CHAPTER 2. LITERATURE REVIEW
new attachment point and the MN would start getting its traffic again.
2.3 Adaptive Mobility Management in IP-based Networks
The existing IP mobility schemes have also been shown to exhibit various inefficiencies in
dynamic mobility environments. Various optimizations in these schemes have been proposed
which generally optimize only a particular aspect of mobility. For instance, a solution mini-
mizing handover latency and packet losses would incur high signaling and tunnelling overheads
and vice versa.Therefore, a trend to propose the adaptive mobility management solutions came
to prominence in which solutions are designed to operate adaptively according to the existing
scenarios and were thus able to maintain a balance between those trade-offs.
In this section, several efforts previously made in order to make the handover event more
compliant to the existing mobility conditions are explored. The adaptive mobility process, in
this context, is defined as the process which is capable to change its execution principles and/or
their order for varying conditions/requirements.
2.3.1 Existing Proposals for Adaptive Mobility in IP Networks
The IP based mobility schemes, like other mobility schemes, also represent static mobility ser-
vice provisioning in general, as they dont change their execution principles. The fast handover
version of MIPv6 [13] which, based on detecting MNs movement at lower layers, initiates
handover signaling predictively, can be seen as an exception. This is because, in case it fails
to complete the handover process proactively, it is capable to operate reactively. Other MIPv6
derivatives provide same mobility services under any mobility scenario.
The IP-based adaptive mobility solutions have predominantly been based on session-to-
mobility ratio (SMR) parameter. The SMR has been a popular metric since it takes both MNs
mobility and MNs session activity into consideration. Secondly, it provides a simplistic yet
pragmatic calculation.
An adaptive MAP selection scheme for HMIPv6 is proposed in [40], in which the MN first
estimates its SMR. Based on the estimated value, the MN chooses a MAP that can promise
minimum mobility costs, which include the location update and packet delivery costs. If the
estimated SMR does not lie within the upper or lower SMR thresholds respectively, the MN
2.4. CHAPTER SUMMARY 21
choose another MAP that minimizes the total cost. A similar SMR-based anchor selection
scheme for MIPv6 domain is proposed in [41].
Another SMR-based proposal in [42] optimizes the binding update cost in NEMO environ-
ment. Different SMR thresholds are defined for the adaptive binding updates for an MR and a
VMN. In case if the SMR is lower than the predefined threshold, the MR registers its RCoA
with its Home Agent (ie. MR/HA). Otherwise, it registers its LCoA with its Home Agent (i.e.
MR/HA). On the other hand, the Visiting Mobile Node (VMN) conversely registers its LCoA
if SMR is lower than threshold while registers RCoA if the current SMR is equal to or greater
than the SMR threshold.
Several solutions consider alternative protocols for execution at MN’s handover, which
are chosen based on the SMR values. In [43], the protocol respectively operates F-PMIPv6
or a Proactive Route Optimized PMIPv6 modes according to lower and higher SMR values
compared to a predefined threshold. The Proactive Route Optimized PMIPv6 mode is also
termed as session-aware adaptive proxy handoff (S-APHO). It is argued that the FPMIPv6
incurs high packet delivery cost from additional tunnelling from LMA to MAGs, while the
Route-Optimized PMIPv6 causes high handoff latency, which is mainly caused due to route
optimization signaling involved to establish a direct path between nMAG and the cnMAG. If
the SMR value is lower than threshold, the protocol runs F-PMIPv6 signaling, while if the SMR
value is higher, the S-APHO is activated. In the S-APHO mode, the LMA carries out the RO
signaling as soon as it receives the PBU for de-registration from the pMAG.
Similarly in [44], the packet delivery cost and bandwidth consumption are evaluated even
during the intra-MAP mobility in HMIPv6 networks, and if these costs are higher than certain
thresholds, then MIPv6 operation is executed instead. Likewise, the MN chooses between
HMIPv6 and MIPv6 in [45] according to its moving speed and traffic intensity. The HMIPv6 is
not utilized in high traffic and lower handoff frequency conditions.
2.4 Chapter Summary
This chapter explores the existing literature on DMM. The significance of DMM in comparison
to the centralized IP mobility schemes is highlighted in Section 2.1. In Section 2.2, the current
standardization efforts for DMM at IETF are first discussed. This followed a brief discussion on
22 CHAPTER 2. LITERATURE REVIEW
key proposals for DMM, which are mainly categorized as IP-based and SDN-based proposals.
Section 2.3 explores the existing work on adaptive IP mobility protocols.
The DMM solutions for IP networks are mostly based on network-based mobility principles.
Among these, the proposed fully distributed solutions have synchronization issues among the
control entities, while the partially distributed solutions incur high tunnelling costs as they need
to tunnel the traffic of MN from existing anchor(s) to its new location. Several SDN-based
IP solutions for DMM have also been proposed. They either rely on packet forwarding from
previous attachment point of MN to its new attachment point, thus causing route optimization
issues, or compute and deploy a new path every time a MN moves into a new attachment
point. These approaches are not suitable for MNs moving with high speeds or having longer or
multiple sessions.
Due to their inherent design considerations which lack flexibility of operation, the existing
DMM solutions have limited applicability. In order to suit the varying mobility demands, these
solutions need to have flexible design consideration, to allow an adaptable operation under
dynamic mobility scenarios.
The need for the IP-based mobility schemes to operate adaptively has been identified in
past, and several solutions have been proposed. These adaptive IP mobility solutions aim to
optimize the generally conflicting objectives simultaneously, such as reducing signaling costs
and handover latencies. These solutions mainly rely on an SMR parameter in order to execute
the handover protocol in a particular mode of operation e.g. executing the BU process with a
local or alternatively with a remote anchor during handover. Likewise, some solutions utilize
SMR to choose among the alternate IP mobility protocols for execution during handoff.
In the 5G mobility environments, novel services and applications will have diverse char-
acteristics. Therefore, appropriate mobility-related decisions cannot be made based on gener-
alizing different types of application sessions under a single parameter like SMR. Moreover,
due to network architecture features such as decentralization, control and data plane separa-
tion, deployment of multiple anchors, and high traffic volumes, the direct integration of these
schemes to 5G is unlikely to bring efficiency for mobility support. These solutions however, can
potentially provide a good foundation for designing the adaptability features based on control
entities such as an SDN controller. The SDN controller with a centralized view of the network
domain, can also provide a wider range of decision parameters for intelligent decision making
2.4. CHAPTER SUMMARY 23
purposes.
In the next chapter, the proposed AMM scheme is presented. The design principles and
several handover subprocesses involved in the proposed mobility architecture are described.
The proposed scheme essentially consists of different algorithms which are evaluated during
different stages of the handover process. This helps to adaptively choose the most optimal
mode of operation based on the current mobility requirements of the MN.
24 CHAPTER 2. LITERATURE REVIEW
Chapter 3
Adaptive Multimode Decentralized Mobility
Solution
In this chapter, a novel SDN-based adaptive mobility management architecture is presented.
The proposed mobility architecture introduces a novel Handover Mode Selection phase during
the traditional handover process. During this phase, the SDN controller evaluates the suitable
mode of handover operation for MN according to its prevailing mobility and session require-
ments. The proposed mobility architecture aims to provide efficient mobility solution for high
mobility and high session activity environments, thereby addressing the limitations identified in
the existing DMM process under such scenarios.
The chapter is organized as follows: In Section 3.1, the design principles of the proposed
scheme are first enlisted. The fundamentals of the OpenFlow protocol along with relevant
concepts which are utilized in the proposed mobility scheme are also summarized. In Section
3.2, a brief analysis and a taxonomy of the generic network-based IP mobility handover sub-
processes is provided. This classification provides a baseline for the proposed solution. In
Section 3.3, an overview of the proposed mobility architecture along with a description of the
protocol principles, owing to the introduction of the novel Handover Mode Selection phase
is presented. Section 3.4 describes the proposed signaling messages and their functionality.
Section 3.5 describes the proposed mobility architecture and also presents the involved handover
process. Section 3.6 presents the summary of the chapter.
25
26 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
3.1 The Design Principles
The proposed solution is designed according to the following principles:
a. The proposed solution follows OpenFlow protocol specification 1.3.5 [1], which is stan-
dardized by the Open Networking Foundation (ONF). However, it relies on some modest
extensions to the OpenFlow protocol specification which are discussed in Section 3.4.
b. It follows the PFMIPv6 principles. Based on these principles, both predictive (proactive)
and reactive forms of the proposed scheme are defined.
c. It considers the decision parameters that are either available within a generic SDN con-
troller, or can be evaluated through simple computations.
3.1.1 An overview of the OpenFlow Protocol
The OpenFlow protocol [1] in the SDN architecture is a standard specification for commu-
nication between an SDN Controller and the underlying data plane forwarding entities. It
is thus a key element in the SDN architecture which enables the SDN controller to manage
the underlying entities. These entities at data plane are called OpenFlow switches, or simply
forwarding entities (FEs). The communication between an OpenFlow switch and the Controller
takes place over an OpenFlow channel.
A typical OpenFlow switch (or FE) consists of a single or a series of flow tables. The
flow tables arranged so are termed as a pipeline. Each flow table has several entries named flow
entries which relate to a particular ongoing flow. Through the OpenFlow protocol, the controller
implements the forwarding decisions in the switch by adding, modifying or removing these flow
entries. The switch, on receiving an incoming data packet, tries to match an entry in the flow
table. If the matching entry is found, it executes instructions in the instructions field of the flow
entry. A typical instruction is Output Action which forwards the packet out to a specified port.
Figure 3.1 shows the basic components of an OpenFlow switch.
The messages exchanged between an OpenFlow switch and the controller are classified into
three types: (a) the controller-to-switch messages, (b) the asynchronous messages, and (c) the
symmetric messages. The controller-to-switch messages, are sent from Controller to switch.
3.2. NETWORK-BASED IP MOBILITY HANDOVER SUB-PROCESSES 27
Figure 3.1: Main Components of an OpenFlow switch [1]
Packet-out messages which are sent by the Controller to a particular port of the switch are
a typical example of controller-to-switch messages. The asynchronous messages are sent by
the switch to the controller. The Packet-In messages, which are used to send a packet to the
Controller by a switch when it is unable to process it, or needs to inform Controller about
an Error, are an example of asynchronous messages. The symmetric messages can be sent in
any direction. Hello messages and Echo request/reply messages are examples of symmetric
messages.
The OpenFlow standard also defines Experimenter messages as symmetric messages. The
Experimenter messages aim to provide a standardized method of defining new messages, for
novel research solutions which would require new signaling between Controller and switch. In
our proposed scheme, we have also proposed some new signaling messages which are of type
Experimenter.
3.2 Network-based IP Mobility handover sub-processes
The proposed mobility architecture comprises of several handover sub-processes which are
essentially derived from MIPv6-based protocols and their enhancements. These sub-processes
are executed in succession to accomplish the handover process. In network-based IP mobility
protocols, some of these handover subprocesses rely entirely on MN’s movement, and network
nodes cannot control them. Others also rely on MN’s movement, however, the network node
can control their execution.
28 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
In order to seamlessly evolve the MIPv6-based protocols towards SDN paradigm, imple-
mentation of the handover sub-processes, which can be controlled by network nodes, can be
implemented such that they can be controlled by an SDN controller. Implementation of these
handover subprocesses as “standalone modules” on the centralized SDN controller is identified
as a viable approach to deploy them over SDN [46]. The SDN Controller can thus control the
execution of such handover subprocesses. We have also utilized the same approach in our
proposed mobility architecture.
In this section, we first define and briefly discuss these handover sub-processes. We then
present a taxonomy of these sub-processes, and based on this taxonomy, we describe the pro-
posed mobility solution, which is detailed in the subsequent sections.
3.2.1 The Handover sub-processes in the proposed scheme
In order to describe the handover sub-processes in the proposed scheme, we use terminologies
such as point-of-attachment, attachment point and edge node, interchangeably to represent a
network node an MN can attach to.
• MN Handover Prediction: The MN, during the handover prediction, learns that it is moving
into the domain of a new subnet and informs its current point-of-attachment about its
prospective new attachment point. It also shares the L2 network information of the new
network e.g. the new AP-ID with it. As a result, the current attachment point for MN can
prepare for MN’s handoff to the indicated new network. This process is only involved in
protocols which support predictive handovers.
• MN’s attachment detection: The MN’s attachment detection is the mechanism by which an
edge node detects a MN’s attachment to its link. This is also an L2 specific process, and
may represent an attachment of an MN due to its handover, or its initial attachment as it
newly enters the domain.
• Registration or Binding Update: The edge node, as it detects a new node to its link, per-
forms binding update registration. Unlike host-based mobility solutions, the binding
registration is performed by the edge node on MN’s behalf, by signaling the node which
maintains the Mobility Database for the domain. This process ensures that the informa-
tion about the current location of MN is updated each time the MN undergoes handover.
3.2. NETWORK-BASED IP MOBILITY HANDOVER SUB-PROCESSES 29
• Packet Forwarding: After the network learns MN’s new location, it has to resume its traffic
through its new attachment point. The packet forwarding in IP-based mobility protocols is
generally enabled through tunnelling from previous attachment point to new attachment
point, or from an anchor node towards the new attachment point. In an SDN domain,
traffic resumption is effectuated through path reconfiguration from the previous location
of the MN to its new location.
• Path Optimization: Packet forwarding from previous network or from a centralized anchor
towards new network of MN cannot guarantee an optimal path for traffic resumption.
For example, from Figure 3.2, if an MN undergoes handovers from FE-1 to FE-5, with
path towards n-FE being reconfigured during each handover process, the MN’s flows will
have to traverse through FE-1, FE-2, FE-3 and FE-4 to arrive at FE-5. Therefore, path
optimization may be carried out to configure an optimized path for MN’s traffic after its
handover. The path optimization process is analogous to route optimization process of
IP mobility protocol. However, it has different functional principles since it has to be
executed by an SDN Controller owing to the control and data plane separation.
• Buffering: In buffering process, the network nodes, e.g. the previous point of attachment for
MN, or the current anchor node, buffers the packets for MN until it learns about its new
network. This process saves the incoming packets in a node’s buffer, as it detects MN’s
handover in order to avoid packet losses.
• Bicasting: Bicasting mechanism, although has not been a standardized part of any Mobile
IPv6 protocol, has been utilized in its several enhancements. It provides an effective way
to temporarily continue sending traffic to MN over its previous as well as new network
simultaneously, while it is undergoing handover.
3.2.2 A Classification of the Network-based Handover Sub-processes
For a network-based decentralized mobility solution, we categorize the above handover sub-
processes as primary and supportive sub-processes, as shown in Figure 3.3. The MN’s at-
tachment detection along with binding update and packet forwarding are termed as primary
handover sub-processes. Without performing the primary handover sub-processes, the basic
handover process cannot complete.
30 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
Figure 3.2: Demonstrating the Path Optimization Process in an SDN Domain
The supportive handover sub-processes generally play a supportive role to the primary sub-
processes in order to optimize the handover process. These are not mandatory to accomplish a
typical handover event, and include path optimization, buffering and bicasting.
In the proposed mobility architecture, the handover sub-processes which cannot be con-
trolled by the CTR take place on a per-MN basis. On the other hand, the handover sub-processes
which can be controlled by CTR are executed on a per-flow basis. These are shown in green
and red in Figure 3.3 respectively.
3.3. OVERVIEW OF THE PROPOSED MOBILITY ARCHITECTURE 31
Figure 3.3: Classifying the Handover Subprocesses
3.3 Overview of the Proposed Mobility Architecture
In the proposed scheme, certain handover sub-processes detailed in Section 3.2 are condition-
ally enabled or disabled, according to MN’s current mobility requirements. The handover
management protocol thus flexibly operates in multiple modes of operation, unlike the tradi-
tional mobility solutions which lack flexibility. The handover process in the proposed scheme
accordingly incorporates a new Handover Mode Selection phase in which the CTR evaluates
the mode of operation for the next handover event that best suits the mobility needs of the
MN. The Handover Mode Selection phase conceptually comes after the Handover Information
Gathering phase and before the Handover Decision and Handover Execution phases [47, 48].
This is represented through Figure 3.4.
The Handover Information Gathering phase and the Handover Mode Selection phase are
collectively termed as Handover Preparation phase. Both these phases are carried out at CTR.
During the Handover Information Gathering phase, the CTR checks the ongoing sessions, and
32 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
Figure 3.4: The Handover Mode Selection phase among traditional handover phases
also evaluates the current handover frequency �curr of MN. The subsequent Handover Mode
Selection phase chooses the handover sub-processes to be enabled or disabled for the next
handover event.
During the Handover Preparation phase, the CTR updates a Mobility Database in which it
updates the context information of MN. The context information includes the current mobility
as well as session information for MN. A typical entry of the Mobility Database identified by
the MN’s Identifier (m mnId) is shown in Figure 3.5. The mobility information includes the IP
address of MN’s current serving FE (m servingFE), its �curr, the � � Thresholds (�th1 and
�th2), the number of currently active sessions (↵), and the path optimizations threshold (µth).
The CTR also maintains the information about each active session for MN, and distinguishes
them as Conversational, Non-conversational Multimedia and Non-Real-time sessions. For any
k sessions of each of these types, the CTR maintains the packet arrival rate (�x k), its session
length (⇡x k), and the addressing information of its respective anchor (m anchorAddressx k).
Both the Handover Information Gathering and Handover Mode Selection phases are periodi-
cally carried out by the CTR to update �curr and the information of the ongoing sessions, in the
Mobility Database in preparation for the next handover event. These are thus repeated each time
when (a) an ongoing handover event successfully completes, (b) the expected subnet residence
time interval for the MN elapses, (c) the MN establishes a new session, and (d) an ongoing
session terminates.
The Handover Decision phase represents the phase when the MN decides to change its
current attachment point. There could be different criteria for MN to decide the handover – a
well-known criterion being the Received Signal Strength (RSS). The MN may make handover
decision as it receives better RSS from a neighbouring access network, and initiates handover
to it. The MN may update its current attachment point about its prospective handover or it
3.4. THE PROPOSED SIGNALING MESSAGES 33
Figure 3.5: A typical Mobility Database Entry in the proposed AMM scheme
may directly attach to new network without providing any such update to its current point of
attachment. The handover process may thus be termed as predictive or reactive in either of these
scenarios respectively.
In case of a predictive handover, the handover initiation from MN represents the start of
Handover Execution phase, while, the MN’s attachment detection at new network represents
start of the Handover Execution phase in reactive handover. During the Handover Execution
phase, the actual handover signaling according to the handover sub-processes enabled during
the Handover Mode Selection phase is carried out.
The handover signaling in the proposed scheme is carried out among the CTR, the FEs
and the Anchor nodes during Handover Execution phase. We have defined OpenFlow-based
signaling messages to be exchanged among these entities.
In the following subsections, we first present the signaling messages proposed in the AMM
scheme. We then present a set of algorithms during the Handover Information Gathering and
Handover Mode Selection phases, which are used by the CTR to ENABLE or DISABLE the
handover sub-processes. Finally, we discuss the Handover Execution process and present the
signaling sequence involved in both predictive and reactive handovers.
3.4 The Proposed Signaling Messages
The proposed AMM mobility scheme defines OpenFlow-based signaling messages which are
defined based on OpenFlow Experimenter header. An OpenFlow message of type Experi-
menter, just like any other OpenFlow message, begins with the OpenFlow header which is
34 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
followed by the Experimenter header.
The proposed signaling messages are defined both for predictive and reactive handovers.
These messages also include the messages for path optimization process. The proposed mes-
sages sent from the CTR to the FE effectively function as OpenFlow flow-mod or Packet-
In messages. A flow-mod message adds, modifies or deletes a flow entry in the flow table.
However, as this flow table entry modification in the proposed scheme is happening as a result of
handover, the respective messages exchanged between the CTR and entities such as p-FE, n-FE,
current Anchor, new Anchor etc., are represented through different terminologies. Similarly,
certain messages or indications which are received by an FE from MN are sent to the CTR as
OpenFlow Packet-In messages. A Packet-In message contains a packet which is received at an
FE’s port, for which it is unable to take any action since it does not find any rules to process the
packet in its flow table.
3.4.1 Proposed Extensions to the OpenFlow Protocol
The proposed mobility management architecture relies on certain modest extensions to the
standard OpenFlow specification. These extensions are optional and the proposed protocol
can still operate with same handover performance even if these are not implemented.
The standard OpenFlow specification defines a Flow-Removed message which is sent from
an FE to CTR to update the CTR about removal of a flow entry. A flow entry in an FE can
be removed if it is expired as a result of timeout, or is removed in response to a flow-mod
(REMOVE) message from CTR. In the latter case, the CTR sets a OFPFF SEND FLOW REM
flag if it needs confirmation from the FE about the removal of the flow entry.
However, the standard OpenFlow specification does not specify any such responses as a
result of flow-mod (ADD) or flow-mod (MODIFY) requests from the CTR.
For an OpenFlow-based handover protocol to operate in high mobility and session activity
scenarios, an efficient protocol operation can be achieved if the CTR gets a similar Acknowl-
edgement for flow-mod (ADD) and flow-mod (MODIFY) messages, as it can receive for flow-
mod (REMOVE) messages. Thus, we proposed to extend the OpenFlow protocol with these
Acknowledgement messages which are termed as Flow-Added and Flow-Modified respectively.
The CTR if requires these acknowledgements, will accordingly have to set the respective flags
3.4. THE PROPOSED SIGNALING MESSAGES 35
Table 3.1: The Proposed Signaling Messages for the AMM Protocol
Proposed Message OpenFlow Message Type AMM Handover Phaseofp ho adv buffer support flow-mod (ADD) Handover Mode Selectionofp ho adv bicast support flow-mod (ADD) Handover Mode Selection
ofp ho update info Packet-In Handover Executionofp ho support cmd flow-mod (MODIFY) Handover Executionofp ho prep cmd flow-mod (ADD) Handover Execution
ofp ho attach info Packet-In Handover Executionofp ho path update cmd flow-mod (MODIFY) Handover Executionofp path update cmd flow-mod (MODIFY) Handover Executionofp path update ack Flow-Modified (optional) Handover Executionofp path rem cmd flow-mod (REMOVE) Handover Executionofp ho update cmd flow-mod (ADD) Handover Executionofp ho update ack Flow-Added (optional) Handover Executionofp anch init flow-mod (ADD) Handover Executionofp anch ack Flow-Added (optional) Handover Executionofp anch rem flow-mod (REMOVE) Handover Execution
i.e. OFPFF SEND FLOW ADD and OFPFF SEND FLOW MODIFY to true.
Such Acknowledgement messages can be especially useful in scenarios in which sending
out a particular message depends on the successful addition or modification of a flow entry.
3.4.2 The Proposed Signaling Messages
The proposed signaling messages in the AMM protocol are of type flow-mod and Packet-In, as
listed in Table 3.1. The flow-mod messages among these may or may not require the respective
Acknowledgements.
Proposed Signaling Messages for Handover Mode Selection
During the Handover Mode Selection phase when the CTR evaluates if it requires to provide
buffering and bicasting services to certain flows of the MN, it can also pre-install the inactive
flow entries for respective flows at p-FE and the current Anchor. The inactive flow entries can
also be installed for packet forwarding.
36 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
In the proposed protocol, the flow-mod type messages are essentially responsible to es-
sentially effectuate packet forwarding, bicasting and buffering. The packet forwarding and
bicasting process require common flow-mod ADD/MODIFY/REMOVE type commands from
CTR. The implementation of buffering however can be done through Packet-In event/message.
A Packet-In event is generated by an OpenFlow switch if it requires to transfer the control
of a packet to the CTR. In this case, the OpenFlow switch may buffer the packet in its memory
or may send its buffer id in Packet-In message. Alternatively, it may send some initial bytes or
full packet to the controller.
According to the standard OpenFlow specification, this mechanism can be applied to any
incoming traffic which needs to be buffered. For this purpose, a flow entry can be created
(through flow-mod (ADD)) whose Output Action generates a Packet-In event. The Output
Action in this case directs the packet to the CONTROLLER RESERVED port, as a result of
which the packet may be saved at FE or sent to the Controller for buffering. In the proposed
protocol, it is assumed that the FE nodes (p/n-FEs and Anchors) have sufficient memory to
buffer all incoming packets of the MN. In practical scenarios, if an FE runs out of memory,
buffering can also take place at CTR in which case the packets will be sent to the CTR as
Packet-In messages.
The proposed signaling messages for buffering and bicasting communicated to p-FE and
current Anchor by the CTR are as follows.
• ofp ho adv buffer support This message is sent from CTR to an FE (i.e. the p-FE or
the current Anchor) to pre-install a flow entry on it. The priority of this flow entry is kept
very low, so that it does not get executed and remains inactive.
• ofp ho adv bicast support This message is also sent from CTR to to an FE (i.e. the
p-FE or the current Anchor) to pre-install a flow entry. The priority of this flow entry is
also kept very low to keep it inactive.
Proposed Signaling Messages during Predictive Handover:
The proposed signaling messages for predictive handover are defined below:
• ofp ho update info This message is sent from an FE to CTR, when the FE receives a
3.4. THE PROPOSED SIGNALING MESSAGES 37
Handover Indication message from MN. The MN sends the Handover Indication message
to FE to initiate the predictive handover. The Handover Indication message may carry
information such as AP-ID of the scanned new AP.
• ofp ho support cmd This message is sent from CTR to the current Anchor(s) of the
MN’s flows to modify the flow entries which were added during the Handover Mode
Selection phase. As a result, the buffering and bicasting services get enforced. For
buffering, the priority of the respective flow entry is increased, while for bicasting, the
n-FE information is updated as destination so that traffic is directed towards it as well.
The CTR may send two different messages to activate each of these flow entries. The
Acknowledgement flag is set to FALSE in this message.
• ofp ho prep cmd The ofp ho prep cmd message is sent from CTR to n-FE. The CTR,
when it earlier receives the ofp ho update info message from p-FE, checks the AP-
ID and learns the n-FE which manages that AP. It then sends the ofp ho prep cmd
message to n-FE to add new flow entries on it so that it may start handling MN’s traffic
which is to be forwarded to it from p-FE. The Acknowledgement flag for this message is
kept FALSE.
• ofp ho attach info The ofp ho attach info message is sent by n-FE to CTR.
This message is sent to CTR after the MN indicates its attachment to n-FE. It thus
indicates the CTR that the MN has indeed attached to n-FE and the n-FE is ready to
forward incoming traffic to the MN.
• ofp path update cmd This message is sent from CTR to current Anchor(s) for ongoing
flows. This message modifies the flow entry at current Anchor so that it stops sending
traffic to p-FE and instead send traffic to n-FE. The Acknowledgement flag in this case is
set to TRUE.
• ofp path update ack The Anchor(s) in turn updates its flow table entries, and sends
back the ofp path update ackmessage back to CTR. The ofp path update ack
message is effectively an Acknowledgement message of ofp path update cmd.
• ofp path rem cmd The ofp path rem cmd message is sent to p-FE to remove the flow
table entries for the respective flows of the MN. The CTR sends this message to p-FE
once it gets an Acknowledgment that the current Anchor has updated flow entries to
38 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
send traffic directly to the n-FE. Alternatively, if the (optional) Acknowledgement is not
implemented, it may expect to receive an error for a short period, which if not received,
would indicate that the desired flow modification has been successfully carried out.
• ofp ho path update cmd The ofp ho path update cmd is also a flow-mod mes-
sage which update the existing flow table entries to start packet forwarding from p-FE to
n-FE. An additional message may also be communicated by the CTR if it requires to stop
bicasting or buffering.
Proposed Signaling Messages during Reactive Handover
The proposed signaling messages for reactive handover are defined below:
• ofp ho attach info The ofp ho attach info message is sent from an FE to CTR
which receives the Attachment Announcement from MN. This message may contain in-
formation such as the MN ID of the attached MN.
• ofp ho support cmd As the CTR receives the ofp ho attach info, and finds an
MN already registered has now attached to another FE without priorly indicating its
intentions to handover, it recognizes that the AMM has to operate reactively. Accordingly,
the CTR sends the ofp ho support cmd message to p-FE to effectively modify the
flow entries e.g. to start buffering at p-FE until the new flow rules are installed at n-FE,
and is consequently ready to receive and forward the MN’s traffic.
• ofp mn info update cmd The CTR also responds to n-FE with ofp ho update cmd
message to add new flow entries at n-FE for MN’s the ongoing flows.
• ofp ho update ack The n-FE installs flow entries for respective flows of MN, and (op-
tionally) sends back the ofp ho update ack message to CTR.
• ofp ho path update cmd The CTR, on receiving the ofp ho update ack message
from n-FE, sends the ofp ho path update cmd message to p-FE to update the flow
entries, so that the MN’s ongoing flows can be forwarded to the n-FE.
Proposed Signaling Messages for Path Optimization
The proposed signaling messages for path optimization are defined below:
3.5. HANDOVER PROCESS OF AMM SCHEME 39
• ofp anch init The ofp anch init message is sent from the CTR to newly evaluated
anchor for the MN’s flows. This message also adds new flow table entries for the ongoing
flows of the MN which would be anchored by this new Anchor.
• ofp anch ack The chosen anchor node on receiving ofp anch initmessage from CTR
updates its flow entries and sends back the Acknowledgement message, ofp anch ack
back to CTR. This is also an optional Acknowledgement message, and if not available,
the CTR can assume the successful addition of flow entry at new Anchor after waiting for
a short period, expecting an possible error indicating failure of the flow entry addition.
• ofp anch rem This message is sent by the CTR to the current Anchor(s) of the ongoing
flows after the CTR receives the ofp anch ack message from the new Anchor(s). This
message also effectively acts as flow-mod message, as it removes the flow table entries
from the current Anchors.
3.5 Handover Process of AMM Scheme
This section describes the handover process of the AMM scheme which undergoes four major
phases. The Handover Decision phase among these represents the instant when the MN decides
to handover, and is discussed alongside the Handover Execution phase in the below subsections.
3.5.1 The Handover Information Gathering phase
During the Handover Information Gathering phase, the SDN Controller collects the context
information of MN which consists of information on MN’s ongoing sessions as well as its
current handover frequency. The CTR first checks and identifies the types of currently active
sessions for MN whether they are conversational, non-conversational multimedia, or non-real-
time sessions. The active number of each session type is represented by ↵c, ↵nc and ↵nR
respectively. The CTR also checks the current packet arrival rate �p for each session. Moreover,
through Algorithm 1, it adjusts the handover frequency (�) thresholds, and then also evaluates
the current handover frequency (�curr). All these parameters are evaluated to be used during the
subsequent Handover Mode Selection phase.
In order to evaluate the handover frequency thresholds, we assume a default time interval
40 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
Tdef over which a default number of handovers Ndef take place. Ts represents the current time
period over which Ndef handovers occur. TsNdef
defines the expected subnet residence interval.
The default handover frequency (�def ) is calculated for Ndef over Tdef . Two � threshold values
�th1 and �th2 are defined, where �th1 represents high handover frequency above which, enabling
the supportive non-PO-based1 handover sub-processes for real-time flows are desirable. The
�th2 represents higher handover frequency than �th1 , and represents a value above which the
supportive non-PO-based handover sub-processes must be enabled to ensure seamless handover.
According to the current scenario, as Ts varies, the �th1 and �th2 are correspondingly ad-
justed in Algorithm 1. This in turn impacts the decisions the CTR makes during the Handover
Mode Selection phase through Algorithms 2-4. The CTR then evaluates �curr and - both of
which are subsequently used in Handover Mode Selection phase. is given as m
Tdefwhere m
represents |Ts � Tdef | and ✏ = 10�2. The current handover frequency, �curr is then calculated
over an interval ⌧ , which is based on the lower value among Ts and Tdef .
Algorithm 1 Handover Information Gathering phase1: Estimate Ts and �s;2: if Ts < Tdef then3: �th1 �def ;4: �th2 �s;5: ⌧ = 2 · Ts;6: bc;7: else if Ts > Tdef then8: if m < ✏ then9: �th1 = �th2 �def ;
10: else11: �th1 �def ;12: �th2 �s;13: ⌧ = 2 · Tdef ;14: de;15: �curr = N⌧/⌧ ;
3.5.2 The Handover Mode Selection phase
The Handover Mode Selection phase determines the prospective enforcement of the handover
sub-processes which are controlled by CTR, thereby selecting the mode of operation for the
next handover event. The Handover Mode Selection phase is depicted through Algorithms 2-4,1The non-PO-based handover subprocesses include buffering and bicasting. The PO-based handover
subprocesses include Anchor Selection, Flow Selection, and PO Signaling
3.5. HANDOVER PROCESS OF AMM SCHEME 41
wherein the CTR first evaluates µth that corresponds to different values of �curr (Algorithm 2)
and then chooses priority sessions for PO (Algorithm 3). This follows a lightweight anchor
selection process for the chosen flow(s) (Equation 1 & 2). Finally, Algorithm 4 decides whether
the buffering and bicasting services are to be enabled during the handover event.
In high mobility scenarios, evaluating a new optimized path and consequently implementing
the forwarding rules over the full SDN domain at each handover event is prone to incur longer
service disruptions. On the other hand, resuming the ongoing sessions for MN simply through
packet forwarding from MN’s previous location to its new location also results in non-optimized
path. The proposed solution thus relies on a reference entity for each of MN’s ongoing flows
through which these flows are anchored to the MN’s new location. Through this approach, the
CTR only needs to update the forwarding rules at the anchor node, installs new rules at n-FE
and removes rules from previous entity. In case, the mobility context of the MN actually allows
CTR to change its anchor, only then it will have to re-evaluate the path inside its domain. This
process is demonstrated through an example scenario in Figure 3.6, where an MN establishes
a session at FE-1, and another session at FE-2. Both these sessions are anchored by different
FEs.
During the MN’s handover from FE-3 to FE-4, the CTR decides to change the anchor for
flow-1, and during the next handover from FE-4 to FE-5, it changes the anchor for flow-2 as
shown in Figure 3.6.
In any case, when the CTR chooses to change the anchor node on MN’s handoff, it first
evaluates the most suitable node based on MN’s new FE. Certain recent studies have proposed
anchor selection mechanisms e.g. in [39, 49]. However, these solutions either involve MN in
anchor selection mechanism [49], thus being unsuitable for a network-based mobility solution,
or provide heavy-weight mechanisms [39], which would require substantial modifications to
be applied to our proposed mobility architecture. Therefore, we have proposed a lightweight
anchor selection mechanism which is based on Multiple Attributes Decision Making (MADM)
approach.
In Algorithm 2, the CTR evaluates µth which corresponds to the value of n, which is
evaluated in Algorithm 1. Based on the values of Ts with respect to Tdef , is rounded off
in Algorithm 1, such that it favours the execution of an PO for Ts > Tdef and prevents it
otherwise.
42 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
Figure 3.6: Demonstrating the Path Optimization process in the proposed scheme
Flow Selection during Handover Mode Selection
In Algorithm 3, the CTR prioritizes the ongoing active sessions for PO. The conversational
sessions are given higher priority for PO in order to ensure that they are provided an optimized
path throughout their duration, so that the end-user experiences minimal delay. For ↵c < µth,
the CTR executes PO for all the ongoing conversational sessions. This is followed by the non-
conversational multimedia sessions and the non-real-time sessions, provided that (↵nc+↵nR) <
3.5. HANDOVER PROCESS OF AMM SCHEME 43
Algorithm 2 Evaluation of µth at Handover Mode Selection1: Evaluating µth;2: if �curr > �th2 then3: µth 0;4: PO FALSE;5: else if �th1 �curr �th2 then6: µth
7: else8: µth + 1;
return µth
(µth � ↵c). Otherwise, for any ↵x > µth, the CTR chooses session(s) with ⇡max, where ⇡x
represents the current session length of session x from previously successful PO for the session.
Anchor Selection during Handover Mode Selection
As sessions are chosen for PO, the CTR then chooses a suitable anchor among the candidate
anchors for each of these sessions through a well-known Simple Additive Weighting (SAW)
technique of Multiple Attribute Decision Making (MADM) method [50]. The active user
density (�), the number of hops between the candidate anchor of the flow and its n-FE (⌘),
and an H-factor (H) are the attributes in SAW. The CTR having view of the domain, inherently
maintains the �, while ⌘ is evaluated as,
⌘ = h+ 1 (3.1)
where, h represents the number of hops between candidate anchor and p-FE. The H-factor
is the ratio of the total number of flows of MN to pass through a particular candidate anchor
after PO to µth. This is based on Heat factor defined in [49], and implies that the anchor chosen
to serve more flows for MN should have more weightage than others. The value function for a
candidate anchor j is given as,
%j = !1 · �j + !2 · ⌘j + !3 ·Hj (3.2)
where !k the weight assigned to the kth attribute is evaluated through rank sum weights
44 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
Algorithm 3 Flow Selection for µth > 0 during Handover Mode Selection phase1: CTR determines ↵c, ↵nc and ↵nR
2: ↵ = ↵c + ↵nc + ↵nR;3: Initialization:4: i, j, ⇡max, µ 0;5: ↵x 1;6: Evaluating ↵x:7: for i = 0; i 0; i+ = µth do8: if ↵c > 0 then9: ↵x ↵c;
10: ↵c NULL;11: goto FlowSelection;12: else if ↵nc > 0 then13: ↵x ↵nc;14: ↵nc NULL;15: goto FlowSelection;16: else if ↵nR > 0 then17: ↵x ↵nR;18: ↵nR NULL;19: goto FlowSelection;20: FlowSelection;21: while j < ↵x do22: if ↵x µth then23: µ 0; . µ is RESET24: µ = ↵x;25: if (µth � µ) == 0 then26: return27: j = j + ↵x;28: µth (µth � µ);29: else30: for (l = 0; l µth; l ++) do31: candF low[↵x]; . an array of candidate flows32: for (k = 0; k ↵x; k ++) do33: Evaluate ⇡max among candF low[↵x];34: Compare ⇡k for candF low[k] with ⇡max;35: if ⇡k > ⇡max then36: ⇡max ⇡k;37: Choose candF low[k] for PO38: candF low[k] NULL;39: µth µth � 1;40: j ++;
return
3.5. HANDOVER PROCESS OF AMM SCHEME 45
technique [50],
!k =N � rk + 1
PN
l=1(N � rl + 1)(3.3)
Buffering, Packet Forwarding and Bicasting during Handover Mode Selection:
The buffering, bicasting and packet forwarding services are evaluated for the ongoing flows by
the CTR during the Handover Mode Selection phase. These evaluations are done on a per-flow
basis, and are done for both predictive and reactive handover cases. The CTR thus separately
evaluates these rules for both predictive and reactive cases through Algorithm 4 and Algorithm
5 respectively. It installs these rules in the involved nodes for predictive handover case during
the Handover Mode Selection phase. These nodes include the p-FE, and the current Anchor(s)
of flows for which these services are enabled. For reactive case, these rules are installed during
the Handover Execution phase, after the CTR learns about MN’s new attachment.
These services are also evaluated by controller based on the session type and the handover
frequency for MN. The CTR also decides the duration until which these services remain en-
abled. This duration is set according to the signaling messages received by the respective
entity. The ongoing conversational sessions are given higher preference followed by non-
conversational multimedia and non-real-time sessions. The CTR, based on the current handover
frequency of the MN, also evaluates the entity among p-FE and current anchor(s) at which these
services are to be enabled.
For example, in case the MN has lower handover frequency than �th1 during predictive
handover, the algorithm enables bicasting service for conversational sessions of the MN both at
p-FE and the respective current anchors each of these flows. The duration for which bicasting
would remain enabled is set according to signaling messages these entities receive. At p-FE, it is
enabled as the MN receives the ofp ho support cmd message and is disabled as it receives
ofp ho support disable message. Similarly, at any current Anchor, it is enabled as it
receives the ofp ho support cmd message from the CTR, and disables it when it receives
ofp path update cmd message.
Like bicasting, buffering can also be enabled at p-FE or the current Anchor for MN. Accord-
ing to Algorithm 4, it is enabled at p-FE for �curr < �th1 , only for minimal duration between the
46 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
p-FE receives the ofp ho support cmd and ofp ho support disable message. For
higher handover frequency, it remains disabled for conversational sessions. On the other hand,
for non-conversational multimedia sessions, buffering is enabled at current anchor.
The packet forwarding process between the p-FE and n-FE is only enabled by CTR after the
n-FE indicates it that it is ready to receive the MN’s traffic. It is subsequently disabled as the
CTR updates new path between current anchor and n-FE, and sends the ofp path rem cmd
message to p-FE.
In case of reactive handover, the bicasting service remains disabled, since the MN has
already detached from its previous link. If buffering is set to true by Algorithm 5, it is enabled at
current Anchor so that no traffic could be sent to p-FE. The packet forwarding, if enabled, starts
at p-FE as it receives the ofp ho path update cmd message from CTR and continues until
it receives the ofp path rem cmd from CTR.
3.5.3 The Handover Execution phase
The Handover Execution process follows the Handover Decision process in the proposed scheme.
The Handover Decision process relies on whether the MN indicates its current FE about its
imminent handover or attaches to new FE without such indication. The handover process thus
may take place predictively or reactively. In this section, we present the Handover Execution
process in the proposed scheme through signaling sequence involved in both predictive and
reactive cases.
Predictive Handover:
During the predictive handover,
1. As the MN in p-FE’s domain detects imminent handover e.g. due to higher RSS from the
neighbouring FE’s AP, it sends a Handover Indication message to the p-FE. This
message may contain among other information, the network identifier e.g. Access Point
ID of the network into it moving into.
2. The p-FE then creates the ofp ho indicate info message and sends it to the CTR.
This message essentially carries the Handover Indication message message.
3.5. HANDOVER PROCESS OF AMM SCHEME 47
Algorithm 4 Evaluating Buffering and Bicasting during Handover Mode Selection1: CTR determines provisioning of Buffering and Bicasting for Predictive Handover;2: if ↵c > 0 then3: for (i = 0; i ↵c; i++) do4: if (�curr < �th1) then5: Buffering TRUE at p-FE;6: . from ofp ho support cmd$ofp ho path update cmd;7: Bicasting TRUE from current Anchor;8: . from ofp ho support cmd$ofp path update cmd;9: Bicasting TRUE from p-FE;
10: . from ofp ho support cmd$ofp ho path update cmd;11: PacketForwarding TRUE from p-FE to n-FE;12: . from ofp ho updatecmd$ofp path rem cmd;13: else14: Buffering FALSE;15: Bicasting TRUE from current Anchor;16: . from ofp ho support cmd$ofp ho support disable
17: PacketForwarding TRUE from p-FE to n-FE;18: . from ofp ho path update cmd$ofp path rem cmd;19: else if ↵nc > 0 then20: CTR chooses the Non-Conversational Multimedia session with �max
21: if (�curr < �th1) then22: Buffering TRUE at current Anchor;23: . from ofp ho support cmd$ofp path update cmd;24: Bicasting TRUE at current Anchor;25: . from ofp ho support cmd$ofp path update cmd;26: PacketForwarding TRUE from p-FE to n-FE27: . from ofp ho path update cmd$ofp path rem cmd;28: else29: Buffering TRUE at current Anchor;30: . from ofp ho support cmd$ofp path update cmd;31: Bicasting FALSE;32: PacketForwarding TRUE from p-FE to n-FE;33: . from ofp ho path update cmd$ofp path rem cmd;34: else35: Buffering FALSE;36: Bicasting FALSE;37: PacketForwarding TRUE from p-FE to n-FE38: . from ofp ho path update cmd$ofp path rem cmd;
return
48 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
Algorithm 5 Evaluating Buffering and Bicasting during Handover Mode Selection1: CTR determines provisioning of Buffering and Bicasting for Reactive Handover;2: Bicasting FALSE;3: if ↵c > 0 then4: for (i = 0; i ↵c; i++) do5: Buffering TRUE at current Anchor6: . from ofp ho support cmd$ofp ho path update cmd;7: PacketForwarding TRUE from p-FE to n-FE;8: . from ofp ho path update cmd$ofp path rem cmd;9: else if ↵nc > 0 then
10: CTR chooses the Non-Conversational Multimedia session with �max
11: if (�curr < �th1) then12: Buffering TRUE at current Anchor;13: . from ofp ho support cmd$ofp path update cmd;14: PacketForwarding TRUE from p-FE to n-FE;15: . from ofp ho path update cmd$ofp path rem cmd;16: else17: Buffering FALSE;18: PacketForwarding TRUE from p-FE to n-FE;19: . from ofp ho path update cmd$ofp path rem cmd;
return
3. The CTR on receiving this message, updates the Mobility Database entry for MN. If
PO were enabled during the Handover Mode Selection phase, it also evaluates suitable
Anchor for the flows chosen for PO. For this purpose, it evaluates the new Anchor(s)
among FE which surround the n-FE, through mechanism described in Section 3.5.2.
The CTR also checks the new AP-ID it received in the ofp ho indicate info mes-
sage and identifies the respective n-FE associated to it. It then creates and sends the
ofp ho prep cmd message to the n-FE which installs the flow entries for the ongoing
flows of the MN.
4. Meanwhile, the CTR also creates and sends the ofp ho support cmd message to p-
FE. This message enforces buffering and bicasting service if they were enabled during
the Handover Mode Selection phase. The p-FE thus starts sending traffic to MN over its
wireless link, and will also be sending traffic over to n-FE’s link.
5. On the other hand, the n-FE installs the flow entries sent to it via the ofp ho prep cmd
message, and as soon as it receives the MN’s Attachment Announcement to its wireless
link, it sends back the ofp ho attach info message to the CTR.
6. The CTR as a result sends the ofp ho path update cmd message to p-FE, which
3.5. HANDOVER PROCESS OF AMM SCHEME 49
Figure 3.7: Message flow of the Proposed Predictive Operation
will stop buffering or bicasting (if enforced earlier), and will forward any traffic for MN
towards the n-FE.
7. The CTR then initiates the path reconfiguration process with the current Anchor(s) of the
ongoing flow(s). For this purpose, it sends the ofp path update cmd message to the
current Anchor(s). This message installs flow entries at current anchor(s) so that they
move the traffic of MN towards n-FE.
8. After flow modifications, the current anchor(s) send the (optional)
ofp path update ack message to CTR.
50 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
9. The CTR, after receiving the ofp path update ack message sends the
ofp path rem cmd message to p-FE. With ofp path rem cmd message, the p-FE
removes the flow table entries for the respective flows for the MN. So any packet forward-
ing from p-FE to n-FE stops at this point.
10. The CTR, next initiates the path optimization process if it was enabled during the Han-
dover Mode Selection phase. For this purpose, it already has suitable anchor(s) evaluated
for the chosen flow(s) for PO in Step 4. It sends the ofp anch init message to the
new Anchor(s) to instruct it to install the flow entries for a particular flow.
11. The new Anchor(s) installs the flow entries, and send back the (optional) ofp anch ack
message to CTR.
12. The CTR in turn sends the ofp anch rem message to current Anchor, which instructs
it to remove the flow entries for the subjected flows of the MN.
Reactive Handover:
During the reactive handover,
1. The MN announces its attachment with n-FE. This is represented by Attachment An-
nouncement message in Figure 3.8.
2. The n-FE accordingly sends an ofp ho attach info message to CTR which essen-
tially carries the information received in the Attachment Announcement.
3. The CTR which has pre-computed the flow instructions for MN during the Handover
Mode Selection phase, accordingly sends the instructions set back to n-FE right away
in ofp ho update cmd message. Moreover, the CTR also carries out the Anchor
Selection mechanism which is described in Section 3.5.2.
4. Meanwhile, the CTR also sends the ofp ho support cmd message to p-FE. The p-
FE accordingly enforces the buffering and/or bicasting processes by modifying the flow
entries which are pre-installed rules during the Handover Mode Selection phase.
3.5. HANDOVER PROCESS OF AMM SCHEME 51
Figure 3.8: Message flow of the Proposed Reactive Operation
5. On the other hand, as the n-FE finishes installation of these rules, it sends back the (op-
tional) ofp mn info update ack to CTR to indicate that the necessary flow entries
are installed and it is ready to manage traffic destined towards the MN.
6. As soon as the CTR receives the ofp ho update ack message, it sends the
ofp ho path update cmd message to p-FE. With this message, the p-FE installs the
required flow entries and sends all traffic it receives for MN towards the n-FE.
7. The CTR then initiates the path reconfiguration process with the current Anchor(s) of the
52 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
ongoing flow(s). For this purpose, it sends the ofp path update cmd message to the
current Anchor(s).
8. The current Anchor(s) on receiving this message, modifies its flow entries in order to
divert the MN’s flows towards n-FE. After flow modifications, it sends the (optional)
ofp path update ack message to CTR.
9. The CTR, after receiving the ofp path update ack message sends the
ofp path rem cmdmessage to p-FE. As a result of receiving the ofp path rem cmd,
the p-FE removes the flow table entries for the respective flows of the MN.
10. The CTR, next initiates the path optimization process if it was enabled during the Han-
dover Mode Selection phase. For this purpose, it already has suitable anchor(s) evaluated
for the chosen flow(s) for PO in Step 3. It sends the ofp anch init message to the
new Anchor(s) to instruct it to install the flow entries for ongoing flows.
11. The new Anchor(s) installs the flow entries, and send back the (optional) ofp anch ack
message to CTR.
12. The CTR in turn, sends the ofp anch rem message to the current Anchor, which
instructs it to remove the flow entries for subjected flows of the MN.
3.6 Chapter Summary
This chapter presents the detailed description of the proposed mobility architecture. The design
principles of the proposed scheme are first established, which is followed by a discussion and a
taxonomy of the handover sub-processes involved in the proposed mobility architecture. New
signaling messages, proposed both for predictive and reactive handover cases along with path
optimization process are described. This followed the detailed discussion of the proposed
mobility scheme. Different algorithms which constitute the novel Handover Mode Selection
phase are described, along with the protocol operation for both predictive and reactive handover
cases.
The next chapter presents analytical evaluation of the proposed AMM solution in compari-
son with the PMIPv6-based DMM protocol. The analytical models developed for high mobility
3.6. CHAPTER SUMMARY 53
and session activity are developed, and the performance comparison of both schemes is done
based on session disruption latency, packet loss and signaling cost.
54 CHAPTER 3. THE ADAPTIVE MULTIMODE DECENTRALIZED MOBILITY SOLUTION
Chapter 4
Analytical Evaluation for the Proposed Scheme
The analytical modelling has remained a popular approach for performance evaluations of
mobility protocols. Several analytical frameworks to evaluate the performance of IP mobility
protocols have been proposed in the open literature [51, 52]. These analytical frameworks
facilitate modeling and evaluation of the mobility protocols and various enhancements proposed
over the years.
In this chapter, we first evaluate and compare the handover performance of the three PMIPv6-
DMM (pDMM-I, pDMM-II and pDMM-III) proposals proposed by the IETF through analytical
modelling. The comparison is done based on handover latency, packet loss and signaling cost.
For simplicity, this comparison is done for a single handover instance of a MN with single
ongoing session.
Based on the most optimal handover performance among PMIPv6-DMM schemes, one
scheme is chosen for its performance comparison with the proposed AMM scheme. This
comparison is done considering the high mobility and session activity scenario. In Section
4.2, the expressions from Section 4.1 are thus expanded. In Section 4.3, a detailed comparative
analysis of both schemes is performed. Section 4.4 presents the summary and concludes this
chapter.
4.1 Comparison of pDMM-I, pDMM-II and pDMM-III
In this section, a comparison of pDMM-I, pDMM-II and pDMM-III is presented, which is
based on fundamental handover performance evaluation metrics like handover delay, signaling
55
56 CHAPTER 4. ANALYTICAL EVALUATION
cost and packet loss.
Handover Delay Comparison:
Figure 4.1: Impact of processing delay at MAAR (PDmaar) on total handover delay on pDMMschemes (Case - 1a)
In order to compare the three approaches for pDMM, we first formulate expressions for
the delay incurred by each of them according to the analytical framework [51]. The total
handover delay as defined in [53] is the time instance between the MN receives last data packet
at pMAARs link to the first data packet it receives at the new link. According to [51], the major
delay factors during handover include, (a). the L2 handover delay (tL2), (b). wired and wireless
link transmission delay between nodes x and y (Tx,y), (c). processing delay at node x (PDx),
and (d). queuing delay (⌦) at a packet forwarding node e.g. a MAAR.
DpDMMI= tL2 + 3 · (PDmaar + ⌦maar) + 4 · Tmaar,cmd + 2 · PDcmd + Tmn,pmaar (4.1)
DpDMMII= tL2 + 3 · (PDmaar +⌦maar) + 2 · Tmaar,cmd +PDcmd + Tpmaar,nmaar + Tmn,pmaar
(4.2)
4.1. PDMM SCHEMES COMPARISONS 57
Figure 4.2: Impact of transmission delay between MAAR and CMD (Tmaar,cmd) on totalhandover delay on pDMM schemes (Case - 1b)
DpDMMIII= tL2+2 · (PDmaar +⌦maar)+ 2 ·Tmaar,cmd+PDcmd+Tpmaar,nmaar +Tmn,pmaar
(4.3)
As previously noted, these approaches are inherently reactive in nature, the L2 handover
signaling precedes the L3 handover signaling. Thus, for comparison, each of these schemes are
set to have common L2 delay. Values of other performance metrics used are shown in Table
4.1. Other than L2 delay, the average processing delay at MAARs and the average transmission
delays between MAARs and the CMD have significant contribution to the overall handover
latency. Values of both these parameters are thus varied to calculate their impact on overall
latency for each of pDMM schemes. The results are shown in Figure 4.1, and 4.2 respectively.
The results in Figures 4.1, and 4.2 show that pDMM-III has most optimal handover per-
formance in terms of handover latency which is nearly half of pDMM-I scheme. This is
largely because the CMD can send the PBA* message to the sMAAR without waiting for
the PBA* from the pMAAR. And as soon as the pMAAR performs route update according
to the PBU* received from the CMD, it starts forwarding traffic to the sMAAR assuming that
it is ready to receive traffic as CMD had already sent the PBA* to it. For pDMM-III scheme,
58 CHAPTER 4. ANALYTICAL EVALUATION
Table 4.1: Parameter notations with description and default values for three PMIPv6-DMMSchemes Comparison
Parameter Notation Description Default ValuetL2 Layer 2 handover delay 50 ms
⌦maar Queuing delay 4 msPDmaar Processing delay at MAAR 30 msPDcmd Processing delay at CMD 30 msTsmaar,mn Transmission delay between sMAAR and MN 6 ms
Tpmaar,smaar Transmission delay between pMAAR and sMAAR 6 msTmaar,cmd Transmission delay between MAAR and CMD 6 msDBC Database update cost 15 units
PCmaar = PCcmd Processing cost at MAAR and CMD 30 unitsTCpmaar,Smaar Transmission cost between sMAAR and pMAAR 10 unitsTCmaar,cmd Transmission cost between MAAR and CMD 10 units
transmission of both PBA*s don’t contribute to the handover latency, since reception of the
PBA* at nMAAR from CMD does not trigger any packet-forwarding/service resumption for
MN, while the pMAAR on the other hand also does not relate sending of PBA* to CMD to the
forwarding of traffic that it receives. As mentioned earlier, it starts forwarding traffic to nMAAR
as soon as it configures the new prefix of MN received from CMD. Similarly, in pDMM-II the
PBA* sent to CMD from pMAAR does not add to the overall handover latency for the same
reasons.
Packet Loss Comparison:
According to [51], the packet loss is proportional to the handoff latency. The pDMM schemes
do not consider any buffer management schemes. Therefore, the packets arrival rate �p is the
second parameter that has affect on packet loss. The total packet loss incurred by each of these
schemes is given as [51],
PpDMM�X
loss= �p ·DpDMMX (4.4)
Figures 4.3 and 4.4 compare the total packet loss of each pDMM scheme for Case 1a and
Case 1b with different values of packet arrival rates which range from 1-5 packets/ms.
4.1. PDMM SCHEMES COMPARISONS 59
Figure 4.3: Impact of packet arrival rate (�p) on total packet loss of pDMM schemes (w.r.t.Case - 1a)
Signaling Costs Comparison:
Finally, the signaling cost of each of pDMM schemes is evaluated. According to [51], the
signaling packet processing cost (PC) at nodes and their transmission cost (TC) over the wired
or wireless links constitute the total signaling cost [51]. However, in case of a pDMM scheme,
the MAAR and the CMD nodes have to update their binding cache and binding update lists as a
result of processing signaling packets. Due to decentralized architecture of pDMM, the binding
update list at each anchor node requires to remain updated continuously, just like the binding
cache at CMD. Moreover, compared to the centralized IP mobility solutions, the binding update
list structure needs to be more robust, as discussed in Section 5.1.1. Both binding cache and
the binding update list get updated essentially through the PMIPv6-DMM signaling. Therefore,
the costs associated to the database updates which include both binding cache and the binding
update list are also taken into account for signaling costs analysis. These are accordingly given
as,
60 CHAPTER 4. ANALYTICAL EVALUATION
Figure 4.4: Impact of packet arrival rate (�p) on total packet loss of pDMM schemes (w.r.t.Case - 1b)
CpDMMI= 3 · PCmaar + 2 · PCcmd + 4 · TCcmd,maar + 5 ·DBC (4.5)
CpDMMII= 3 · PCmaar + 2 · PCcmd + 3 · TCcmd,maar + TCpmaar,nmaar + 5 ·DBC (4.6)
CpDMMIII= 3 · PCmaar + 2 · PCcmd + 4 · TCcmd,maar + 5 ·DBC = CpDMMI
(4.7)
Since from Figures 2.4 and 2.6 in Chapter 2, it is clear that the control packets exchanged by
MAAR and CMD entites, and the respective processes on them in both pDMM-I and pDMM-
III are essentially the same with only their order of execution rearranged, the expression for
signaling cost for both these schemes is also the same. In our analysis, we provide a collective
4.1. PDMM SCHEMES COMPARISONS 61
Figure 4.5: Impact of transmission cost (TCmaar,cmd) on signaling cost of pDMM Schemes
Figure 4.6: Impact of processing cost PC on signaling cost of pDMM Schemes
comparison of both with CpDMMII. The costs units used for analysis are shown in Table 4.1.
Figure 4.5 shows the comparison of CpDMMIand CpDMMIII
with CpDMMII, when TCmaar,cmd
62 CHAPTER 4. ANALYTICAL EVALUATION
is varied between 10 and 80 units. The CpDMMIand CpDMMIII
have slightly higher signaling
cost, compared to CpDMMII. However, it is only 3.7% higher compared to the CpDMMII
.
Similarly, varying PC on the same scale, as shown in Figure 4.6 also shows only 3.2% higher
signaling cost compared to CpDMMII.
4.2 Analytical Modelling for High Mobility/Session Activity
From Section 4.1, the pDMM-III is found to have the optimal handover performance compared
to other schemes. We thus choose this scheme to compare its performance with the proposed
AMM scheme. In order to compare the handover performance of both schemes under high
mobility and session activity scenarios, we expand the Equations (4.3), (4.4) and (4.7) which
provide expressions for handover latency, packet loss and signaling cost for pDMM-III. We
refer to this scheme as PMIPv6-DMM henceforth.
We also formulate the corresponding expressions for the proposed AMM scheme. The
PMIPv6-DMM under such scenario is compared with both predictive and reactive operations
of AMM. Keeping in view multiple sessions involved, instead of handover latency, the per-
formance comparison of both schemes is evaluated based on session disruption latency. Other
parameters like packet loss and signaling cost of both schemes is also evaluated.
The performance comparison is done on session disruption latency, packet loss and signaling
cost. The network, traffic and mobility models considered for this comparison are described
below:
Network Model:
The network model for performance comparison is shown in Figure 4.7, in which a generic
representation for both localized PMIPv6 and SDN domains is provided. The MN’s point of
attachment thus represents both MAAR for PMIPv6-DMM or FE for SDN domain. Similarly,
the centralized control entity represents the CMD for PMIPv6-DMM or CTR for SDN. For the
sake of simplicity, we assume that the number of hops between the MN’s point of attachment
and the centralized entity is constant. Moreover, the link characteristics such as link delays and
bandwidth are also equal for all links, among these entities.
The mobility domain connects to n different CNs through a gateway node (GW Node). It
4.2. ANALYTICAL MODELLING FOR HIGH MOBILITY/SESSION ACTIVITY 63
Figure 4.7: Network Model for performance comparison
is to be noted that there could be multiple gateway nodes in the domain to connect it to the
external network. The blue dotted lines between the GW Node and the points of attachment
of MN represent that each point of attachment has reachability to the GW Node - these do not
represent a direct link.
Traffic and Mobility Model:
In order to model high mobility under high session activity environment, we assume the worst
case mobility and session activity scenarios. For high mobility, we assume that each cell visited
by the MN is controlled by a separate AR [54]. The MN is thus considered to attach to n
different pMAARs or p-FEs during its movement in the domain, as shown in Figure 4.7. Each
handover of MN would accordingly require the handover operation above Layer 2. Similarly,
for a worst case session activity scenario, we assume that the MN establishes a new session in
64 CHAPTER 4. ANALYTICAL EVALUATION
every subnet with a different CN, while it moves inside the domain.
Moreover, we also assume that each session remains active from the time it is initiated until
the MN remains in the domain. Also, the packet arrival rate of each session is equivalent and
is represented by �p. However, the control messages exchanged in both PMIPv6-DMM and the
AMM scheme have different packet sizes. A normal PMIPv6 signaling message which carries
all mandatory options is on average 144 bytes in size [18]. An OpenFlow control packet in
AMM, has 56 bytes on average1[1].
4.2.1 Modelling PMIPv6-DMM for High Mobility/Session activity
Session Disruption Delay:
In order to accommodate all active sessions of MN to handover performance analysis, as it
undergoes multiple handovers, we define session disruption delay parameter instead of the
handover latency. Considering we have n ongoing sessions of MN, and an m� th session takes
maximum time among n to resume, we define the session disruption latency as the interval
between the last packet of the m� th session received at the previous network to the first packet
of this session received at the new network. This can be mathematically given by expanding
Equation (4.3) as follows:
(4.8)DPMIPv6�DMM = tL2 + 2 · PDmaar + PDcmd + 2 · Tmaar,cmd +
(m+ 1) · (⌦+ TD + PDmaar,cmd) +m · Tmaar,maar + Tmn,smaar
As previously noted, the size of the control packet for mobility signaling is different in a
PMIPv6 and SDN domains. The packet size thus has an impact at both PDx and the Tx,y.
The PDx as a function of packet size sp is given as
PDx = sp · P (4.9)
1According to OpenFlow specification [1], a flow-mod message and its acknowledgement are both 56 bytes onaverage. The Packet-In message is of 32 bytes, however, the data it carries may increase its size. We have thusassumed its size to be 56 bytes as well.
4.2. ANALYTICAL MODELLING FOR HIGH MOBILITY/SESSION ACTIVITY 65
Here P represents the delay a network node takes to process per unit byte. Similarly, for unit
transmission delay per byte U , the Tx,y is also given as,
Tx,y = sp · U (4.10)
Thus Equation (4.8) can be written as,
(4.11)DPMIPv6�DMM = tL2 + 2 · sp · P + sp · P+ (m+ 1) · (⌦+ TD + sd · P ) +m · (sd · P + so · P ) + sd · U
Packet Loss:
For n active sessions with equal packet arrival rate of �p, Equation (4.4) can be expanded as,
PpDMM�X
loss=
i=nX
i=1
�p ·Di (4.12)
Here, Di is the delay associated to resume an individual session anchored by an i � th
anchor. It is given as,
(4.13)Di = tL2 + 2 · sp · P + sp · P + (i+ 1) · (⌦+ TD + sd · P )
+ i · (sd · P + so · P ) + sd · U
Signaling Costs:
The signaling cost expression is usually defined in terms of packet delivery cost and the packet
processing cost [51]. The packet delivery cost represents the cost associated to deliver a control
packet from one node to another. The packet processing cost relates to processing the contents
of the packet, and generating its response if required. However, if the packet processing results
in updating the database, the costs to update the database has to be taken into account as well.
Since, the PMIPv6-DMM scheme involves updating the binding cache at CMD, as well as
binding update list at MAAR entities, for a fair comparison with AMM’s Mobility Database
update costs (discussed in the next section), the Equation (4.7) is thus expanded to include the
66 CHAPTER 4. ANALYTICAL EVALUATION
database update cost (DBC) as well. Thus, the signaling cost of PMIPv6-DMM for n ongoing
sessions of MN is given as,
CPMIPv6�DMM = (n+2) ·DBCmaar+(n+1)(2 ·TCmaar,cmd+PCcmd+PCmaar+DBCcmd)(4.14)
The packet size sp of a control packet also becomes an important factor for signaling costs
comparison between PMIPv6-DMM and AMM. The signaling costs expression for PMIPv6-
DMM given by Equation (4.14) is thus also expanded to express both the packet delivery and
packet processing costs as function of packet size. However, the DBC does not depend upon
the sp since a database is updated after the packet is processed, and only a small chunk of
information obtained as a result of packet processing is updated to the database.
Considering the processing costs at both CMD and MAAR entity are equivalent, the Equa-
tion (4.14) is thus re-written as,
(4.15)CPMIPv6�DMM = (n+ 2) ·DBCmaar + (n+ 1)(2 · sp · � + 2 · sp · u+DBCcmd)
4.2.2 Modelling AMM for High Mobility/Session activity
In this section, we formulate expressions for session disruption delay, packet loss and signaling
cost both for predictive and reactive operations of the AMM scheme. However, unlike the
PMIPv6-DMM, since it can operate in multiple modes, the presence of the handover support
services like buffering, bicasting and path optimization correspondingly determine the respec-
tive expressions.
For simplicity, these expressions are derived without distinguishing whether the type of flow
is conversational, non-conversational multimedia or non-real time. Thus, these expressions are
formulated keeping in view the k flows out of n have the handover support services enabled.
Session Disruption Delay for AMM-Predictive:
The session disruption delay for AMM scheme’s predictive operation is impacted if the bi-
casting service is enabled or disabled. However, if the bicasting is enabled only for k flows,
the session disruption delay, by definition, will still be dependent upon the resumption of all
n flows. Thus in order to study the impact of bicasting on the session disruption delay, we
4.2. ANALYTICAL MODELLING FOR HIGH MOBILITY/SESSION ACTIVITY 67
formulate expressions considering that bicasting is either enabled for n flows, or is disabled for
all flows. The latter expression thus, also relates to the case when bicasting is enabled for k
flows.
Assuming that MN starts Layer 2 handover right after sending the Handover Indication to
p-FE as shown in Figure 3.7, the session disruption delay with bicasting service enabled for n
flows can be expressed as follows:
DBicast(n)AMM�Predictive
=maxntL2, (n+1) ·(PDfe+⌦fe+Tfe,ctr)+PDctr+Tfe,fe+Tmn,fe
o
(4.16)
From Equation (4.9) and (4.10), Equation (4.16) can be given as,
(4.17)DBicast(n)AMM�Predictive
= maxntL2, (n+ 1) · (sof · P + ⌦fe + sof · U)
+ (sof · P ) + +sd · U + Tmn,fe
o
If bicasting is not enabled, or is enabled only for k sessions, where k < n, the session
disruption delay for AMM-Predictive is given as,
(4.18)DBicast(0/k)AMM�Predictive
= 2 · Tmn,fe + 4 · Tfe,ctr + (2n+ 2)⌦fe + 6 · PD + Tfe,fe
In terms of sof , Equation (4.18) becomes,
(4.19)DBicast(0/k)AMM�Predictive
= 2 · Tmn,fe + 4 · sof · U + (2n+ 2)⌦fe + 6 · sof · P + sd · U
Session Disruption Delay for AMM-Reactive:
Unlike the AMM-Predictive, bicasting is not applicable to the AMM-Reactive. Moreover, the
reactive operation starts after the L2 handover. The expression for session disruption delay is
thus given as,
DAMM�Reactive = tL2+2 ·Tmn,fe +(n+1) ·⌦fe +2n ·PD+(2n+1)(Tfe,ctr)+Tfe,fe
(4.20)
In terms of sof and sd, Equation (4.20) is given as,
(4.21)DAMM�Reactive = tL2 + 2 · Tmn,fe + (n+ 1) · ⌦fe + 2n(sof · P )+ (2n+ 1)(sof · U) + sd · U
68 CHAPTER 4. ANALYTICAL EVALUATION
Packet Loss for AMM-Predictive:
The packet loss in the AMM can be controlled through buffering. However, an FE relies on
signaling from CTR to actually enable buffering. Therefore, packet loss is expected for a short
interval even if buffering is enabled for some flows i.e. until the CTR updates flow entries after
learning about MN’s prospective handover.
In AMM, considering that buffering is enabled for k ongoing flows, the packet loss can be
expressed as follows:
PAMM�Predictive
loss=
kX
i=0
�p ·Di00
AMM�Predictive+
n�kX
i=0
�p ·Di
AMM�Predictive(4.22)
Here, D00AMM�Predictive
represents the interval before buffering is enabled, and is given as,
Di00
AMM�Predictive= (i+ 1)(sof · P + ⌦fe + sof · U) + sof · P
Thus, if buffering is enabled for all ongoing sessions, then k = n, and Equation (4.22) is
reduced as,
PAMM�Predictive
loss=
nX
i=0
�p ·Di00
AMM�Predictive(4.23)
Similarly, if buffering is not enabled for any session, then for k = 0, Equation (4.22)
becomes,
PAMM�Predictive
loss=
nX
i=0
�p ·Di
AMM�Predictive(4.24)
4.2. ANALYTICAL MODELLING FOR HIGH MOBILITY/SESSION ACTIVITY 69
Packet Loss for AMM-Reactive:
Similar to the above approach for packet loss modelling in AMM-Predictive, the packet loss in
AMM-Reactive can be formulated as,
PAMM�Reactive
loss=
kX
i=0
�p ·Di00
AMM�Reactive+
n�kX
i=0
�p ·Di
AMM�Reactive(4.25)
Here, Di00AMM�Reactive
represents the interval before the buffering is enabled, and is given as,
Di00
AMM�Reactive= tL2 + Tmn,fe + (i+ 1)(sof · P + ⌦fe + sof · U) + sof · P
If buffering is enabled for all ongoing sessions, then k = n, and Equation (4.25) is reduced
as,
PAMM�Reactive
loss=
nX
i=0
�p ·Di00
AMM�Reactive(4.26)
Similarly, if buffering is not enabled for any session, then for k = 0, Equation (4.25)
becomes,
PAMM�Reactive
loss=
nX
i=0
�p ·Di
AMM�Reactive(4.27)
Signaling Costs for AMM-Predictive:
The signaling sequence of AMM-Predictive is shown in Figure 3.7. The majority of the mes-
sages sent from CTR to an FE are flow-mod messages. In AMM, in order to adaptively provide
the handover support services on a per-flow basis, it is necessary that different flow entries for
different flows are installed at FE. Therefore, if a particular service is enabled for k ongoing
flows, the CTR is required to send k flow-mod messages to the respective FEs. However, the
70 CHAPTER 4. ANALYTICAL EVALUATION
packet forwarding service can be enabled efficiently if it is effectuated through a single flow-
mod entry which would match and forward the incoming traffic on destination address basis.
Intuitively, enabling an increased number of handover support services for an increased
number of flows, higher signaling costs would be incurred. Thus, to be more specific, we
focus on three major cases of enabling these handover support services. These include, (i) All
services (path optimization, buffering and bicasting) are enabled for k flows, (ii). Only path
optimization is enabled for k flows, and (iii). Only buffering and bicasting are enabled for k
flows. Accordingly, the signaling costs represented as CAll(k)AMM�Predictive
, CPO�Only(k)AMM�Predictive
and
CBuff�Bicast�Only(k)AMM�Predictive
, are given as,
(4.28)CAll(k)AMM�Predictive
= 3 ·DBC + 8k · TC + 8k · PC + 4 · PC + 2 · TC+ n · TC + n · PC + 2(n� k) · TC + 2(n� k) · PC
Simplifying Equation (4.28)
(4.29)CAll(k)AMM�Predictive
= 3 ·DBC + (6k + 2 + 3n) · TC + (6k + 4 + 3n) · PC
In terms of an OpenFlow packet size sof , Equation (4.29) is given as,
(4.30)CAll(k)AMM�Predictive
= 3 ·DBC + (6k + 2 + 3n) · sof · � + (6k + 4 + 3n) · sof · u
Similarly, CPO�Only(k)AMM�Predictive
is given as,
CPO�Only(k)AMM�Predictive
= 3 ·DBC +3k · TC +3k ·PC +6 ·PC +4 · TC +n · TC +n ·PC
(4.31)
Simplifying Equation (4.31)
(4.32)CPO�Only(k)AMM�Predictive
= 3 ·DBC + (n+ 3k + 6) · PC + (n+ 3k + 4) · TC
In terms of sof , Equation (4.32) is given as,
(4.33)CPO�Only(k)AMM�Predictive
= 3 ·DBC + (n+ 3k + 6) · sof · u+ (n+ 3k + 4)t · sof · �
Similarly, CBuff�Bicast�Only(k)AMM�Predictive
is given as,
(4.34)CBuff�Bicast�Only(k)AMM�Predictive
= 3 ·DBC + 7k · TC + 7k · PC
+ 6 · PC + 4 · TC + n · TC + n · PC
4.2. ANALYTICAL MODELLING FOR HIGH MOBILITY/SESSION ACTIVITY 71
Simplifying Equation (4.34)
(4.35)CBuff�Bicast�Only(k)AMM�Predictive
= 3 ·DBC + (n+ 7k + 6) · PC + (n+ 7k + 4) · TC
In terms of sof , Equation (4.35) is given as,
(4.36)CBuff�Bicast�Only(k)AMM�Predictive
= 3 ·DBC + (n+ 7k + 6) · sof · u+ (n+ 7k + 4) · sof · �
Signaling Costs for AMM-Reactive:
The Signaling Costs for AMM-Reactive are also evaluated based on the three cases men-
tioned in the previous subsection. For reactive case, these are represented as CAll(k)AMM�Reactive
,
CPO�Only(k)AMM�Reactive
and CBuff�Bicast�Only(k)AMM�Reactive
, and are given as,
(4.37)CAll(k)AMM�Reactive
= DBC + 8k · TC + 8k · PC + 4 · PC
+ 3 · TC + 2(n� k) · TC + 2(n� k) · PC
Simplifying Equation (4.37)
(4.38)CAll(k)AMM�Reactive
= DBC + (2n+ 6k + 3) · TC + (2n+ 6k + 3) · PC
In terms of sof , Equation (4.38) is given as,
(4.39)CAll(k)AMM�Reactive
= DBC + (2n+ 6k + 3) · sof · � + (2n+ 6k + 3) · sof · u
For CPO�Only(k)AMM�Reactive
,
(4.40)CPO�Only(k)AMM�Reactive
= DBC + 3k · TC + 3k · PC + 4 · PC + 3 · TC+ 2(n� k) · TC + 2(n� k) · PC + 2n · TC + 2n · PC
Simplifying Equation (4.40)
(4.41)CPO�Only(k)AMM�Reactive
= DBC + (4n+ k + 3) · TC + (4n+ k + 4) · PC
In terms of sof , Equation (4.41) is given as,
(4.42)CPO�Only(k)AMM�Reactive
= DBC + (4n+ k + 3) · sof · � + (4n+ k + 4) · sof · u
72 CHAPTER 4. ANALYTICAL EVALUATION
For CBuff�Bicast�Only(k)AMM�Reactive
,
(4.43)CBuff�Bicast�Only(k)AMM�Reactive
= DBC + 7k · TC + 7k · PC + 4 · PC + 3 · TC+ 2n · TC + 2n · PC
Simplifying Equation (4.43)
(4.44)CBuff�Bicast�Only(k)AMM�Reactive
= DBC + (2n+ 7k + 3) · TC + (2n+ 7k + 4) · PC
In terms of sof , Equation (4.44) is given as,
(4.45)CBuff�Bicast�Only(k)AMM�Reactive
= DBC + (2n+ 7k + 3) · sof · � + (2n+ 7k + 4) · sof · u
4.3 Comparative Numerical Analysis of PMIPv6-DMM and AMM
In this section, we provide the results and discussions on the performance evaluation of AMM
scheme in comparison to the PMIPv6-DMM. The performance of both predictive and reactive
modes of AMM is compared with PMIPv6-DMM. The analysis is based on the formulated
expressions for session disruption latency, packet loss and signaling costs. Different parameters
used for comparison, along with their description and default values are shown in Table 4.2.
In order to focus on the DMM limitations in high mobility and session activity environments,
we consider a worst case scenario, as described in Section 4.2, where an MN undergoes n
handovers with n active sessions, each anchored by a different subnet the MN has visited in
the domain. Thus, n being a common parameter which represents both mobility and session
activity is varied to study the handover performance in different scenarios.
In addition to n, we also study the impact of other relevant factors which can significantly
influence these handover performance metrics, such as link delay and processing delay for
session disruption delay, and packet arrival rate (�p) for packet loss. Similarly, for signaling
costs analysis, the impact of processing costs and the transmission costs of control signals is
also studied.
4.3. COMPARATIVE NUMERICAL ANALYSIS OF PMIPV6-DMM AND AMM 73
Table 4.2: Parameter notations with description and default values for PMIPv6-DMM andAMM Comparison
Parameter Notation Description Default ValuetL2 Layer 2 handover delay 50 ms
⌦maar/fe Queuing delay 4 msP Average per-byte processing delay 0.12 msU Average per-byte transmission delay 0.12 mssp Average size of a PMIPv6 message 144 bytessof Average size of an OpenFlow message 56 bytessd Average size of a data packet 100 bytesso Average size of tunnel header 40 bytesTD Tunnelling delay 6 msDBC Database update cost 15 units�p Average packet arrival rate per session 4 packets/msn Total number of active session of MN 5k Total sessions with active handover support services 2� Unit processing cost per byte 2 unitsu Unit transmission cost per byte 1.6 units
4.3.1 Session Disruption Delay Comparison
The session disruption delay for PMIPv6-DMM scheme is evaluated through Equation 4.13.
For AMM, as previously noted, the handover support service which can influence the session
disruption delay for predictive handovers is bicasting. However, since the session disruption
delay depends on the resumption of all ongoing flows, regardless if they have the bicasting
enabled or not, Equation 4.18 is used for session disruption delay evaluation of the AMM-
Predictive, while Equation 4.20 is used for AMM-Reactive.
The session disruption delay, as shown in Figure 4.8, increases with the increase in the num-
ber of flows. The AMM-Predictive has least handover delay, since due to Handover Initiation
by MN from the previous subnet, the packet forwarding starts as soon as the CTR learns the
n-FE of MN. Packet forwarding from p-FE towards n-FE may start even before the MN attaches
to it. The AMM-Reactive on the other hand, induces nearly twice the session disruption delay
as that of the AMM-Predictive. This is because, in this case, no handover indication is provided
proactively by the MN. As a result, the packet forwarding starts only after the CTR installs flow
entries both at p-FE and n-FE which result in higher latencies.
74 CHAPTER 4. ANALYTICAL EVALUATION
Figure 4.8: The impact of n on session disruption delay
Figure 4.9: The impact of average per-byte processing delay (P ) on session disruption delay
In PMIPv6-DMM, a session can resume only after the respective anchor is updated about the
new location of the MN by the CMD. It is also to be noted that unlike AMM, packet forwarding
from pMAAR to nMAAR can only take place through tunneling. As a result, if an anchor
lies at a farther distance, the flow anchored by it will have to traverse through the subnets the
MN visited after initiating that flow. Moreover, since each intermediate hop would require
tunnelling and de-tunnelling, it would induce extra latencies. The overall session disruption
4.3. COMPARATIVE NUMERICAL ANALYSIS OF PMIPV6-DMM AND AMM 75
Figure 4.10: The impact of average per-byte transmission delay (U) on session disruption delay
interval of PMIPv6-DMM is nearly 47% higher compared to the AMM-Reactive handover.
The processing delays at network nodes as well as the transmission delays among two nodes
for handover signaling messages, are also important factors which impact the session disruption
intervals. Both these parameters depend on the size of the signaling packet being communicated
or processed. Therefore, in order to comparatively evaluate their impact on PMIPv6-DMM and
AMM schemes, we have varied the values of P between 0.06 ms to 0.36 ms as shown in Figure
4.9. Similarly, the values of U are varied between 0.12 ms to 0.72 ms to compare their impact
on PMIPv6-DMM and AMM. The results shown in Figures 4.9 and 4.10 exhibit same trends,
as shown in Figure 4.8.
4.3.2 Packet Loss Comparison
The Packet loss comparison between the PMIPv6-DMM and the AMM protocols also follows
similar trend as the session disruption delays. In addition to the parameters which impact
the session disruption delays, the the packets arrival rate (�p) of the ongoing flows is directly
proportional to the packet loss during the interval the MN undergoes handover.
The PMIPv6-DMM does not consider any packet loss prevention mechanism such as buffer-
ing in its operation. As a result it causes high packet loss especially if the handover latency is
76 CHAPTER 4. ANALYTICAL EVALUATION
Figure 4.11: The impact of average per-byte processing delay (P ) on Packet Loss
Figure 4.12: The impact of average per-byte transmission delay (U) on packet loss
high and/or the (�p) is larger value.
The AMM protocol, on the other handover supports buffering. However, it adaptively
enables buffering for the chosen flows only. Therefore, in addition to factor which impact
packet loss in PMIPv6-DMM, the packet loss in AMM are depend on the number of flows with
active buffering support (k). Moreover, it is also important to note that, in AMM, the OpenFlow
4.3. COMPARATIVE NUMERICAL ANALYSIS OF PMIPV6-DMM AND AMM 77
FEs can only enable buffering if the CTR adjusts the respective flow entries to enforce buffering.
They cannot enforce buffering at their own, unlike for instance FMIPv6 protocol. As a result,
some packet loss is inevitable since, there is short interval in both AMM-Predictive and AMM-
Reactive during which the CTR on learning about MN’s movement has to explicitly install the
flow entries by sending the flow-mod messages to FEs.
Figure 4.13: The impact of packet arrival rate (�p) on packet loss
Figure 4.14: The impact of selected sessions with active handover support services (k) onpacket loss
78 CHAPTER 4. ANALYTICAL EVALUATION
The results shown in Figures 4.11 and 4.12 show that the increasing transmission and
processing delays significantly impact the packet loss during handovers. The AMM-Predictive
causes least packet loss due to efficient buffering and packet forwarding as the CTR receives
proactive handover indications from MN. Similarly, with the increase in (�p) values, the packet
loss is higher as shown in Figure 4.13.
Since the buffering support in AMM protocol is adaptively enabled for the chosen k flows,
it is also essential to evaluate its impact on packet loss. Figure 4.14 show the packet loss
comparison for this case. With the parameters such as (�p), P and U kept constant, the packet
loss of PMIPv6-DMM remains the same regardless of the value of k. For AMM-Predictive and
AMM-Reactive on the other hand, increase in the value of k result in reduced packet loss as
shown in Figure 4.14.
4.3.3 Signaling Costs Comparison
The signaling costs in AMM scheme substantially depend upon the number of flows for which
any handover support services are enabled. This is because, in order to enable them at the under-
lying data plane FEs, the CTR has to send control messages per flow to the FEs. Accordingly,
for signaling costs analysis, we study the impact of variable values of k, which represents the
number of flows for which a particular handover support service is enabled.
For a comprehensive signaling costs evaluation, we study the impact of each of these pa-
rameters in two major cases, which include (i) when none of the handover support services are
enabled for any flows, (ii) when all handover support services for selected k flows are enabled.
In each of these cases, in addition to k, we study the impact of � as well as u on signaling costs.
Case 1: No Handover Support Service enabled for any flow
This case provides a fundamental instance for comparative signaling costs analysis of PMIPv6-
DMM and AMM with no handover support services available. Figure 4.15 shows the signaling
costs comparison between PMIPv6-DMM with AMM schemes for different values of n. The
PMIPv6-DMM clearly incurs high signaling costs which is nearly double than the cost incurred
by the AMM protocols.
The signaling costs for PMIPv6-DMM and the AMM protocol are defined as functions of
4.3. COMPARATIVE NUMERICAL ANALYSIS OF PMIPV6-DMM AND AMM 79
the PMIPv6 and OpenFlow packet sizes. The size of the packet thus affects its transmission as
well as processing costs. The PMIPv6 has larger packet size compared to OpenFlow flow-mod
or Packet-In signals, as its control messages such as PBU and PBA carry several mandatory
options, which contribute to the significant signaling costs in PMIPv6-DMM.
The database update cost in PMIPv6-DMM is another significant factor for high signaling
costs. In PMIPv6-DMM, each MAAR node maintains a binding update list entry, in which it
maintains the information of each MN to which it anchors an active session. If the number of
active sessions of MN is higher, the CMD will have to send a PBU* message to each anchor
to update MN’s new location as it indicates its handover. Each anchor will thus have to update
its binding update list at each handover event which results in additional database update costs
(DBC) at MAAR. On the other hand, no such database updates are required at FEs, since all
control information is maintained at the CTR.
Interestingly, on the other hand, unlike the session disruption delay and packet loss, the
signaling costs of AMM-Reactive are lower as compared to the AMM-Predictive. This is
because fewer control packets are required since the MN does not have to share its handover
initiation information with its current network. Moreover, it requires fewer database updates,
unlike AMM-Predictive which has to carry out some additional updates with database owing to
the proactive handover indications it receives from MN.
The overall signaling cost comparison of PMIPv6-DMM and AMM shows that PMIPv6-
DMM, due to aforementioned factors induces twice as much signaling cost compared to AMM
for different values of n. Further evaluation of signaling cost for different values of � and u,
show similar performance as shown in Figures 4.16 and 4.17 respectively.
Case 2: All Handover Support Services enabled for k flows
The handover support services in the proposed AMM scheme are enabled by the CTR through
flow-mod messages. In order to provide per-flow mobility services, the AMM scheme has to
rely on handling each ongoing MN flow through a dedicated flow entry. Thus, for provision of
any handover support services, these flow entries have to be modified through separate flow-mod
messages. As a result, if all the available handover support services are to be enabled, higher
number of signaling messages are required to be sent to the FEs.
80 CHAPTER 4. ANALYTICAL EVALUATION
Figure 4.15: The impact of total active sessions (n) on comparative signaling costs with nohandover support services are enabled
Figure 4.16: The impact of processing cost per byte (�) on comparative signaling costs withno handover support services are enabled
Under such scenario, the signaling costs in AMM further rise significantly, if an increased
number of flows are offered all handover support services. This is shown in Figure 4.18, which
shows that if the value of k rises, the AMM incurs even higher signaling costs compared to
the PMIPv6-DMM protocol. However, if k is kept at a lower value, e.g. k = 2, the signaling
4.3. COMPARATIVE NUMERICAL ANALYSIS OF PMIPV6-DMM AND AMM 81
Figure 4.17: The impact of transmission cost per byte (U) on comparative signaling costs withno handover support services are enabled
costs of AMM protocols, although approach the signaling costs of PMIPv6-DMM, can be kept
comparatively lower. This is shown in Figure 4.19 and 4.20, in which � and u are changed for
signaling cost comparisons.
Figure 4.18: The impact of selected sessions (k) on comparative signaling costs with allhandover support services enabled
82 CHAPTER 4. ANALYTICAL EVALUATION
Figure 4.19: The impact of processing cost per byte (�) on comparative signaling costs withall Handover Support Services enabled
Figure 4.20: The impact of transmission cost per byte (u) on comparative signaling costs withall handover support services enabled
4.4 Chapter Summary
This chapter presents the comparative performance evaluation of the proposed AMM protocol
with PMIPv6-DMM. First, the three PMIPv6-DMM proposals currently being studied at the
4.4. CHAPTER SUMMARY 83
IETF, are evaluated through fundamental analytical expressions, which focus on a single han-
dover event with a single ongoing session of MN. Among these, the proposal with most optimal
handover performance in terms on handover latency, packet loss and signaling cost is chosen
for comparative analysis with the AMM protocol. Next, the basic analytical expressions are
extended for modelling high mobility and session activity scenarios.
The comparative analysis based on these extended expressions, shows that the proposed
AMM protocol can substantially reduce the session disruption latency. Consequently, the proto-
col can promise minimized packet loss as well. It also promises normal signaling cost, however,
under intense scenarios when the handover support services are provided to an increased number
of the ongoing sessions of the MN, the AMM protocol appears to incur higher signaling costs.
In the AMM protocol, the CTR decides to enable the handover support services based
on certain thresholds e.g µth which limits the provisioning of handover support services to a
limited number of ongoing flows. Therefore, the provisioning of all handover support services
to several ongoing sessions of the MN is unlikely in practice.
The next chapter continues the comparative performance evaluation of the AMM protocol
with PMIPv6-DMM. The performance study of both protocols is performed based on handover
latency through ns-3 simulations. The chapter also presents an ns-3 module implementing the
PMIPv6-based DMM, and the implementation of the proposed AMM solution in ns-3.
84 CHAPTER 4. ANALYTICAL EVALUATION
Chapter 5
Performance Analysis through ns-3 Simulations
In this chapter, further performance evaluation of the proposed AMM scheme is presented based
on handover latency through ns-3 simulations, in comparison to the IETF’s PMIPv6-DMM
proposal. In Section 5.1, the implementation of PMIPv6-DMM in ns-3 simulator is described.
The implementation of the proposed AMM scheme is also discussed in this section. In Section
5.2, the simulation setup for the experimentation on both schemes is described. The simulation
results of PMIPv6-DMM scheme, as well as the proposed AMM scheme, are then presented.
Based on these results, a comparative performance analysis of both schemes based on average
handover latency is presented in Section 5.3. Section 5.4 summarizes this chapter.
5.1 Implementation of PMIPv6-DMM and AMM Schemes in ns-3
Ns-3 is a discrete-event network simulator, and is being widely used for implementing new
protocols for evaluation purposes. It offers a variety of features which include support for
both IP and non-IP based systems[2]. New models of ns-3 are constantly being developed
and contributed by the research community. Among these, the PMIPv6 [55] and OpenFlow
ofswitch13 modules [3] have also been contributed and are made available opensource.
The ns-3 simulator is designed on a hierarchy of modules which are based on C++ object-
oriented programming. These modules generally have dependencies on some of the core ns-3
classes. It also allows users to modify the existing classes and modules, or to add their own
modules in the simulator for testing their respective algorithms, protocols etc. The organization
85
86 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
of source code for ns-3 is shown in Figure 5.1, which shows that the modules generally have
dependencies on the modules which lie beneath them.
Figure 5.1: Software organization of ns-3 [2]
5.1.1 Implementation of PMIPv6-DMM in ns-3
An ns-3 module for PMIPv6 protocol has been contributed[55] which implements the PMIPv6
standard [18]. We have utilized similar principles to implement the IETF’s PMIPv6-based
distributed mobility management proposal [7]. In this section, we first describe certain changes
required in PMIPv6 for implementing the the DMM functionality. We then describe the han-
dover process in DMM which is implemented in the PmipDmm module.
Key changes required for DMM implementation in PMIPv6: Firstly, the Binding Up-
date List at MAG, now has to be enriched with following information so that it can handle
the PBU* message as well as sends back its acknowledgement i.e PBA. Earlier, the MAG was
required to only build the PBU message, while handling the PBU and then responding with
PBA message had to be done by the LMA. For DMM, the MAAR should also be able to
support these functions. Following additional pieces are information have to be contained in
the Binding Update List in order to support DMM at a MAAR entity.
• sMAAR Address Field: The field is required to hold the current serving MAAR’s IPv6
address received in the sMAAR option in the PBU* message.
• Handoff Indicator field: This field is required to hold the information from the Handoff
Indicator Option from the PBU* message. The value for this field has to copied from the
Handoff Indicator Option in the PBU message. If the PBU message does not contain the
Handoff Indicator option, the value of this field should be set to zero.
5.1. IMPLEMENTATION OF PMIPV6-DMM AND AMM SCHEMES IN NS-3 87
• Access Technology type field: This field is required to hold the information from the Access
Technology Type Option from the PBU* message. The value for this field has to be copied
from the Access Technology Type Option in the PBU message. If the PBU message does
not contain such an option, the value of this field has to be set to zero.
• Timestamp field: This field is required to hold the timestamp value from the Timestamp
option field in the PBU* message. Since it is an optional field, it is not required to be
present in the respective PBA* message if it were not present in the PBU* message.
• Mobile Node Link-layer Identifier Field: This field is required to hold the Mobile Node
Link-layer Identifier value contained in the PBU* message. Since it is an optional field, it
is required to be present in the Binding update list only if the the received PBU* message
had this field, since the respective PBA* message then also needs to contain it.
• The Link-Local Address Field: This field is required to hold the Link-Local Address value
from the Link-Local Address option in the PBU* message. If the PBU* message does
not contain the Link-Local Address option, the respective PBA* message must also not
contain this option. However, if this value of this option in PBU* message is set to zero,
the MAAR has to generate a Link-Local Address that can be used on a point-to-point link
with s-MAAR.
• New Flag ‘C’: A new flag ‘C’is introduced, which if set to 0, indicates that the MN is
currently attached to the MAAR’s link, and if set to 1, it indicates that the MAAR is
acting as an anchor for MN.
• CMD’s Address: The LMA’s address is replaced by the CMDs IPv6 address.
• pMAAR’s Information Field: The pMAARs’ information field is included which essen-
tially includes the list of global IPv6 addresses of all previous MAARs of MN along
with the HNPs anchored by them. This field is added at sMAAR as soon as it receives
the PBA* message from the CMD.
A new Binding Update List for an MN is created by MAAR as soon as it attaches to it.
The MAAR then sends the PBU message to the CMD for binding registration. As the MN
moves out of sMAAR’s domain to another MAAR, the current MAAR has to assume the
role of MN’s anchor if it started new sessions in its domain. In that case, the same binding
88 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Figure 5.2: Binding Update List implementation for PmipDmm in ns-3
update list undergoes RESTRUCTURING as it receives the PBU* message from CMD. During
RESTRUCTURING phase, it updates and resets certain elements of the binding update list.
Moreover, it removes and adds some elements as well, according to the information it receives
from the PBU* message. Figure 5.2 indicates the elements that undergo these changes as a
result of PBU* reception.
Another significant change for DMM support in PMIPv6 involves updating the PBU and
PBA header fields, both of which include a new flag ‘D’, which indicates support for DMM.
New pMAAR and sMAAR options defined in [7] have also been implemented in the PmipDmm
module.
5.1. IMPLEMENTATION OF PMIPV6-DMM AND AMM SCHEMES IN NS-3 89
Figure 5.3: A Flowchart demonstrating the handover signaling exchange for PmipDmm in ns-3
Just like the binding update list, certain changes in binding cache maintained at CMD are
also needed. In addition to an existing flag, named P in our implementation, which indicates
that this binding cache is created to hold proxy registration, a new flag ‘M’is also introduced,
which, if set to true indicates that the binding cache holds proxy registration for a MN to which
the DMM service is being provided. The introduction of a new flag ‘M’is proposed keeping
in view the requirement to ensure that the DMM solution support does not negate the support
for centralized PMIPv6 protocol. The ‘M’flag in BCE is set if the D flag in the received PBU
message from sMAAR is set.
The core structure of the PmipDmm Module The PmipDmm module essentially im-
plements the DMM functionality through several ns-3 classes, functions and callbacks. The
callback functionality in ns-3 provides a method of generating triggers among different ns-
3 modules without any inter-modular dependency [2]. The module considers WiFi as the
underlying L2 technology. The core structure of the module showing the key classes of the
module, which are involved during the handover process, is illustrated in Figure 5.3.
90 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
During handover, the MN’s attachment is first detected by the MAC layer of the WiFi
AP, which generates a callback to a handler function at the PmipDmmMaar class, which is
primarily responsible to handle any new MN which moves into its domain. This handler
function creates a binding update list, and also formulates a PBU message and sends it to the
CMD’s address through the ns-3 Send() message. The PBU message traverses down through the
Ipv6L3Protocol, and is received at the NetDevice of the CMD. The CMD deserializes the PBU
message to obtain the information it carries. The deserialization of the PBU message involves
classes which include the Ipv6MobilityL4Protocol, Ipv6MobilityDemux and Ipv6MobilityBindi-
ngUpdate as shown in Figure 5.3.
The CMD according to the MN’s information received in the PBU message, updates the
BCE for MN, creates a PBA* message to be sent back to the sMAAR, and several PBU*
messages, each of which is sent to a pMAAR which currently anchors a flow for MN. These
messages are sent through the same ns-3 Send() function, and are received at the NetDevice
of the respective nodes. Both these messages are deserialized through the same classes as
described above. The respective MAAR entities which receive these messages perform their
respective functions, described in Section 2.3.
5.1.2 Implementation of the proposed AMM Scheme in ns-3
In order to implement the proposed AMM scheme, we have used an ns-3 module which im-
plements the OpenFlow v1.3.5 protocol [1], and is named as ofswitch13 [3]. This module
relies on an external ofsoftswitch13 library, and provides implementation of the Open-
Flow Controller application and the OpenFlow switch network device (or the FE), through
OFSwitch13::Controller and OFSwitch13::Device classes respectively. Its module structure is
shown in Figure 5.4.
For AMM implementation, we have extended the OFSwitch13::Controller class to imple-
ment the Algorithms 1 to 5 within this class. The proposed messages handlers are also imple-
mented in the OFSwitch13::Controller and OFSwitch13::Device. However, these messages are
implemented at the external ofsoftswitch13 library.
The AMM implementation in ofswitch13 module also relies on several new callbacks,
which are implemented in other ns-3 modules. Certain functions implemented in the
OFSwitch13::Controller class are triggered through these callbacks from other modules in the
5.2. HANDOVER DELAY ANALYSIS OF PMIPV6-DMM AND THE AMM SCHEME 91
Figure 5.4: The ofswitch13 module structure [3]
event of, for example, a predictive handover initiation, reactive handover detection, or as an
application starts or stops.
For triggering the predictive handover, we have implemented a callback function inside the
MAC of MN, which generates the trigger if it receives a Probe Response message from an AP
from another domain. The reactive handover is triggered if the MN successfully attaches to
another AP through a callback function implemented with the MAC of the AP. This is the same
implementation as in [55] as well as in PmipDmmmodule. Similarly, the callbacks implemented
in ns-3 applications such as OnOffApplication indicate the Controller about the instances when
an application starts or stops. The OnOffApplication in AMM implementation represents a
real-time session.
The key functions in the OFSwitch13::Controller, which are triggered by these callbacks in-
clude PerformHandoverInformationGathering(), PerformMuThEvaluation(), HandleAMMPre-
dictiveHandover(), and HandleAMMReactiveHandover().
5.2 Handover Delay Analysis of PMIPv6-DMM and the AMM Scheme
In this section, we first describe the simulation setup to perform experiments. The experiments
for both PMIPv6-DMM and AMM schemes are performed separately since these are imple-
mented in different domains which have different traffic forwarding mechanisms. The routers
in the IP domain make their forwarding decisions at their own, while the FEs in the SDN
domain rely on the SDN controller for this purpose. Therefore, we first present the general
92 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
handover latency observations in the experiment results of both these schemes. We then present
a detailed comparison of both schemes in the subsequent subsection which is based on the
average handover latency values under different scenarios.
5.2.1 The Simulation Set-up
The simulation set-up to study the mobility performance consists of two subnets of a localized
and decentralized mobility domain. Figure 5.5 depicts this scenario for an IP domain, while
Figure 5.6 shows this scenario for an SDN domain.
In the IP domain, the access points AP-1 and AP-2 are managed by a MAAR entity. Each
MAAR entity is controlled by the CMD entity. The core network is formed by three routers,
which connect the domain to three servers. In the SDN domain in Figure 5.6, both the APs
are connected to the FE, through a CSMA link. These FE nodes are controlled by the SDN
Controller (CTR), which implements the AMM functionality.
Both these domains are connected to three server nodes, with which the MN establishes
three sessions. The CN-1 generates the ns3::OnOffApplication, CN-2 generates the
ns3::BulkSendApplication and CN-3 generates the ns3::UdpClientServer application. With
regards to the AMM protocol, the ns3::OnOffApplication corresponds to the conversational ses-
sion, the ns3::BulkSendApplication corresponds to a multimedia session, and the
ns3::UdpClientServer application corresponds to the non-real time session. Since this experi-
mentation aims to study the handover latency of both schemes, only bicasting service is kept
enabled from pFE for the ns3::OnOffApplication in the proposed scheme.
For simulation in both these scenarios, the MN undergoes handovers among AP-1 and AP-
2, both of which are managed by different subnets. It follows the ns3::RandomWalk2dMobility-
Model. The wireless links between the APs and the MN implement the ns3::RangePropagation-
LossModel and ns3::ConstantSpeedPropagationDelayModel. The MN establishes a session
with each CN during its movement in the domain. These sessions remain active while the MN
resides in the domain.
In order to evaluate the handover performance of the PMIPv6-DMM scheme, we have
performed several experiments under this scenario. The simulation for each experiment is run
for 360 seconds, in order to allow the handover event to take place randomly under random
5.2. HANDOVER DELAY ANALYSIS OF PMIPV6-DMM AND THE AMM SCHEME 93
Figure 5.5: The simulation setup for PMIPv6-DMM Experiments
moving patterns of MN. Due to the fact that the PMIPv6-DMM scheme operates reactively,
while the proposed AMM schemes can operate predictively as well as reactively, different
number of handovers for similar simulation setups are observed in both domains.
For performance analysis, different simulation parameters are adjusted with their typical
values shown in Table 5.1 and 5.3. The key parameters which have been shown to have a
significant impact on DMM performance include the velocity of MN and the session activity.
The session activity for these experiments is defined in terms of the traffic generation rate of
each individual session. In order to study the impact of both these parameters on the DMM and
the proposed AMM scheme, we vary the relevant simulation parameters, which include:
1. The velocity range set for the MN.
2. The traffic generation rate of each of the ongoing session.
94 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Figure 5.6: The simulation setup for an SDN domain for the proposed AMM Experiments
In our experiments, we vary each one of these parameters, while keeping the other constant.
Due to a restricted mobility domain, the MN undergoes several handovers among both these
subnets, thus providing an high mobility simulation environment.
5.2.2 Experiment Results
Handover Performance under varying Traffic Generation rate: In the first set of exper-
iments, we exponentially vary the traffic generation rates from the server, while keeping the
velocity range constant. The parameter values adjusted for these experiments are given in Table
5.1. The total traffic generation rate values shown are the approximate values only. Each of these
values include the traffic generation rates of each of the individual sessions as given in Table
5.2. The MN in each of these experiments undergoes several handovers at random intervals. It
thus resides in a particular subnet for different intervals as well.
5.2. HANDOVER DELAY ANALYSIS OF PMIPV6-DMM AND THE AMM SCHEME 95
Figure 5.7: Impact of Traffic Generation Rate = 64 Kb/s on total service disruption interval inPMIPv6-DMM scheme
Figure 5.8: Impact of Traffic Generation Rate = 64 Kb/s on total service disruption interval inAMM scheme
Figure 5.9: Impact of Traffic Generation Rate = 128 Kb/s on total service disruption intervalin PMIPv6-DMM scheme
For PMIPv6-DMM domain, the MN undergoes 27 handovers. For traffic generation rates
of 64 Kb/s (Figure 5.7) and 128 Kb/s (Figure 5.9), the handover latency values observed at
each of these handover instances, although different, remain in the range of 300-400 ms. The
96 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Figure 5.10: Impact of Traffic Generation Rate = 128 Kb/s on total service disruption intervalin AMM scheme
Figure 5.11: Impact of Traffic Generation Rate = 256 Kb/s on total service disruption intervalin PMIPv6-DMM scheme
Figure 5.12: Impact of Traffic Generation Rate = 256 Kb/s on total service disruption intervalin AMM scheme
5.2. HANDOVER DELAY ANALYSIS OF PMIPV6-DMM AND THE AMM SCHEME 97
Figure 5.13: Impact of Traffic Generation Rate = 512 Kb/s on total service disruption intervalin PMIPv6-DMM scheme
Figure 5.14: Impact of Traffic Generation Rate = 512 Kb/s on total service disruption intervalin AMM scheme
minimum handover latency observed is 264 ms, while higher handover latencies upto 700 ms
are also observed at some instances. As the traffic generation rate is increased, a slight reduction
in handover latency is observed. The minimum handover latency observed is 242 ms for 256
Kb/s and 244 ms for 512 Kb/s. The reduction in handover latency is due to the fact that the
packets arrived at their destination earlier due to faster generation of traffic. This reduction is
however minimal because, with increase in the traffic generation rates more packets are queued
at network nodes.
In the SDN domain implementing the AMM protocol, the MN undergoes approximately 40
handovers in each of these experiments. In majority of handover instances which are depicted
in Figures 5.21 to 5.24, the handover latency remains in the range of 160 ms. The highest
handover latency observed for 64Kbps, 128Kbps and 256 Kbps observed is 520ms, while one
98 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Table 5.1: Simulation Setup for Case-1
Parameter ValuesVelocity Range 10 - 30 m/s
Total Traffic Generation Rate (approx.) 64Kb/s, 128Kb/s, 256Kb/s, 512Kb/s
Table 5.2: Simulation Setup for Case-1 - Traffic Generation Rates for Individual Sessions
Parameter ValuesTraffic Generation Rates for Conversational session 32Kb/s, 64Kb/s, 128Kb/s, 256Kb/s
Traffic Generation Rates for Multimedia session 24Kb/s, 48Kb/s, 96Kb/s, 192Kb/sTraffic Generation Rates for Non-real time session 8Kb/s, 16Kb/s, 32Kb/s, 64Kb/s
instance for 512Kbps shows 646ms as well.
Handover Performance under varying Velocity Range: This set of experiments with vary-
ing Velocity ranges provides greatly contrasting results, compared to the first case. This is
because with different velocity ranges the MN undergoes handovers at different instances. The
number of handovers the MN undergoes is also different.
For velocity range of 1 - 14 m/s, a total of 10-11 handovers are observed in both PMIPv6-
DMM and AMM schemes. Among these handovers, the minimum handover latency observed
is 339ms in PMIPv6-DMM and 171ms in the AMM scheme.
Figure 5.15: Impact of MN’s Velocity Range = 1� 14 m/s on total service disruption intervalin PMIPv6-DMM scheme
For PMIPv6-DMM, as the velocity range is further increased, to be between 15 - 28 m/s
and 29 -42m/s, as many as 27 and 51 handovers are respectively observed. Under 28 m/s, the
minimum handover latency observed is 391 ms, while above 28 m/s, the minimum velocity
5.2. HANDOVER DELAY ANALYSIS OF PMIPV6-DMM AND THE AMM SCHEME 99
Figure 5.16: Impact of MN’s Velocity Range = 15� 28 m/s on total service disruption intervalin PMIPv6-DMM scheme
Figure 5.17: Impact of MN’s Velocity Range = 29� 42 m/s on total service disruption intervalin PMIPv6-DMM scheme
Figure 5.18: Impact of MN’s Velocity Range = 1� 14 m/s on total service disruption intervalin AMM scheme
observed is 339 ms. In some cases the handover latency of 1+ seconds is also observed. This is
because of two major factors: (a) the to and fro movement of MN at subnet boundaries owing to
its very high velocity and random movement, (b) loss of AP beacons and router advertisements.
100 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Figure 5.19: Impact of MN’s Velocity Range = 15� 28 m/s on total service disruption intervalin AMM scheme
Figure 5.20: Impact of MN’s Velocity Range = 29� 42 m/s on total service disruption intervalin AMM scheme
On the other hand, in case of AMM, the minimum handover latency for 15-28 m/s velocity
range is 196 ms, and 174ms for 29-42 m/s. The maximum handover latency observed in both
these cases is 777 ms owing to the handover failure due to the aforementioned factors.
Table 5.3: Simulation Setup for Case-2
Parameter ValuesVelocity Range 1 - 14 m/s, 15 - 28 m/s, 29 - 42 m/s
Total Traffic Generation Rate (approx.) 192 Kb/s
5.2. HANDOVER DELAY ANALYSIS OF PMIPV6-DMM AND THE AMM SCHEME 101
Table 5.4: Simulation Setup for Case-2 - Traffic Generation Rates for Individual Sessions
Parameter ValuesTraffic Generation Rates for Conversational session 96Kb/s
Traffic Generation Rates for Multimedia session 64Kb/sTraffic Generation Rates for Non-real time session 32Kb/s
5.2.3 Comparative Analysis of PMIPv6-DMM and AMM Schemes
In this section, we present the overall handover latency comparison of both schemes which is
based on the experiment results presented in the previous section. For this purpose, we compare
the average handover latency in each experiment.
In the first set of experiments, the lower traffic generation rate results in the lower packet
arrival rates. As a result, the average handover delay for PMIPv6-DMM greatly varies and
approaches 800 ms at several instances, for traffic generation rates between 64 and 256 Kbps.
However, as the traffic generation rate is doubled to 512 Kbps, the handover latency also
significantly improves as traffic arrival rate is increased.
On the other hand, the AMM scheme also follows the similar trend, although it provides
much lower handover latency which remains within the range of 400 ms for traffic genera-
tion rates of less than or equal to 256 Kbps. For 512 Kbps, the handover latency remains
within the range of 300 ms. The major cause for the difference in handover latencies between
AMM and PMIPv6-DMM schemes is that, the bicasting service remains enabled, since the
ns3::OnOffApplication remains active. The comparison between AMM and PMIPv6-DMM
schemes is shown in Figures 5.21, 5.22, 5.23 and 5.24.
Finally, under variable MN velocity ranges, the MN undergoes fewer handovers for lower
velocities. As a result, its handover frequency (�) is also lower. Thus, in this case, we compare
the average handover latency for the first ten handovers only. As shown in Figure 5.25, the
average handover latency for PMIPv6-DMM mostly remains within 500 ms under this scenario.
On the other hand, in case of AMM scheme, almost all handovers are executed predictively. As
a result, the handover latency is significantly improved and remains within the range of 300 ms.
However, as we increase the velocity ranges, the MN undergoes several handovers reac-
tively. Thus, it induces much higher handover latencies compared to the first case, and usually
102 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Figure 5.21: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Traffic Generation rate = 64 Kbps
Figure 5.22: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Traffic Generation rate = 128 Kbps
goes beyond 400 ms. However, compared to the PMIPv6-DMM scheme, the AMM scheme
with active bicasting still shows improved handover performance. Finally, for high velocity
ranges, the MN mostly undergoes reactive handovers which result in higher handover latencies
for both schemes. In PMIPv6-DMM, the average handover latency mostly remains in the range
of 700 ms, while in the AMM scheme, it approaches 400 ms at different instances.
5.3. CHAPTER SUMMARY 103
Figure 5.23: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Traffic Generation rate = 256 Kbps
Figure 5.24: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Traffic Generation rate = 512 Kbps
5.3 Chapter Summary
This chapter presents the detailed simulation study to compare the handover latencies of both
the PMIPv6-DMM and the proposed AMM schemes. From the simulation results we draw
104 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Figure 5.25: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Velocity range = 1 - 14 m/s
Figure 5.26: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Velocity range = 15 - 28 m/s
following major conclusions:
1. The proposed AMM scheme provides significant improvement in handover performance
in terms of handover latency under diverse mobility scenarios which are characterized
by different traffic generation rates of ongoing sessions, as well as the MN velocities.
5.3. CHAPTER SUMMARY 105
Figure 5.27: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Velocity range = 29 - 42 m/s
This is because of active bicasting, ability to operate predictively and packet forwarding
from pFE to nFE. Simulation results have shown that compared to PMIPv6-DMM, it can
promise upto 50% reduction in handover latency as traffic generation rates are varied, and
upto 40% reduction under different velocity ranges.
2. The performance evaluation of PMIPv6-DMM shows that under high mobility scenarios
and session activity, it induces higher handover latencies. On the other handover, if the
velocity is lower, the handover latencies are comparatively low as well. This substantiates
the analytical performance studies in [8] and [9], according to which the PMIPv6-DMM
performs well only if the MN’s velocity is lower.
106 CHAPTER 5. IMPLEMENTATION AND PERFORMANCE EVALUATION IN NS-3
Chapter 6
Conclusions and Future Work
This chapter summarizes and presents conclusions of this thesis in Section 6.1. In Section 6.2,
some possible future research directions are identified.
6.1 Conclusions
The work presented in this thesis aims to provide a flexible decentralized mobility solution to
improve the performance of the DMM process through SDN technology. A novel multimode
handover approach is proposed which functions based on a Handover Mode Selection phase.
The proposed mobility architecture is based on OpenFlow protocol. It follows the FPMIPv6
protocol principles, and is thus in line with the key requirements defined by the IETF for DMM
proposals.
The proposed scheme, by taking under consideration the MN’s handover frequency and its
ongoing sessions adaptively executes handover in a pre-selected mode of operation. It provides
the handover support services such as buffering and bicasting etc. to the selected flows of MN
under high mobility and session environments, in order to improve the handover performance.
In this thesis, we have also analyzed the existing DMM proposals, along with their design
features. We have also provided a brief discussion on existing proposals which aim to achieve
adaptable mobility behaviour in the IP mobility protocols, and have outlined the reasons because
of which they cannot be directly integrated into the DMM paradigm to support 5G mobility.
In Chapter 4, we have developed an analytical model to evaluate the performance of the pro-
posed AMM and PMIPv6-DMM solutions under high mobility and session activity scenarios.
107
108 CHAPTER 6. CONCLUSIONS AND FUTURE WORK
The results have shown significant handover performance improvement in the AMM compared
to the PMIPv6-DMM in terms of session disruption latency and packet loss. It also promises
reduced signaling costs if the handover support services are enabled only for selected flows.
In Chapter 5, we have presented results of the simulations performed through the ns-3
simulator for both PMIPv6-DMM and the proposed AMM scheme under diverse scenarios.
The AMM scheme, is able to adapt to the mobility requirements of MN and thus provides
reduced latency compared to the PMIPv6-DMM scheme. This allows us to conclude that the
flexible design consideration for handover protocols in order to adapt to the mobility need of
the MNs, can help in maintaining the handover latency within the acceptable ranges even under
high mobility and high session activity scenarios.
The current standardization efforts for DMM at the IETF are mainly focused on a network-
based DMM solution which follows the PMIPv6 protocol, and thus inherits its several salient
features. It is thus a promising candidate for further development towards a complete inter-
net standard. As part of this research, we have also developed a new ns-3 module, named
PmipDmm, which implements this solution.
6.2 Future Works
The research on DMM, although has roots in centralized IP mobility enhancements, is still in its
early stages. The existing DMM solutions are far from meeting the DMM requirements framed
by the IETF. Based on the work presented in this thesis, following are the prospective avenues
which could be further pursued in order to enrich the research presented in this thesis.
1. The evolution of Distributed Mobility Management towards SDN principles requires
further research in order to enhance the basic mobility support towards more advanced
mobility solutions which could for example, ensure security, QoS aspects during han-
dovers as well.
2. Multicast mobility support on Distributed Mobility Management [56, 57] requires fur-
ther research, as high proportion of the current and future network applications would
comprise of the multicast sessions.
3. The decentralized mobility where the mobility might have to rely on multiple anchors
6.2. FUTURE WORKS 109
introduces new security challenges. Research is required to address such challenges in
DMM, e.g. an attacker masquerading itself a false anchor, by sending false PBU messages
to CMD, or the CMD entity being flooded with the false PBU messages.
4. We have presented the ns-3 module design for PMIPv6-based DMM module. At IETF
a MIPv6 based DMM solution is also under consideration [22]. Thus, a similar MIPv6-
based module for DMM could also be developed based on [58] for performance analysis
of host-based DMM process.
5. A further enhancement of our presented PmipDmm module can be done on to simulate
the PMIPv6-DMM in the LTE networks.
110 CHAPTER 6. CONCLUSIONS AND FUTURE WORK
References
[1] OpenFlow Switch Specification Version 1.3.5 (Protocol version 0x04), Open Networking
Foundation Std., 2015.
[2] ns-3 [online]. [Online]. Available: https://www.nsnam.org/
[3] L. J. Chaves, I. C. Garcia, and E. R. M. Madeira, “Ofswitch13: Enhancing ns-3 with
OpenFlow 1.3 support,” in Proceedings of the Workshop on Ns-3, ser. WNS3 ’16. New
York, NY, USA: ACM, 2016, pp. 33–40.
[4] T. S. Rappaport, S. Sun, R. Mayzus, H. Zhao, Y. Azar, K. Wang, G. N. Wong, J. K. Schulz,
M. Samimi, and F. Gutierrez, “Millimeter Wave Mobile Communications for 5G Cellular:
It Will Work!” IEEE Access, vol. 1, pp. 335–349, 2013.
[5] H. Chan, D. Liu, P. Seite, H. Yokota, and J. Korhonen, Requirements for Distributed
Mobility Management, IETF RFC 7333, August 2014.
[6] D. Liu and P. Seite, Distributed Mobility Management: Current practices and gap
analysis, IETF RFC 7429, January 2015.
[7] A. d. l. Oliva, F. Giust, and C. Bernardos, A PMIPv6-based solution for Distributed
Mobility Management, IETF Internet Draft (work in progress) draft-bernardos-dmm-
pmip-08, March 2017.
[8] J. Carmona-Murillo, I. Soto, F. Rodrıguez-Perez, D. Cortes-Polo, and J. Gonzalez-
Sanchez, “Performance Evaluation of Distributed Mobility Management Protocols:
Limitations and Solutions for Future Mobile Networks,” Mobile Information Systems, vol.
2017, 2017.
[9] L. Yi, H. Zhou, D. Huang, and H. Zhang, “An analytical study of distributed mobility
111
112 REFERENCES
management schemes with a flow duration based model,” Journal of Network and
Computer Applications, vol. 41, pp. 351 – 357, 2014.
[10] J. Bailey and S. Stuart, “Faucet: deploying SDN in the enterprise,” Queue, vol. 14, no. 5,
p. 30, 2016.
[11] I. F. Akyildiz, S. Nie, S.-C. Lin, and M. Chandrasekaran, “5G roadmap: 10 key enabling
technologies,” Computer Networks, vol. 106, no. Supplement C, pp. 17 – 48, 2016.
[12] I. Vision, “Framework and overall objectives of the future development of IMT for 2020
and beyond,” ITU, Feb, 2014.
[13] H. Yokota, K. Chowdhury, R. Koodli, B. Patil, and F. Xia, Fast Handovers for Proxy
Mobile IPv6, IETF RFC 5949, September 2010.
[14] Z. Zhu, L. Zhang, and R. Wakikawa, A survey of mobility support in the Internet, IETF
RFC 6301, July 2011.
[15] C. Perkins, D. Johnson, J. Arkko et al., Mobility Support in IPv6, IETF RFC 6275, July
2011.
[16] H. Soliman, L. Bellier, and K. E. Malki, Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management, IETF RFC 5380, October 2008.
[17] R. Koodli, Fast Handovers for Mobile IPv6, IETF RFC 5568, July 2009.
[18] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, Proxy Mobile IPv6,
IETF RFC 5213, August 2008.
[19] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, Network Mobility (NEMO)
Basic Support Protocol, IETF RFC 3963, January 2005.
[20] J. H. Lee, J. M. Bonnin, I. You, and T. M. Chung, “Comparative Handover Performance
Analysis of IPv6 Mobility Management Protocols,” IEEE Transactions on Industrial
Electronics, vol. 60, no. 3, pp. 1077–1088, March 2013.
[21] F. Giust, A. de la Oliva, and C. J. Bernardos, “Flat access and mobility architecture:
An IPv6 distributed client mobility management solution,” in 2011 IEEE Conference on
Computer Communications Workshops (INFOCOM WKSHPS), April 2011, pp. 361–366.
REFERENCES 113
[22] ——, An IPv6 Distributed Client Mobility Management approach using existing
mechanisms, IETF Internet Draft (work in progress) draft-bernardos-dmm-cmip-07,
March 2017.
[23] K. S. Kong, W. Lee, Y. H. Han, M. K. Shin, and H. You, “Mobility management for all-IP
mobile networks: Mobile IPv6 vs. Proxy mobile IPv6,” IEEE Wireless Communications,
vol. 15, no. 2, pp. 36–45, April 2008.
[24] H. Luo, H. Zhang, Y. Qin, and V. C. M. Leung, “An Approach for Building Scalable Proxy
Mobile IPv6 Domains,” IEEE Transactions on Network and Service Management, vol. 8,
no. 3, pp. 176–189, September 2011.
[25] M. Perras and J. Cartmell, “Mobility for heterogeneous SmallNets,” Telecommunication
Systems, vol. 61, no. 2, pp. 277–294, 2016.
[26] F. Giust, C. J. Bernardos, S. Figueiredo, P. Neves, and T. Melia, “A hybrid MIPv6 and
PMIPv6 distributed mobility management: The MEDIEVAL approach,” in 2011 IEEE
Symposium on Computers and Communications (ISCC), June 2011, pp. 25–30.
[27] M. K. Murtadha, N. K. Noordin, B. M. Ali, and F. Hashim, “Design and evaluation
of distributed and dynamic mobility management approach based on PMIPv6 and MIH
protocols,” Wireless Networks, vol. 21, no. 8, pp. 2747–2763, 2015.
[28] H. A. Chan, “Proxy mobile IP with distributed mobility anchors,” in 2010 IEEE Globecom
Workshops, Dec 2010, pp. 16–20.
[29] L. Yi, H. Zhou, D. Huang, and H. Zhang, “D-PMIPv6: A distributed mobility management
scheme supported by data and control plane separation,” Mathematical and Computer
Modelling, vol. 58, no. 56, pp. 1415 – 1426, 2013.
[30] T.-T. Nguyen and C. Bonnet, “DMM-based inter-domain mobility support for Proxy
Mobile IPv6,” in 2013 IEEE Wireless Communications and Networking Conference
(WCNC), April 2013, pp. 1998–2003.
[31] J. C. Cancho, J. C. Murillo, D. C. Polo, J. L. G. Sanchez, and F. J. R. Perez, “TE-DMM:
A Proposal to Improve the Control Plane in PMIPv6-based DMM Networks,” IEEE Latin
America Transactions, vol. 13, no. 9, pp. 3149–3155, Sept 2015.
114 REFERENCES
[32] T.-X. Do and Y. Kim, “EPD-NEMO: efficient PMIPv6-based distributed network mobility
management,” Wireless Networks, vol. 21, no. 7, pp. 2303–2314, 2015.
[33] P. Bertin, J.-H. Lee, and P. Seite, Distributed Mobility Anchoring, IETF Internet Draft
(work in progress) draft-chan-dmm-distributed-mobility-anchoring-08, July 2016.
[34] J. H. Lee, Z. Yan, J. M. Bonnin, and X. Lagrange, “Dynamic tunneling for network-
based distributed mobility management coexisting with PMIPv6,” in 2013 IEEE 24th
Annual International Symposium on Personal, Indoor, and Mobile Radio Communications
(PIMRC), Sept 2013, pp. 2995–3000.
[35] L. M. Contreras, L. Cominardi, H. Qian, and C. J. Bernardos, “Software-Defined
Mobility Management: Architecture Proposal and Future Directions,” Mobile Networks
and Applications, vol. 21, no. 2, pp. 226–236, 2016.
[36] J. Bi and Y. Wang, Software Defined Mobility Management for Mobile Internet. John
Wiley & Sons, Ltd, 2015, pp. 265–287.
[37] Y. Li, H. Wang, M. Liu, B. Zhang, and H. Mao, “Software Defined Networking for
Distributed Mobility Management,” in 2013 IEEE Globecom Workshops (GC Wkshps),
Dec 2013, pp. 885–889.
[38] Y. Wang, J. Bi, and K. Zhang, “Design and Implementation of a Software-Defined
Mobility Architecture for IP Networks,” Mob. Netw. Appl., vol. 20, no. 1, pp. 40–52, Feb.
2015.
[39] A. Bradai, A. Benslimane, and K. D. Singh, “Dynamic anchor points selection for
mobility management in Software Defined Networks,” Journal of Network and Computer
Applications, vol. 57, pp. 1 – 11, 2015.
[40] S. Pack, M. Nam, T. Kwon, and Y. Choi, “An adaptive mobility anchor point selection
scheme in Hierarchical Mobile IPv6 networks,” Computer Communications, vol. 29,
no. 16, pp. 3066 – 3078, 2006.
[41] D.-C. Wang, W. He, and I.-R. Chen, “Smart Routers for Cross-Layer Integrated Mobility
and Service Management in Mobile IPv6 Systems,” Wirel. Pers. Commun., vol. 69, no. 1,
pp. 449–469, Mar. 2013.
REFERENCES 115
[42] S. Pack, T. Kwon, Y. Choi, and E. K. Paik, “An Adaptive Network Mobility Support
Protocol in Hierarchical Mobile IPv6 Networks,” IEEE Transactions on Vehicular
Technology, vol. 58, no. 7, pp. 3627–3639, Sept 2009.
[43] S. Jeon and Y. Kim, “Adaptive Handoff Management in the Proxy Mobile IPv6 Domain,”
in 2011 IEEE 73rd Vehicular Technology Conference (VTC Spring), May 2011, pp. 1–5.
[44] X.-H. Peng, H.-K. Zhang, and S.-D. Zhang, “Integrated optimization of management cost
of hierarchical mobile IPv6 and its performance simulation,” in Wireless Communications
and Networks, vol. 5284, 2004, pp. 302–308.
[45] P. Xue-Hai, Z. Hong-Ke, H. Jiu-Chuan, and Z. Si-Dong, “Modeling in Hierarchical
mobile IPv6 and intelligent mobility management scheme,” in 14th IEEE Proceedings
on Personal, Indoor and Mobile Radio Communications, 2003. PIMRC 2003., vol. 3, Sept
2003, pp. 2823–2827 vol.3.
[46] L. Cominardi, F. Giust, C. J. Bernardos, and A. D. L. Oliva, “Distributed mobility
management solutions for next mobile network architectures,” Computer Networks, vol.
121, pp. 124 – 136, 2017.
[47] P. M. L. Chan, R. E. Sheriff, Y. F. Hu, P. Conforto, and C. Tocci, “Mobility management
incorporating fuzzy logic for heterogeneous a IP environment,” IEEE Communications
Magazine, vol. 39, no. 12, pp. 42–51, Dec 2001.
[48] M. Kassar, B. Kervella, and G. Pujolle, “An overview of vertical handover decision
strategies in heterogeneous wireless networks,” Computer Communications, vol. 31,
no. 10, pp. 2607 – 2620, 2008.
[49] Y. Wang, J. Bi, and X. Jiang, “A multi-anchoring approach in mobile IP networks,”
Wireless Communications and Mobile Computing, vol. 16, no. 18, pp. 3423–3438, 2016.
[50] K. P. Yoon and C.-L. Hwang, Multiple attribute decision making: An Introduction. Sage
publications, 1995, vol. 104.
[51] C. Makaya and S. Pierre, “An Analytical Framework for Performance Evaluation of IPv6-
Based mobility Management Protocols,” IEEE Transactions on Wireless Communications,
vol. 7, no. 3, pp. 972–983, March 2008.
116 REFERENCES
[52] J. H. Lee, T. Ernst, and T. M. Chung, “Cost analysis of ip mobility management protocols
for consumer mobile devices,” IEEE Transactions on Consumer Electronics, vol. 56, no. 2,
pp. 1010–1017, May 2010.
[53] R. Li, J. Li, K. Wu, Y. Xiao, and J. Xie, “An Enhanced Fast Handover with Low Latency
for Mobile IPv6,” IEEE Transactions on Wireless Communications, vol. 7, no. 1, pp. 334–
342, Jan 2008.
[54] F. Giust, C. J. Bernardos, and A. de la Oliva, “Analytic evaluation and experimental
validation of a network-based ipv6 distributed mobility management solution,” IEEE
Transactions on Mobile Computing, vol. 13, no. 11, pp. 2484–2497, Nov 2014.
[55] H. Y. Choi, S. G. Min, Y. H. Han, J. Park, and H. Kim, “Implementation and Evaluation
of Proxy Mobile IPv6 in ns-3 Network Simulator,” in 2010 Proceedings of the 5th
International Conference on Ubiquitous Information Technologies and Applications, Dec
2010, pp. 1–6.
[56] S. Figueiredo, S. Jeon, D. Gomes, and R. L. Aguiar, “D3M: multicast listener mobility
support mechanisms over distributed mobility anchoring architectures,” Journal of
Network and Computer Applications, vol. 53, pp. 24 – 38, 2015.
[57] T.-T. Nguyen and C. Bonnet, “DMMS: a flexible architecture for multicast listener support
in a distributed mobility management environment,” Computer Networks, vol. 94, pp. 129
– 144, 2016.
[58] M. K. Rana, B. Sardar, S. Mandal, and D. Saha, “Implementation and performance
evaluation of a mobile IPv6 (MIPv6) simulation model for ns-3,” Simulation Modelling
Practice and Theory, vol. 72, pp. 1 – 22, 2017.
Top Related