a software deﬁned networking based adaptive multimode decentralized ... › 116510 › 1 ›...

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

To my family

iii

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

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

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

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

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


val in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96




val in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96




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


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


interval in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100


interval in AMM scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.21 Average Handover Latency comparison of PMIPv6-DMM and AMM Schemes

for Traffic Generation rate = 64 Kbps . . . . . . . . . . . . . . . . . . . . . . . 102


for Traffic Generation rate = 128 Kbps . . . . . . . . . . . . . . . . . . . . . . 102






for Velocity range = 1 - 14 m/s . . . . . . . . . . . . . . . . . . . . . . . . . . 104


for Velocity range = 15 - 28 m/s . . . . . . . . . . . . . . . . . . . . . . . . . 104


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

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.


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


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.


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


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


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


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


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


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.


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


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,


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


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


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


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.

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.


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.


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


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


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


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.


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


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


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


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


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


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.


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


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


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


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


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.


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


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


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.


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.


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


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


and session activity are developed, and the performance comparison of both schemes is done

based on session disruption latency, packet loss and signaling cost.

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,


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.


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,


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


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


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


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.


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


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


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


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


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



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


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


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


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)


= 3 ·DBC + (6k + 2 + 3n) · TC + (6k + 4 + 3n) · PC

In terms of an OpenFlow packet size sof , Equation (4.29) is given as,


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


(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




= 3 ·DBC + (n+ 7k + 6) · PC + (n+ 7k + 4) · TC



= 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



= DBC + (2n+ 6k + 3) · TC + (2n+ 6k + 3) · PC



= 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



= DBC + (4n+ k + 3) · TC + (4n+ k + 4) · PC



= DBC + (4n+ k + 3) · sof · � + (4n+ k + 4) · sof · u


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



= DBC + (2n+ 7k + 3) · TC + (2n+ 7k + 4) · PC



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


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


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


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


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


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


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


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.


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


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


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


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.

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


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.


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


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


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


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.


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.


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


Figure 5.10: Impact of Traffic Generation Rate = 128 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


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




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.




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


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


Figure 5.21: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Traffic Generation rate = 64 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

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


Figure 5.25: Average Handover Latency comparison of PMIPv6-DMM and AMM Schemesfor Velocity range = 1 - 14 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.



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.

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.

a software deﬁned networking based adaptive multimode decentralized ... › 116510 › 1 ›...

Documents