Wireless distributed mobility management on a road scenario

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2014

Jo˜

ao Pedro

Coelho de Azevedo

Wireless Distributed Mobility Management on a

Road Scenario

Mobilidade Distribu´ıda em Hotspots num Ambiente

de Estrada

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2014

Jo˜

ao Pedro

Coelho de Azevedo

Wireless Distributed Mobility Management on a

Road Scenario

Mobilidade Distribu´ıda em Hotspots num Ambiente

de Estrada

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obten¸cão do grau de Mestre em Engenharia Electrónica e Telecomunica¸cões, realizada sob a orienta¸cão cient´ıfica da Pro-fessora Doutora Susana Sargento, ProPro-fessora Associada do Departamento de Electrónica, Telecomunica¸cões e Informática da Universidade de Aveiro e co-orienta¸cão do Doutor Tiago Condeixa, Systems Engineer at Veniam.

(4)

(5)

o j´uri / the jury

presidente / president Professor Doutor Rui Lu´ıs Andrade Aguiar,

Professor Associado com Agrega¸cão, Departamento de Electrónica, Teleco-munica¸cões e Informática da Universidade de Aveiro

vogais / examiners committee Professor Doutor Joel Jos´e Puga Coelho Rodrigues

Professor Auxiliar, Departamento de Inform´atica da Faculdade de Engen-haria da Universidade da Beira Interior (arguente)

Professora Doutora Susana Isabel Barreto de Miranda Sargento

Professora Associada, Departamento de Electrónica, Telecomunica¸cões e Informática da Universidade de Aveiro (orientadora)

(6)

(7)

agradecimentos / acknowledgements

Agrade¸co à minha fam´ılia pelo apoio incondicional durante o meu per-curso académico e em especial aos meus pais por me darem o privilégio de obter um grau académico.

Agrade¸co à Professora Susana Sargento pela oportunidade de desen-volver este trabalho sob a sua excelente orienta¸cão e pela confian¸ca em mim depositada. No âmbito da Disserta¸cão quero também agradecer ao Tiago Condeixa, pela ajuda e apoio prestados durante cada uma das fases de desenvolvimento, a toda a equipa de engenharia da Ve-niam, que sempre se mostrou dispon´ıvel para esclarecimentos, e aos elementos do grupo NAP do IT-Aveiro.

Gostaria de agradecer de forma especial ao Lu´ıs Guedes e ao João Mendes pelos 5 fantásticos anos e pela partilha da experiência Erasmus. Ao António Carvalho, Joana Garrido, Filipe Serra, Gra¸ca Lemos e Hélder Machado por serem a minha fam´ılia longe de casa.

O meu muito obrigado ao Francisco Ruivo, ao Artur Amorim e `a Mar-garida Moura por serem os amigos de sempre!

Por último, mas sem menos importância, agrade¸co a todos aqueles com quem me cruzei na Universidade de Aveiro, na AJC, no IEEE e no CLUTA por me ajudarem ser um melhor estudante, um melhor profissional, um melhor comunicador: um melhor cidadão.

(8)

(9)

Palavras-Chave Gest˜ao Distribu´ıda de Mobilidade, Mobilidade de Rede, DMIPA, VANET, Comunica¸c˜oes Veiculares, norma IEEE 802.11p, norma IEEE 801.11g

Resumo Actualmente, a conectividade ub´ıqua ´e uma necessidade importante

para a generalidade da popula¸cão. As pessoas querem e, em muitos casos, têm a necessidade de estar ligadas entre si e com o mundo. Para partilhar um v´ıdeo, participar numa reunião online ou apenas para manter contacto com os amigos e familiares, a Internet faz ver-dadeiramente parte do nosso dia-a-dia. No entanto, este crescimento maci¸co do mundo online apresentou uma série de desafios às equipas de engenharia e investiga¸cão em redes de computadores. Um desses desafios é a mobilidade.

O tema da mobilidade na rede não é uma questão recente, uma vez que as pessoas desejam aceder à Internet em todos os lugares e querem poder fazê-lo como se estivessem em casa. Várias solu¸cões foram ap-resentadas e aplicadas ao longo dos anos; no entanto, com a expansão das redes veiculares, novas solu¸cões são necessárias de modo a cumprir os requisitos de tais redes.

Neste trabalho foi realizado um estudo sobre as solu¸cões de gestão de mobilidade dispon´ıveis. As solu¸cões de gestão de mobilidade es-tudadas incluem solu¸cões centralizadas e distribu´ıdas; no entanto, o foco do trabalho apresentado está nas solu¸cões distribu´ıdas. Neste contexto, é apresentada uma implementa¸cão de um novo protocolo de gestão distribu´ıda de mobilidade, DMIPA, adequado para ser utilizado num ambiente veicular. Este novo protocolo pretende aplicar a gestão da mobilidade de forma distribu´ıda pelos vários nós da rede, evitando as desvantagens de solu¸cões centralizadas, mesmo em redes que não oferecem qualquer apoio à mobilidade, sem quaisquer mudan¸cas de hardware ou de rede.

Al´em disso, o protocolo foi testado em laborat´orio e na estrada, a fim de obter dados reais sobre o seu desempenho e comportamento. Este teste foi realizado utilizando as tecnologias de acesso IEEE 802.11g, utilizado em pontos de acesso Wi-Fi, e IEEE 802.11p, uma tecnologia

(10)

(11)

Keywords Distributed Mobility Management, Network Mobility, DMIPA, VANET, Vehicular Communications, IEEE 802.11p standard, IEEE 801.11g standard, Seamless Handover

Abstract In today’s world, connectivity is an important requirement for the pop-ulation. People want and, in a broad range of cases, need to be con-nected with each other and with the world. To share a video, attend an e-meeting or just keep in touch with friends and family, Internet is truly part of our everyday life. However, this massive growth of the connected world presented a lot of challenges to the engineering task-forces and research teams in computer networks. One of these challenges is mobility.

The network mobility theme is not a recent matter in the networking world since people want to reach the Internet everywhere and still be able to do it like when at home. Several solutions have been presented and applied over the years; however, with the expansion of vehicular networks, new solutions must be presented in order to fulfill the re-quirements of such networks.

In this work a study on the available mobility management solutions is performed. The studied mobility management solutions include both centralized and distributed solutions; however, the focus of the work presented is in the distributed category. In this context an implemen-tation for a new distributed mobility management protocol, DMIPA, suitable to be used in a vehicular environment is presented. This new protocol aims to deliver mobility management in a distributed way, avoiding the disadvantages of centralized solutions, even in networks that do not provide any support for mobility without any hardware or network changes.

Moreover, the protocol was tested in laboratory and on the road in order to acquire real data about the performance and behaviour of the implementation. These tests were based on the access technolo-gies IEEE 802.11g, commonly used in WiFi access points, and IEEE

(12)

(13)

List of Figures

2.1 OBU with connected antennas. 802.11p antenna, 802.11g antenna

and GPS antenna, from left to right . . . 8

2.2 VANETs in the Intelligent Transport Systems environment [1] . . . 9

2.3 Technical Challenges in VANET’s [2] . . . 10

2.4 Centralized Mobility Management Architecture Examples (adapted from [3] . . . 13

2.5 Distributed Mobility Management Architecture Example (adapted from [3] . . . 13

2.6 SIP Operation Example (adapted from [4]) . . . 16

2.7 MIPv6 Operation Example . . . 19

2.8 PMIPv6 Operation Example . . . 22

2.9 N-PMIPv6 typical scenario [5] . . . 23

2.10 N-PMIPv6 Operation Representation [5] . . . 24

2.11 LISP Architecture and Operation Example [6] . . . 27

2.12 DMIPA Architecture and Elements [7] . . . 29

3.1 DMIPA Architecture [7] . . . 33

3.2 DMIPA Operation [7] . . . 34

3.3 DMIPA Scheme Example . . . 37

4.1 Typical Structure of an OpenWrt package . . . 41

4.2 The Gateworks Cambria GW2358-4 SBC . . . 43

4.3 Router Advertisement message [8] . . . 46

4.4 Neighbor Advertisement message [9] . . . 47

4.5 Representation of a BU message showing the added mobility option 53 4.6 MN - DMAR interaction . . . 55

(18)

4.7 Logical Operation of a MN connecting to a AR . . . 57

4.8 NetRider OBU/RSU . . . 58

4.9 UWME used data structures . . . 61

4.10 Dataflow of the process to choose the best neighbor RSU . . . 62

5.1 Laboratory Experiment Scenario . . . 64

5.2 Road Experiment Scenario . . . 65

5.3 Handover Latency in the laboratory testbed . . . 68

5.4 Throughput before, during and after handover . . . 69

5.5 Packet Loss in the laboratory testbed . . . 70

5.6 Handover Latency using IEEE 802.11p on the road . . . 70

(19)

List of Tables

(20)

(21)

Abbreviations

AP Access Point

AR Access Router

ASA Anchor Set Acknowledgement ASU Anchor Set Update

BA Binding Acknowledgement BE Binding Error

BRR Binding Refresh Request BSS Basic Service Set

BU Binding Update CN Correspondent Node CoA Care-of Address

CSV Comma Separated Values DHP Distributed Home Proxy DHoA Distributed Home Address DMAR Data Mobility Access Router DMIPA Dynamic Mobile IP Anchoring DMIPv6 Distributed Mobile IPv6

(22)

DSRC Dedicated Short Range Communications EID Endpoint Identifier

ETR Egress Tunnel Router ePMIP enhanced Proxy Mobile IP FA Foreign Agent

FN Foreign Network FPMIP Fast Proxy Mobile IP

GDB GNU Debugger

GPS Global Positioning System

HA Home Agent

HN Home Network

HoA Home Address

HTTP Hypertext Transfer Protocol I2I Infrastructure to Infrastructure ICMP Internet Control Message Protocol

IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force

IP Internet Protocol

IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISA Instruction Set Architecture ITR Ingress Tunnel Router LAN Local Area Network

(23)

LISP Locator Identifier Separation Protocol LMA Local Mobility Anchor

LMD Local Mobility Domain LTE Long Term Evolution M2M Machine to Machine MAG Mobile Access Gateway MANET Mobile Ad-hoc NETwork

MIP Mobile IP

MIPv4 Mobile IPv4 MIPv6 Mobile IPv6 mMAG mobile MAG

MN Mobile Node

MNP Mobile Network Prefix

MN-HNP Mobile Node Home Network Prefix MN-ID Mobile Node Identifier

MSF Mobility Support Flag ND Neighbor Discovery NA Neighbor Advertisement

NAP Network Architectures and Protocols NIC Network Interface Card

N-PMIPv6 Network Proxy Mobile IPv6 NS Neighbor Solicitation OBU On Board Unit

(24)

OS Operating System

PBA Proxy Binding Acknowledge PBU Proxy Binding Update PMIP Proxy Mobile IP PMIPv6 Proxy Mobile IPv6

PNEMO Proxy Mobile IPv6 (PMIPv6)-based NEtwork MObility QoS Quality of Service

RA Router Advertisement RLOC Routing Locator RS Router Solicitation

RSSI Received Signal Strength Indication RSU Road Side Unit

RTP Real-time Transport Protocol SBC Single Board Computer

SCTP Stream Control Transmission Protocol SDP Session Description Protocol

SIP Session Initiation Protocol TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol USB Universal Serial Bus

UWME WAVE Management Entity V2I Vehicle to Infrastructure

(25)

V2V Vehicle to Vehicle

VANET Vehicular Ad-hoc NETwork WAN Wide Area Network

WAVE Wireless Access in Vehicular Environments WiFi Local Area Wireless Technology

(26)

(27)

Chapter 1 Introduction

1.1 Motivation

During the last years the global community has proven how important being connected to the Internet is in our lives, specially when in transit. According to the 2014 version of a well known yearly report on mobile data traffic [10], presented by Cisco, the mobile data traffic grew 81 percent in 2013 representing now almost 18 times the size of the whole global Internet in the beginning of the century. Both numbers are highly motivated by the proliferation and crescent number of smartphones available in the market, which lead to an increase of 50 percent in smartphone usage, in the same period. With more and more Internet capable devices available, and added capabilities every year, mobile device users become more demanding, setting new trends in the mobile data market. One of the most remarkable trends presented in the same report is the video dominance over other services, with growth rates only comparable with Machine to Machine (M2M) traffic. This and the expanding user mobility present new challenges to the infrastructure already deployed, such as session continuity (given the higher time per connection), which is inwardly connected with mobility management. Mobility is today a keyword for almost any Information Technology industry sector, and it is clear that people want to be connected everywhere, anytime.

In this perspective, provide users with mobility solutions has been a natural concern for the main players in the telecommunications market which recognize mobility management as a key feature in their infrastructure. Given the

(28)

impor-tance of this matter, the scientific community has been working on solutions to provide network mobility. These solutions can be categorized as centralized and distributed.

Although centralized mobility solutions follow the current network topology mindset, they also present several problems regarding security and scalability, and so, new contributions regarding distributed mobility management tend to be very well accepted by the scientific community and the telecommunications operators. Some developments on distributed mobility management have been presented in the last years, and there is even a Working Group in Internet Engineering Task Force (IETF) for Distributed Mobility Management [11].

It was on this context that the Network Architectures and Protocols (NAP) research group, at Instituto de Telecomunica¸c˜oes, started the development of a fully distributed mobility management solution, that goes by the name of Dynamic Mobile IP Anchoring (DMIPA). This protocol aims to create a new architecture where mobility management is spread around all the fixed access points and mobile nodes of the network, avoiding the single points of failure and scalability issues some times present in centralized solutions. Also this new protocol aims to be compatible with legacy infrastructure, which is one great advantage as it fits the already deployed network solutions.

As the modern networking paradigms move towards flatter topologies, it is important to test new approaches like DMIPA in real world scenarios and environ-ments. It is equally important to test these solutions against the emerging dynamic environments present in cities and roads. This Dissertation develops and deploys DMIPA in a real network, using both WiFi and IEEE 802.11p technologies, both in the lab and in the road, and evaluates DMIPA in several scenarios to assess its feasibility to support seamless mobility in wireless and vehicular scenarios.

1.2 Objectives and Contributions

In a general way, the work hereby presented is related to distributed mobility management; moreover, in a more focused perspective, all tasks were performed taking into account the evolution to a vehicular network environment. Even so, the path taken towards the vehicular environment leads to an intermediate phase where a solution for Wi-Fi fixed networks, such as the ones present in our houses

(29)

or workplaces, was achieved, being later described as the 802.11g solution. The objectives of this work are as follows:

• Implementation of the DMIPA protocol using both WiFi and vehicular tech-nologies;

• Validation and laboratory test of the DMIPA protocol using both WiFi and vehicular technologies;

• Extension of the implemented solution to a road environment;

• Evaluation of the protocol using vehicular technology;

• Performance comparison between vehicular and non-vehicular technologies;

• Performance comparison with other mobility solutions.

The first two objectives aim to get a fully functional version of DMIPA capable to take advantage of the better performance of vehicular technologies against the common wireless networks. This version of DMIPA is validated and tested in a controlled environment before extending it to a road environment, which is the following objective.

The technology extension to a real environment presents the designed protocol with new challenges, since this is a much more dynamic environment. The tests are performed on a local road near Instituto de Telecomunica¸c˜oes.

The third and fourth objectives of this work are to assess the overall perfor-mance of DMIPA given other 3rd party protocols and implementations, all devel-oped in our group, and tested in similar scenarios. This will give us the information required to understand which is the best approach in these dynamic scenarios.

In order to achieve all the proposed objectives, the following contributions were provided:

• Overall implementation of DMIPA using regular Local Area Wireless Tech-nology (WiFi) techTech-nology and IEEE 802.11p;

• Overall testing of DMIPA in the laboratory and in a real road scenario;

• Comparison between DMIPA and other mobility protocols, providing an assessment on which protocols are most suitable for vehicular environments;

(30)

• Paper submission on IEEE ICC Workshop on Dependable Vehicular Com-munications (DVC) 2015: ”Distributed Mobility Management in Vehicular Networks: A Real-World Deployment”.

1.3 Document Organization

This dissertation is composed by six chapters, organized as follows:

• Chapter 1: contextualization of the work done, motivation and objectives of this Dissertation;

• Chapter 2: state of the art presentation regarding vehicular networks and mobility management;

• Chapter 3: full description of DMIPA, the protocol chosen as research object in this work;

• Chapter 4: implementation details stating tools and processes used in order to test the suitability of DMIPA to be used in vehicular environments;

• Chapter 5: scenarios evaluated as well as the results obtained after running the tests both in laboratory and in a real road environment;

• Chapter 6: the last chapter resumes the work done, takes conclusions about DMIPA performance and suggests future paths in order to advance this sub-ject.

(31)

Chapter 2 State of the Art

2.1 Introduction

The chapter here presented aims to give an insight in some topics of rele-vance for the developed work pursuing this academic degree. It presents vehicular networks, their specific aspects and technologies, following approaches and require-ments for mobility. The focus of this work is presented as well as several mobility management solutions. The organization of the chapter is as follows:

Section 2.2 describes vehicular networks and its features.

Section 2.3 presents the centralized and distributed approaches to provide mo-bility in a network.

Section 2.4 describes the fundamentals and operation principles of some rele-vant mobility management solutions.

Section 2.5 summarizes the addressed contents of the chapter.

2.2 Vehicular Ad-hoc Networks

Vehicular networks are a reality nowadays after a decade of research. A Vehic-ular Ad-hoc NETwork (VANET) is a class of Mobile Ad-hoc NETwork (MANET) that uses vehicles as network nodes providing communications between nearby vehicles and between vehicles and fixed equipment [12]. Empowered by short to medium range communication technologies, vehicular networks aim to provide a broad range of applications to their users.

(32)

VANET applications are often categorized in the following areas:

• active road safety applications;

• traffic efficiency and management applications;

• comfort and infotainment applications.

With mobility solutions in mind, this section provides a brief reading on specific details of VANETs, explains the technical challenges that researchers face, and presents the importance of mobility in such networks.

2.2.1 Characteristics of Vehicular Networks

As a very specific type of dnetwork, the VANETs have some exclusive charac-teristics [13]:

• Predictability: due to the GPS systems on-board vehicles and the fact that vehicles usually only move around in roads;

• Always available power: just like any other component of the vehicle, the On Board Units (OBUs) should not lack power supply;

• Partitioned network: given the very dynamic environment, we can usually find isolated vehicle clusters creating a fragmented network;

• Rapid topology changes: since the network nodes are the vehicles and they are always on the move, it is very easy for a network topology to change frequently;

• Large scale networks: with the amount of vehicles populating nowadays roads this already is a potentially huge network. Also with the expanding number of vehicles this is an ever-expanding network;

• Variable network density: given the vehicular environment, it is possible to find very dense networks (eg. traffic jams) and truly sparse networks (eg. suburban traffic).

(33)

2.2.2 Network Access Technologies and Equipment

In order to access a vehicular network, the vehicle must be equipped in such a way that enables it to take advantage of some readily available technologies.

The used network access technologies in VANETs are: Dedicated Short Range Communications (DSRC), 802.11p Wireless Access in Vehicular Environments (WAVE), WiFi and cellular. The first two technologies are usually used only in VANETs and the standards that are associated to them were developed with vehicular networks in mind. WiFi is the access technology used to connect to Wireless Local Area Networks (WLANs). The use of WiFi is justified by the need of providing internet access to people traveling in the vehicles, and the com-mon devices do not support the mentioned vehicular communication technologies. However, it is proven that WiFi is not suited to VANETs with significant mobility [5].

As mentioned, internet access using the cellular network is also broadly used in order to connect vehicles in VANETs. However, this is not the optimal solution as the prices per gigabyte of information is way higher in cellular than using one of the other mentioned technologies.

To use these technologies, vehicles are equipped with devices known as OBU. An OBU is an embedded device that provides the vehicle with the following equip-ment [13]:

• Processing Unit: performs all the communication and application tasks;

• Wireless transceivers: needed to access the networks of the different men-tioned technologies;

• GPS: provides vehicle location and time synchronization;

• Sensors: provide the ability to sense the world around the vehicle recording data that can be useful;

• Human-Machine Interface: interfaces that enable interaction between the OBU and the passengers or maintainers of the system.

An example of an OBU is presented in Figure 2.1 where it is possible to identify some of the components mentioned above.

(34)

Like vehicles have OBUs, then infrastructure has Road Side Unit (RSU) which are similar devices but provide services to the OBUs. Usually these devices are located in strategic points defined with methods like the one presented in [14].

Both OBUs and RSUs need a set of antennas connected in order to be able to propagate and receive the signals generated by each other.

Figure 2.1: OBU with connected antennas. 802.11p antenna, 802.11g antenna and GPS antenna, from left to right

2.2.3 Vehicular Network Architectures

It is possible to identify different network architectures regarding VANETs. The network architectures in the literature are the following:

• Hybrid: this is a non-centralized architecture since there is no central au-thority regulating communications. This architecture favors flexibility and distributed data flow being considered the most intelligent one;

• Pure cellular/WLAN: when using this architecture vehicles have to choose between a way to access the network, via cellular gateways or through Access Points (APs) using their WLAN interface;

(35)

• Pure ad-hoc: this option prioritizes the peer-to-peer communication among vehicles, meaning that, even if there are connection options available, the first one to be always chosen is the ad-hoc connection.

Figure 2.2: VANETs in the Intelligent Transport Systems environment [1]

A note must be made to state that along with Vehicle to Vehicle (V2V) commu-nications VANETs also include Vehicle to Infrastructure (V2I) and Infrastructure to Infrastructure (I2I) communications. Several examples of this categories of communication can be observed in Figure 2.2.

2.2.4 Technical Challenges

As mentioned before, there are three categories of applications for VANETs; however, the main technical challenges are associated with two of these categories: security and comfort applications [2].

Regarding the first category, the main issues that research community is fac-ing are related with MAC Layer, Message Dissemination, Clusterfac-ing and Power Assignment. Given the different nature of messages that need to be transmitted, some kind of prioritization and service differentiation must be in place, for example event driven messages should have higher priority then regular, periodic messages.

(36)

In order to achieve this MAC Layer development, efforts must be held aiming the standardization of a VANET dedicated MAC Layer. Dissemination of information is a matter of great importance in VANETs, since often vehicles need to commu-nicate with other vehicles or infrastructure that is outside its range. In this way, a set of protocols and architectures has to be developed and improved to get this done. Clustering techniques and algorithms are a big play in VANETs, as it is important to avoid flooding of messages in situations of densely populated road environments. Lastly, Power Assignment is also a concern as vehicles exchange messages with their neighbors. At some extent this issue relates with the last one, since transmission power rates can make a vehicle find more or less neighbors. For example, at a fixed transmission power rate, a vehicle will find few neighbors in a low traffic situation and an excessive amount of near vehicles if the traffic is high. On the comfort applications side, the main issues identified are related with the Carry and Forward/Routing mechanisms: Geographic Forwarding, Trajectory Forwarding and Opportunistic Forwarding. All these methods to forward messages across VANETs aim to reduce overhead and end-to-end delays during communi-cations using different approaches given different road scenarios.

(37)

It must also be referred that there are ongoing efforts regarding security matters in VANETs like authentication, privacy or secure positioning.

Another field of research in vehicular networks relates with the nodes mobil-ity. This is a key aspect in every vehicular networks given that vehicles are not static entities in the network environment, and as they move the network topology changes. This changes must, however, be seamless to the end-user (passengers in a bus for example). In order to achieve these seamless handovers, it is vital to guarantee that communications are not disrupted in the process and that the times these processes take are minimal and not perceived by the user.

The mobility protocols dealing with such requirements and environments must always achieve great performances given the increasing mobility level and dy-namism of the cities we live in. Moreover, these protocols must be able to provide mechanisms easily scalable, since the nodes in our networks have been increasing as never before.

These challenges are real concerns when developing solutions or deploying ve-hicular networks. This and a few more challenges are also presented in available literature such as [15][16].

Mobility Management is the scope of this work, and so, in the next sections several mobility management solutions are presented in order to give an overview of the so far developed work.

2.3 Mobility Classification and its Requirements

Since the main focus of this work is a distributed mobility management so-lution it is important, in a first approach, to understand the differences between distributed and centralized architectures and what are the main requirements for distributed mobility management solutions. Since the time when the first steps made in order to find mobility management solutions were taken, several protocols have been presented to the industry and the scientific community, being some of them standardized and nowadays well accepted by service providers.

However, despite all the differences between protocols, a few trends can be noticed when analyzing those protocols [17]: usually there is a central point in the network that provides reachability to the moving nodes and a continuous connec-tion experience to the end-user, protocols are improved with tailored extensions in

(38)

order to optimize handover performance, multihoming (the use of more than one interface to connect to multiple networks simultaneously) is a common concern when extending protocols with new components and functionalities. These trends present a great opportunity for improvement in the way network architectures are designed since they pose a relatively high security risk as there is only one point of attachment for multiple devices’s traffic and the processing power needed in order to support all the extensions when deploying a protocol tends to be difficult to manage [18][3].

The distributed solutions are in this context the answer for some of these issues, specially scalability and security concerns related to the single point of failure. In these solutions the management of the mobility process is performed the access points in the network, and so, a possible security breach affects less network nodes. In terms of scalability, most of the mobility solutions rely on tunneling to keep nodes reachable after moving between networks. This means that the more nodes we have connected to a management point of the network, the more power this point will need to deal with all the tunneling. When considering a distributed approach, the number of dependence is highly reduced, reducing also the processing.

The remaining of this section will be devoted in presenting both approaches to provide mobility support in networks: centralized and distributed. Since the objec-tive of this work is a distributed solution, the requirements to provide distributed mobility will also be addressed.

2.3.1 Centralized Mobility Management

The common feature among centralized mobility management solutions is the existence of a single mobility anchor that keeps the mapping information between the host identifier and its location. While doing this the central node of the network also has to route the packets to the appropriate hosts no matter where they are. In this solution the data and control plane are also centralized. Examples of centralized network architectures can be found in Figure 2.4 where a Mobile IP (MIP)/Proxy Mobile IP (PMIP) and a cellular network are presented.

(39)

HA / LMA

MN / MAG MN / MAG

P - GW

S - GW S - GW

MIP / PMIP 3GPP EPS

Figure 2.4: Centralized Mobility Management Architecture Examples (adapted from [3]

2.3.2 Distributed Mobility Management

In distributed mobility management solutions the mobility functions are spread through multiple networks (refer to Figure 2.5). This allows a host to obtain mo-bility services provided by a nearby network infrastructure. Distributed momo-bility management solutions can be fully or partially distributed depending whether both data and control plane are fully distributed. This class of mobility solu-tions approaches the trendy flat network design that has been disseminated in the networking researching community.

Mobile Node Mobility Enabled Router Mobility Enabled Router Mobility Enabled Router

Figure 2.5: Distributed Mobility Management Architecture Example (adapted from [3]

(40)

2.3.3 Distributed Mobility Management Requirements

Some problems related with the centralized models for mobility management were identified being the 5 most relevant listed as follows[3]:

• Non-optimal routing: the need to use a central network node that routes all the traffic usually leads to longer routes. This is very relevant when accessing locally available contents.

• Divergence from trends in network architectures: with the current trends pointing to flatter networks and service providers network offloading, central-ized mobility solutions and these trends tend to move in opposite directions.

• Low scalability: the increasing number of hosts requiring mobility support generates the need to maintain high volumes of tunneled traffic which can be very demanding.

• Single point of failure or attack: relying on a central node to perform most of the mobility related tasks makes the whole system more vulnerable to failures. Also a successful attack to the central node has a greater impact when compared with a distributed approach.

• Inefficient resources management: hosts do not always need mobility services as they tend to stay in the same network for long periods of time; however, a centralized mobility architecture keeps location records of all hosts all the time, thus providing always-on reachability.

When developing new distributed mobility management solutions, the devel-opers should always try to avoid the issues above mentioned. To do so, a set of requirements for distributed mobility management solutions have been proposed: processing must be distributed among the diverse entities that form the network following the current trends in network evolution; new works must provide trans-parency to upper layers in order to support application flows that cannot cope with a change of IP address; new approaches must target Internet Protocol ver-sion 6 (IPv6) since this is the IETF line of work; new solutions should consider using available protocols and extensions already accepted by IETF so they are

(41)

less error-prone; compatibility with already deployed networks must be guaran-teed, so older devices and networks can still operate; presented solutions must not introduce or enhance security risks.

2.4 Mobility Management Solutions

In a fast pace and dynamic world, as the one we live in nowadays, it is not rare that devices and end-users roam between networks more than once a day. In the particular case of vehicular networks this happens even more frequently as the nodes are constantly moving. However, the roaming between networks poses new challenges like the assignment of new addresses to the devices and the break of active sessions after the movement. In this section, it is presented an overview of some of the most significant efforts made with the objective of making possible the intra and inter network movement minimizing or even completely avoiding data losses and session breaks.

2.4.1 Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP) is a control protocol aimed to ease the es-tablishment, modification and termination of connection sessions, operating over different types of sessions such as multimedia or Internet telephony session [4]. Located at the Application Layer SIP is completely independent from the Trans-port Layer being able to operate over Transmission Control Protocol (TCP), User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP) [19]. SIP is not a complete communications system, so it is usual to find it associ-ated with other well established protocols like Session Description Protocol (SDP) for media identification, Real-time Transport Protocol (RTP) for media streams transmission, or Transport Layer Security (TLS) for secured transmissions. SIP’s multimedia communications control is based on five pillars [4]:

• User Location: getting the location of the network end-point used for com-munication;

• User Availability: determine whether the callee wants to engage in a com-munication;

(42)

• User Capability: recognize the media and media settings to be used through-out the communication;

• Session Setup: starts the session, sharing the communication settings be-tween the caller and callee;

• Session Management: transfer, parameter modification and termination of sessions and services.

The operation of SIP is similar to the Hypertext Transfer Protocol (HTTP) operation; however, note that SIP is not an extension of HTTP, given that it is based in the request/response transaction model. A typical session initiation in SIP is triggered when a network end-point formulates an INVITE request which is sent to a server. If there are any Proxy Servers in the way, the request may be forwarded to intermediate nodes before it gets to the destination (which can be more than one entity). The destination then replies accepting or denying the connection. During the session, the parameters agreed can be changed using the re-INVITE request. In order to finish a session, a BYE request is sent to the other end of the communication.

Invite F1 Invite F2 Invite F3 100 Trying F4 100 Trying F5 100 Trying F6 180 Ringing F7 180 Ringing F8 180 OK F9 180 OK F10 180 OK F11 ACK F12 Media Session Bye F13 200 OK F14

Phone 1 Proxy A Proxy B Phone 2

Figure 2.6: SIP Operation Example (adapted from [4])

Regarding mobility, SIP (Figure 2.6 presents an exemple) supports four types: terminal, personal, session and service mobility [20]. Terminal mobility is related with the movement of a device between Internet Protocol (IP) sub-nets still being able to be reachable for requests and maintaining sessions during the movement.

(43)

In order to achieve terminal mobility, SIP provides tools in three different phases of the communication: pre-call, mid-call and network partition recovery. Session mobility occurs when a user maintains its session while changing terminals. Using SIP session mobility can be provided using at least three methods. The first, and most simple, relies on the server to deal with the IP addresses and ports, and to send this information to both sides using INVITE messages. The second method, third-party call control, uses a third element in the network to manage the session. This method presents a disadvantage, since a third element must be in session all the time given that it has the responsibility to manage the session (modifications and termination). The last presented method is based on the transfer of the session to a new destination. To do this, the user willing to move, sends a REFER request to the other side of the session indicating the new location for the session. Personal mobility refers to the ability of a single user to be reachable in different terminals using the same logical identity. In order to provide this type of mobility, it is necessary to get available 1-to-n and m-to-1 address mappings which can be obtained using SIP forking proxies.

As a final remark, it is important to stress the ease of use of SIP, and that, although this protocol can provide mobility in environments where Internet tele-phony is the central service, it lacks support for other important services and so it must be combined with other protocols (in lower layers) such as Mobile IPv6 (MIPv6).

2.4.2 Mobile Internet Protocol (MIP), versions 4 and 6

MIP is a protocol proposed by IETF that allows transparent routing of IP datagrams independently of the node location [21]. The situation that MIP aims to address occurs when a user moves from its home network to another network, not being able to receive the incoming data on the previously used network. In order to solve this situation MIP relies on the use of two different IP addresses on the nodes, thus being able to maintain the TCP connections already started. MIP introduced new functional entities to the networking environment: the Mobile Node (MN), the Home Agent (HA) and the Foreign Agent (FA). The MN is the moving node on the network, the one looking for connection mobility. Although moving, the MN keeps one of the IP addresses fixed to which we call Home Address (HoA). The HA

(44)

is a router located in the MN’s Home Network (HN); it has the responsibility of tunneling the traffic between the HN and the Foreign Network (FN) - the network to which the MN roams - and of keeping the location of the MN. The FA is a router present in the FN that provides the MN with routing services and delivers the traffic sent by the HA to the MN. When the MN wants to send datagrams, the FA serves as the default router. Along with the new entities, MIP introduces also the concepts of HoA (already presented) and Care-of Address (CoA) which is the topologically correct address assigned to the MN when it reaches a FN.

The operation principle of MIP relies on support services provided by the protocol:

• Agent Discovery: when reaching a new network, the MN can send a solic-itation message in order to discover if there are any agents present in the network that can provide mobility;

• Registration: being in a FN, the MN needs to register its new CoA with the HA. This can be processed in two different ways: directly with the HA or using the FA as a proxy which forwards the registration to the HA;

• Tunneling: after the registration is done, the HA has the ability to forward the received datagrams, with MN as destination, to the FA using datagram tunneling.

Even though it was a breakthrough when launched, MIP in its initial version (Mobile IPv4 (MIPv4)) presented some drawbacks and flaws namely those in the security and Quality of Service (QoS) fields [22]. MIPv4 has a security issue because it is difficult to create coexistence between this protocol and the security solutions deployed in the market, since MIPv4 communications carry two different addresses from two different networks which is not acceptable by most firewall systems. Also MIPv4 creates Triangular Routes as part of its principle of operation which leads to non-symmetrical reachability in communications, thus losses in QoS. The solution for the presented problems was presented with MIPv6 which is based on core features of IPv6, such as larger addressing space, auto-configuration services, efficient routing and built-in security. One of the main advantages of MIPv6 over MIPv4 is the possibility to exclude the presence of the FA, once using IPv6, the address is obtained using the auto-configuration services.

(45)

Home Network Internet HA Visited Network Mobile Node Correspondent Node _{CN to MN tunnel}

Figure 2.7: MIPv6 Operation Example

MIPv6 introduces some new signaling messages related with Binding Manage-ment: Binding Update (BU), Binding Acknowledgement (BA), Binding Refresh Request (BRR) and Binding Error (BE).

The method of operation of MIPv6 is depicted in the Figure 2.7 and explained as follows:

• the MN discovers the agent and performs address auto-configuration in order to acquire a CoA;

• the MN proceeds with registration with its HA using a BU;

• the HA replies with a BA in order to validate the registration and then prepares the tunneling;

• the HA intercepts all packets destined for MN and forwards them using the previously created tunnel;

• everytime the MN moves all the previous steps repeat in order to maintain reachability.

In this protocol, mobility support is shared by the end-host and the network. In MIP the host is required to have mobility functionalities embedded in its IPv6 stack in order to be able to exchange the required signaling messages to obtain the

(46)

CoA and to report to its HA. The next sections present new approaches to relieve the MN from providing mobility support.

ok

2.4.3 Proxy Mobile Internet Protocol (PMIPv6)

The network based mobility is a different approach to provide mobility. PMIPv6 is one of the protocols in this set of network based mobility approaches [23]. The name of this protocol comes after one of its key aspects: the existence of a proxy mobility agent in the network that performs the signaling exchanges on behalf of the host. This way, the adoption of PMIPv6 does not imply any changes in the host’s system which represent added value for the protocol. Considering MIP for comparison purposes with this protocol, using a network-based approach presents the following advantages:

• Deployment: there is no need to modify the IPv6 stack of the host in order to support mobility, which allows a service provider to give this service to as many hosts as it wishes;

• Controllability: actuating only at the network level, it allows the service provider to control the network QoS and traffic rates;

• Performance: as the host does not take a role in the mobility process, less messages are exchanged and so the tunneling overhead is shortened.

The PMIPv6 introduced network entities and concepts that were not present in the MIP environment such as:

• Local Mobility Domain (LMD): a PMIPv6 enabled network;

• Local Mobility Anchor (LMA): a router that maintains the routes for each host connected to the LMD;

• Mobile Access Gateway (MAG): the first router after the host which acts on behalf of the hosts;

• Mobile Node Identifier (MN-ID): a unique identifier for the host (eg. the MAC address);

(47)

• Mobile Node Home Network Prefix (MN-HNP): the prefix that the LMA assigns to the host.

In order to understand how PMIPv6 works, it is important to stress that using this architecture, the LMA acts as the HA and that the messages and CoA are now proxied using the MAG for that effect. The MAG is then the network entity that is between the host and the network, and is the element that registers the host movement and tracks its location.

A movement operation using PMIPv6 follows the above described steps:

• after reaching a new LMD, the host attaches to a MAG that sends a Proxy Binding Update (PBU) to the LMA responsible for the mobility management in the LMD;

• the LMA processes the PBU and allows it to store the information, assign a home network prefix to the host and reply with a Proxy Binding Acknowledge (PBA). Moreover, the LMA also creates a tunnel to the MAG which will later be used to forward the incoming traffic destined to the host;

• upon receiving the PBA, the MAG creates a tunnel to the LMA - then forming a bidirectional tunnel - which will be used to forward the traffic created by the host. Also, the MAG sends a Router Advertisement (RA) to the host, so it can create its IP address using the MN-ID and the MN-HNP;

• when a packet is sent to the host and it reaches the LMA, this element makes a lookup on its rules and encapsulates the packet prior to send it to the appropriate MAG;

• the MAG receives the encapsulated packets from the LMA and forwards them to the respective host.

The steps above are always repeated for every movement that the host does, and can be followed with the help of Figure 2.8 that depicts the PMIPv6 architecture.

2.4.4 N-PMIPv6

Upon testing PMIPv6, it has become clear that new requirements to mobil-ity exist. Some new approaches were developed in order to extend the original

(48)

Figure 2.8: PMIPv6 Operation Example

protocol. Among these extensions, the most remarkable are Fast Proxy Mobile IP (FPMIP)[24]. FPMIP extension aims to provide global mobility support, since originally PMIP protocol was designed for localized mobility management.

Even with these extensions, the need to allow private subnets of a MAG to have mobility support exists. In PMIPv6 and its extensions, such support is not given: the MAGs must be fixed and directly connected to the LMA, not allow-ing the creation of MAG chains. In this context, several approaches for network mobility were proposed, such as NEMO [25], P-NEMO [26], and Network Proxy Mobile IPv6 (N-PMIPv6) [27], were proposed. The one chosen by a previous work from our research group, which lead to a Master’s Dissertation work, implemented N-PMIPv6 as an extension of PMIPv6 [5].

The N-PMIPv6 protocol aims to extend the PMIPv6 in order to enable it with the following capabilities:

• Provide mobility to the OBUs and its private networks;

• Extend the range of RSUs connection, using the chaining concept between OBUs in order to achieve multihop mobility.

(49)

These two objectives were achieved after modifications to the original PMIPv6, which included the addition of a new network entity named mobile MAG (mMAG) on the OBU side. This new entity corresponds to an extension of the already deployed MAG entity, which now should be able to: identify whether it is being used as a static node or a mMAG; identify the IPv6 address prefix to preform auto address configuration and get connected to the LMA; implement Router Solicitation (RS) filtering since it should not receive and process the self sent RSs messages.

Also the LMA must be able to identify mMAGs and connect to them through the creation of tunnels just the way it happens with the MAGs.

In Figure 2.9 it is possible to see a typical N-PMIPv6 scenario in which it is possible to observe a network movement and the chaining concept applied.

Figure 2.9: N-PMIPv6 typical scenario [5]

Figure 2.10 presents an handover situation which follows the next steps, ac-cording to [28][29]:

(50)

Figure 2.10: N-PMIPv6 Operation Representation [5]

1. When the MAG-1 detects the attachment of a mMAG, it sends a PBU message containing the mMAG-ID to the LMA;

2. The LMA using the PBU message information assigns a HNP (HNP-1 in the figure) to the mMAG creating a BCE. It then sends the PBA to MAG-1;

3. The MAG-1 can then send the RA message which includes the network prefix HNP-1 to be used by the mMAG;

4. After receiving the RA, the mMAG sends to the LMA the MNN-ID in a PBU message;

5. With the last message, the LMA assigns a new network prefix, HNP-2 to the MNN and creates a BCE but this time using the Mobility Flag which was added by N-PMIPv6 to the protocol. This flag indicates that the MNN is connected to a mobile network;

6. The mMAG receives a PBA from the LMA and sends the RA with HNP-2 to the MNN.

(51)

After the previous steps, it is possible to reach the MNN from the outside. The packets being sent to the MNN first pass in the LMA which tries to find the MNN’s BCE. Since it has the Mobility flag set, then it will search for the correspondent mMAG BCE. Then, the traffic is encapsulated twice: once to reach the MAG and again to reach the mMAG. This way the LMA sends the traffic to the MAG which removes the tunneling header and sends it to the mMAG, which in its turn recovers the original packet and delivers it to the MNN.

Although it accomplished the initial specifications, the N-PMIPv6 still is, from this work point of view, a protocol with flaws given that it creates a single point of failure as all the traffic must go through the LMA.

2.4.5 Locator/ID Separation Protocol (LISP)

With the strong growth of Internet in the last years, a new scalability problem arose in routing and multihoming aspects. The widespread IP networks nowadays used by everyone are based in an addressing scheme that uses a unique address as both a locator and an identifier of the host [30]. However, this scheme is not suitable for topology changes in the network given that the addresses are topologically assigned. The ”location/ID separation” is an issue of research for IETF and several universities and research groups for more than fifteen years [31]. Even with the advent of IPv6, this remained a problem since this new suite uses addresses the same way as its previous version, Internet Protocol version 4 (IPv4), it only has larger addresses.

Locator Identifier Separation Protocol (LISP) is a network architecture that gives a new meaning to the IP address, guaranteeing Location/ID Separation [32]. LISP functional core is the creation of two distinct namespaces and the use of two IP addresses: Endpoint Identifiers (EIDs), assigned to end-hosts, and Routing Locators (RLOCs), assigned to the routing system components. The LISP system is then responsible for the mapping between the two sets of addresses.

One of the key aspects of LISP is that hosts operate the same way they do without LISP, and so, this approach is transparent for the user. The EID, address assigned to hosts, is a topology independent address, and it does not change. It is used to track sockets and connections and to send and receive packets. Routers doing normal packet forwarding based on IP destination addresses is another of the

(52)

key aspects of LISP; however, there is an exception to be noted. LISP introduces, among others, two entities named Egress Tunnel Router (ETR) and Ingress Tunnel Router (ITR). These are routers present in LISP Sites, and do the processing of LISP-encapsulated IP packets in order to make them flow through the Internet. A typical LISP architecture also uses the following entities:

• EID-to-RLOC Database: is the database containing the mappings between each EID and its RLOC. Usually, a portion of this database is also stored in the ETR with the entries related to its LISP Site. Another aspect worth of note is that this database is globally accessible;

• Map-Server: is a network infrastructure element that learns the mapping entries sent by the ETRs and makes the EID-to-RLOC Database available;

• Map-Resolver: is the network component that receives the LISP encapsu-lated Map-Requests and makes queries to the EID-to-RLOC Databse.

Regarding LISP operation and considering that Host1 wants to communicate with Host2, a typical transaction would be performed as follows:

• Host1 does a DNS lookup on Host2 in order to get its record, and so it retrieves an address which is the EID of Host1;

• the packets are sent by Host1 and forwarded by routers inside the LISP site until they reach an ITR;

• the ITR must be able to get a mapping between the EID of the packets and the RLOC using the Map-Request control messages;

• the ITR adds a LISP header to the packets containing the RLOC, which represents the ETR of another LISP site;

• since the ETR knows where Host2 is, given its EID, it strips the LISP header and forwards the packets to Host2.

The steps above specified can be followed using Figure 2.11, which depicts the LISP architecture and operation.

(53)

Figure 2.11: LISP Architecture and Operation Example [6]

Concerning mobility, LISP does not support it by default; however, efforts were made in order to build an extension which gives mobility support using LISP [33]. This extension of the protocol, LISP-MN, developed by LISPmob, allows a host to have a fixed EID even when it roams to a different LISP site or non-LISP site. Also, the MN has the task of keeping its most recent RLOC and to inform the Mapping System of any changes using Map-Register messages, making it always accessible even outside its usual LISP site. This way LISP is able to provide ”Location/ID Separation” and mobility support at the same time.

2.4.6 Dynamic Mobile IP Anchoring (DMIPA)

Regarding distributed IP mobility management, several solutions have been presented over the time. These solutions are presented in two categories: network-based and host-network-based.

On the network-based category, some of the reference works presented include [34], which follows the conclusions that a centralized anchor inserts a performance decrease in the network and sub-optimal routing when compared with a distributed approach [35]. In this work, the author proposes the distribution of the mobil-ity management, separating data and control planes and positioning the mobilmobil-ity functions in the most appropriate locations. Another example of a network-based

(54)

approach is enhanced Proxy Mobile IP (ePMIP)[36]. This solution transforms the entities present in PMIP in elements which incorporate mobility functions, giving them the names of eLMA and eMAG. The mechanism used to provide mobility to the MNs is based on the properties of the assigned IPv6 address prefix properties upon the attachment of the MNs to the eMAG.

There are also some host-based solutions to provide mobility management. One of them is Distributed Mobile IPv6 (DMIPv6)[37], a MIPv6 compatible protocol, which introduces the use of Distributed Home Proxy (DHP) and Distributed Home Address (DHoA), while maintaining the older HAs and HoAs. This new approach allows a MN to use different DHPs for different data flows accordingly with the network status, this way reducing congestion and failure possibility in the HA.

Another host-based solution is DMIPA, a distributed mobility protocol for dynamic environments [7], being developed and tested at Instituto de Telecomu-nica¸c˜oes. This solution goes beyond the previous approaches in the way that it is a fully distributed solution while, for instance, DMIPv6 relies on a centralized HA when no DHPs are available. Also, DMIPA does not require the establishment of tunnels since the first MN attachment, but only after the first movement.

The key aspects of DMIPA are:

• Access Routers (ARs) with mobility are known as DMARs;

• New sessions are always anchored to the most recent Data Mobility Access Router (DMAR);

• Already present sessions remain anchored to the previous DMARs;

• When the MN roams, the forwarding of previous sessions is always guaran-teed by the connected router, unless it does not support mobility in which case the MN supplies this functionality;

• the MN itself keeps its mobility context.

The architecture and elements of DMIPA are presented in Figure 2.12.

Since DMIPA is the main object of this work, it will be further explained in Chapter 3.

(55)

IP Network IP Prefix P2::/64 IP Prefix P3::/64 IP Prefix P1::/64 DMAR1 AR DMAR2 CN IPv6 Addr: P1::MN/64 DMARs: P1::DMAR1/64 IPv6 Addr: P1::MN/64 P2::MN/64 DMARs: P1::DMAR1/64 IPv6 Addr: P1::MN/64 P3::MN/64 DMARs: P1::DMAR1/64 P3::DMAR2/64 MN Tun 1 Tun 2

Figure 3.3: DMIPA Architecture Overview.

The BU and BA messages have the functions of updating the binding caches of DMARs and to create bi-directional tunnels between two DMARs or between a DMAR and a MN. The RS and RA messages have the same purpose as described earlier. However, DMIPA introduces a Mobility Support Flag (MSF) in the Reserved field of the RA message in order to provide useful information about if it is a DMAR or an AR. If the MSF flag is set to zero, then it is a legacy AR; otherwise MSF is equal to one indicating that it is a DMAR. Moreover, it is added two messages that are exchanged when MN and current DMAR communicate with each other: Anchor Set Update (ASU) and Anchor Set Acknowledgement (ASA). The MN sends the ASU message providing its attached DMAR with the IPv6 addresses of the current set of DMARs. The ASA is sent by the DMAR as a reply to the ASU message. This message indicates the success of the process.

DMIPA works as follows:

1) DMAR1: the MN attaches to DMAR1.

2) RS/RA: initially MN requests the network prefix by sending a RS message. Then, DMAR1 replies with a RA message which contains the network prefix P1::/64 and a true MSF value.

3) Configure P1::MN/64: after receiving the RA, the MN configures the IPv6 address P1::MN/64 as a preferred address.

4) Add P1::DMAR1/64: MN adds the IPv6 address of DMAR1 to the database that contains the available DMARs set.

5) Session 1: MN initiates data session 1 using P1::MN/64 as IPv6 source address. 6) AR: the MN attaches to a legacy AR.

33

Figure 2.12: DMIPA Architecture and Elements [7]

2.5 Chapter Remarks

This first chapter presented topics related with the advances already done with focus on the subject of this dissertation: mobility in vehicular networks. Features of VANETs, architecture and technologies involved in a vehicular network deploy-ment were reviewed to give insight into the vehicular networks world paradigm. Then, two approaches to provide mobility were discussed: centralized and dis-tributed approaches.

Along with the importance of having tests made with vehicular network access technology, namely IEEE 802.11p WAVE, it is also important to understand the mobility protocols existent in order to better conceive and implement new solu-tions pursuing high performance handovers guaranteeing session continuity, thus VANET’s end-users mobility. This line of thought justifies the description of main features and principles of operation of the presented mobility protocols. The next chapter focus will be on DMIPA, the already introduced mobility management protocol that will be developed in this Thesis.

(56)

(57)

Chapter 3 DMIPA: a distributed approach

to mobility

DMIPA[7] is a host-based distributed mobility management scheme thought for flat and heterogeneous network architectures. This approach is intended for scenarios where the Correspondent Node (CN) does not have mobility support, since it can be any node of any network, and so the mobility management features of DMIPA are distributed through the MNs and their points of attachment, the ARs. One of the main advantages of this solution for the mobility management problem is the ability to provide global mobility to the MN, even if some nodes of the network do not support mobility. In order to accomplish this, DMIPA relies on a dynamic anchoring strategy, allowing a session to be anchored to any of the ARs with mobility support available.

Being this a distributed mobility scheme, the functionalities that DMIPA in-troduces are not centered on the same entity, and so are distributed through the different entities present in a typical DMIPA scenario: the DMARs manage the IP data anchoring, leaving the mobility context management to the MNs.

3.1 DMIPA Functionalities and Features

DMIPA addresses the session continuity issue of ongoing sessions when a han-dover is performed to a new IP network. In order to achieve this, the protocol specifies its functionality divided in two parts [38]:

(58)

• IP data anchoring: the data sessions are associated with a mobility anchor which is responsible to forward these sessions to the roaming node using IP tunneling techniques;

• IP mobility context management: each roaming node, or MN, is held respon-sible to maintain and update a list of its previous addresses and connected access points in order to keep an always up to date mobility context.

These two functionalities combined with the distribution of responsibilities by the nodes present in the network create an opportunity for DMIPA to tackle some of the issues found in other presented mobility protocols.

One of the most important of these issues is scalability. Being the majority of mobility protocols classified as centralized mobility management protocols they rely on a central node to keep track of the mobility context and data flows. This central node is held responsible for the maintenance of a potentially large number of data sessions which is increasingly heavy regarding processing. Furthermore, in the event of a failure it can shut a whole network down. When using a distributed approach there is no single point of failure, given that the mobility support is spread around the network as is the processing power needed to keep the network behaving as expected.

Another aspect worth mentioning is the legacy support of already deployed hardware. DMIPA aims to provide support for legacy network nodes, given that a handover from a mobility-enabled access point to a regular access point (without mobility support) is described in the DMIPA protocol. In this case, the MN keeps the previously used mobility context in order to guarantee session continuity.

3.2 Architecture Overview

A typical deployment scenario of DMIPA is the one mainly composed by the following main entities:

• MN: the Internet-connected device whose location and point of entry to the Internet frequently changes. Unlike the centralized approach of mobility management, in DMIPA the MN has an important role in the continuity of sessions during a network roaming;

(59)

• DMAR: an AR which has mobility features embedded.

In Figure 3.1 these two entities are presented in their place inside the DMIPA’s architecture along with a representation of the anchoring mechanism used by this protocol. In such representation it is possible to observe that the mobile node must maintain all the used IPv6 addresses even when roaming across networks in order to keep reachable by the CNs.

DMAR 1 DMAR 2 AR CN 1 CN 2 Internet MN MN MN IPv6 Addresses: P1:MN/64 . DMARs: P1:DMAR/64 IPv6 Addresses: P1:MN/64 P2:MN/64 . DMARs: P1:DMAR/64 IPv6 Addresses: P1:MN/64 P2:MN/64 P3:MN/64 . DMARs: P1:DMAR/64 P3:MN/64 P1::/64 P2::/64 P3::/64

Figure 3.1: DMIPA Architecture [7]

As mentioned before, the MNs take an important role in the protocol since the mobility process is triggered by them. If the MN finds a near DMAR it will use this DMAR in order to offload all the processing, allowing the DMAR to take care of the mobility process. Otherwise, if the MN connects to an AR it has to be able to deal with the mobility process. Furthermore, the MN has the responsibility of choosing the anchor of a session. The selection of the anchor is of great importance when considering a dynamic scenario where there is a mix of DMARs and ARs. Every time the MN gets a new prefix from a DMAR, it sets this prefix as the preferred anchor for new sessions. If the MN gets connected to an AR the previous DMAR remains as the preferred anchor.

(60)

3.3 Protocol Operation

Figure 3.2: DMIPA Operation [7]

With the development of MIPv6, two new types of messages were defined, which are the BU and BA [39], being also used by DMIPA. The functions of these two messages are to update the binding database of DMARs and to establish bi-directional tunnels between DMARs or between a DMAR and a MN. Tunneling is a key aspect of DMIPA as it allows two nodes to communicate while abstracting themselves from the network devices that are between them.

With IPv6 it was introduced the concept of Stateless Autoconfiguration Mode which relies on the RS and RA messages [40]. These two types of messages allow a new node in the network to find the router which will be held responsible for routing its generated traffic. The discovery process occurs in one of two ways: the router replies to an RS with an RA or the new node waits to receive one of the periodically sent RAs. The first method, being an active mechanism, provides

Wireless distributed mobility management on a road scenario

Jo˜

ao Pedro

Coelho de Azevedo

Wireless Distributed Mobility Management on a

Road Scenario

Mobilidade Distribu´ıda em Hotspots num Ambiente

de Estrada

Jo˜

ao Pedro

Coelho de Azevedo

Wireless Distributed Mobility Management on a

Road Scenario

Mobilidade Distribu´ıda em Hotspots num Ambiente

de Estrada

Contents

List of Figures

List of Tables

Abbreviations

Chapter 1

Introduction

1.1

Motivation

1.2

Objectives and Contributions

1.3

Document Organization

Chapter 2

State of the Art

2.1

Introduction

2.2

Vehicular Ad-hoc Networks

2.2.1

Characteristics of Vehicular Networks

2.2.2

Network Access Technologies and Equipment

2.2.3

Vehicular Network Architectures

2.2.4

Technical Challenges

2.3

Mobility Classification and its Requirements

2.3.1

Centralized Mobility Management

2.3.2

Distributed Mobility Management

2.3.3

Distributed Mobility Management Requirements

2.4

Mobility Management Solutions

2.4.1

Session Initiation Protocol (SIP)

2.4.2

Mobile Internet Protocol (MIP), versions 4 and 6

2.4.3

Proxy Mobile Internet Protocol (PMIPv6)

2.4.4

N-PMIPv6

2.4.5

Locator/ID Separation Protocol (LISP)

2.4.6

Dynamic Mobile IP Anchoring (DMIPA)

2.5

Chapter Remarks

Chapter 3

DMIPA: a distributed approach

to mobility

3.1

DMIPA Functionalities and Features

3.2

Architecture Overview

3.3

Protocol Operation