Présentée Par

Hassan Ali Ahmad

Professeur M César Viho

Mlle Lila Boukhatem

M Tarik Taleb

Design and Analysis of Distributed Mobility Management in IPv6 Mobile Networks

Keywords: Distributed Mobility Management, Dynamic Mobility Management, IPv6, MIPv6, PMIPv6, SIP, Protocol Design, Performance Analysis, Mobile Networks, Network Architecture

Current network architectures, as well as mobility management protocols, are generally deployed in a centralized manner. All the data traffic passes through a single centralized entity, and all the users' bindings are managed at this entity as well. As the number of mobile users and the volume of their traffic increase, such centralized architectures are expected to encounter scalability issues as well as performance issues. Moreover, these protocols are designed to be always activated, managing all the services and all the traffic in the same way. They do not take into consideration that a given mobile user may not move during the use of a service or that a service may not require mobility functions at all. Such approaches may thus lead to non-optimal routing and large overhead due to tunneling mechanisms.

Recently, mobile network operators are experiencing a rapid increase in mobile data traffic. In order to cope with this, a new trend is to flatten networks architectures and hence IP mobility management protocols need to be adapted for such evolution. Therefore, there is a need to define novel mobility management mechanisms that are both distributed and offered dynamically. They should be distributed in order to avoid any network bottleneck or single point of failure, and to provide better reliability. They should be activated and deactivated dynamically as needed, in order to globally reduce the network resources consumption and to increase the achieved performances.

In order to cope with this context, the thesis concerns designing, analyzing, and evaluating novel IPv6 network architectures and mobility protocols that are distributed and dynamic, and in particular distributed mobility management (DMM). First, we present the different architectures of mobile data networks as well as existing mobility protocols. We then extract the DMM problem statement and present the DMM history, discussing the related work. Before proposing any extension, we categorize the existing mobility schemes into global and local mobility management and carry out a comparative analysis on each category. We then draw out conclusions and perspectives, paving the way towards proposing enhancements or even a new scheme. After defining a use-case scenario and identifying our requirements and objectives, we propose a new distributed dynamic mobility management scheme. The proposed scheme is mainly based on the mobile IPv6 (MIPv6) protocol, with an optional extension for the joint use with the session initiation protocol (SIP). The proposed scheme operations are detailed in different scenarios. In order to evaluate the proposed scheme, we carry out a qualitative analysis as well as a quantitative analysis in terms of mobility costs, handover, and quality-of-service. After assuring the benefits of the proposed scheme, we study its impacts on other aspects such as security considerations and location management, proposing a solution track for each.

Recently, mobile network operators are experiencing a rapid increase in mobile data traffic. Operators' statistics show that 2012 has seen more mobile data traffic than all the preceding years combined [START_REF]The Mobile Economy 2013[END_REF]. Between 2012 and 2013, they show that the voice traffic has increased only two percent but the data traffic has doubled on mobile networks [START_REF]The Mobile Economy 2013[END_REF][START_REF]Mobile Economy Europe 2013[END_REF][START_REF]GSMA Intelligence (collected data directly from the mobile networks operators)[END_REF][START_REF] Ericsson | Ericsson Mobility Report[END_REF]. Nowadays, high-speed mobile data networks, such as 4G, are widely deployed all around the world. Mobile users can enjoy high data rate transmission. This stimulates the usage of smart phones and thus generates a dramatic increase of the load on mobile networks. A typical mobile PC is expected to generate 11GB, a tablet 3.1GB, and a smartphone around 2GB per month by the end of 2018 [START_REF] Ericsson | Ericsson Mobility Report[END_REF]. Not only the data traffic of current users is increasing, but also the number of subscriptions and users [START_REF]The Mobile Economy 2013[END_REF][START_REF]Mobile Economy Europe 2013[END_REF][START_REF]GSMA Intelligence (collected data directly from the mobile networks operators)[END_REF][START_REF] Ericsson | Ericsson Mobility Report[END_REF].

As a result, mobile network operators are expecting an explosion in mobile data traffic [START_REF]The Mobile Economy 2013[END_REF][START_REF] Ericsson | Ericsson Mobility Report[END_REF][START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF]. They are therefore performing various efforts to tackle such challenge, especially at the standardization organizations. Several new technologies and practices are showing up as hot topics. Fixed-mobile network convergence, mobile data offloading, decentralized network architecture, software-defined networks, cloud computing, and many others are ongoing attempts to cope with the challenge of the new era of mobile data networks.

In this context, the telecommunications operator Orange [START_REF]The telecommunications operator Orange (France Telecom formerly[END_REF] initiated in 2008 several projects that consider distributed mobility management (DMM). Orange efforts resulted in a proposal called dynamic mobility anchoring (DMA) [START_REF] Bertin | A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures[END_REF][START_REF] Bertin | Distributed or Centralized Mobility?[END_REF][START_REF] Bertin | An Evaluation of Dynamic Mobility Anchoring[END_REF]. DMA was not based on the IETF [10] mobility protocols.

In 2010, Orange and others pushed the topic to the IETF for discussion. The topic gained interest from various telecommunications industry and academic institutes. At IETF, it was required to extend the IETF mobility protocols, such as mobile IPv6 (MIPv6) [START_REF]IETF RFC 3775[END_REF] or proxy mobile IPv6 (PMIPv6) [START_REF]IETF RFC 5213[END_REF], rather than to propose a new one. Therefore, Orange attempted [START_REF] Seite | Dynamic Mobility Anchoring[END_REF][START_REF] Seite | Distributed Mobility Anchoring[END_REF] to adapt DMA to appear as an extension of one of the IETF mobility protocols, the PMIPv6 protocol.

However, the desire to design a DMM protocol that is based on existing mobility protocols was not satisfied. For this reason, Orange Labs in collaboration with Telecom Bretagne proposed at that time in October 2010 this PhD thesis to achieve this goal. This PhD was carried out in Orange Labs under an industrial contract for research (called CIFRE).

Beside contributing to the Orange internal project LETSMOVE, I contributed through this PhD to the European projects MEVICO [START_REF]Mobile Networks Evolution for Individual Communications Experience (MEVICO) Project[END_REF] and CROWD [START_REF]Connectivity management for eneRgy Optimised Wireless Dense networks (CROWD) Project[END_REF] (and their deliverables), to the IETF standardization (DMM working group), as well as to several industrial and academic collaborations such as with Intel Corporation, Samsung, and University of Aveiro. In addition, I published several International publications and submitted a patent application.

In short, this PhD thesis concerns designing, analyzing, and evaluating novel network architectures and mobility protocols that are both distributed and dynamic.

The thesis is divided into three parts as follows.

Part I

In Chapter 1, we review carefully the different architectures of the existing mobile data networks, including the 3GPP [START_REF]3rd Generation Partnership Project, 3GPP[END_REF] (from the general packet radio service (GPRS) to the evolved packet system (EPS)), 3GPP2 [START_REF][END_REF] and mobile WiMAX [19] architectures. We also go over the current practices of the existing IP mobility protocols, namely mobile IPv6 (MIPv6) and proxy mobile IPv6 (PMIPv6). In general, these architectures and protocols are deployed in a hierarchical and centralized manner. Moreover, they are designed to be always activated, regardless of the mobility and service contexts. Besides, we consider mobility support at upper layers through the session initiation protocol (SIP) [START_REF]SIP: Session Initiation Protocol[END_REF][START_REF] Schulzrinne | Application-layer mobility using SIP[END_REF] since it performs in a very different manner, that is end-to-end. Throughout all of these reviews, we extract the distributed dynamic mobility management (DMM) problem statement. Instead of being centralized, mobility management should be distributed in order to avoid any network bottleneck or single point of failure. Instead of being always-activated, mobility management should be dynamically activated and deactivated in order to reduce network resources consumption and to achieve better performance. As DMM is addressed at the the IETF (since 2010, when this thesis started) and then chartered as a working group, we present its history there. We also present and discuss the advantages and shortages of the most relevant work to our study, that is the dynamic mobility anchoring (DMA) scheme. DMA is a mobility management scheme that is, to an extent, based on PMIPv6 but relies on a distributed architecture.

The main contributions of this chapter are twofold. The first is to review thoroughly of the existing network architectures and mobility protocols. The second is to extract the DMM problem statement.

Part II

Since it is required to extend the existing mobility schemes, we aim in this part at investigating thoroughly the strong and weak points of each scheme. We consider this as an essential step before proposing any extension. In order to achieve this, we define an analysis framework, we categorize the schemes, and then we carry out a comparative analysis for each category. This part is partially published in [P1, P4, P6].

In Chapter 2, we develop an analytical framework for protocols modeling and analysis. In addition, we define a variety of analysis criteria that can examine thoroughly the mobility protocols. We define the cost analysis metrics in order to analyze the network resources consumption. We also define the handover and quality-of-service analysis metrics in order to examine both control and data planes performances.

Compared to the related studies in the literature, the main contributions are the following. The first is to develop analytically all the protocol aspects (e.g. refreshing rate) as well as the DMM-related aspects (e.g. new vs. handover traffic) that are not addressed before. The second is to define various analysis criteria that can investigate any mobility protocol aspects from several points of view. The third is to develop for each analysis metric a general analytical expression that can be applied to any mobility protocol.

At this stage, we consider the cost analysis as the priority since our main concern is the increase in mobile data traffic. We carry out two comparative cost analyses as follows.

The main contributions of these two analyses are the conclusions and perspectives that we draw out after each analysis. Through these conclusions, we pave the way towards proposing enhancements or even a novel scheme. For instance, we demonstrate the benefits of the joint use of IP mobility and SIP. We also mention the interest in considering scenarios where the other communicating user is mobility-unaware. Moreover, we examine the expected advantages of distributed architectures, on both control and data planes aspects.

Part III

After investigating the existing mobility schemes, we conclude their shortages and propose a novel one. We then analyze its performance and study its impacts on other networking aspects. Through some of the results of this part, we have contributed to [P2, P3, P5, P7, P8, P9, D1, D2, I1, I2].

In Chapter 5, we propose a novel distributed dynamic mobility management scheme. The proposed scheme is mainly based on the MIPv6 protocol, called distributed dynamic MIPv6 (DDM), with an optional extension for the joint use with SIP, called joint DDM-SIP (JDS).

After illustrating a use-case scenario, we define our requirements and objectives, considering the conclusions of all the previous analyses. Based on the requirements, we define the two concepts of the proposed scheme: distributed mobility management and dynamic mobility management. The former can be achieved by confining the mobility support and distributing the mobility anchoring functions at the access routers level, keeping the rest of the network unaware of the mobility events and their support. The latter can be accomplished by activating the IP mobility support only when needed, i.e., when both the mobile user actually undergoes an IP handover and the applicative service needs the mobility support as well.

In addition to proposing a new mobility scheme, the main contributions are the following. i) DDM supports both local and global mobility scenarios. The mobile user can move not only within its operational domain but also between different operational domains and access networks. This gains interest as the future wireless and mobile Internet is expected to be composed of several access networks. ii) Moreover, DDM considers both scenarios of full and partial deployment of the mobility functions at the access routers. The mobile network operator may opt to deploy the mobility functions either at each access router or at some of them only. This feature allows a tradeoff between the targeted performance and deployment monetary cost. It also eases the architecture migration phase, allowing a step-by-step migration. iii) Besides, we introduce the optional joint use of DDM and SIP, JDS. In JDS, SIP supports mobility for the SIP-based sessions and DDM for the other sessions. The motivation behind such joint use is to reduce further the overhead and achieve better performance if possible, noting that SIP is an end-to-end protocol that does not rely on anchoring or tunneling mechanisms.

After proposing a new scheme, it is essential to analyze and evaluate it in comparison with other protocols and proposals. It is also essential to study its impacts on other networking aspects.

In Chapter 6, we carry out a qualitative analysis and a quantitative analysis. Beside DDM, we consider DMA, MIPv6, PMIPv6, and SIP. The qualitative analysis studies the main characteristics and impacts of the different schemes. It also discusses the main benefits of DDM versus the main relevant schemes, MIPv6 and DMA. The quantitative analysis includes a cost analysis, a handover analysis, and a quality-of-service analysis. We investigate the impact of many parameters on the different analyses metrics. As a result, all the performance evaluations encourage towards adapting the proposed scheme. We show that DDM reduces significantly the mobility costs and hence the network resources consumption. We also show that DDM reduces significantly the handover latency and end-to-end delay, providing better performance and quality-ofservice to the end user.

In Chapter 7, we present two complementary studies that are accomplished in order to complete and perfect the proposed scheme. The first concerns the security considerations. We study both the link-layer and binding-related security aspects. We then propose the use of some existing protocols and mechanisms to overcome the identified issues. The second concerns the location management for reachability support. We study the possibility of reachability support at the IP layer through MIPv6 as well as at the application layer through SIP. We then introduce the concept of location areas to SIP in order to reduce the location updates loads at the SIP servers. We compare, through performance analysis, those loads between the default mode of SIP and the proposed one.

Part I

State of the Art and Mobility Protocols

In this chapter, we present the different mobile data networks architectures as well as the different mobility protocols. Through the evolution of these architectures, we then introduce the need for distributed mobility management (DMM). We present the DMM problem statement, its history and current status at the Internet engineering task force (IETF) [10], as well as the related work.

Mobile Data Networks

After being designed for voice communications, mobile networks are nowadays utilized more for data services. Although voice is still one of the crucial services from users' standpoint, it is seen as one of the plenty data services from the perspective of mobile network operators. Voice traffic is even foreseen to form a small percentage of total traffic and to consume network resource much less than e.g. video traffic. It is hence the mobile data era and mobile network operators are concerned more and more about the mobile data traffic.

In this section, we present an overview of mobile data networks, including the 3rd generation partnership project (3GPP) [START_REF]3rd Generation Partnership Project, 3GPP[END_REF], the 3rd generation partnership project 2 (3GPP2) [START_REF][END_REF], and the worldwide interoperability for microwave access (WiMAX) [19] mobile networks, as well as their evolution from an architecture point of view.

3GPP mobile networks

Architecture evolution

After the initial design of global system for mobile communications (GSM, also called 2G) as a circuit-switched network in early 1990s, packet-switched extensions started to appear in late 1990s. The general packet radio service (GPRS, also called 2.5G) enhanced GSM by enabling mobile users to access the Internet. Afterwards, in early 2000s , the universal mobile telecommunications system (UMTS, also called 3G) inherited the GPRS architecture and combined the properties of the circuit-switched voice network and the packet-switched data network, offering more possibilities compared to its predecessors. Then, the high speed packet access (HSPA, also called 3G+) extended UMTS, improving its performance. Later, with the unprecedented interest in mobile Internet, the evolved packet system (EPS) showed up, providing a pure packet-switched and all-IP network.

Although there are much more features to compare between these different systems, we are interested in discussing the evolution in their architectures. We focus then on EPS since it is the most recent system and its deployment is ongoing. 3 illustrate the GPRS, UMTS, and EPS networks architectures [START_REF]Network architecture[END_REF], respectively. The architectures of GPRS and UMTS are very similar to the extent that they are sometimes referred to as 2G-GPRS and 3G-GPRS, respectively. Their radio access network (RAN) is composed of two types of entities that act as base station and controller. Their packet core network is composed of three types of entities, the serving GPRS support node (SGSN), the gateway GPRS support node (GGSN), and the home location registrar (HLR).

Both SGSN and GGSN perform both data plane and control plane duties. The SGSN is responsible for authentication, authorization, and mobility management signaling. It is also responsible for data packets forwarding, being the first entity to see the IP data packets in the uplink and the last one in the downlink. The GGSN handles session initiation, handover, and session tear-down signaling from the SGSN. It is the topological anchor point of the mobility management, i.e. the topological point of attachment of the user's IP prefix that is stable while moving. It is the gateway that is responsible for the routing from and to the external IP-networks such as the Internet.

On the other hand, the EPS [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA)[END_REF][START_REF]General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[END_REF][START_REF]Architecture enhancements for non-3GPP accesses[END_REF] introduces several modifications compared to GPRS and UMTS. It turns the network to all-IP, reduces the hierarchy levels, and separates the data and control planes to a certain extent. Hereafter we describe the EPS architecture in more details.

Evolved Packet System (EPS)

The access network in EPS is called evolved universal terrestrial radio access network (E-UTRAN) [START_REF]Evolved Universal Terrestrial Radio Access (E-UTRA)[END_REF]. It is also referred to as long term evolution (LTE) access network. It is composed of a unique type of entities, namely the evolved node B (eNodeB). The eNodeB is the base station that offers the radio connectivity.

On the other hand, the core network in EPS is called evolved packet core (EPC) [START_REF]General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[END_REF]. The EPC supports not only the LTE access network but also other types of 3GPP and non-3GPP access networks. The EPC is composed of four types of entities as follows.

• serving gateway (SGW);

• packet data network gateway (PGW);

• mobility management entity (MME);

• home subscriber server (HSS). The gateways (SGW and PGW) deal with the data plane. They transport the IP data traffic between the user, referred to as user equipment (UE) in EPS, and the external networks.

The SGW is the point of interconnection between the LTE radio-side and the EPC. As its name indicates, this gateway serves the user by routing the incoming and outgoing IP packets. It is logically connected to the other gateway, the PGW.

The PGW is the point of interconnection between the EPC and the external IP networks. These networks are called packet data networks (PDN), such as the Internet and the IP multimedia subsystem (IMS) [START_REF]IP Multimedia Subsystem (IMS)[END_REF]. The PGW routes packets to and from the packet data networks. The PGW also performs various functions such as IP address/prefix allocation or policy control and charging.

The MME deals with the control plane. It handles the signaling related to mobility and security for E-UTRAN access. The MME is responsible for the tracking and the paging of the user in idle mode.

The HSS is a database that contains user-related and subscriber-related information.

Mobility management in 3GPP networks

Basically, 3GPP mobile networks rely on the GPRS tunneling protocol (GTP) [START_REF]GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface[END_REF][START_REF]General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)[END_REF][START_REF]3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)[END_REF] for mobility management. EPS allows also the partial usage of proxy mobile IPv6 (PMIPv6) beside GTP [START_REF]General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[END_REF][START_REF]Architecture enhancements for non-3GPP accesses[END_REF]. PMIPv6 is described and discussed in Section 1.2.

As its name sounds, GTP is a tunneling protocol that allows the transportation of different networking protocols over the 3GPP core network. Its basic functionality is to uniquely identify the tunnel to which the user IP packets belong. It carries the user IP packets and manages the data plane. It also carries specific signaling traffic between various network entities.

GTP is sometimes considered as a group of communications protocols since it can be decomposed into GTP control plane (GTP-C) and GTP user/data plane (GTP-U) as follows. GTP-C is in charge of creating, modifying (such as adjusting quality of service parameters), and deleting tunnels for the user sessions. It also permits to handle user mobility within the access network. GTP-U encapsulates the user IP packets when passing from the radio access network to the core network and also through the core network.

As GTP establishes different tunnels between the network entities, each tunnel is identified by a tunnel endpoint identifier (TEID). Based on TEID, the network is able to choose the appropriate GTP tunnels to transfer the IP packets between the user and the packet data networks. When the user moves from one eNodeB to another eNodeB, it may stay in the scope of the same SGW and MME, same MME but different SGW, same SGW but different MME, or different SGW and MME. Depending on the mobility scenario, the relocation of one or more GTP tunnels is needed. Fig. 1.5 and Fig. 1. [START_REF]The telecommunications operator Orange (France Telecom formerly[END_REF] shows two examples on the intra-SGW intra-MME and inter-SGW intra-MME handover scenarios, respectively. In the first, only the GTP-U tunnel on SGW-eNodeB is relocated since the user is still in the scope of the same SGW and MME. This mobility is transparent to the PGW. In the second, all the GTP-U and GTP-C tunnels are relocated since the user changes the SGW. The old SGW-eNodeB GTP-U tunnel is torn down and a new one is established between the new SGW and new eNodeB of the user. The new SGW is selected by the MME. It is worth mentioning that during the handover, packet forwarding from the previous eNodeB to the new eNodeB may be done directly or through the SGW(s).

Note that GTP mobility management is a network-based approach. When the user undergoes a handover, GTP tunnel(s) relocation between the network entities is handled by the network. The user does not participate in the mobility-related signaling.

GTP tunnels can be established only between the 3GPP network entities. GTP mobility management is restricted to the 3GPP domain, i.e. when the user is in the scope of 3GPP networks such as intra-EPS mobility and inter-3GPP mobility.

Mobility management hierarchy in 3GPP networks

As it appears from the two handover scenarios described above, when the user move far enough from the initial point of attachment, the handover has to be performed between higher level network entities. The only network entity that does not change during a session is the network anchor point, i.e. the GGSN in GPRS/UMTS/HSPA and the PGW in EPS. These levels of mobility management create a hierarchy. This hierarchy appears also in the number of network entities in a deployed network. Fig. 1.7 illustrates the mobility management hierarchy in 3GPP networks architectures. The levels of hierarchy are depicted from top to bottom, where the anchor point is at the top and the base stations are at the bottom. The user would be in the bottom of the view moving horizontally.

Therefore, the 3GPP standardization organization attempted to reduce the levels of hierarchy in 3GPP architectures. For instance, HSPA Release 7 introduces new options in order to reduce the levels of hierarchy [START_REF]High Speed Packet Access (HSPA) evolution[END_REF][START_REF]One Tunnel Functional description[END_REF]. The first is to bypass the SGSN in the data plane and to establish direct tunnel between the radio network controller (RNC) and GGSN. In the second, the RNC can be bypassed also in order to establish direct tunnel between the NodeB and GGSN. Fig. 1.8 and Fig. 1.9 illustrate these options.

In EPS, the SGW and the PGW are specified independently but in practice they may be combined in a single entity [START_REF]General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[END_REF] by network vendors. This entity is then referred to as the system architecture evolution (SAE) gateway (SAE-GW). In fact, it is the case in ongoing deployments. Fig. 1.10 illustrates this case.

Finally, it is worth mentioning that there are ongoing studies on the deployment of IPv6 in 3GPP mobile networks, particularly in EPS [START_REF]IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)[END_REF][START_REF] Korhonen | IPv6 for 3GPP Cellular Hosts[END_REF][START_REF] Korhonen | Deploying IPv6 in 3GPP Networks: Evolving Mobile Broadband from 2G to LTE and Beyond[END_REF]. This encourages towards specifying new IPv6 mobility protocols for 3GPP EPS that are not hierarchical.

3GPP2 mobile networks

The 3rd Generation Partnership Project 2 (3GPP2) [START_REF][END_REF] is a collaboration aimed at developing globally applicable specifications for third generation (3G) mobile systems.

In practice, 3GPP2 is the standardization group for CDMA2000 which relies on the code division multiple access (CDMA) technology.

As a general philosophy behind the design of the 3GPP2 architecture, the IETF protocols are employed whenever possible [START_REF]Version 1.0.0[END_REF]. This is in order to minimize the number of new protocols required and to maximize the utilization of well accepted standards and hence the speed to market. Fig. 1.11 illustrates the network architecture of 3GPP2 mobile network architecture [START_REF]-E[END_REF].

The radio access network (RAN) is composed of two functions, namely the radio resources control (RRC) and the packet control function (PCF). The former is responsible for radio resources and the latter for layer 2 connection.

On the other hand, the packet data serving node (PDSN) is responsible for establishing, maintaining, and terminating the point-to-point protocol (PPP) [START_REF]The Point-to-Point Protocol (PPP)[END_REF] to the mobile station. The PDSN can be considered as the mobile station's point of attachment.

For security, the architecture relies on a remote authentication dial in user service (RADIUS) server which provides authentication, authorization, accounting (AAA) management for the mobile stations.

To support IP mobility, the PDSN is connected, through an IP network, to the home agent (HA). The home agent is defined by the mobile IP (MIP) protocol and serves as the mobility management anchor point (as presented and discussed in Section 1.2). However, the home agent resides in the home network and this leads to mobility management hierarchy similar to the one described above in 3GPP networks.

The CDMA development group (CDG) [38] states that, as of September 2013, there are 313 operators in 118 countries offering CDMA2000 service. It is is mostly used in North America and Asia Pacific. It is not considered as wide as 3GPP networks, though.

RAN

Mobile WiMAX

Mobile WiMAX relies on the IEEE 802.16 standard [START_REF][END_REF] for the air interface and on the WiMAX forum [19] for the requirements, architecture, and protocols. The WiMAX forum has developed a network reference model to serve as an architecture framework for WiMAX deployments [START_REF]021v02[END_REF]. Fig. 1.12 illustrates the mobile WiMAX network architecture.

The access network in mobile WiMAX is called the access service network (ASN). The ASN is owned by an access service provider (ASP) and is composed of two types of entities. The first is the base station (BS) which provides the air interface for users. It may also have some additional functions such as handover triggering, tunnel establishment, and radio resource management. The second is the ASN gateways (ASN-GW) which typically acts as a layer 2 traffic aggregation point within an ASN. It may also have some additional functions such as establishment and management of mobility tunnel with base stations, intra-ASN location management and paging, and routing to the selected core network.

The core network in mobile WiMAX is called connectivity service network (CSN). The CSN is owned by a network service provider (NSP) and provides IP connectivity and all the IP functions. It provides connectivity to the Internet, other public networks, and corporate networks. It is responsible for IP address management and includes the mobility management anchor point. It supports mobility, roaming, and location management between ASNs, and also supports roaming between different NSPs. In addition, the CSN includes authentication, authorization and accounting (AAA) server(s) and provides per user policy management of quality-of-service and security.

Mobility management in mobile WiMAX relies on IP mobility protocols such as mobile IP (MIP) and hence the anchor point is the home agent (HA). We do not detail the IP mobility protocols here since we present and discuss them in Section 1.2. However, the anchor point is in the CSN and this leads to mobility management hierarchy similar to the one described above in 3GPP networks. Finally, it can be said that mobile WiMAX has been a step towards IP-based mobile networks. Although mobile WiMAX has been deployed in by more than 200 operators in more than 80 countries [START_REF]List of deployed WiMAX networks[END_REF], it is not considered as wide as 3GPP networks.

IPv6 Mobility Protocols

After presenting the 3GPP, 3GPP2, and WiMAX mobile networks, we present and discuss in this section the IP mobility protocols.

IP mobility refers to the user's movement, inside a network (local mobility) or between networks (global mobility), that leads to a change in the point of attachment at the IP level. The IP mobility event is referred to as IP handover. The IP mobility leads to a change in the user's IP address and hence needs to be managed or handled appropriately in order to guarantee the continuity of the user's ongoing sessions.

The IP mobility protocols refer to the protocols that can manage or handle the IP mobility. The main IP mobility protocols act at the IP layer in order to manage the IP mobility in such a way the user can still use its previous IP address. Consequently, the IP mobility is transparent to the upper layers. Other protocols act at the upper layers, such as the application layer, and handle the IP mobility even that they do not allow the user to use its previous IP address.

Hereafter, we present the following IP mobility protocols.

• mobile IPv6 (MIPv6) [START_REF]IETF RFC 3775[END_REF],

• proxy mobile IPv6 (PMIPv6) [START_REF]IETF RFC 5213[END_REF],

• session initiation protocol (SIP) [START_REF]SIP: Session Initiation Protocol[END_REF][START_REF] Schulzrinne | Application-layer mobility using SIP[END_REF].

MIPv6 is the main host-based IPv6 mobility protocol and PMIPv6 is the networkbased variant of MIPv6. MIPv6 and PMIPv6 are standardized by IETF and considered as the key IPv6 mobility protocols. They are well investigated, tested and deployed. They are included in several 3GPP, 3GPP2, and mobile WiMAX specifications such as [START_REF]General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[END_REF][START_REF]Architecture enhancements for non-3GPP accesses[END_REF][START_REF]-E[END_REF][START_REF]021v02[END_REF][START_REF]Mobility management based on Dual-Stack Mobile IPv6[END_REF][START_REF]Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols[END_REF]. It is essential to consider them in our study.

SIP is an application-layer signaling protocol standardized by IETF. It is well investigated with lot of extensions, and deployed in mobile networks. Although IETF does not look at SIP as a mobility protocol, SIP can natively support mobility as well as reachability at the application-layer for SIP-based sessions. Compared to IPlayer mobility schemes, SIP performs in a very different manner and hence it is highly interesting to include it in our study.

In this section, it is intended to introduce these protocols and describe them from architectural standpoint only. However, it is not intended to detail e.g. the operations, procedures, and signaling since they are detailed and analyzed in later chapters, particularly in Chapter 3 and Chapter 4.

Mobile IPv6 (MIPv6)

Mobile IPv6 (MIPv6) [START_REF]IETF RFC 3775[END_REF] is an IPv6 mobility protocol that provides session continuity and reachablity while moving around in the global IPv6 Internet. In the context of global mobility, it is not feasible to require additional mobility-related capabilities in all the serving access networks. The only entity that is guaranteed to be aware of the mobile node (MN) mobility is the MN itself. Hence, MIPv6 adopts a host-based scheme and the mobile node (MN) participates in the mobility-related signaling.

In MIPv6, each MN is always identified by its home address (HoA), regardless of its current point of attachment to the Internet. While situated away from its home, an MN is also associated with a care-of address (CoA), which provides information about the MN's current location.

MIPv6 introduces a new network entity called the home agent (HA). The HA maintains the MN's binding between the home address and care-of address in the binding cache. This binding is updated by the MN itself, upon each IP handover. The HA is typically implemented at a router in the MN's home network and serves as the mobility anchor of the MN. While the MN is away from home, the HA intercepts packets on the home link destined to the MN's home address, encapsulates them, and tunnels them to the MN's registered care-of address.

The default mode of communication in MIPv6 is called the bidirectional tunneling (BT) mode. IPv6 packets addressed to the MN's home address are routed to the HA by standard IPv6 routing mechanisms and then tunneled from the HA to the MN. Similarly, IPv6 packets sent by the MN are tunneled to the HA first then routed to their final destination, the correspondent node (CN).

MIPv6 defines also a route optimization (RO) mode to allow direct communication between the MN and the CN. This is achieved through enabling the CN to cache the binding of an MN's home address with its care-of address. Then, the MN's care-of address is used by the CN as a destination address in the packets destined for the MN, and by the MN as a source address in the packets destined for the CN. However, the MN and CN are respectively required to use a new home address destination option and a new type 2 routing header that are defined by MIPv6. This introduces additional overhead. Note that the RO mode cannot be activated unless the CN is an MIPv6 client; this brings significant limitations to the usage of RO. Fig. 1.13 illustrates the architecture and mobility management of MIPv6 in its default mode. The HA is located in the MN's home network. The MN moves from visited network 1 to visited network 2, undergoing an IP handover. While the MN's home address is always PrefH::MN, the MN's care-of address changes from PrefV1::MN to PrefV2::MN. The MN updates its binding at the HA and the HA registers the new care-of address in the binding cache. All IPv6 data packets from and to the MN are routed via the HA through a tunnel between the MN and the HA.

From architecture point of view, it appears clearly that the HA is the MN's anchor point in both control plane and data plane.

Internet

Proxy Mobile IPv6 (PMIPv6)

Proxy mobile IPv6 (PMIPv6) [START_REF]IETF RFC 5213[END_REF] is an IPv6 mobility protocol that is based on MIPv6 but designed/optimized for mobility management in a localized domain, called PMIPv6-domain. In other terms, PMIPv6 provides mobility support in a single operational domain but not between different operational domains such as in the global Internet. This limitation in the mobility scope allows the network to be operated in such a way it can manage the nodes mobility by itself. In other terms, the general knowledge on the possible points of attachment for the MN (i.e. the access routers of the domain) allows to implement some mobility functions in all of them so that the MN never attaches to a classical access router.

Compared to MIPv6, the main feature in PMIPv6 is to be network-based. This means that the MN is not required to participate in any mobility-related signaling. It is also not required to handle tunnel establishment and management. Instead, the network handles the mobility management on behalf of the MN. Accordingly, no additional capabilities (e.g. MIPv6 client) are required at the MN and the mobility management is totally transparent to the MN.

In order to achieve this, PMIPv6 introduces two network entities, namely the mobile access gateway (MAG) and the local mobility anchor (LMA), as follows.

The MAG is a function on an access router (AR) that manages the mobility-related signaling and also establishes the tunnel for an MN attached to it. It is responsible for tracking the MN's movements to and from it and for signaling the MN's LMA to update the MN's binding. It is also responsible for establishing and managing the tunnel for the MN. It can be said that the mobility functions defined in MIPv6 for the MN are moved from the MN to the MAG.

On the other hand, the LMA is the home agent [START_REF]IETF RFC 3775[END_REF] for the MNs in the PMIPv6domain. It is the entity that manages the MNs bindings states. It is also the gateway to the external networks such as the Internet. The LMA is the topological anchor point for the addresses, particularly the home network prefix(es), assigned to the MNs in the PMIPv6-domain.

Consequently, the IPv6 packets destined for the MNs addresses are naturally routed to the LMA through standard IPv6 routing mechanisms. The LMA encapsulates these packets and tunnel them to the corresponding MAG. The MAG decapsulates them and delivers them to the MN. Similarly, IPv6 packets sent by the MN are encapsulated at the MAG, tunneled to the LMA, and then routed to their final destination.

It is worth mentioning that in PMIPv6, the MN is always advertised the same home network prefix by the MAG with the help of the LMA. Consequently, the MN uses always its home address and does not need any care-of address. This makes the mobility completely transparent to the MN. Fig. 1.14 illustrates the architecture and mobility management of PMIPv6. The LMA and multiple MAGs are located in the PMIPv6-domain. The MN moves from one MAG subnet to another MAG subnet, undergoing an IP handover. The new MAG updates the binding at the LMA. The LMA registers the new MAG address in the binding cache entry of the corresponding MN. Then, a bidirectional tunnel is established between the MAG and the LMA for the MN's data traffic. The figure shows an example how a data packet is sent from the CN to the MN; it is routed to the LMA, tunneled from the LMA to the MAG, and then delivered to the MN.

From architecture point of view, it appears clearly that the LMA is the MN's anchor point in both control plane and data plane.

Internet

Session Initiation Protocol (SIP)

Session initiation protocol (SIP) [START_REF]SIP: Session Initiation Protocol[END_REF] is an application-layer signaling protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, multimedia conferences, and text messaging. SIP supports the following five aspects: user location (to determine the location of a user), user availability, user capabilities, session setup, and session management (e.g. to modify session parameters).

SIP [START_REF]SIP: Session Initiation Protocol[END_REF] introduces several logical entities to the network. For each domain (e.g. example.com) there is an SIP proxy server and a registrar server (RS). These logical entities are usually co-located when deployed. The proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. Note that the user can obtain the IP address of the SIP proxy server by performing a domain name system (DNS) lookup of the domain name. SIP identifies each user by a unique SIP uniform resource identifier (URI), e.g. alice@example.com. In order to associate the SIP-URI with the current IP address, SIP provides a registration function that allows the user to upload their current IP address to the registrar server. The registrar writes this association/binding into a database and the user is required to update their IP address upon initial attachment and also upon each IP address change, e.g. when undergoing an IP handover. This information in the registrar server is used by the proxy servers to locate the user when needed, e.g. to forward a request destined for the user. To conclude, it can be said that SIP can natively provide location management and hence reachability support.

In order to initiate a communication in SIP, the caller (e.g. sip:alice@orange.com) is required to invite the callee (e.g. sip:bob@telecomb.com). The invitation includes the caller's IP address, the callee's SIP-URI, the session identifier, and other fields. If the caller knows the callee's IP address, then the invitation can be sent directly. Otherwise, a SIP proxy server can be used to forward the invitation. First, the caller performs a DNS lookup of the callee's domain name (e.g. telecomb.com) which returns the IP address of the SIP proxy of the callee's domain (e.g. sip:proxy.telecomb.com). The caller then sends the invitation to this SIP proxy server. The SIP proxy server obtains the callee's IP address by performing a lookup of the callee's SIP-URI (which is included in the invitation) at the registrar server. Then, it forwards the invitation to the callee. The callee replies to the caller either accepting or rejecting the invitation.

During the session, any of the communicating users can request to modify the session through re-inviting the other party directly (no need to pass through a proxy this time). Upon undergoing an IP-handover, the user can modify its IP address used to send and receive data packets for the session, without changing the session identifier. Then, the other party updates the session and uses the new IP address as a destination address in the data packets. Consequently, SIP can natively support terminal mobility for SIPbased sessions [START_REF] Schulzrinne | Application-layer mobility using SIP[END_REF]. Compared to MIPv6/PMIPv6 where the HA/LMA is topologically the anchor point in the data plane, SIP is an end-to-end protocol; data packets are transmitted directly between the communicating users without any tunneling even after undergoing an IP handover. Fig. 1.15 illustrates the architecture and mobility support in SIP.

To sum up, although SIP is designed as a signaling protocol, it can natively support both mobility and reachability at application layer for SIP-based sessions. From architecture point of view, SIP is an end-to-end protocol that relies neither on mobility anchoring nor on tunneling mechanisms, and hence it can be said that the data plane is distributed. On the other hand, the control plane relies on the registrar server, the proxy server, and also the DNS, and hence it is kind-of centralized. Current network architectures, as well as IP mobility management protocols, are generally deployed in a centralized manner. All the data traffic passes through a single centralized entity, and all the users' binding-records are managed at this entity as well. As the number of mobile users and the volume of their traffic increase, such centralized architectures are expected to encounter scalability issues (e.g. network bottleneck, and single point of failure), security issues (e.g. attacks focused on the centralized anchor), as well as performance issues (e.g. centralized and non-optimal routing, large tunneling overhead).

Moreover, these protocols are designed to be always activated, managing all the services and all the traffic in the same way. They do not take into consideration that a given mobile user may not move during the use of a service, which exceeds 60 percent of the cases in operational networks [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF] (see Table 1.1), or that a service may not require IP mobility functions at all. Such approaches may thus lead to non-optimal routing and large overhead due to tunneling mechanisms.

Recently, mobile users' demand on data traffic is increasing dramatically. Operators' statistics show that the usage of mobile data traffic has doubled during the last year. This is expected to continue in this decade [START_REF]The Mobile Economy 2013[END_REF][START_REF] Ericsson | Ericsson Mobility Report[END_REF][START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF] (see Fig. 1.16), especially with the deployment of 4G networks, resulting in an explosion in mobile Internet traffic. In order to cope with such rapid explosion, a new trend is to flatten networks architectures and hence IP mobility management protocols need to be adapted for such evolution.

A flat architecture is by principle composed of a unique functional entity, the access router (AR). The AR is the first-hop router and the user's point of attachment at the IP level and, for simplicity, at the radio level as well. It provides basic attachment functions such as IP address allocation and routing. The AR also provides the mobilityrelated functions and hence these functions are brought to the network edge closer to the user. All the ARs are connected to the Internet through an operated IPv6 network † . Fig. 1.17 illustrates an example of IPv6 mobile network with a flat architecture (derived by the telecommunications operator Orange).

In conclusion, there is a need to define novel mobility management mechanisms that are both distributed and offered dynamically. They should be distributed in order to avoid any network bottleneck or single point of failure, and to provide better reliability. They should be activated and deactivated dynamically as needed, in order to globally reduce their signaling load and to increase the achieved performances; with the endorsement of the dynamic mobility management the mobility functions are only activated when necessary, depending on the mobility behavior of the user, the type of used services, or the networking context in general.

Accordingly, the IETF chartered recently the distributed mobility management (DMM) working group [START_REF]IETF DMM charter[END_REF]. Various efforts from both industry and academia are being performed on specifying DMM schemes. One of the DMM requirements [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF] is to rely on the existing IP mobility protocols by extending and adapting them. This is in order to benefit such standardized protocols before specifying new ones, and also to facilitate the migration of networks architectures.

The thesis concerns designing, analyzing, and evaluating novel IPv6 network architectures and mobility protocols that are both distributed and dynamic, and in particular Distributed Mobility Management (DMM) architectures and protocols.

History of DMM

IPv6 mobility management started with MIPv6, which was standardized in 2004. As discussed before, MIPv6 is host-based and supports global mobility in the IPv6 Internet. After, discussions were initiated on specifying a network-based mobility protocol that is optimized for local mobility support in a single operational domain. Several years of work resulted in standardizing the PMIPv6 protocol in 2008. PMIPv6 inherited the main concepts of MIPv6, both relying on a centralized anchor entity for both data and control planes. This may lead to several issues, as mentioned above in the problem statement, and since that time there have been efforts to design an extension that is "distributed." Dynamic mobility anchoring (DMA) [START_REF] Bertin | A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures[END_REF][START_REF] Bertin | Distributed or Centralized Mobility?[END_REF][START_REF] Bertin | An Evaluation of Dynamic Mobility Anchoring[END_REF], derived by the telecommunications operator Orange, raised the issue at relevant fora in 2008, proposing a first attempt. Then, the issue was raised in IETF, the main standardization body for such topic. At that time, the two main IETF working groups related to IP mobility management were the mobility extensions for IPv6 (MEXT) [47] and the network-based mobility extensions (NETEXT) [START_REF]IETF NETEXT charter[END_REF] which were chartered for MIPv6 and PMIPv6 extensions, respectively.

There was, implicitly, a general agreement at IETF to extend the existing IETF protocols rather than proposing a new one. As PMIPv6 was at that time the novel promising mobility protocol, IETF folks focused on extending PMIPv6. For instance, the early two drafts were in NETEXT; the first was by Huawei and attempted to distribute the mobility anchor in PMIPv6 [START_REF] Chan | Distributed Local Mobility Anchors[END_REF][START_REF] Chan | Proxy Mobile IP with Distributed Mobility Anchors[END_REF], and the second was by Orange and adapted DMA to be, to an extent, PMIPv6-based [START_REF] Seite | Dynamic Mobility Anchoring[END_REF][START_REF] Seite | Distributed Mobility Anchoring[END_REF].

At the beginning, different points of view showed up and the motivation behind distributed mobility management was under discussion. The reason behind such debate in standardization bodies is not necessary because the raised issues are not clear enough. However, it was agreed to work on the subject in a more structural and methodological manner. Then several interested players (e.g. Huawei, Orange, KDDI, China Mobile, Telecom Italia, Alcatel-Lucent, Ericsson) collaborated together. They produced in 2010 two main drafts on the DMM use-case scenarios [START_REF] Yokota | Use case scenarios for Distributed Mobility Management[END_REF] and the DMM problem statement [START_REF] Chan | Problem statement for distributed and dynamic mobility management[END_REF], as well as other publications such as [START_REF] Chan | Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues[END_REF].

Meanwhile, many drafts are under submission to IETF as proposals [START_REF]IETF DMM working group documents[END_REF]. Part of these drafts are based on either MIPv6, PMIPv6, or network mobility (NEMO) basic support protocol [55] ‡ . Such proposals are referred to as mapping-based mobility management since they are based on a mapping between two IP addresses. Others that are based on routing techniques (referred to as routing-based mobility management) or even locator/identifier separation do also exist. There is also ongoing works on mobility anchor selection. However, there is no final agreement on any of them as a protocol solution. Even, not every draft does really provide what is claimed in its title at the protocol operation level.

In 2012, and after a long parturition, the DMM working group was chartered by the IETF. The charter included the main objective and required to extend the existing IPv6 mobility protocols. Hereafter, we cite some of the DMM charter [START_REF]IETF DMM charter[END_REF] text:

The Distributed Mobility Management (DMM) working group specifies IP mobility, access network and routing solutions, which allow for setting up IP networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to manage IP mobility sessions.

The protocol solutions should be based on existing IP mobility protocols, either host-or network-based, such as Mobile IPv6, Proxy Mobile IPv6 and NEMO.

Solutions may also focus specifically on managing the use of care-of versus home addresses in an efficient manner for different types of communications.

The distributed mobility management solutions primarily target IPv6 Deployment and should not be tailored specifically to support IPv4.

In addition, the charter mentions the following work items: solution requirements, practices, gap analysis, and extensions (if needed). The requirements draft [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF] is almost approved. The practices and gap analysis are currently under discussion and several drafts target this work item [START_REF] Liu | Distributed Mobility Management: Current practices and gap analysis[END_REF][START_REF] Chan | Distributed Mobility Management Framework[END_REF][START_REF] Zuniga | Mobility Practices and DMM Gap Analysis[END_REF][START_REF] Liebsch | Distributed Mobility Management -Framework & Analysis[END_REF][START_REF] Chan | Framework for Mobility Management Protocol Analysis[END_REF]. However, there is still no agreement on the protocol solutions.

Hereafter, we present the most relevant work to our study, DMA.

Dynamic Mobility Anchoring (DMA)

Dynamic mobility anchoring (DMA) [START_REF] Bertin | A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures[END_REF][START_REF] Bertin | Distributed or Centralized Mobility?[END_REF][START_REF] Bertin | An Evaluation of Dynamic Mobility Anchoring[END_REF][START_REF] Seite | Distributed Mobility Anchoring[END_REF][START_REF] Louin | Network and Host Based Distributed Mobility[END_REF]] is a mobility management scheme that is, to an extent, based on PMIPv6 but relies on a distributed architecture. Mobility management is moved to the network edge in order to anchor the traffic closer to the MN, rather than at a centralized entity in the core network. To the best of our knowledge, DMA is the first attempt to address this issue. DMA is investigated through simulations and tested in a test-bed. Although DMA is neither standardized nor deployed, we consider it since it is highly relevant to our study.

DMA is required to support the local mobility only. The MN moves in a single IPv6 operational domain. The operator of this domain is required to fully implement the DMA requirements at each AR. Each AR is required to have both mobility anchoring and location update functionalities, i.e. the LMA and MAG functionalities. The AR is then referred to as mobility capable access router (MAR) [START_REF] Seite | Distributed Mobility Anchoring[END_REF]. Consequently, it is guaranteed that the MN is always attached to an AR that can act as a mobility anchor.

Compared to PMIPv6 where all the data traffic is anchored at the same entity, i.e. the LMA, dynamic anchoring means to change the anchoring point for new sessions. This allows the MN to always initiate new sessions using the current IP address. The data traffic is then routed optimally without tunneling. If these sessions are terminated before undergoing an IP handover, then there is no need to keep the MAR where they were initiated as an anchor. On the other hand, if the MN undergoes an IP handover before terminating these sessions, then the mobility management is needed and activated dynamically.

Upon an IP handover, tunneling mechanisms are needed in order to guarantee session continuity for the MN. AS the anchoring point is moved to the access network, the tunnel is established in the access network rather than between the access network and the core network. In particular, the tunnel is established between the serving MAR and the anchoring MAR. Then, data packets destined for the MN are routed naturally to the anchoring MAR by standard IPv6 routing mechanisms, encapsulated by the anchoring MAR to be tunneled to the serving MAR, and then decapsulated by the serving MAR to be delivered to the MN.

In order to establish a tunnel with the anchoring MAR(s), the serving MAR needs some additional information such as the IP address of the anchoring MAR(s). This information is natively known by the MN. However, relying on the MN to obtain this information turns the scheme to a host-based scheme. In order to keep the scheme network-based, DMA relies on a database in the network to store the ongoing mobility sessions and their associated anchors for all the MNs. Fig. 1.18 illustrates the architecture and mobility management in DMA. The local mobility domain is an IPv6 operational domain that serves the MN through MARs, connects to the Internet through gateways (GW), and relies on a mobility sessions database. While attached to MAR1 subnet, the MN configures IP address PrefM1::MN and initiates a session (S1) with a CN. The data packets of S1 are routed optimally without any tunneling. The MN moves to MAR2 subnet and configures IP address PrefM2::MN, undergoing an IP handover. MAR2 obtains the needed information from the database and establishes a tunnel with MAR1 for the data packets of S1. MAR1 creates/updates the binding cache entry for the MN. The CN still addresses the S1 data packets to PrefM1::MN and hence they are routed to MAR1. MAR1 tunnel these packets to MAR2 which delivers them to the MN.

From architecture point of view, the anchors are distributed in the access network and hence the data plane is distributed. Bindings maintenance and tunnels management are distributed but the information repository is centralized, and hence the control plane is partially distributed.

DMA shortages

Despite of the advantages of DMA, the following can be noticed. First, DMA does not support global mobility over the IPv6 Internet. If the mobile user departs from the DMA local domain, then the mobility is no more supported.

In addition, DMA does not consider mobility-functions' partial deployment at the access routers, i.e. some of the access routers are mobility capable but not all of them. The mobile network operator is obliged to deploy the DMA functionalities at all the access routers in its operational network at once, and hence a step-by-step migration is not possible. Consequently, there is no system fallback if some of the access routers fails to provide mobility support and also there is no backward compatibility with legacy IP mobile networks.

Finally, DMA is partially distributed and relies on a centralized database for the control plane. Such database is required to be updated frequently for all the sessions/anchors of all the users. If this database fails, then the mobility is no more supported in all of the network and hence it is considered as a single point of failure.

Internet

Summary

In this chapter, we have presented and discussed the different mobile data networks, including 3GPP, 3GPP2, and WiMAX mobile networks. We have focused on their architectures as well as their mobility management. Then, we have presented and discussed the IPv6 mobility protocols, namely mobile IPv6 (MIPv6) and proxy mobile IPv6 (PMIPv6). In addition, we have considered the session initiation protocol (SIP) which can natively support mobility and reachability at the application-layer in a very different manner compared to IP-layer mobility protocols.

After studying all of these architectures and protocols, we have concluded the common feature which is being hierarchical and centralized. Considering the ongoing rapid increase in mobile data traffic, we have extracted the problem statement of distributed mobility management (DMM). We have then recounted the history of DMM especially in the IETF, mentioning ongoing works and actions there. We have also presented dynamic mobility anchoring (DMA) since it is highly relevant to our study, mentioning both its advantages and limitations.

The thesis concerns designing, analyzing, and evaluating novel IPv6 network architectures and mobility protocols that are both distributed and dynamic.

In the next Part, we develop the necessary analytical models and analysis metrics. Then, we carry out a comparative analysis on the global mobility management schemes (MIPv6, SIP, and their integration as well) and another one on the local mobility management schemes (PMIPv6 and DMA).

Part II Protocols Modeling and Analysis

Introduction

In this chapter, we present first the analytical models derived in order to model different mobility management schemes in all-IPv6 networks. These models are used later for several performance analysis studies on those schemes, after categorizing them.

Then, we present the considered criteria and metrics for protocols analyses. We consider three types of analyses:

• Cost Analysis,
• Handover Analysis,

• Quality-of-Service Analysis.

Through carrying out different analyses, we can investigate the strong and weak points of each mobility management scheme. We can hence be able to draw out conclusions and perspectives, paving the way towards proposing enhancements or even a novel scheme.

For this rationale, we consider this work as an essential step and one of the corner stones of the thesis.

Analytical Models

Network model

The network model is illustrated in Fig. 2.1. It is an all-IPv6 network. The MN moves in a domain consisting of K rings of hexagonal-shaped cells; the number of cells in a domain, N , can be calculated as follows:

N = 1 + K i=1 6i = 3K(K + 1) + 1.
(2.1)

All the cells have the same area, A c , and in each cell there is one AR. The AR is the first hop router; it is the MN's point of attachment at both radio and IP levels. While an MN is mobile and wireless-connected to the network through an AR, we assume for simplicity that a CN is non-mobile and wired-connected to the network.

We denote by h x,y the average hop distance, i.e. average number of hops, between two network entities x and y. The average hop distance is assumed to be symmetric, i.e. h x,y = h y,x . Furthermore, since a wireless link is usually less stable (lower reliability and lower data rate) than a wired link, we introduce ω to be the average weighting factor of a wireless link. This means that a transmission over a wireless link generally costs ω times as much as that over a wired link, on average. Table 2.1 shows the list of the average hop distances.

Then we define the network scale, ξ, to be the ratio between the number of hops between two ARs and the number of hops between an AR and a centralized entity in the network. ξ is expressed as follows:

ξ = h ar,ar h ar,central . (2.2)
In addition, we consider in some cases dividing the network into Location Areas (LA) having the same area A a . Each LA consists of N cells in the form of K rings, as illustrated in Fig. 2.2, and hence has an area A a = N A c .

Mobility model

Based on our network model, an MN undergoes an IP-handover when crossing from one cell to another. Thus the IP-handover rate is equal to the cell-boundary crossing rate.

First, we assume that the MN's residence time in a cell t c is a random variable which follows an exponential distribution with mean value 1/µ c . We consider then the well-known fluid-flow mobility model [START_REF] Morales-Andres | An approach to Modelling Subscriber Mobility in Cellular Radio Networks[END_REF] to represent the MN's movement. Under this model, it is assumed that the direction of the movement is uniformly distributed over the range [0, 2π[, and that the MN is with high mobility and infrequent speed change.

The cell-boundary crossing mean rate is expressed as follows [START_REF] Akyildiz | A dynamic location management scheme for nextgeneration multitier PCS systems[END_REF]:

µ c = v L c π A c , (2.3)
where v is the average movement speed of the MN, L c is the cell's perimeter, and A c is the cell's area.

By considering a hexagonal-shaped cell with side length R, we get

L c = 6R, A c = (3 √ 3/2)R 2 , and hence L c = 8 √ 3 √ A c .
Then, µ c can be re-written in the following two forms:

µ c = 4 √ 3 3π v R ≃ 0.735 v √ R , (2.4
)

µ c = 8 √ 3 π v √ A c ≃ 1.184 v √ A c . (2.5)
When we divide the network into LAs that have the same area, each LA consists of N cells and hence has an area A a = N A c . The LA-residence time is a random variable t a that is exponentially distributed with mean rate µ a . By approximating an LA by a hexagon (as illustrated in Fig. 2.2) with area N A c , we can estimate the LA-crossing rate as follows:

µ a = 8 √ 3 π v √ A a = 8 √ 3 π v √ N A c = µ c √ N .
(2.6)

Refreshing rate

Signaling messages having a lifetime period, T , should be periodically refreshed when the MN stays in the same cell, or in the same LA. Our aim is to calculate the mean refreshing rate in both cases.

Let N r be the number of refreshing during a cell-residence time t c , with an average value E(N r ). As illustrated in the time diagram of refreshing in Fig. 2.3, we have:

N r = t c T and E(N r ) = E t c T , (2.7)
where ⌊X⌋ is the integer part of X.

N r is clearly a positive discrete random variable. Thus, E(N r ) can be re-written in the following form:

E(N r ) = ∞ k=0 k Pr(N r = k), (2.8) time …
Nr : number of refreshings in cell-residence time

tc1 tc2 tc3 tcn … T T T T       T t c 1       T t c 2       T t c 3       T t cn

Registrations due to handovers

Registrations due to refreshing Pr(N r = k) can be determined as follows:

Pr(N r = k) = Pr t c T = k = Pr kT ≤ t c < (k + 1)T = Pr kT ≤ t c -Pr (k + 1)T ≤ t c . (2.9)
Note that t c is exponentially distributed with mean rate µ c , then we get

Pr(N r = k) = e -kµcT -e -(k+1)µcT = e -µcT k 1 -e -µcT = ρ k 1 -ρ , with ρ = e -µcT , (2.10)
which is a geometric distribution.

Then, E(N r ) can be determined as follows

E(N r ) = ∞ k=0 k ρ k 1 -ρ = 1 -ρ ∞ k=0 k ρ k , with ρ < 1 = 1 -ρ ρ 1 -ρ 2 = ρ 1 -ρ = 1 e µcT -1 . (2.11)
Then, the refreshing mean rate during a cell-residence time, η c , can be determined as follows:

η c = µ c E(N r ) = µ c 1 e µcT -1 . (2.12)
Similarly, the refreshing mean rate during an LA-residence time, η a , can be determined as follows:

η a = µ a 1 e µaT -1 = µ c √ N 1 e µcT / √ N -1 . (2.13)
Note that the refreshing rate is rarely considered in the literature. Otherwise, it is presented either without calculation as a presumed value or with less accurate approximations such as in [START_REF] Makaya | An Analytical Framework for Performance Evaluation of IPv6-Based mobility Management Protocols[END_REF]. To the best of our knowledge, the refreshing rate has not been derived analytically in the literature. We believe that such parameter should be considered for a proper analysis and that our derived expression is well accurate.

Traffic model

First of all, we assume that the sessions arrival to an MN follows a Poisson process with mean rate λ s (i.e. the inter-arrival time between sessions is exponentially distributed with this rate). We assume also that the duration of a typical session is exponentially distributed with mean rate µ s . The motivation behind these choices is the memoryless property of the exponential distribution which can represent the human behavior. Besides, these are the adopted choices in the majority of literature studies.

An MN may communicate with one or more CNs at a time. We are interested in knowing the average number of CNs for an MN at a time, N cn , as a function of λ s and µ s .

We consider two different scenarios. The first scenario is a basic one that represents IP telephony or IP TV systems. The second scenario is a general one that represents Internet, and hence it is later considered the default scenario.

Scenario 1

Scenario 1 tries to represent an MN that is receiving only voice over IP (VoIP), or e.g. only IP TV, sessions. We assume in this scenario that the MN can have at most one active session with one CN at a time. Then, the MN can be in one of two states: either idle (no active session) or active (one active session).

We model this scenario as a system consisting of two states under the probability distribution of M/M/1/1 queue (see Fig. 2.4). Let P idle and P active be the probabilities that the MN is idle or active, respectively. When the system reaches steady-state, we have λ s P idle = µ s P active , and by axiom of probability we have P idle + P active = 1. Then we get

P idle = µ s λ s + µ s
, and As a result, N cn can be calculated as follows (verified with [START_REF] Kleinrock | Queueing Systems: Theory[END_REF])

P active = λ s λ s + µ s . ( 2
N cn = 0 • P idle + 1 • P active = P active = λ s λ s + µ s . (2.15)

Scenario 2

Scenario 2 tries to represent an MN connecting to the Internet with several types of sessions. We assume in this scenario that the MN may have infinite number of simultaneous active sessions with infinite number of CNs. By assuming that each active session is with a different CN, then N cn is equal to the average number of simultaneous active sessions.

This scenario can be modeled as a system under the probability distribution of M/M/∞ queue (see Fig. 2.5). Let P n be the probability of having n simultaneous active sessions. When the system reaches steady-state, we have

nµ s P n = λ s P n-1 ⇒ P n = λ s nµ s P n-1 ∀ n > 0, (2.16)
then we get

P n = (λ s /µ s ) n n! P 0 ∀n ≥ 0.
(2.17)

In addition, by axiom of probability ∞ n=0 P n = 1, we get

P 0 = 1/ ∞ n=0 (λ s /µ s ) n n! = e -λs/µs . (2.

18)

Then P n is given by a Poisson distribution as follows

P n = (λ s /µ s ) n n! e -λs/µs , (2.19)
and N cn can be calculated as follows (verified with [START_REF] Kleinrock | Queueing Systems: Theory[END_REF])

N cn = ∞ n=0 nP n = λ s µ s . (2.20)

New traffic vs Handover traffic

In order to be dynamic, some mobility management schemes may distinguish

• new traffic: data traffic for flows that did not undergo any IP-handover, and,

• handover traffic: data traffic for flows that did undergo one or more IP-handovers.

Then, in order to model such schemes we need to calculate the probabilities that a traffic is a new traffic or a handover traffic.

First, we denote by λ n and λ h the new traffic arrival mean rate and the handover traffic arrival mean rate, respectively. The overall traffic arrival rate in a cell is λ n + λ h .

Then the probability that a traffic is a new traffic, P n , and the probability that a traffic is a handover traffic, P h , are expressed as follows [START_REF] Fang | Teletraffic Analysis and Mobility Modeling for PCS Networks[END_REF][START_REF] Fang | Channel occupancy times and handoff rate for mobile computing and PCS networks[END_REF]

P n = λ n λ n + λ h
, and

P h = λ h λ n + λ h . (2.21)
In the following, we determine λ h . First, let N H/S be the number of handovers for a session, with mean value E[N H/S ]. Since each new session initiates E[N H/S ] handover sessions on average, then we obtain [START_REF] Fang | Teletraffic Analysis and Mobility Modeling for PCS Networks[END_REF][START_REF] Fang | Channel occupancy times and handoff rate for mobile computing and PCS networks[END_REF]:

λ h = λ n E[N H/S ].
(2.22)

It has been shown in [START_REF] Fang | Channel occupancy times and handoff rate for mobile computing and PCS networks[END_REF] that whatever are the distributions of the cell residence time and the session duration, we have

E[N H/S ] = µ c µ s . (2.23)
Then we get

λ h = λ n µ c µ s , (2.24)
and hence

P n = µ s µ s + µ c
, and

P h = µ c µ s + µ c . (2.25)
In addition, an MN may have several anchors at a time due to distinguishing new traffic and handover traffic. Then we denote by N anchor the average number of anchors for an MN at a time. N anchor can be calculated as the ratio between the number of anchored sessions (P h N cn ) and the number of sessions per anchor (λ s /µ c ).

Delay model

We consider the time of sending a packet over wired and wireless links, including transmission and propagation times [START_REF] Mcnair | An Inter-System Handoff Technique for the IMT-2000 System[END_REF]. Processing times, e.g. at routers, are neglected.

Wired links

We assume that the wired links are reliable and hence there is no need for any retransmission. Then, the delay of a packet of size p sent from x to y is expressed as follows:

d x,y (p) = h x,y p B wd + L wd , (2.26)
where B wd and L wd are the bandwidth and propagation latency in wired links, respectively.

Wireless links

Wireless links are considered less reliable compared to wired links. This may introduce packet transmission failures and hence several re-transmissions. Let n f be the number of wireless link failures, and P f be the probability that the wireless link fails. Then, the delay of a packet of size p sent over the wireless link is expressed as follows [START_REF] Mcnair | An Inter-System Handoff Technique for the IMT-2000 System[END_REF][START_REF] Kleinrock | Queueing Systems: Theory[END_REF]:

d wl (p) = p B wl + L wl 1 + ∞ n f =0 n f Pr{n f failures & 1 success} = p B wl + L wl 1 + P f 1 -P f = p B wl + L wl 1 1 -P f (2.27)
where B wl and L wl are the bandwidth and propagation latency in wireless links, respectively.

Cost Analysis

The motivation behind carrying out a "cost analysis" is mainly because our major concern is the rapid increase in mobile data traffic. Thus, we consider the cost of data/bytes/packets' transmission through the network. This shows the load on the network and evaluates the efficiency of each mobility scheme in optimizing the network resources and their consumption.

Cost analysis also gains interest as high quality multimedia and streaming sessions are expected to represent a huge percentage of the near future services. For instance, mobile video traffic has exceeded 50% of mobile traffic for the first time in 2012, and is expected to increase to 66% by 2017 [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF].

In IP networks, the transmission cost is proportional to the distance in hops between the source and the destination [START_REF] Xie | A novel distributed dynamic location management scheme for minimizing signaling costs in Mobile IP[END_REF]. Thus, we calculate a cost as the product of the transmitted data size and the traversed hop distance, as illustrated in Fig. 2.6.

Mobility may affect signaling between network entities, change the routing path of data packets, and introduce tunneling. Thus, we consider the following mobility costs.

Signaling cost

The Signaling Cost (SC) represents the cost of mobility-related signaling messages for an MN per unit time.

Hereafter is a general form for SC expressions. Later, this general form can be applied to each protocol based on its procedures in order to model the SC of the different protocols.

SC = Procedure i Rate i • Pr i • Cost procedure i (2.28)
where Rate i is the mean rate of a specific signaling procedure i (e.g. handover and refreshing rates), P r i is the probability that procedure i occurs, and Cost procedure i is the unit cost of procedure i. A signaling procedure consists in general of one or more messages exchanges, and hence Cost procedure is generally expressed as follows,

AR CN MN h wired hops

Cost procedure = Signaling j Message j • Hops j (2.29)
where M essage j is the size (in bytes) of a signaling message j, and Hops j is the average number of hops traversed by message j.

It is worth mentioning that we do not consider the cost of discovering a new AR upon movement and the cost of configuring a new IP address since they are common whatever is the used mobility protocol.

Data packet delivery cost

The Data packet delivery Cost, called simply Data Cost (DC), represents the cost of delivering data packets to an MN per unit time. Hereafter is a general form for DC expressions.

DC = N Sessions • Rate Session Duration • N Packets/Session • Packet i Pr i • Cost packet i (2.30)
where N Sessions is the average number of sessions per unit time for an MN, Rate Session Duration is the session duration mean rate (added for normalization per unit time), N P ackets/Session is the average number of packets per session, Cost packet i represents the unit cost of transmitting a packet i, and P r i is the probability that transmitting packet i costs Cost packet i (used if different packets of the same session may be transmitted through different paths, e.g. probability that a packet belongs to new or handover traffic).

In general, one or more overheads can be added to a data packet over a part or all of the traversed path between MN and CN, and hence Cost packet is expressed as follows,

Cost packet = Packet • Hops ′ + (Packet + Overhead ) • Hops ′′ (2.31)
where P acket is the data packet average size in bytes, Overhead is the additional overhead size in bytes, Hops ′ and Hops ′′ are the number of hops traversed by a data packet without and with additional overhead, respectively. Note that this is a general expression, e.g. if there isn't/is an additional overhead all over the routing path, then Hops ′′ /Hops ′ is set to zero.

Tunneling cost

Tunneling Cost (T C), which is similar to DC but it is dedicated to represent the cost of adding tunneling overheads. Hereafter is a general form for T C expressions.

TC = N Session • N Packets/Session • Rate Session Duration • Packet i Pr i • Cost overhead i (2.32)
where Cost overhead is the unit cost of adding an overhead for a packet, and hence it is expressed as follows,

Cost overhead = Overhead • Hops ′′ (2.33)

Processing cost

In addition to the costs defined above, we consider a Processing Cost (P C) concerning the number of signaling messages sent to a network entity by an MN per unit time.

For example, we count the average number of registrations (e.g. upon handovers or for refreshing) sent to a specific server per unit time.

The interest in this metric is due to the fact that higher values reflect more probability of encountering scalability issues, which are a major concern in current mobility protocols.

Hereafter is a general form for P C expressions.

PC = Procedure i Rate i (2.34)
where Rate i is the mean rate of a specific signaling procedure i (e.g. handover and refreshing rates) that is performed with a specific server.

Handover Analysis

When dealing with mobility management, it is essential to analyze the handover phase. This reflects the control plane performance and evaluates the efficiency of the protocol in handling handovers. In what follows, we consider the Handover Latency (T HL ) as the main handover metric.

Handover latency

During handover, there is a period during which the MN is unable to receive or send packets because of link switching delay and IP protocol operations. Thus, we consider the Handover Latency (T HL ) as a key performance metric.

The Handover Latency (T HL ) is defined as the time between the last moment where the MN can receive and send packets through the previous AR and the first moment where it can receive and send packets through the new AR.

T HL is generally expressed as follows:

T HL = T L2 + T M D + T LU (2.35)
where:

• T L2 : is the Layer 2 (L2) handover latency.

• T M D : is the movement detection latency.

• T LU : is the location update latency.

Note that we do not consider an authentication latency which depends on the used authentication mechanisms and protocols.

T L2 depends on the Layer 2 technology being used. T M D is composed of exchanging the router solicitation (RS) and router advertisement (RA) messages between the MN and the new AR over the wireless link, to be expressed as follows:

T M D = 2 Delay wireless (M essage) (2.36)
where Delay wireless (α) is the delay of transmitting data of size α over a wireless link.

Note that when configuring a new IP address, we consider the update of neighbor discovery protocol [START_REF]IETF RFC 4861[END_REF] and stateless address autoconfiguration [START_REF]IPv6 Stateless Address Autoconfiguration[END_REF] processes through the optimistic duplicate address detection (DAD) [START_REF]IETF RFC 4429[END_REF], and hence no delay is introduced by the DAD process.

It can be noticed that T L2 and T M D are independent of the mobility protocol. For fairness, we assume then that they are the same for all protocols.

On the other hand, T LU depends on the mobility protocol and its specific procedures; hence, it should be modeled for each protocol separately. However, the location update consists in general of exchanging one or more signaling procedures over wireless link and/or between network entities. Then, it could be expressed generally as follows:

T LU = Signaling i Delay wireless (M essage i ) + Signaling j Delay x j ,y j (M essage j ) (2.37)
where Delay x,y (α) is the delay of transmitting data of size α over a wired path between network entities x and y.

QoS Analysis

Quality-of-service (QoS) generally describes the assurance of sufficiently low delay and packet loss for certain types of applications or traffic [START_REF] Zhao | Internet Quality of Service: an Overview[END_REF].

In what follows, we consider both the Packet Loss (number of lost packets, N P L ) and the End-to-End Delay (T E2E ) as the main QoS parameters.

Packet loss

Packets may be lost due to several factors such as congestion, bandwidth limit, etc. Hereafter we consider the packet loss only due to handover.

While the MN experiences its handover, data packets sent from its CN(s) will be lost if any buffering mechanism is not supported. We define Packet Loss as the number of packets (i.e. data packets sent from the CN(s) to the MN) that are lost during a handover, and we denote it by N P L .

The packet loss during a handover is proportional to both the handover latency and the packet arrival rate to the MN. The packet arrival rate for one session can be calculated as the product Rate Session Duration •N P ackets/Session . We also take into account the number of simultaneous sessions. Then, N P L is generally expressed as follows:

N P L = N Sessions • Rate Session Duration • N P ackets/Session • T HL (2.38)

E2E delay

The End-to-End Delay T E2E is the time of sending a data packet between the MN and its CN. This metric is important for the QoS and crucial for real-time services such as voice over IP (VoIP). The main aspects affecting this metric are both the routing and tunneling.

T E2E is expressed in general as follows.

T E2E = route i P r i • Delay route i (2.39)
where P r i is the probability that a data packet is transmitted over a route i (used if there may be different routing paths for different packets), and Delay route i is the end-to-end delay over a specific routing path i, which can be derived as follows.

If assuming that the CN is wired connected to the network, then the data packet is transmitted over only one wireless hop (MN-AR), either with or without an additional overhead. It is transmitted also over other wired hops between the MN's AR and the CN. Depending on the protocol mechanisms, an overhead might be added over a part or all of the route. Hence, Delay route is expressed in general as follows.

Delay route = Delay wireless (P acket || P acket + Overhead)

(2.40)

+ Delay x,y (P acket) + Delay y,z (P acket + Overhead).

Note that the expression is a general form and some of the values might be zero depending on the protocol.

Summary

In this chapter, we have identified the parameters of the needed analytical models. For each parameter, we have derived its expression in terms of other known variables that can be either given a default value or varied in a range of values. This is essential to investigate the effect of each variable on the analytical parameters in order to carry out a comparative or a performance analysis.

We have also identified the analyses criteria. We have considered cost, handover, and QoS analyses as different criteria to examine mobility management schemes. For each analysis, we have identified several metrics that can reflect the performance of both control plane and data plane operations. The expressions of these metrics have been derived in a general form that can be applied to any mobility management scheme or protocol.

In the next two chapters of this part, we will carry out two cost analyses. The first is on the global mobility management schemes. The second is on the local mobility management schemes. We separate the two categories in order to obtain fair results, where in the latter the user mobility is restricted within a single operational domain but in the former it is not. Through these analyses, the two categories of mobility schemes can be investigated deeply in order to bring out conclusions and perspectives for the next steps.

In order to facilitate the readability of the next chapters, the list of symbols (pp. xviii-xix) summarizes the models parameters and analyses metrics defined in this chapter.

CHAPTER 3 Analysis of Global

Mobility Management Schemes

Mobility management schemes are categorized into global mobility and local mobility support. In this chapter, we carry out a comparative analysis of different global mobility management schemes. As our main concern is the rapid increase in mobile data traffic, we choose to perform a "cost analysis" at this stage rather than analyzing other metrics. Handover and QoS analyses come out later.

First, we apply the analytical models and general forms of the costs expressions (derived in Chapter 2) on the different schemes in order to model them. We then investigate the impact of several parameters on these metrics. Finally, we draw out conclusions and perspectives paving the way towards proposing enhancements.

The study and results presented in this chapter have been published in [P4].

Introduction

Future wireless and mobile Internet is expected to be composed of several access networks and operational domains. When a mobile node (MN) moves from one network to another causing change in its network topology, global mobility support is needed in order to maintain session continuity. This brings new challenges for the different global mobility management schemes.

In our study, we consider the network layer based protocol mobile IPv6 (MIPv6) [START_REF]IETF RFC 3775[END_REF], the application layer based protocol session initiation protocol (SIP) [START_REF]SIP: Session Initiation Protocol[END_REF][START_REF] Schulzrinne | Application-layer mobility using SIP[END_REF], and an approach integrating both, to be called mixed MIPv6-SIP (MMS). Other protocols or schemes supporting local mobility are studied in Chapter 4.

The aims of considering these different schemes are twofold.

• The first is to carry out a comparative cost analysis on these global mobility schemes especially as they manage mobility at very different layers in different manners.

• The second is to evaluate the gain of introducing SIP besides MIPv6 (as in MMS) for global mobility management in terms of mobility costs.

Cost analysis reflects the load on the network introduced by each mobility management scheme. In other terms, we can through cost analysis evaluate the efficiency of each scheme in optimizing the network resources and their consumption. Hence, such analysis gains more interest as the high quality multimedia and streaming sessions are expected to represent a huge percentage of the near future services [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF].

Related work

In the literature, some related studies on cost analysis were performed, e.g. [START_REF] Xie | A novel distributed dynamic location management scheme for minimizing signaling costs in Mobile IP[END_REF][START_REF] Makaya | An Analytical Framework for Performance Evaluation of IPv6-Based mobility Management Protocols[END_REF][START_REF] Lee | Cost analysis of IP mobility management protocols for consumer mobile devices[END_REF][START_REF] Pack | Adaptive Route Optimization in Hierarchical Mobile IPv6 Networks[END_REF][START_REF] Lee | A comparative performance analysis on Hierarchical Mobile IPv6 and Proxy Mobile IPv6[END_REF][START_REF] Lee | How much do we gain by introducing route optimization in Proxy Mobile IPv6 networks?[END_REF][START_REF] Zhang | P-MIP: Paging Extensions for Mobile IP[END_REF][START_REF] Lee | Shall we apply paging technologies to Proxy Mobile IPv6?[END_REF][START_REF] Gohar | Network-Based Distributed Mobility Control in Localized Mobile LISP Networks[END_REF][START_REF] Lee | A competent global mobility support scheme in NETLMM[END_REF]. These studies concern mainly the IP mobility management protocols such as MIPv6 and its extensions. Application layer protocols such as SIP are not covered by these studies.

On the other hand, the authors in [START_REF] Wang | Signalling analysis of cost-efficient mobility support by integrating mobile IP and SIP in all IP wireless networks[END_REF] propose a mobility management approach by integrating MIP and SIP, and present a signaling cost analysis without considering the other mobility costs. They add a return routability procedure to SIP which is not required in the SIP standard. Moreover, they do not consider the registration refreshing.

In fact, most of the studies do not consider the signaling refreshing, otherwise the refreshing rate is presented either without calculation as a presumed value or with less accurate approximations. To the best of our knowledge, the refreshing rate has not been derived analytically in the literature. However, the refreshing rate has a significant impact on the signaling and hence it should be considered for a proper analysis and precise results. Furthermore, most of the literature studies do not consider the session duration as a parameter in order to calculate the average number of active sessions at a time. This parameter, however, highly affects the signaling between the communicating nodes and should be considered properly.

Hence, we still miss a precise and complete analysis on all the mobility costs in MIPv6 and SIP, taking into consideration all the related parameters and their effects.

Mobile IPv6 (MIPv6)

Overview on MIPv6

In MIPv6 [START_REF]IETF RFC 3775[END_REF], each MN is always identified by its home address (HoA). While situated away from its home, the MN is also associated with a care-of address (CoA). The home agent (HA) maintains the MN's bindings between HoA and CoA. The HA is also the mobility anchor of the MN.

MIPv6 defines two modes of communication between the MN and the CN: MN performs the BU procedure with the CN. This binding is valid for a specified lifetime. The RR and BU procedures should be refreshed.

In this mode, the MN sends/receives data packets to/from the CN directly without passing through the HA. A new type of IPv6 routing header (Type 2) including an additional header is used.

Note that because the MN needs to exchange two of these messages via the HA using its HoA, the RO mode cannot be activated unless the MN uses the BT mode for a while. Thus, we define R ro to be the ratio between the number of packets sent in the RO mode and the total number of packets sent during the session (0 ≤ R ro < 1). Table 3.1 lists the mobility messages in MIPv6 with their sizes at the IP level [START_REF] Grech | An Analysis of Mobile IPv6 Signaling Load in Next Generation Mobile Networks[END_REF]. Table 3.2 lists the data packet and overheads sizes.

MIPv6 signaling and processing costs

In MIPv6, the MN performs upon an IP-handover the BU procedure with the HA. In order to activate the RO mode, the MN is requested to perform the BU procedure (including the return routability procedure) with each CN. All of these procedures should be refreshed periodically when the MN stays in the same sub-network.

Then the signaling cost (SC) in MIPv6 with RO is expressed as follows:

SC(mip) = (µ c + η bu c )(C bu ha + N cn C bu cn ), (3.1)
where µ c is the handover mean rate, η bu c is the refreshing mean rate for the BU procedure, N cn is the average number of CNs for an MN at a time, and finally C bu ha and C bu cn are respectively the unit costs of the BU procedures with the HA and with a CN, being expressed as follows (see Fig. 3.1 and Table 3.1):

C bu ha = (M bu + M ba )h mn,ha (3.2)
C bu cn = (M hoti + M hot )h mn,ha + (M hoti ′ + M hot ′ )h ha,cn + (M coti + M cot )h mn,cn + (M bu ′ + M ba ′ )h mn,cn . (3.3)
When the RO mode is not considered, then the signaling cost in default MIPv6 is expressed as follows:

SC(mip) = (µ c + η bu c )C bu ha . (3.4)
On the other hand, the processing cost (P C) represents the number of BU requests sent to the HA by an MN per unit time, to be calculated as follows:

P C(ha) = µ c + η bu c . (3.5)

MIPv6 data and tunneling costs

In MIPv6, there are two modes for delivering the data packets to the MN, the BT and RO modes. In the former, the packets are routed through the HA, where a tunnel is established between the MN and the HA. In the latter, the packets are transmitted directly between the MN and the CN, using an additional routing overhead. The RO mode cannot be activated unless the BT mode is used for a while (thus we have defined R ro as mentioned before).

Then the data cost (DC) in MIPv6 with RO is expressed as follows:

DC(mip) = N cn µ s N p/s [(1 -R ro )C packet bt + R ro C packet ro ], (3.6)
where N cn is the average number of CNs for an MN at a time, µ s is the session duration mean rate, N p/s is the average number of packets per session, and finally C packet bt and C packet ro are respectively the unit costs of sending a packet to the MN in the BT and RO modes, being expressed as follows:

C packet bt = (δ + τ )h mn,ha + δh ha,cn , (3.7)
C packet ro = (δ + θ)h mn,cn . (3.8)
When the RO is not considered, then R ro = 0 and hence the data cost in default MIPv6 is expressed as follows:

DC(mip) = N cn µ s N p/s C packet bt .
(3.9)

The tunneling cost (T C) is similar to the data cost, but it is dedicated to show the cost of the tunneling overhead. Thus, it is expressed as follows:

T C(mip) = N cn µ s N p/s [(1 -R ro )τ h mn,ha + R ro θh mn,cn ]
(3.10)

Session Initiation Protocol (SIP)

Overview on SIP

SIP [START_REF]SIP: Session Initiation Protocol[END_REF] introduces several logical entities to the network. For each domain (e.g. example.com) there is an SIP proxy and a registrar server (RS). SIP identifies each user by a unique SIP-URI (e.g. alice@example.com). In order to associate the SIP-URI with the current IP address, the user sends a REGISTER to the RS which writes the binding and replies by an OK. This binding is valid for a specified lifetime (the default value is 3600 seconds [START_REF]SIP: Session Initiation Protocol[END_REF]), hence it should be refreshed. In order to initiate a communication in SIP, the caller is required to send an INVITE to the callee which replies by an OK, and then the caller confirms by an ACK.

SIP can support terminal mobility as follows [START_REF] Schulzrinne | Application-layer mobility using SIP[END_REF] (see Fig. 3.2). Upon undergoing an IP-handover, the MN performs the INVITE procedure with the CN informing it of its new IP address (without changing the session identifier). The MN also performs the REGISTER procedure with the RS.

Compared to MIPv6 where the HA is a centralized entity in the data plane, SIP is an end-to-end protocol; data packets are transmitted directly between the MN and its CNs.

The mobility messages in SIP are listed in Table 3.3 with their sizes at the IP level [START_REF] Dutta | Application Layer Mobility Management Scheme for Wireless Internet[END_REF].

SIP signaling and processing costs

In SIP, the MN performs upon an IP-handover the REGISTER procedure with the RS. This procedure should be refreshed periodically when the MN stays in the same sub-network. The MN performs also the INVITE procedure with each CN (it is not requested to refresh this procedure). Then the signaling cost (SC) in SIP is expressed as follows:

SC(sip) = (µ c + η register c )C register rs + µ c N cn C invite cn , (3.11)
where µ c is the handover mean rate, η register c is the refreshing mean rate for the REG-ISTER procedure, N cn is the average number of CNs for an MN at a time, and finally C register rs and C invite cn are respectively the unit costs of the REGISTER procedure with the RS and the INVITE procedure with a CN. They are expressed as follows (see Fig. 3.2 and Table 3.3):

C register rs = (M register + M ok )h mn,rs , (3.12
)

C invite cn = (M invite + M ok ′ + M ack )h mn,cn . (3.13)
On the other hand, the processing cost (P C) represents here the number of REG-ISTER requests sent to the RS by an MN per unit time, to be calculated as follows:

P C(rs) = µ c + η register c . ( 3

SIP data and tunneling costs

In SIP, all of the data packets are sent directly between the MN and the CN without any tunneling. Then the data cost (DC) in SIP is expressed as follows:

DC(sip) = N cn µ s N p/s C packet sip . (3.15)
where C packet sip is the unit cost of sending a packet to the MN in SIP. It is expressed as follows:

C packet sip = δh mn,cn . (3.16)
Note that this is also the data cost when using standard IP.

There is no tunneling in SIP, hence:

T C(sip) = 0 (3.17)
3.4 Mixed MIPv6-SIP (MMS)

Overview on MMS

SIP supports mobility for SIP-based sessions only, but does not for other IP sessions as MIPv6. Then, in a real scenario we need MIPv6 besides SIP in order to support mobility for all IP sessions. Thus, we take into consideration in our study the joint use of MIPv6 and SIP as a mobility management approach and we call it mixed MIPv6-SIP (MMS); SIP supports mobility for the SIP-based sessions and MIPv6 does for the others. Considering this approach also shows if there is an interest in (or how much we can gain by) introducing SIP besides MIPv6 for global mobility management.

In this approach, the MN needs upon an IP-handover to update its bindings at both the HA and the RS. The BU and REGISTER messages need to be refreshed, where each has a different lifetime. The MN needs also to update its IP address at its CNs either by the INVITE procedure for SIP-based sessions or by the MIPv6 procedure of RO mode (when considering RO) for the other sessions. Fig. 3.3 shows an example where the MN undergoes an IP-handover while communicating with two CNs one of them is with an SIP-based session.

The way of delivering data packets to the MN depends on the session type. For the SIP-based sessions, data packets are routed directly without tunneling between the CN and the MN. For the rest of the sessions, to be supported by MIPv6, data packets are routed either in the BT mode or the RO mode of MIPv6. Note that when using MIPv6, the RO mode may be either activated (MMS+RO) or not (MMS).

MMS signaling cost

In this approach, the MN performs upon an IP-handover the REGISTER procedure with the RS and the BU procedure with the HA. The MN performs the INVITE procedure with the CNs having SIP-supported sessions, and the BU procedure with the rest of the CNs (to activate the RO mode of MIPv6 if considered). We denote by P sip cn the probability that the CN's session is SIP-supported. These procedures (except the INVITE procedure) should be refreshed as mentioned before.

Then, the signaling cost (SC) in MMS is expressed as follows:

SC(mms) = (µ c + η register c )C register rs + µ c P sip cn N cn C invite cn + (µ c + η bu c )[C bu ha + (1 -P sip cn ) N cn C bu cn ].
(3.18)

MMS data and tunneling costs

Since part of the sessions is using SIP (with probability P sip cn ) and the other part is using MIPv6, then the data cost (DC) in MMS is expressed as follows:

DC(mms) = P sip cn DC(sip) + (1 -P sip cn ) DC(mip). (3.19)
Consequently, the tunneling cost (T C) in MMS is expressed as follows:

T C(mms) = (1 -P sip cn ) T C(mip).
(3.20)

Numerical results and discussions

We present and discuss in this section the numerical results showing the impact of the cell's radius R and the average sessions arrival rate λ s on the mobility costs.

Based on the analytical models defined before, Fig. 3.4 illustrates the visited network where the MN is moving and the home network where the HA and the RS are located.

In addition, the default values of the analytical parameters are assumed to be as follows:

• h wl = 2 (i.e. equivalent to 2 hops),

• h internet = 16 hops [78] (= h ar,ha = h ar,rs = h ar,cn = h ha,cn ),

• v = 3 m/s = 10.8 km/hr (this is considered as an average speed for non-mobile, lowly-mobile and highly-mobile users),

• R ≈ 4000 m (to guarantee the peak performance e.g. in LTE networks), equivalent to A c = 40 km 2 when considering hexagonal shaped cells.

• T bu = 420 s [START_REF]IETF RFC 3775[END_REF] (BU lifetime), and T register = 3600 s [START_REF]SIP: Session Initiation Protocol[END_REF] (REGISTER lifetime)

• λ s = 40/3600 s -1 (i.e. 40 sessions per hour for an MN),

• 1/µ s = 240 s = 4 min, and N p/s = 1000 packets (which is equivalent to an average throughput of 13 kbps per session for an MN),

• R ro = 0.8,

• P sip cn = 0.5.

Internet

Impact of the cell's radius

First, we investigate the impact of the cell's radius R. We consider all of the default values and we vary R from 600 to 6250 meters in order to study different deployment scenarios where the cell's area is between 1 and 100 km 2 . This affects the handover rate, µ c , as well as the refreshing rates of the BU and REGISTER procedures, η bu c and η register c , respectively. We are then interested in the impact on the signaling cost and processing cost.

Signaling and processing costs Fig. 3.5 shows the variation of the signaling cost as a function of R. As R increases the residence time in a cell increases. Hence, the handover rate decreases but the refreshing rate increases. Since the binding lifetime in MIPv6 is relatively short, the signaling cost in MIPv6 decreases more slightly than in SIP. Moreover, while the BUs with all the CNs are required to be refreshed in MIP+RO, the INVITE in SIP is not required to be refreshed. This leads to higher signaling cost in MIP+RO than in SIP for large cells. This also leads to slight degradation in the signaling cost of MIP+RO even when setting the BU lifetime T bu = 3600 seconds as depicted in Fig. 3.6. However, in this case the signaling cost of SIP is the highest because its messages are text-based and hence relatively large. The SC of MMS+RO is relatively high in both cases due to the need of both home registrations of MIPv6 and SIP. Fig. 3.7 depicts the processing cost at the HA and RS (BU lifetime T bu = 420 seconds, and REGISTER lifetime T register = 3600 seconds). The processing cost shows the number of home registration requests sent by an MN per unit time. As it appears in the figure, the processing cost in MIPv6 is higher than that in SIP. This is because the refreshing rate in MIPv6 is much higher. When setting the BU lifetime T bu = 3600 seconds, the two processing costs are equal.

Impact of the sessions arrival mean rate

Now we examine the impact of the sessions arrival mean rate, λ s . We consider all the default values for other parameters and we vary λ s from 0 to 300/3600 sessions per second (i.e. 0 to 300 sessions per hour for an MN). As λ s increases, the average number of CNs for an MN at a time N cn increases. Hereafter, we show the variation of mobility costs with respect to N cn .

Signaling cost

Fig. 3.8 shows the variation of the signaling cost with respect to N cn . In fact, the required number of home registrations is not affected but more CNs bindings are needed (except if not activating the RO mode of MIPv6). While these bindings are not required to be refreshed in SIP, they should be refreshed in MIPv6 in a relatively high rate (their lifetime is 7 minutes at most [START_REF]IETF RFC 3775[END_REF]). This explains why the signaling cost in MIPv6+RO increases more sharply than that of SIP.

Data and tunneling costs

Fig. 3.9 shows the variation of the data cost with respect to N cn . As N cn increases, the average number of simultaneous active sessions increases and hence the data cost increases. SIP provides the lowest cost due to direct routing path between the communicating nodes and also since there is no tunneling. On the other hand, MIP (without RO) has the highest cost due to non-optimal routing and also tunneling. The data cost in MIP+RO is higher than that in SIP. This is because the RO mode cannot be activated in MIPv6 unless the BT mode is used for a while, and also since the RO mode needs an additional tunneling overhead. However, SIP supports mobility for SIP-supported sessions but not all IP sessions. When having one-type sessions such as VoIP and IP TV, providing mobility can be achieved by SIP only. But when having several types of sessions, MMS can reflect a more realistic scene for a typical MN. When comparing MMS to MIP and MMS+RO to MIP+RO, we note generally that introducing SIP to the mobility management scheme and using it when possible reduces the data cost and hence is recommended. Fig. 3.10 shows the variation of the tunneling cost with respect to N cn . In fact, the tunneling cost is included in the data cost but we separate it here in order to compare the effects of tunneling overhead to those of routing path. We note that the tunneling cost in MIP+RO is higher than that of MMS, while it is the inverse for their data costs.

Conclusions and Perspectives

In this chapter, we have modeled the mobility costs of the global mobility management schemes MIPv6, SIP, and their integration MMS. We have considered all the related aspects, including the refreshing rates and the session duration. Note that these two parameters are rarely considered in the literature while they should be considered for a proper analysis. Finally, we have provided a comparative cost analysis by investigating the impact of several parameters such as cell's radius and sessions arrival mean rate.

It has been shown that the binding refreshing has a significant effect, especially in MIPv6, on both signaling and processing costs. This increases the load on the wireless bandwidth as well as the risks of encountering scalability issues at the centralized entities.

The data packet delivery cost is mainly affected by primely the routing path and secondarily the tunneling overhead. It is much higher than the signaling cost; thus, it is worth optimizing the data plane in order to enhance the mobility management scheme. This might be accomplished by introducing SIP besides MIPv6 for global mobility support: SIP supports mobility for SIP-based sessions and MIPv6 for other IP sessions.

Finally, compared to the other approaches, the default mode of MIPv6 (bidirectional tunneling) is the only scheme that does not require any additional capabilities at the CN. However, it does not allow optimal routing path between the MN and CN which leads to relatively high data packet delivery cost. This issue might be solved with distributed mobility management (DMM). DMM is expected, thanks to its design, to route optimally, without tunneling, a significant percentage of data traffic.

Management Schemes

After studying in the previous chapter the global mobility management schemes, we carry out in this chapter a cost analysis on the local mobility management schemes. These two studies are complementary in order to cover both categories and hence be able to complete the scene.

Similarly to the previous chapter, we apply the analytical models and general forms of the costs expressions on the different schemes. Then, we investigate the impact of several parameters in order to draw out conclusions and perspectives.

The study and results presented in this chapter have been published in [P1, P6].

Introduction

IPv6 mobility management has started with mobile IPv6 (MIPv6) [START_REF]IETF RFC 3775[END_REF], which has been standardized in 2004. As discussed before, MIPv6 is host-based and supports global mobility for a mobile node (MN) while moving around in the IPv6 Internet. After, discussions have been initiated on specifying a network-based mobility protocol that is designed/optimized for local mobility support in a single operational domain. For this objective, the network-based localized mobility management (NETLMM) working group [START_REF]IETF NETLMM WG[END_REF][START_REF]Problem Statement for Network-Based Localized Mobility Management (NETLMM)[END_REF] has been chartered in IETF at that time. Several years of work resulted in standardizing a new protocol in 2008, namely proxy mobile IPv6 (PMIPv6) [START_REF]IETF RFC 5213[END_REF].

PMIPv6 inherits the concepts of MIPv6 and adapts them for network-based local mobility support. However, there is still a centralized anchor entity; all the data traffic of all MNs passes through this entity and all the bindings are managed at it as well. This may lead to several scalability and performance issues, as discussed before. Thus, and since the standardization of PMIPv6, there have been efforts to design a novel extension of PMIPv6 that is "distributed." One of the early (the first, to the best of our knowledge) proposals is dynamic mobility anchoring (DMA) [START_REF] Bertin | A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures[END_REF][START_REF] Bertin | Distributed or Centralized Mobility?[END_REF][START_REF] Bertin | An Evaluation of Dynamic Mobility Anchoring[END_REF][START_REF] Seite | Distributed Mobility Anchoring[END_REF][START_REF] Louin | Network and Host Based Distributed Mobility[END_REF]. The most important is that DMA is still alive since 2008 through IETF contributions in the distributed mobility management (DMM) working group [START_REF]IETF DMM charter[END_REF] which has been chartered recently in 2012, and this is promising in terms of standardization.

Both PMIPv6 and DMA are network-based and designed for local mobility support.

In this chapter, we consider them in a comparative cost analysis as the representatives of centralized and distributed approaches. This analysis is interesting as it could evaluate how much we gain with a distributed approach with respect to a centralized one.

Proxy Mobile IPv6 (PMIPv6)

Overview on PMIPv6

As mentioned above, PMIPv6 [START_REF]IETF RFC 5213[END_REF] is a mobility protocol that provides mobility management in a localized domain, called PMIPv6-domain. Compared to MIPv6, the main feature in PMIPv6 is to be network-based. This means that the MN is not required to participate in any mobility-related signaling. Instead, the network handles the mobility management on behalf of the MN. In order to achieve this, PMIPv6 introduces two network entities, namely the local mobility anchor (LMA) and the mobile access gateway (MAG). The former is the home agent [START_REF]IETF RFC 3775[END_REF] for the MN in a PMIPv6-domain. The latter is a function on an access router (AR) that manages the mobility-related signaling for an MN that is attached to it.

Upon an IP handover from one MAG to another, the binding is updated at the LMA as follows.

The previous MAG detects the MN's movement (the mechanism for MN's movement detection is not specified in PMIPv6, but some possible options are link-layer events or an IPv6 neighbor unreachability detection event). The previous MAG sends then a proxy binding update (PBU) to the LMA de-registering the MN (a PBU with lifetime set to zero). The LMA replies by a proxy binding acknowledgement (PBA).

On the other hand, the new MAG detects the MN's attachment and sends a PBU to the LMA on behalf of the MN. After processing the PBU, the LMA detects that there is already a binding for that MN (based on the MN identifier). The LMA updates the binding (in particular by the proxy care-of-address of the new MAG) and hence the tunnel/routing information in order to handle properly the MN's traffic. The LMA sends a PBA to the new MAG, including the same home network prefix(es) already assigned to the MN. The new MAG is then able to send a router advertisement (RA) with the same network prefix as the MN received from the previous MAG. Consequently, the MN does not detect a link change and it keeps the same address(es).

In order to properly provide the MN with session continuity, the new MAG must discover and use the same LMA that the previous MAG was using. The LMA discovery can be achieved through one of the solutions proposed in [START_REF]Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6[END_REF]. Here, we consider the recommended solution in [START_REF]Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6[END_REF] which is as follows. First, the MAG receives the LMA's fully qualified domain name (FQDN) from the authentication, authorization and accounting (AAA) infrastructure during the network access authentication. Then, the MAG resolves the FQDN to the LMA's IP address through a domain name system (DNS) lookup. PMIPv6 manages all the sessions in the same way. All the data traffic of the MN passes through the LMA. A tunnel is established between the LMA and the MAG that is currently serving the MN in order to forward the data packets from/to the MN. Fig. 4.1 shows the mobility management in PMIPv6. Table 4.1 lists data packet, overhead and message sizes, at IP level. Note that we consider same size for signaling messages since they are similar in PMIPv6 and DMA.

PMIPv6 signaling and processing costs

In PMIPv6, upon a handover, the previous MAG deregisters the MN at the LMA. After discovering the LMA through a DNS lookup, the new MAG registers the MN. Then, signaling cost (SC) in PMIPv6 is expressed as follows (see Fig. 4.1):

SC(pmip) = µ c (C binding pmip + C dns pmip ) + (µ c + η bu c )C binding pmip , (4.1)
where µ c is the handover mean rate, η bu c is the refreshing mean rate for the BU procedure, and finally C binding pmip and C dns pmip are respectively the unit costs of registration/deregistration and DNS lookup in PMIPv6, being expressed as follows:

C binding pmip = (M pbu + M pba )h ar,lma , (4.2)
C dns pmip = (M dns_q + M dns_r )h ar,dns .

The processing cost (P C) represents the average number of PBUs sent per unit time to the mobility anchor LMA in PMIPv6, P C(lma). It is expressed as follows:

P C(lma) = 2µ c + η bu c , (4.4)

PMIPv6 data and tunneling costs

PMIPv6 manages all the data traffic of the MN similarly; all of it passes through the LMA, where a tunnel is established between the current MAG serving the MN and the LMA. Then, the data cost (DC) in PMIPv6 is expressed as follows:

DC(pmip) = N cn µ s N p/s C packet pmip , (4.5)
where N cn is the average number of CNs for an MN at a time, µ s is the session duration mean rate, N p/s is the average number of packets per session, and C packet pmip is the unit cost of delivering one packet in PMIPv6. The latter is expressed as follows (see Fig. 4.1 and Table 4.1):

C packet pmip = δh wl + (δ + τ )h ar,lma + δh lma,cn . (4.6)
The tunneling cost (T C) is similar to the data cost but it is dedicated to represent the cost of adding tunneling overheads. Then, the tunneling cost in PMIPv6 can be derived from its data cost by setting δ = 0, and hence is expressed as follows:

T C(pmip) = N cn µ s N p/s (τ h ar,lma ).

(4.7)

4.3 Dynamic Mobility Anchoring (DMA)

Overview on DMA

DMA [START_REF] Bertin | A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures[END_REF][START_REF] Bertin | Distributed or Centralized Mobility?[END_REF][START_REF] Bertin | An Evaluation of Dynamic Mobility Anchoring[END_REF][START_REF] Seite | Distributed Mobility Anchoring[END_REF][START_REF] Louin | Network and Host Based Distributed Mobility[END_REF] relies on a distributed architecture. Mobility management is moved to the network edge in order to anchor the traffic closer to the MN, rather than at a centralized entity in the core network. This is necessary in order to cope with the rapid increase in mobile data traffic, avoiding any network bottleneck.

DMA is required to support the local mobility only. The MN moves in a single operational domain. The operator of this domain is required to implement the DMA requirements at each AR. Each AR is required to have both mobility anchoring and location update functionalities, i.e. LMA and MAG; it is then referred to as mobility capable access router (MAR) [START_REF] Seite | Distributed Mobility Anchoring[END_REF]. Hence, it is guaranteed that the MN is always attached to an AR that can act as a mobility anchor.

Compared to PMIPv6 where all the data traffic is anchored at the same entity, i.e. the LMA, dynamic anchoring means to change the anchoring point for new sessions. This allows the MN to always initiate new sessions using the current IP address. The data traffic is then routed optimally without tunneling. If these sessions are terminated before undergoing an IP handover, then there is no need to keep the MAR where they were initiated as an anchor. On the other hand, if the MN undergoes an IP handover before terminating these sessions, then the mobility management is needed and activated dynamically.

In what follows we consider the DMA newest proposal in IETF, described in [START_REF] Seite | Distributed Mobility Anchoring[END_REF]. This proposal is based on PMIPv6 and hence considered as PMIPv6-based DMM.

Since the MN moves inside a single operational domain, the network is able to manage the mobility. The new MAR sends on behalf of the MN a proxy binding update (PBU) to the previous MAR, which replies by a proxy binding acknowledgement (PBA). A tunnel is then established between the new MAR and previous MAR of the MN. The data traffic of the sessions that are initiated at the previous MAR is then routed via this tunnel. Tunneling is used in this case in order to guarantee session-continuity as well as to avoid complicated procedures such as context transfer. Otherwise, the session may break down if the new MAR is used directly because of the change in MN's IP address.

However, the MN initiates new sessions after the handover using the new IP address. The data traffic of these new sessions is routed optimally. As a result, DMA is expected to route optimally, without tunneling, most of the data traffic based on statistics showing that more than 60% of sessions are non-mobile [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF].

In order to be able to send PBU(s), the new MAR needs to know some additional information. This information includes the IP addresses of the MN's previous MAR(s) used for anchoring the MN's previous sessions, and the associated active IP addresses of the MN. One would ask how does the new MAR knows such information. Hereafter are two different options that allow the new MAR to know such information.

Option 1: Relying on the MN

The MN knows all the information about its IP addresses, its sessions and associated anchors. The MN creates a database and updates it upon initiating or terminating a session. The new MAR retrieves the needed information from the MN by sending to it an Info Query (IQ). The MN replies by an Info Reply (IR). Then, the new MAR sends the PBU(s) on behalf of the MN. This option does not introduce any new network entity but the MN is no longer agnostic of the mobility support. Since the MN participates, even partially, in the mobility-related signaling, this option is considered host-based in IETF and the approach is no longer network-based.

Option 2: Relying on a Database

In order to achieve a network-based solution without the participation of the MN in the mobility management signaling, the architecture is partially distributed and relies on a database (DB) [START_REF] Seite | Distributed Mobility Anchoring[END_REF] in the network. The DB stores ongoing mobility sessions for all the MNs. For each MN, the DB stores its active IP addresses and associated anchors' IP addresses. The DB is expected to be updated each time an MN configures or releases an IP address. When the MN attaches to a new MAR, this MAR retrieves the needed information from the DB through an Info Query (IQ). The DB replies by an Info Reply (IR). Then, the new MAR sends the PBU(s) on behalf of the MN.

This option does not affect the MN and keeps the approach network-based. However, it introduces a centralized entity in the control plane of the network. The approach is then considered partially distributed and no longer fully distributed.

For the cost analysis, we consider the second option only since it is the networkbased one, which keeps the comparison with PMIPv6 fair. Fig. 4.2 illustrates generally the mobility management in DMA Option 2. Note that the MN might undergo an IP handover either while idle, or while having one or more sessions anchored at one or more MARs.

DMA signaling and processing costs

In DMA, upon a handover, the new MAR retrieves the IP addresses of the anchoring MARs for the MN from the DB. The new MAR registers then the MN at all these MARs. Then, signaling cost (SC) in DMA is expressed as follows (see Fig. 4.2):

SC(dma) = µ c C db dma + (µ c + η bu c )N anchor C binding dma , (4.8)
where µ c is the handover mean rate, η bu c is the refreshing mean rate for the BU procedure, N anchor is the average number of anchors for an MN at a time, and finally C db dma and C binding dma are respectively the unit costs of the information retrieval and the registration procedures, being expressed as follows:

C db dma = (M db_q + M db_r )h ar,db , (4.9)
C binding dma = (M pbu + M pba )h ar,ar .

(4.10)

The processing cost (P C) represents the average number of PBUs sent per unit time to a mobility anchor MAR in DMA, P C(mar). Assuming a uniform distribution for the MNs in the N cells, it is expressed as follows:

P C(mar) = (µ c + η bu c )N anchor N . (4.11)
One would ask about the average number of lookups performed per unit time at the DNS server in PMIPv6 and at the sessions' database in DMA. In fact, both are equal to the handover rate µ c since a lookup is performed upon a handover. We do not consider these processing costs since they do not represent binding updates but only lookups.

DMA data and tunneling costs

DMA distinguishes new and handover traffics. While the former is routed directly to the CN, the latter is tunneled to the anchoring MAR and then routed to the CN. Then, the data cost (DC) in DMA is expressed as follows:

DC(dma) = N cn µ s N p/s (P n C packet dma-direct + P h C packet dma-indirect ), (4.12)
where N cn is the average number of CNs for an MN at a time, µ s is the session duration mean rate, N p/s is the average number of packets per session, P n and P h are respectively the probabilities that a traffic is a new or handover traffic, and finally C packet dma-direct and C packet dma-indirect are respectively the unit costs of delivering one packet in the direct and indirect modes of DMA, being expressed as follows (see Fig. 4 Consequently, the tunneling cost (T C) in DMA can be derived from its data cost by setting δ = 0, and hence it is expressed as follows:

T C(dma) = N cn µ s N p/s (P h τ h ar,ar ).

(4.15)

Numerical results and discussions

In this section, we present and discuss the numerical results. We study the impact of several parameters such as cell's radius R, average sessions arrival rate λ s , and network scale ξ on the mobility costs.

The default values of the system parameters are assumed to be as follows.

• Network Model:

-K = 3 rings ⇒ N = 37 cells,
h wl = 2 (i.e. equivalent to 2 hops),

h ar,ar = √ N hops ⇒ h ar,ar ≈ 6 hops,

h ar,central = 12 hops (= h ar,lma = h ar,dns = h ar,db ).

-Generally, the average number of hops between two neighbor ARs is less than that between an AR and a centralized entity, i.e. network scale is ξ ≤ 1. In the literature, the default value of this ratio is generally considered between 0.2 and 0.5, e.g. [START_REF] Lee | How much do we gain by introducing route optimization in Proxy Mobile IPv6 networks?[END_REF][START_REF] Zhang | P-MIP: Paging Extensions for Mobile IP[END_REF][START_REF] Lee | Shall we apply paging technologies to Proxy Mobile IPv6?[END_REF][START_REF] Gohar | Network-Based Distributed Mobility Control in Localized Mobile LISP Networks[END_REF][START_REF] Lee | A competent global mobility support scheme in NETLMM[END_REF]. In our case, the default value of the network scale is ξ = 0.5. However, we investigate later the impact of this parameter on the different costs.

• Mobility model:

v = 3 m/s = 10.8 km/hr (this is considered as an average speed for nonmobile, lowly-mobile and highly-mobile users),

-R ≈ 4000 m (to guarantee the peak performance e.g. in LTE networks), equivalent to A c = 40 km 2 when considering hexagonal shaped cells.

• Traffic model:

λ s = 40/3600 s -1 (i.e. 40 sessions per hour for an MN),

-1/µ s = 240 s = 4 min, and N p/s = 1000 packets (which is equivalent to an average throughput of 13 kbps per session for an MN),

Impact of the sessions arrival mean rate

First, we investigate the impact of the sessions arrival mean rate λ s . We consider all of the default values except that of λ s . We vary λ s from 0 to 300/3600 sessions per second (i.e. 0 to 300 sessions per hour). This means that the average number of CNs for an MN at a time N cn varies from 0 to 20. Fig. 4.3 shows the variation of the signaling cost as a function of N cn . In PMIPv6, the signaling cost is constant since the number of ongoing sessions has no effect on the signaling. On the other hand, DMA is flow-based and hence the signaling cost increases as the number of handover sessions increases. In fact, a large percentage of sessions does not undergo any handover and hence does not need mobility support in DMA. Furthermore, the signaling messages in DMA are exchanged between the ARs rather than between the ARs and the LMA (which is centralized) as in PMIPv6. Thus, the signaling cost in DMA is still less than that in PMIPv6 even when communicating with 20 different CNs at a time on average, which is an extreme case, especially since assuming that each session is with a different CN. Fig. 4.4 shows the variation of the data cost as a function of N cn . It appears that DMA outperforms PMIPv6. This is because a large percentage of data traffic is routed directly between the MN and its CNs. Even for tunneled traffic, the tunnel is between ARs in DMA, rather than between an AR and the LMA as in PMIPv6. Note that the data cost is much higher than the signaling cost and hence it is worth optimizing the data plane. Fig. 4.5 shows the variation of the tunneling cost as a function of N cn . It appears clearly that the tunneling cost in PMIPv6 is much higher than that in DMA. This is because in PMIPv6 all of the data traffic of the MN is tunneled to the LMA before being forwarded to the CNs. In DMA, most of data traffic is routed optimally without tunneling.

Impact of the cell's radius

Now, we investigate the impact of the cell's radius R. We consider all of the default values except that of R. We vary R from 600 to 6250 m. This means that the cell's area varies between 1 and 100 km 2 . Fig. 4.6 shows the variation of the signaling cost as a function of R. As R increases, the residence time in a cell increases and hence the handover rate decreases. Thus, the signaling costs in both PMIPv6 and DMA decreases. It appears that the signaling cost in DMA is less than that in PMIPv6. Fig. 4.7 shows the variation of the processing cost as a function of R. It appears clearly that the PC at the LMA is much higher than that at an MAR. This is due to distributing the management of the binding updates at the AR level in DMA. Fig. 4.8 shows the variation of the data cost as a function of R. Although the handover rate is varying, the data cost in PMIPv6 does not vary. This is because PMIPv6 manages all the data traffic similarly. On the other hand in DMA, as the handover rate decreases, the percentage of new traffic (which is routed directly and without tunneling) increases and hence the data cost decreases. Nevertheless, the data cost in PMIPv6 is always more than twice that in DMA.

Impact of the network scale

As mentioned before, the default value of the network scale ξ is considered to be 0.5. Now we examine the effect of this parameter on the costs in order to to verify if there is a significant impact or not. We vary the average number of hops between two ARs h ar,ar from 1 to 12 hops. Thus, the network scale is varied from 1/12 to 1.

Fig. 4.9, Fig. 4.10, and Fig. 4.11 show respectively the variation of the signaling cost, data cost, and tunneling cost as a function of the network scale ξ. Note that this parameter has no impact on PMIPv6 since signaling, data packets routing, and tunneling relationships are always between the MAG (at AR) and the LMA (centralized). In DMA, the mobility functions are moved to the ARs level and hence the mentioned relationships are mainly between the ARs themselves. Thus, the network scale parameter has an impact on DMA. However, it appears that the costs in DMA are always less than in PMIPv6, even for ξ = 1 which is an extreme case. This confirms the previous results and analysis.

Conclusions and Perspectives

In this chapter, we have presented a comparative cost analysis on the local mobility management schemes PMIPv6 and DMA. PMIPv6 and DMA have been considered as the representatives of centralized and distributed schemes, respectively. We have modeled the mobility costs for both schemes. Numerical results have been presented by investigating the impact of several parameters such as sessions arrival mean rate, cell's radius, and network scale.

It has been shown that DMA outperforms PMIPv6 significantly in optimizing the network resources consumption as well as the mobility management performance. Hereafter, we address some particular conclusions regarding distributed dynamic mobility management, such as DMA.

• Bindings-related messages are exchanged in the access network rather than with a centralized entity in the core networks. This reduces the loads in the core network as well as the global signaling cost.

• With a "distributed scheme", the bindings are managed in a distributed manner at different mobility anchors. This leads to a significant reduction in the processing cost per anchor. As a result, the risks of encountering scalability issues, e.g. single point of failure and attack, are avoided to a considerable extent.

• It has been mentioned that, based on statistics [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF], more than 60% of sessions are non-mobile. The results confirm that with a "dynamic scheme", the data packet delivery cost is reduced between 60% and 75%. This is due to the fact that most of data traffic is routed optimally without tunneling, thanks to the dynamic design. Consequently, network bottlenecks are avoided.

• Tunneling mechanisms are used if and only if needed. When an MN undergoes an IP handover with an ongoing session, data packets for this session need to be tunneled in order to guarantee session-continuity without relying on complicated procedures such as context transfer. As a result, tunneling cost is reduced dramatically.

All these conclusions encourage towards adopting distributed and dynamic mobility management.

Part III Protocol Design and Evaluation

Mobility Management

Introduction

As already discussed, there is a need to define novel mobility management mechanisms that are both distributed and offered dynamically in order to cope with the rapid increase in mobile data traffic. They should be distributed in order to avoid any network bottleneck or single point of failure, and to provide better reliability. They should be dynamic in order to increase the achieved performances and to globally reduce additional overheads. Accordingly, a new working group has been chartered in IETF called distributed mobility management (DMM) [START_REF]IETF DMM charter[END_REF].

For this novel mobility management, we rely on the existing mobility protocols by extending and adapting them. This is in order to benefit the standardized protocols that have been well specified, analyzed and implemented before specifying new ones. Moreover, this facilitates the migration of current network architectures towards the novel ones. Note that this is one of the DMM requirements in IETF [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF].

In addition, future wireless and mobile Internet is expected to be composed of several access networks and operational domains. A mobile user may move between different operational domains, and hence, there is a need for global mobility support beside the local one. While current DMM proposals focus mainly on local mobility support, e.g. dynamic mobility anchoring (DMA) [START_REF] Seite | Distributed Mobility Anchoring[END_REF], we intend to support both global and local scenarios and hence we do not rely on protocols that support local mobility only. Consequently, not only full deployment but also partial deployment of DMM functionalities is supported.

In this chapter, we propose a novel distributed dynamic mobility management scheme that is based on mobile IPv6 (MIPv6) [START_REF]IETF RFC 3775[END_REF], and hence we name it Distributed Dynamic MIPv6 (DDM). It provides both local and global mobility support, and consequently both full and partial deployments of DDM are taken into consideration.

In what follows, we present a use-case scenario in order to illustrate the current issues and to approach the basics of a solution. After identifying our requirements and objectives, we present the concepts of the proposed scheme DDM and then we detail its operations in different scenarios. In addition, we discuss the joint use of DDM with session initiation protocol (SIP).

Part of the ideas presented in this chapter has been published in [P3, P2].

Preliminaries

Use-case scenario

WiFi access technology is nowadays widely available in homes, cafés, hotels, offices, meeting rooms, etc. The user may be either motionless or moving within a WiFi radio access range for some time, e.g. one or two hours. In such situations, the usage of WiFi among other available access technologies, such as long term evolution (LTE), is preferred for some types of applications such as video streaming. This is because of, for example, a lower cost. Note that these different access networks may be managed by the same operator or by different operators.

In our use case scenario, the user has an LTE/WiFi mobile terminal. The user moves from the range of a WiFi radio access (WiFi 1) to another (WiFi 2), e.g. from home to café. The ranges of the two WiFi radio accesses are separated, and an LTE radio access which covers wider radio range is available in-between. For each of WiFi 1, WiFi 2 and LTE access networks there is an access router (AR). Fig. 5.1 shows the scenario's topology.

While located within the radio access range of WiFi 1, the user is attached to access router AR1 with IP address IP@1. The user initiates several communications. Some of the communications (referred to as Coms1) have a short lifetime, e.g. TCP connections for SMTP or HTTP sessions, and they are terminated before the movement of the user outside the radio access range of WiFi 1. Some of the communications (referred to as Coms2) continue after the movement of the user, e.g. a SIP-based communication and an IP-based communication.

Then, the user moves outside the radio access range of WiFi 1. The only available access technology is then LTE. An inter-access handover occurs and the user is hence attached to access router AR2 with IP address IP@2. The user is now connected through the LTE radio access. The Coms2 communications are still going on.

Then, the user enters the radio access range of WiFi 2 and remains there for some time, e.g. one or two hours. Although the LTE radio access is still available, the usage of WiFi 2 radio access is the preferred one. Another inter-access handover occurs, and hence the user is attached to access router AR3 with IP address IP@3. The user is now connected through WiFi 2 radio access. The Coms2 communications are still going on. The user also initiates some new communications (referred to as Coms3). The Coms2 and Coms3 communications are terminated while the user is still attached to AR3.

Approach roots

In what follows we describe the different mobility management approaches with respect to the use-case scenario defined above.

With centralized mobility management, all of the Coms1, Coms2, and Coms3 communications' data flows are anchored at the same entity in the home network that acts as mobility anchor. On the other hand, we may distribute the mobility anchoring function at the AR level. Then each communication could be anchored at the local AR where it is initiated, i.e. current point of attachment. Thus, with distributed mobility anchoring the data flows of Coms1 and Coms2 communications could be anchored at AR1, and that of Coms3 communications could be anchored at AR3. The Coms1 and Coms3 communications are initiated and terminated while the user is attached to AR1 and AR3, respectively. In other terms, the user does not change the point of attachment during the lifetime of each of these communications and hence they do not need mobility support. In such situations, it is more effective to initiate each communication using the local IP address (i.e. the IP address acquired at the current point of attachment) and the standard IP forwarding and routing mechanisms (no tunneling and no mobility context to be stored at the anchor point). Hence, instead of always activating the mobility support, we may activate it only when needed. This kind of dynamic activation/deactivation of mobility support makes the mobility management more flexible, and hence it is expected to reduce significantly the mobility costs.

Each of Coms2 communications undergoes two handovers. Hence, there is need for mobility support in order to provide session continuity; otherwise, some of these communications may not survive due to the IP address change. Handling mobility events needs a protocol that supports mobility. While Coms2 communications are various, the best suitable protocol may differ from one communication to another. Thus we may choose activating a different protocol for each communication. Let us consider for instance that the Coms2 communications include a SIP-based communication (where the mobility can be handled at the application layer by SIP) and an IP-based communication (where the mobility should be handled at the IP layer). Then, to support mobility we may choose e.g. SIP for the former and MIPv6 for the latter.

Requirements & Objectives

As a result of all the conclusions and perspectives of our different analysis studies discussed in previous chapters, we define the following requirements for our new approach:

• Rely on an all-IPv6 network architecture;

• Rely on existing protocols by adapting and extending them • Distribute mobility anchoring at the access routers level, and avoid any centralized entity even in control plane;

• Support flow-based mobility and dynamically activate/deactivate mobility support for each flow as needed;

• Provide both local and global mobility support for IPv6 mobile hosts;

• Consider both scenarios of full and partial deployment of the mobility functions at the access routers, i.e. deploy the mobility functions at each access router or at some of them;

• Provide reachability for incoming SIP-based sessions such as voice over IP (VoIP) calls and text messaging.

In addition, we define the following objectives:

• Optimize the routing path as much as possible, even with mobility-unaware CNs;

• Reduce the end-to-end delay (as a consequence of optimizing the routing path);

• Reduce the tunneling overhead as much as possible;

• Reduce the signaling loads as much as possible;

• Enhance the handover performance such as handover latency and packet loss;

• Reduce the scalability issues and single point of failures and attacks.

Distributed Dynamic MIPv6 (DDM)

Recall on MIPv6

As already presented, MIPv6 is a mobility protocol that provides global mobility support. Session continuity and reachability are maintained for the MN while undergoing IP handovers even when moving from one network to another. In order to achieve this, MIPv6 adopts a host-based approach where the MN participates in the mobility-related signaling.

In MIPv6, each MN is always identified by its home address (HoA). While situated away from its home, the MN is also associated with a care-of address (CoA). The home agent (HA) maintains the MN's binding between HoA and CoA. This binding is updated by the MN itself by sending a binding update (BU) upon each IP handover. The HA is also the mobility anchor of the MN. It is thus considered as a centralized entity in both data and control planes. It is typically implemented at a router, and announces that it is an HA through setting the "H bit" [START_REF]IETF RFC 3775[END_REF] in the router advertisement (RA) message.

DDM concepts

DDM is designed to adapt MIPv6 to the emerging flat IPv6 mobile networks architectures. It intends to confine the mobility support functions at the access routers (ARs) level, keeping the rest of the network unaware of the mobility events and their support. In particular, the HA functionalities are distributed at the ARs level.

In addition, DDM intends to activate dynamically the mobility support only when needed, i.e. when both the MN actually undergoes an IP handover and the applicative service needs the mobility support as well. Compared to MIPv6 where all the data traffic is anchored at the same entity, i.e. the HA, dynamic mobility management aims at changing the anchor for new sessions. In particular, new sessions in DDM are anchored at the current HA (deployed at the AR) and initiated using the current IPv6 address; the current IPv6 address is the MN's HoA for these new sessions and is associated to the current HA.

As a result, the MN may have several HoAs, each associated to an anchoring HA. This is achieved thanks to the IPv6 feature allowing an MN to use several IPv6 addresses simultaneously. The data traffic of the new sessions can be routed optimally without any tunneling between the MN and the CN, until the MN undergoes an IP handover. If the MN undergoes one or more IP handovers before the end of a session, then the data traffic of this session is tunneled between the MN and the anchor of this session.

DDM different scenarios

DDM is required to support global mobility besides local mobility. The MN may move between different access networks and operational domains. Thus, it is not guaranteed that the MN is always attached to an HA; the MN may attach to a classical AR that cannot act as a mobility anchor. In addition, the MN may attach to a legacy MIPv6 network. This pushes towards not modifying the HA functionalities in order to be compatible with those legacy MIPv6 networks. As a result, DDM has to exploit the DMM concepts taking into consideration the different cases and conditions mentioned above. Hence, we distinguish two different use-case scenarios as follows.

In the first scenario, the MN moves in a zone where the HA functionalities are distributed at the ARs level. A concrete example on this scenario is the operational domain of an operator implementing DMM. Then, each AR is an HA and can play the role of mobility anchoring. This enables the MN to always anchor its new sessions at its current HA. Upon attaching to an HA, the MN configures a new IP address. The MN uses this IP address as a source address to initiate new sessions. The data traffic of these sessions is then routed optimally without any need for tunneling. If these sessions are terminated before undergoing any IP handover, then there is no need to keep the HA as an anchor. If the MN undergoes one or more IP handovers before terminating at least one of these sessions, then the MN manages the mobility by sending a binding update (BU) to the HA which replies by a binding acknowledgement (BA). A tunnel is then established between the MN and the HA for the data packets of these sessions. After attaching to a new HA, the MN uses its new IP address to initiate new sessions.

In the second scenario, the MN moves in a zone where some of the ARs implement the HA functionalities but not the others. Two concrete examples on this scenario are the global mobility between different operational domains and the partial deployment of mobility functionalities. In order to know if it is attached to an HA or an AR, the MN checks during the attachment phase the "H bit" (as defined in the MIPv6 protocol [START_REF]IETF RFC 3775[END_REF]) in the RA message. If the "H bit" is set to one, then the MN is attached to an HA and hence can use it as an anchor for new sessions (as in the previous scenario). Otherwise, it is attached to a classical AR and hence should select one of the existing anchoring HAs as an anchor for the new sessions; new sessions are initiated using the MN's HoA associated to the selected HA and their traffic is tunneled via this HA (MN's CoA is the current IPv6 address). 5.4 illustrate an example on mobility management in DDM. In this example, the MN is attached to an HA and then moves towards another HA. This example can represent the local mobility scenario as well as some situations in the global mobility scenario (the latter is discussed later). In other terms, it can also represent the full deployment scenario where the DDM functionalities are deployed at each AR. Hereafter, we detail the DDM operations and mechanisms.

1. First, the MN attaches to HA1 and sends a router solicitation (RS) in order to receive the router advertisement (RA) rapidly (RS and RA are part of the neighbor discovery protocol (NDP) [START_REF]IETF RFC 4861[END_REF]). HA1 replies by an RA providing the MN with its network prefix.

HA1 sets the "H bit" [START_REF]IETF RFC 3775[END_REF] in the RA informing the MN that it is serving as an HA on this link.

We assume that the security protections for the link-layer and NDP are provided, e.g. through the usage of extensible authentication protocol (EAP) [START_REF]Extensible Authentication Protocol[END_REF] and secure neighbor discovery (SEND) [START_REF]IETF RFC 3971[END_REF] protocols.

2. The MN configures a new IPv6 address IP@HA1 through stateless address autoconfiguration [START_REF]IPv6 Stateless Address Autoconfiguration[END_REF] (it can also use a stateful address configuration protocol such as dynamic host configuration protocol for IPv6 (DHCPv6) [START_REF]IETF RFC 3315[END_REF]).

The MN performs the duplicate address detection (DAD) process [START_REF]IETF RFC 4861[END_REF][START_REF]IPv6 Stateless Address Autoconfiguration[END_REF] in order to validate IP@HA1 and verify its uniqueness. However, it is recommended to rely on optimistic DAD [START_REF]IETF RFC 4429[END_REF] in order to avoid additional handover delay.

3. As the MN is attached to an HA, it might use this HA as an anchor for some session(s) after undergoing an IP handover. This requires performing the BU procedure with this HA after the handover.

The BU signaling messages should be protected by IP security (IPsec) [START_REF]Security Architecture for the Internet Protocol[END_REF] as specified in [START_REF]IETF RFC 3775[END_REF][START_REF]Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents[END_REF]. Thus, the MN needs to create the required security associations (SA) with this HA if they are not present. This should be performed before the MN undergoes an IP handover and detaches from this HA.

Since the MN uses several HAs, the manual configuration of the SAs (as required in MIPv6 [START_REF]IETF RFC 3775[END_REF][START_REF]Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents[END_REF]) is probably not possible and hence the dynamic configuration defined in [START_REF]Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture[END_REF] should be used as follows.

The MN initiates an Internet key exchange (IKEv2) [START_REF]Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF] protocol exchange with HA1 just after configuring IP@HA1. The MN uses IP@HA1, which is its HoA at HA1, as an identifier; the SAs are associated to IP@HA1. Then, the IPsec SAs are negotiated for protecting the BU and BA messages when needed. HA1 links these SAs to IP@HA1 as the HoA for these SAs.

HA1 Session S1

Session S1

HoA Anchor Session IP@HA1 HA1 S1

Anchors/Sessions Database (b) IP-handover from HA1 to HA2. Note that security considerations are discussed in more details later in Chapter 7.

HoA Anchor Session

4. Then, the MN initiates a new session S1. The MN uses IP@HA1 as a source address for S1 since it is attached to an HA that can serve as an anchor.

The data traffic of S1 is routed optimally, without any tunneling.

5. Upon an IP handover, the MN attaches to HA2, configures a new IPv6 address IP@HA2 while keeping IP@HA1, and creates the SAs with HA2 (similar operations as in 1, 2, 3).

6. In order to maintain session continuity for S1, a tunnel should be established between the MN and HA1 for the data packets of S1.

Thus, the MN sends a BU (HoA: IP@HA1, CoA: IP@HA2) to HA1 which is considered as the anchor point for S1. The MN uses the IPsec SAs created with HA1 (at step 3) for authentication; the MN authenticates that it is the legitimate MN for this HoA through e.g. the shared secret or certificate created before.

After validating if these SAs are linked to the used HoA i.e. IP@HA1, HA1 accepts the BU and replies by a BA.

Note that the key management capability (K) flag [START_REF]IETF RFC 3775[END_REF] in the BU and BA messages should be set in order to survive a CoA change; the IKE SA endpoints are then able to be changed.

7. While attaching to HA2, the MN initiates a new session S2. The MN uses the current IP address IP@HA2 as a source address.

The data traffic of S2 is routed optimally, without any tunneling.

8. Upon terminating session S1, the tunnel between the MN and HA1 is torn down. Nothing changes for S2.

Note that if a session is initiated and terminated without undergoing any IP handover, then the mobility support is not needed and hence not activated; neither a new anchor nor a tunnel is needed.

To sum up, DDM distinguishes the new traffic (traffic for sessions that did not undergo any handover) and the handover traffic (traffic for sessions that did undergo a handover or more). The new traffic is routed optimally between the MN and the CN. The handover traffic is routed through the anchoring HA(s) by tunneling the data packets between the MN and the anchoring HA(s).

Anchors/sessions database in DDM

As mentioned above, the MN sends BU messages to its anchoring HA(s) upon an IP handover, if any. In order to perform this, the MN is required to create an anchors/sessions database. In this database, each entry includes:

• an HoA for the MN,

• the address of the associated anchoring HA for that HoA,

• the list of active sessions initiated using that HoA.

Upon an IP handover, the MN sends for each entry, if any, a BU to the registered anchoring HA using the associated HoA as the HoA and the current IPv6 address as the CoA.

The MN manages this database according to the following rules.

• The MN updates this database upon configuring a new HoA when attaching to a new HA, as well as upon initiating or terminating a session.

• The MN reserves an entry as long as it has at least one active session associated to that entry.

• The MN deletes an entry when all the active sessions in that entry are terminated.

• Even when the MN becomes idle, however, it keeps at least the most recent entry in order to avoid being without any active anchor and hence to be able to support global mobility as described in the next section.

Global mobility support in DDM

To provide global mobility support for the MN, session continuity should be maintained even if the MN moves from one access network to another one each located in a different operational domain. A feature in DDM is the re-use of HA functionalities and signaling messages defined in MIPv6. This is essential in the context of global mobility in terms of compatibility with legacy networks. In other terms, when the MN attaches to a legacy MIPv6 access network, it can still exploit and benefit the DDM concepts (to a certain extent).

In addition, partial deployments of DDM (i.e. deployment of DDM functionalities at some ARs but not all of them) should be supported.

However, DDM relies on distributing the HA functionalities at the ARs level. The fulfillment of this requirement depends on the serving network of the MN. Some networks, such as the MN operator's network, may fulfill this requirement; other networks may not (see Fig. 5.2).

Then, one would ask what if the MN departs towards a network not implementing the HA functionalities at each AR. In such network, the MN attaches either to an HA or to a classical AR. In order to distinguish these two cases, the MN checks during the attachment phase the "H bit" [START_REF]IETF RFC 3775[END_REF] in the RA message.

• If the "H bit" is set to one, then the serving AR is also functioning as an HA and hence could serve as an anchor. Then, the MN uses the new HA as a new anchor point for the new sessions (as described in the previous section).

• If the "H bit" is not set, then the serving AR is not an HA. Hence, the MN cannot use it as an anchor; otherwise session continuity cannot be maintained upon an IP handover. Thus, the MN selects one of its existing anchoring HAs as an anchor for the new sessions; new sessions are initiated using the MN's HoA associated to the selected HA. Tunneling mechanisms are then needed and the current IPv6 address is used as the MN's CoA. Fig. 5.5 illustrates the continuation of Fig. 5.3 where the MN undergoes an IP handover and attaches to an AR. The MN initiates session S3 using IP@HA2 as an HoA and the current IPv6 address IP@AR as a CoA. However, after attaching to HA3, the MN initiates new sessions (e.g. S4) using current IP address IP@HA3.

One would ask how to select one of the anchors if there are several. We basically consider that the best anchor is the nearest one to the MN topologically in terms of number of hops/delay (other criteria also could be used for anchor selection such as the loads on the anchors, service type, or end-to-end delay). The MN could know the nearest anchor when performing the BU procedure with each of its anchors. It could also ping simultaneously all its anchors just after attaching to a classical AR and before initiating a new session. This does not introduce any additional handover delays since this is performed after the handover.

To avoid being without any anchor, the MN is required to keep in its anchors/sessions database at least the most recent anchor even when becoming in idle mode. This anchor is used to anchor new sessions when the MN attaches to a classical AR if the MN does not have any active anchor.

HoA AnchorSession

Joint DDM-SIP (JDS)

The DMM requirements document [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF] mentions that DMM must provide transparent mobility support above the IP layer when needed. Such transparency is needed e.g. when a session cannot cope with a change in the IP address. However, it is not always necessary to maintain a stable home IP address/prefix for every session or at all times for an MN. Some sessions, e.g. SIP-based sessions, can handle mobility at the application layer and hence do not need IP mobility support; it is then more efficient to deactivate IP mobility support for such sessions [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF].

In this section, we introduce and discuss briefly the joint use of DDM and SIP, named joint DDM-SIP (JDS). JDS is introduced as an optional complement for the proposed DDM scheme. In other terms, the use of SIP beside DDM for mobility management is optional (but recommended) and the decision is left for the mobile network operator.

Concept of joint DDM-SIP

One of the main conclusions and perspectives of Chapter 3 is on the joint use of MIPv6 and SIP. In particular, using SIP for mobility support when possible, i.e. for SIP-based sessions, can reduce the network resources consumption as well as the end-to-end delay. This is due to the fact that SIP is an end-to-end protocol and hence the data traffic is routed optimally and even without any tunneling or anchoring. Consequently, nonoptimal routing, tunneling overheads, and network bottlenecks are naturally avoided.

Accordingly, we have mentioned such joint use of MIPv6 and SIP in our use-case scenario. After distributing mobility anchoring in MIPv6 through the design of DDM, hereafter we discuss using SIP beside DDM for mobility management. The motivation behind such approach is neither because DDM is insufficient nor due to the need of SIP beside DDM, but to reduce further the overhead and achieve better performance when possible.

Without introducing any protocol selection complexity, the MN can distinguish SIP-based sessions and other IP sessions simply as follows.

• If a session is initiated using SIP, which is session initiation protocol, then it is considered SIP-based and mobility for this session is supported by SIP. Note that there is no need to add SIP-based sessions to the anchors/sessions database since they do not need anchors.

Upon an IP handover, mobility is managed through the INVITE procedure (also called re-INVITE in this case) between the MN and relevant CN. The CN updates the MN's IP address in the data packets of the relevant session. Consequently, data packets for SIP-based sessions are always routed optimally, without relying on tunneling or anchoring mechanisms.

• Otherwise, the session is considered an IP session and mobility is supported by DDM. The anchors/sessions database should be updated in order to associate the session with the relevant HoA and HA, as already described.

Upon an IP handover, mobility is managed through the BU procedure between the MN and relevant HA (which then acts as the anchor for that session) in order to create an IP-in-IP tunnel.

As a result, the data packets of any session are routed optimally without tunneling before that session undergoes an IP handover thanks to DDM dynamic design and to SIP end-to-end property. After undergoing an IP handover, if any, data packets of IP (non-SIP) sessions need tunneling but those of SIP-based sessions do not. Therefore, it is expected to enhance the mobility management performance and to reduce the network resources consumption significantly.

It is worth mentioning that since we use SIP, the MN needs to send a REGISTER message to the SIP registrar server (RS) upon an IP handover in order to update its record with its new IP address. This is related to location management (reachability support but not session continuity) and will be discussed later in Chapter 7.

Source address selection

In traditional implementations of MIPv6 and PMIPv6, the MN has a permanent IP address, the HoA. The MN always uses its HoA as a source address (in the original IP header of the packet, not the IP tunneling header in MIPv6 case). Consequently, the change in MN's IP address is totally transparent to the application layer, where SIP acts. Hence, SIP never comes into play for mobility management.

In this context, one of the main issues is on the source address selection (SAS) mechanism, particularly, how to select the source IP address for each session upon an IP handover. IP mobility (IP address change) should be not transparent to SIP in order to let SIP manage mobility for SIP-based sessions. Otherwise, SIP will not be aware of the IP address change and consequently will not trigger the INVITE procedure in the MN to manage mobility. This is a crucial point for the joint use of SIP with an IP mobility protocol that acts at the IP layer.

In order to achieve this, the MN is required to maintain a list of the ongoing SIPbased sessions, each with the relevant CN IP address. Upon an IP-handover, the MN performs the INVITE procedure for each of these sessions with the relevant CN. Recall that the INVITE procedure consists of exchanging three messages between the MN and CN as follows. The MN sends INVITE to the CN updating its IP address by the current one but maintaining the same session ID, the CN replies by an OK, and then the MN confirms by an ACK. Then, the MN chooses the current IP address as a source address in the IP header of the SIP-based sessions data packets.

One would wonder if it is better to use DDM for a particular SIP-based session in some situations as follows. The MN initiates a SIP-based session (S1) and another IP session (S2) using the same IP address (IP@HA) while attached to an HA. The MN undergoes then an IP handover. The MN should perform the BU procedure with that HA to guarantee the session-continuity for S2. Why not to omit the INVITE procedure for S1. In fact, this is possible and this avoids the INVITE procedure signaling loads, but data packets for S1 are going to be sent to the HA first and then tunneled to the MN. From the cost point of view, and based on our previous cost analyses, it is more likely that the cost of non-optimal routing and tunneling overheads (even for few more data packets) is much more than the cost of exchanging the three signaling packets of the INVITE procedure. However, the use of SIP beside DDM and the bounds of using SIP are left as optional choices for the operator.

We illustrate through Algorithm 1 the source address selection in the IP header(s) of each data packet sent by the MN.

As a result, a more dynamic design is achieved through the dynamic selection of best-suitable mobility protocol for each session based on its characteristics. IP mobility management is avoided when mobility can be handled at upper layers. Note that this is one of the DMM requirements [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF].

Conclusion

In this chapter, we have proposed a novel mobility management scheme named distributed dynamic MIPv6 (DDM). DDM provides global as well as local mobility support in a distributed and dynamic manner. After presenting the rationale and concepts of DDM, we have detailed its control and data planes operations in several scenarios (local and global mobility). Then, we have introduced and discussed the joint use of DDM and SIP for mobility management.

In the next chapter, we carry out a qualitative analysis and a quantitative analysis. In the former, we discuss the advantages of DDM with respect to existing protocols and other distributed approaches. In the latter, we evaluate DDM performance in terms of mobility costs, handover, and QoS analyses.

Quantitative Analyses

Introduction

In the previous chapter, we have proposed a new mobility management scheme based on mobile IPv6 (MIPv6), that is distributed dynamic MIPv6 (DDM). After proposing a new scheme, it is essential to analyze and evaluate it in comparison with other proposals and protocols.

In this chapter, we analyze and evaluate the proposed scheme. We carry out a qualitative analysis as well as a quantitative analysis. We consider three main distributed mobility management (DMM) schemes, namely DDM and the two different options of dynamic mobility anchoring (DMA). We consider also three existing protocols, namely MIPv6, proxy mobile IPv6 (PMIPv6), and session initiation protocol (SIP).

It is worth mentioning that we consider DDM as the MIPv6-based DMM scheme and DMA as the PMIPv6-based DMM scheme.

The qualitative analysis compares the main characteristics, impacts, and effects of the different schemes. It also discusses the main benefits of the proposed scheme versus the other schemes. On the other hand, the quantitative analysis includes:

• Cost analysis, comparing DDM to MIPv6 without/with route optimization (RO) and also studying the benefits of the joint use of DDM and SIP (JDS), (note that we do not include other local mobility management schemes in this analysis for fairness);

• Handover analysis and quality of service (QoS) analysis, comparing the three DMM schemes and the three existing protocols all together.

Numerical results are presented and discussed for each of the quantitative analyses, investigating the impact of main parameters on the different analyses metrics. Recall that the motivations behind choosing these analyses criteria have been discussed in details in Chapter 2.

The results presented in this chapter have been published in [P3, P2].

Qualitative Analysis

Overview

In this section, we present a qualitative analysis through Table 6.1 on the different DMM schemes, particularly DDM (MIPv6-based DMM) and the two options of DMA (PMIPv6-based DMM), beside the existing standardized protocols, particularly MIPv6, PMIPv6 and SIP.

The considered aspects include the main characteristics such as the architecture, operating layer, scope of mobility support, as well as the management type and support. These characteristics provide a comparative overview on the schemes in order to enable an operator to adopt one of them as a solution based on their need.

We then indicate the impact of each scheme on the network (required infrastructure) as well as on the end-user (terminal). This affects the implementation perspectives (short-, mid-, or long-term) and provides an idea on the possible difficulties.

After, we resume the main effects on the control plane (e.g. addressing, anchoring, signaling) as well as on the data plane (e.g. routing, tunneling).

DDM vs MIPv6

Compared to MIPv6, DDM is expected to optimize the routing path and avoid any tunneling overhead for a significant percentage of data traffic. This is due to the fact that at a given time more than 60% of the users in operational networks are nonmobile. While this is well clear when considering the default mode of MIPv6, i.e. bidirectional tunneling (BT) between mobile node (MN) and home agent (HA), one could argue that MIPv6 has also identified a route optimization (RO) mechanism. Thus, we discuss hereafter the major differences between DDM management of new sessions (before undergoing any IP handover) and MIPv6 RO mode.

• While MIPv6 RO mode cannot be activated unless the correspondent node (CN) is an MIPv6 client, DDM does not require any additional capabilities at the CN; route optimization could be achieved in DDM even with mobility-unaware CNs thank to its dynamic design. Eliminating this limitation is a major difference between DDM and MIPv6 RO mode.

• While activating MIPv6 RO mode requires that the MN uses the bidirectional tunneling mode for a while, there is no such requirement in DDM.

• While activating MIPv6 RO mode requires many additional signaling (return routability and binding update procedures and their frequent refreshing), DDM does not. • No privacy issues are introduced in DDM as in MIPv6 RO mode where the CN can trace the MN's movements.

In addition, DDM is expected to reduce the tunneling overhead and global network signaling loads, as a consequence of the points just mentioned above as well as because the anchoring HA(s) are closer topologically to the MN.

Finally, the single point of failure issues in MIPv6 are expected to be eliminated with DDM since the bindings' management is distributed at the ARs level instead of being managed at the same entity.

DDM vs DMA

In general, it appears that the DMM schemes have several advantages compared to the existing protocols. Each DMM scheme is convenient for a different situation or need. For instance, there is a tradeoff between the mobility support scope and terminal modification. In order to support global mobility, the DMM scheme should be MIPv6based such as DDM. Hence, it is host-based where the MN is required to manage the mobility (e.g. BU, tunneling). Consequently, the end-user terminal is required to be an MIPv6 client, and also the signaling and tunneling overheads pass over the wireless link. Other DMM schemes may avoid such impacts but on the other hand can support local mobility only.

DMA (PMIPv6-based DMM) Option 1 introduces some modification to the terminal, i.e. a database with source address selection (SAS) mechanism, but can releases the MN from tunneling management and the tunneling overhead does not pass over the wireless link. On the other hand, DMA (PMIPv6-based DMM) Option 2 introduces instead a centralized database in the network. Even if this leads to a partially distributed approach, the advantage is being fully network-based. However, such centralized database may encounter scalability issues because of the frequent updates and requests sent to it for all the MNs. However, even if both DMA (PMIPv6-based DMM) approaches can enhance the performance regarding wireless signaling and/or tunneling, they can support local mobility but not global mobility.

Note that after defining the needs and strategy, a mobile network operator may adopt the convenient scheme. It is also possible to integrate two schemes and use them jointly, as described hereafter.

As a perspective, this analysis may drive towards integrating the MIPv6-based and PMIPv6-based schemes of DMM, i.e. DDM and DMA. A mobile network operator can implement the PMIPv6-based DMM scheme in its operational domain in order to support local mobility for all MNs. An MN that wants to move to another operational domain is required to use a mobility-aware terminal in order to benefit the global mobility support of MIPv6-based DMM scheme.

Cost Analysis

DDM and JDS operations have been detailed in Chapter 5. Hereafter, we model the mobility costs in both schemes. Then, we investigate and discuss the impact of several parameters on the different mobility costs.

Note that the mobility costs in MIPv6 without/with RO have been derived in details in Chapter 3.

DDM mobility costs

Signaling and processing costs

In DDM, the MN performs the BU procedure with each anchoring HA upon a handover and for refreshing. Then, the signaling cost (SC) in DDM is expressed as follows:

SC(ddm) = (µ c + η bu c )N anchor C bu ar , (6.1)
where µ c is the handover mean rate, η bu c is the refreshing mean rate for the BU procedure, N anchor is the average number of anchors for an MN at a time, and C bu ar is the unit cost of the BU procedure with an anchoring HA in DDM. The latter is expressed as follows:

C bu ar = (M bu + M ba )(h wl + h ar,ar ). (6.2)
In DDM, the processing cost (P C) represents the average number of BUs sent by an MN to an anchoring HA per unit time, P C(ha_ddm). Assuming a uniform distribution for the MNs in the N cells, it is expressed as follows:

P C(ha_ddm) = (µ c + η bu c )N anchor N . (6.3)
Data and tunneling costs DDM distinguishes the new and handover traffics. While the former is routed directly to the CN, the latter is tunneled to the anchoring HA and then routed to the CN. Then, the data cost (DC) in DDM is expressed as follows:

DC(ddm) = N cn µ s N p/s (P n C packet ddm-direct + P h C packet ddm-indirect ), (6.4)
where N cn is the average number of CNs for an MN at a time, µ s is the session duration mean rate, N p/s is the average number of packets per session, P n and P h are respectively the probabilities that a traffic is a new or handover traffic, and finally C packet ddm-direct and C packet ddm-indirect are respectively the unit costs of delivering one packet in the direct and indirect modes of DDM, being expressed as follows:

C packet ddm-d = δ(h wl + h ar,cn ), (6.5)
C packet ddm-ind = (δ + τ )(h wl + h ar,ar ) + δh ar,cn . (

The tunneling cost (T C) is similar to the data cost, but it is dedicated to show the cost of the tunneling overhead. Then, it is expressed in DDM as follows:

T C(ddm) = N cn µ s N p/s P h τ (h wl + h ar,ar ).

(6.7)

JDS mobility costs

Signaling and processing costs

When considering JDS, additional signaling to that of DDM is also required. In particular, the MN performs the INVITE procedure with relevant CN(s) of ongoing SIP-based sessions, and also the REGISTER procedure with the registrar server (RS). While the latter requires refreshing, the former does not. Then, the signaling cost (SC) in JDS is expressed as follows:

SC(jds) = SC(ddm) + P sip cn N cn µ c C invite cn + (µ c + η register c )C register rs (6.8)
where P sip cn is the probability that the CN's session is SIP-supported, N cn is the average number of CNs for an MN at a time, µ c is the handover mean rate, η register c is the refreshing mean rate for the REGISTER procedure, and finally C register Concerning the processing cost (P C) in JDS, there are two network entities to take into consideration. The first is the anchoring HA in DDM, which is discussed in DDM processing cost. The second is the RS in SIP, which is discussed in SIP processing cost and expressed as follows (cf. Chapter 3):

P C(rs) = µ c + η register c . (6.9)

Data and tunneling costs

In JDS, mobility is managed for part of sessions that are SIP-based by SIP (with probability P sip cn ), and for the other sessions by DDM. Then, the data cost (DC) in JDS is simply expressed as follows:

DC(jds) = P sip cn DC(sip) + (1 -P sip cn )DC(ddm) (6.10)
where DC(sip) is the data cost in SIP (cf. Chapter 3) and DC(ddm) is the data cost in DDM.

Similarly, the tunneling cost (T C) is expressed as follows:

T C(jds) = (1 -P sip cn )T C(ddm) (6.11)
recalling that T C(sip) = 0 since there is no tunneling in SIP.

Parameters' default values

Hereafter, we list the default values of the different parameters (which are consistent with chapters 3 and 4). These values are used for all the analyses in this chapter.

• Network model: • Mobility model:

-K = 3 rings ⇒ N = 37 cells -h wl = 2 (i.e.
v = 3 m/s = 10.8 km/hr (this is considered as an average speed for nonmobile, lowly-mobile and highly-mobile users)

-R ≈ 4000 m (to guarantee the peak performance e.g. in LTE networks), equivalent to cell's area A c = 40 km 2 when considering hexagonal cells.

• Traffic and Messages:

- -T bu = 420 s (BU lifetime), T register = 3600 s (REGISTER lifetime)

λ
-P sip cn = 0.5 (the probability that the CN's session is SIP-supported) -R ro = 0.8 (ratio between number of packets sent in MIPv6 RO mode to total number of packets sent during the session; R ro = 0 if RO is deactivated)

• Delay Model:

-B wd = 100 Mbps, L wd = 0.5 ms (bandwidth and propagation latency in wired links, respectively)

-B wl = 10 Mbps, L wl = 2 ms (bandwidth and propagation latency in wireless links, respectively)

-P f = 0.35 (probability of wireless-link failure)

-T L2 = 10 ms (link layer delay)

Impact of the sessions arrival mean rate

First, we investigate the impact of sessions arrival mean rate λ s by varying its value from 0 to 300/3600 s -1 . This means that the average number of CNs for an MN at a time N cn varies from 0 to 20. Fig. 6.1 shows the variation of signaling cost as a function of N cn . The signaling cost in MIP (default MIPv6) and DDM are negligible with respect to that in MIP+RO (MIPv6 with RO). This is due to the heavy signaling loads needed to activate the RO mode of MIPv6 with each CN. On the other hand, MIP only requires the BU process with the HA, and DDM brings the anchors closer to the MN. Moreover, most of sessions in DDM do not undergo a handover, and hence do not require any signaling. Fig. 6.2 shows the variation of data cost as a function of N cn . It appears that DDM reduces significantly the data cost compared to MIP. Note that this is achieved without requiring that the CN is a MIPv6-client, thanks to the DDM dynamic design. On the other hand, MIP+RO usage is limited and restricted to this requirement. Fig. 6.3 shows the variation of tunneling cost as a function of N cn . MIP introduces a tunneling overhead between the MN and the HA. Upon activating the RO mode in MIPv6, a new type of routing header including an additional header is used and hence tunneling overhead still exists (even if it is less significant). On the other hand, DDM routes a large percentage of traffic optimally without introducing any tunneling overhead. This is due to distinguishing the new and handover traffics. 6.7 show the variation of data cost and tunneling cost as a function of R, respectively. The cell's radius has no impact on the data and tunneling costs in MIPv6. This is due to its static design; all the traffic is managed similarly in MIPv6. In DDM, as R increases, the proportion of sessions that experience only one cell increases and hence the percentage of new traffic increases. Consequently, the data and tunneling costs decrease. In fact, this is due to the dynamic design in DDM in distinguishing the new and handover traffics. Nevertheless, DDM outperforms both schemes of MIPv6.

Note that similar results are obtained when varying other metrics such as session duration (1/µ s ) or MN's speed (v).

Impact of network scale

The default value of the network scale ξ is considered to be 0.5 (h ar,ar /h ar,central ). Now we examine the effect of this parameter on the costs in order to to verify if there is a significant impact or not. We vary the average number of hops between two ARs h ar,ar from 1 to 12 hops. Thus, the network scale is varied from 1/12 to 1. Fig. 6.8 and Fig. 6.9 show respectively the variation of data cost and tunneling cost as a function of the network scale. This parameter has no impact on MIPv6 both modes due to its static design and centralization of HA. On the other hand, DDM moves the mobility functions to the ARs level and hence the network scale parameter has an impact on DDM. However, it appears that this impact is light and the costs in DDM are always less than in MIPv6, even for ξ = 1 which is an extreme case. This confirms the previous results and analysis.

Impact of HA to AR deployment ratio

We investigate here the impact of HA to AR deployment ratio, i.e. the ratio between the number of ARs with HA functionalities and the total number of ARs in the network. Such investigation is essential first to study the global mobility scenario (including both DDM and legacy MIPv6 networks), and secondly for an operator in favor of deploying DDM partially (on some of its ARs but not all of them).

Fig. 6.10 and Fig. 6.11 show the variation of data and tunneling costs with respect to HA to AR deployment ratio, respectively. Obviously, this parameter has no impact on both modes of MIPv6. On the other hand, both data and tunneling costs decrease as we deploy more the HA functionalities at the ARs since the DDM concepts are exploited more. Note that the data cost in DDM is always less than that in MIPv6 default mode, due to bringing the mobility anchoring closer to the end user. It also starts to be less that that of MIPv6 RO mode when more than 40 percent of ARs act as HAs. On the other hand, the tunneling cost in DDM is always less than that in both modes of MIPv6.

Handover Analysis

Handover latency

Based on our definition and general expression of the handover latency (T HL ) in Chapter 2, it is the time between the last moment where the MN can receive and send packets through the previous AR and the first moment where it can receive and send packets through the new AR.

Handover latency T HL is composed of layer-two handover latency T L2 , movement detection latency T M D , and location update latency T LU . The latter is the only one that depends on the mobility protocol mechanisms and hence varies from one protocol to another. Hereafter, we derive the expression of the location update latency in each considered scheme (MIPv6, PMIPv6, SIP, DDM, and the 2 options of DMA).

First, recall that d wl (p) and d x,y (p) are the delays of a packet of size p sent over a wireless-link or sent between x and y, respectively. Recall also that we denote by M x the average size in bytes of a control message x.

In MIPv6, the MN performs the BU process with the HA.

T LU (mip) = d wl (M bu ) + d ar,ha (M bu ) + d wl (M ba ) + d ar,ha (M ba ). (6.12)
In order to activate the RO mode, the MN performs, in addition to BU process with HA, the return routability (RR) and BU processes with the CN.

T LU (mip+ro) = T LU (mip) + T RR + d wl (M bu ) + d ar,cn (M bu ) + d wl (M ba ) + d ar,cn (M ba ) (6.13)
where T RR is the delay of the return routability process, T RR = max{delay(HoT process), delay(CoT process)}. (

In PMIPv6, the new MAG discovers the MN's LMA through a DNS lookup [START_REF]Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6[END_REF]. Then, the new MAG performs the PBU process with the LMA.

T LU (pmip) = 2 d ar,dns (M dns ) + d ar,lma (M pbu ) + d ar,lma (M pba ). (6.15)
In SIP, the MN performs the INVITE process with its CN.

T LU (sip) = d wl (M invite ) + d ar,cn (M invite ) + d wl (M ok ) + d ar,cn (M ok ) + d wl (M ack ) + d ar,cn (M ack ). (6.16)
In DDM (MIPv6-based DMM), the MN performs the BU process with its HA(s) simultaneously.

T LU (ddm) = d wl (M bu ) + d ar,ar (M bu ) + d wl (M ba ) + d ar,ar (M ba ).

(6.17)

In DMA (PMIPv6-based DMM), the new MAR retrieves the information from the MN (option 1) or from the DB (option 2) and then performs the PBU process with the anchoring MAR(s) simultaneously.

T LU (dma1) = 2 d wl (M inf o ) + d ar,ar (M pbu ) + d ar,ar (M pba ), (6.18

Impact of wireless-link failure probability

Recall that the handover latency metric evaluates the control plane performance since it is affected by the protocol mobility-related operations and signaling. An MN may loose ongoing sessions due to long handover latency. Fig. 6.12 shows the variation of handover latency as a function of wireless-link failure probability P f . P f reflects the stability of the wireless link where a part of the signaling is exchanged.

It appears that the DMM schemes (DDM and DMA) reduce significantly the handover latency compared to the existing protocols. This is due to distributing the mobility anchoring at the ARs level instead of being centralized in the core network as in MIPv6 and PMIPv6. SIP does not anchor the traffic but it uses relatively large messages that are text-based and hence the handover latency in SIP is higher than in MIPv6 or PMIPv6. However, the RO mode of MIPv6 requires much more additional signaling, leading to relatively very high handover latency.

DDM and DMA 1 perform approximately the same since they both rely on a database at the MN. They outperform DMA 2 which relies on a centralized database in the core network. However, they are affected more by very high P f values since they are host-based.

Impact of network scale

In order to study the impact of the network scale ξ, we vary the average hop-distance h ar,ar between two ARs from 1 to 12 (i.e. ξ ∈ [1/12, 1]). Fig. 6.13 shows the variation of handover latency as a function of the network scale. This parameter has no impact on the existing protocols but does have on the different DMM schemes since they move the mobility functions to the ARs. However, it appears that the impact is limited and DDM (similarly DMA 1) outperforms the other protocols in all cases. Nevertheless, the network scale depends on the network topology; the obtained results should be considered carefully by the operator when designing its topology in order to achieve the targeted performances.

QoS Analysis

Packet loss

The packet loss (N P L ) is defined to be the number of packets (i.e. data packets sent from the CN(s) to the MN) that are lost during a handover. Here, we simply apply the general expression (2.38) of packet loss derived in Chapter 2. However, it is recommended to use buffering mechanisms at the anchors as a solution for packet loss. Such solution becomes more scalable and feasible with DMM, since each anchor is responsible for a group of MNs rather than all the MNs in the operational domain; the buffer size may increase dramatically with centralized anchors such as HA in MIPv6 or LMA in PMIPv6.

Impact of sessions arrival mean rate

End-to-End Delay

The end-to-end delay (T E2E ) is the time of sending a data packet between the MN and its CN (cf. Chapter 2). This metric is important for the quality-of-service and crucial for real-time services such as voice over IP (VoIP). The main aspects affecting this metric are routing and tunneling. Hereafter we derive the formulae for the different schemes.

Recall that we denote by δ and τ the sizes in bytes of a data packet and tunneling overhead, respectively. MIPv6 (default mode) and PMIPv6 manage all the traffic in the same way and all the data packets are tunneled via the mobility anchor, i.e. HA and LMA respectively. However, the tunneling overhead in PMIPv6 is not present over the wireless link. The end-to-end delay in MIPv6 is expressed as follows:

T E2E (mip) = d wl (δ + τ ) + d ar,ha (δ + τ ) + d ha,cn (δ).
(6.20)

However, the RO mode in MIPv6 allows direct communication between the MN and its CN (after activating the RO mode) but an additional overhead is still present.

T E2E (mip+ro) = (1 -R ro )T E2E (mip) + R ro (d wl (δ + θ) + d ar,cn (δ + θ)). (6.21)
On the other hand, the end-to-end delay in PMIPv6 is expressed as follows:

T E2E (pmip) = d wl (δ) + d ar,lma (δ + τ ) + d lma,cn (δ). (6.22) SIP is an end-to-end protocol, all the data packets are routed optimally between the MN and its CN.

T E2E (sip) = d wl (δ) + d ar,cn (δ).

(6.23)

The DMM schemes distinguish the new and handover traffics. While the former is routed optimally, the latter is tunneled via an anchor (implemented at an AR). Then, the end-to-end delay in DDM is expressed as follows:

T E2E (ddm) = P n d wl (δ) +

Impact of wireless-link failure probability

Now, we investigate the end-to-end delay T E2E metric which reflects the data plane performance, being crucial for real-time services. Fig. 6.15 shows the impact of the wireless-link failure probability P f on the end-to-end delay. SIP can be considered as the reference since it is an end-to-end protocol and all the data traffic is routed optimally. The different DMM schemes perform the same since they rely on the same dynamic mobility concept (also, the two options of PMIP-based DMM are related to the signaling only). They reduce significantly the end-to-end delay of MIPv6 and PMIPv6 for two reasons.

• The first is routing optimally the new traffic (traffic of sessions that didn't undergo any handover), which counts the largest portion of the whole traffic because of non-mobile users (e.g. at home, office or cafe) and also short sessions (e.g. TCP connection for SMTP or HTTP sessions).

• The second is anchoring the handover traffic at a relatively near anchor (at an AR instead of being at a centralized entity in the core network).

Impact of network scale

After presenting the impact of the wireless-link failure probability on the end-to-end delay, one would argue that an anchor at an AR is not necessarily always nearer than a centralized anchor. Fig.

Conclusions

In this chapter, we have carried out a qualitative analysis as well as a quantitative analysis in order to evaluate our proposed mobility management scheme DDM.

We have clarified through the qualitative analysis the main differences and advantages of DDM in comparison with the existing protocols and other proposed schemes. Then, we have focused in more details on comparing DDM with:

• MIPv6 (both default and route optimization modes) since DDM is MIPv6-based,

• DMA (both options) since it is the most relevant work and we consider it as the representative of the other proposed schemes for distributed mobility management.

Compared to MIPv6, the main advantages of DDM are the full distributed design that avoids any network bottleneck or single point of failure, and also the dynamic design that allows optimal routing (without tunneling) for most of traffic even with mobility-unaware correspondent nodes. Compared to DMA, the main advantages of DDM are the global mobility support (beside the local mobility support) for mobile nodes moving between different operational domains, as well as the consideration of DDM partial deployment scenarios (i.e. mobility functions are deployed at some of access routers but not all of them).

On the other hand, we have considered three different quantitative analyses in terms of mobility costs, handover, and quality-of-service. We have investigated the impact of several parameters on the different metrics (signaling, processing, data packet delivery, and tunneling costs, handover latency, packet loss, and end-to-end delay). As a result, all the performance evaluations encourage towards adapting the proposed scheme.

• It has been shown that DDM reduces significantly the different costs thanks to its distributed dynamic design, where it brings the mobility functions to the access routers level close to the end user.

• Moreover, DDM reduces significantly the handover latency (and consequently the packet loss) as well as the end-to-end delay, achieving better performance in both control and data planes and providing better quality-of-service to the end user.

Finally, we can mention two challenges of the proposed scheme. The first is the deployment monetary cost of a distributed architecture. However, this is not certain since the general-purpose IP equipment is generally much cheaper than other technologydependent equipment due to economies of scale [START_REF] Sim | Seamless IP mobility support for flat architecture mobile WiMAX networks[END_REF]. The second is the need for user's terminal modification. In order to tackle this challenge, the operator should not propose the new mobility service solely. Instead, mobility service should be proposed with a complete package of always-on services that rely on the mobility.

After proposing a new mobility management scheme and assuring its benefits through several performance evaluations, it is essential to investigate its impacts on other networking aspects. In this chapter, we present two different studies:

• security considerations,

• location management (published in [P5]).

Although these two studies are not related to each other, they are complementary to the proposed scheme on distributed dynamic mobility management.

Security Considerations

Introduction

In mobile IPv6 (MIPv6), it is required that there is a prior relationship and preestablished IP security (IPsec) [START_REF]Security Architecture for the Internet Protocol[END_REF] security association (SA) between the mobile node (MN) and its home agent (HA) [START_REF]IETF RFC 3775[END_REF][START_REF]Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents[END_REF]. The MIPv6 standards [START_REF]IETF RFC 3775[END_REF][START_REF]Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents[END_REF] state that "manual configuration of security associations MUST be supported," and that the used shared secrets "MUST be distributed off-line to the mobile nodes." Accordingly, the MN and the HA are able to authenticate each other and to secure the signaling messages, such as the binding update (BU) and the binding acknowledgement (BA), between them.

In distributed dynamic MIPv6 (DDM), that is considered as MIPv6-based distributed mobility management (DMM), the MN changes the anchoring home agent (HA) for new sessions. Consequently, the MN uses several HAs as anchors and these HAs might belong to different access networks. In this context, it is not assumed that the MN has a prior relationship and security association with all these HAs. Furthermore, such assumption does not seem concrete as far as the MN changes its access network from one operational domain to another (global mobility scenario). Therefore, the MIPv6 security mechanisms should be revisited in order to assure their efficiency in the context of DDM.

It is worth mentioning that the route optimization mode is deactivated in DDM and hence all the security aspects related to the mechanisms with the CN (i.e. return routability and BU procedures with the CN) are not considered in our study.

Hereafter, we first classify briefly the threats and attackers. We then identify different scenarios, considering both link-layer security and binding-related security, where there might be new threats or risks introduced because of DDM. Based on these scenarios, we conclude the requirements and mitigations that DDM needs to take into consideration.

Threats, attackers and attacks

The main threats that might be introduced by DDM mechanisms concern the authentication and the signaling protection, both between the MN and the HA. In the absence of authentication or signaling protection, the MN's data traffic might be e.g. anchored at a fake HA or forwarded to an attacker. Moreover, the MN or the HA might be subject to a denial-of-service (DoS) attack. For example, an attack might prevent the MN from communicating with some or all other nodes, or prevent the HA from serving legitimate MNs. Attackers can be classified as follows.

• When located on the same link as the MN, an attacker can send rogue router advertisements (RA) to the MN, send spoofed BUs to the HA, flood BUs to the HA, and intercept BAs sent to the MN.

• When located on the same link as the HA, an attacker can send spoofed BAs to the MN, flood binding requests to the MN, and intercept BUs sent to the HA.

• An attacker might be located somewhere in the Internet but knows some information about the MN. For example, if an attacker knows the home address of the MN and its HA's address, then it can send a spoofed BU on behalf of the MN or flood BUs to the HA.

Link-layer Security i. Rogue Router Advertisement

In IPv6, routers are configured to send router advertisements (RA) [START_REF]IETF RFC 4861[END_REF] to convey information to nodes that enable them to auto-configure [START_REF]IPv6 Stateless Address Autoconfiguration[END_REF] on the network. This information includes, among others, the implied default router address taken from the observed source address of the RA message as well as the on-link prefix information. It also includes some flags such as the "H flag" (defined in MIPv6 [START_REF]IETF RFC 3775[END_REF]) which is used to announce that the router is also functioning as an HA on the link.

Scenario An attacker can send rogue RAs on a link pretending to be the default router. The attacker can pretend, in addition, to be functioning as an HA on that link. When the MN undergoes an IP handover and attaches to that link, it receives those rogue RAs. The MN may configure its new IP address, and may also anchor its new sessions, based on that rogue RA.

Threats A rogue RA may lead network nodes to learn false information. This would result in network traffic being sent through a rogue router. Consequently, the attacker can capture all the MN's traffic. All the packets could be e.g. forwarded to a malicious node attached to that rogue router or even dropped, leading to a denial-of-service (DoS).

The attacker can also insert itself as a man-in-the-middle (MITM) between the MN and its CN, by pretending i) to be the default router/HA for the MN and ii) to be at the same time the MN for the CN. Then the attacker can possibly modify/change the contents of the traffic.

One more issue is the MN's privacy since the attacker can track the MN's movements/location through the BU messages.

Requirements Concluded requirements are i) router authentication and authorization, and ii) RA message protection such as message integrity protection, replay protection, RS/RA correlation.

However, these requirements are not specific to MIPv6 or DMM but are required for IPv6 networks. Yes, such threat might be more harmful in the context of MIPv6 or DMM than usually regarding the possibility of tracking the MN movements/location.

Mitigation The RA message is part of the neighbor discovery protocol (NDP) [START_REF]IETF RFC 4861[END_REF] and hence the requirements can be fulfilled through the usage of secure neighbor discovery (SEND) protocol [START_REF]IETF RFC 3971[END_REF]. SEND provides address ownership proof, router authorization, and NDP messages protection. Consequently, a trust relationship can be built between the MN and HA. Hereafter, we describe SEND briefly, mentioning its capabilities, options, and required infrastructure.

ii. Secure Neighbor Discovery (SEND)

IPv6 nodes use the neighbor discovery protocol (NDP) [START_REF]IETF RFC 4861[END_REF] for, among others, router discovery as well as neighbor discovery. NDP is not secured in its base specification and hence vulnerable to various attacks. Secure neighbor discovery (SEND) [START_REF]IETF RFC 3971[END_REF] is a protocol that specifies security mechanisms for NDP.

SEND defines new network discovery options including cryptographically generated address (CGA) [START_REF]Cryptographically Generated Addresses (CGA)[END_REF], Rivest-Shamir-Adleman (RSA) algorithm, timestamp, and nonce (a random number). Through these options, SEND provides a security shield and enhances NDP with the following three additional capabilities.

The first capability is address ownership proof based on cryptographically generated addresses (CGA) [START_REF]Cryptographically Generated Addresses (CGA)[END_REF]. This makes stealing IPv6 addresses impossible and hence should be used in router discovery (RD), duplicate address detection (DAD), and address resolution. In fact, SEND works by having a pair of private and public keys for each IPv6 node in combination with the new options. Nodes that are using SEND cannot choose their own interface identifier because the interface identifier is cryptographically generated based on the current IPv6 network prefix as well as the public key. However, the CGA interface identifier alone is not sufficient to guarantee that the CGA address is used by the appropriate node. For this purpose SEND messages are signed by usage of the RSA public and private key pair.

The second capability is message protection, including integrity protection, replay protection, and request/response correlation. For instance, given that neighbor and router discovery messages are in some cases sent to multicast addresses, the timestamp option offers replay protection without any previously established state or sequence numbers. When the messages are used in solicitation-advertisement pairs, they are protected with the nonce option.

The third capability is router authorization in order to act as default gateways. In addition, SEND can specify prefixes that routers are authorized to announce on-link. In order to achieve this, SEND extends NDP defining a set of new attributes. SEND defines two new messages for network discovery: certificate path solicitation (CPS), and certificate path advertisement (CPA). The purpose is identifying valid and authorized IPv6 routers and IPv6 prefixes of the network segment. Certification paths, anchored on trusted parties, are expected to certify the authority of routers. A host must be configured with a trust anchor to which the router has a certification path before the host can adopt the router as its default router. CPS and CPA messages are used to discover a certification path to the trust anchor without requiring the actual router discovery messages to carry lengthy certification paths. The receipt of a protected router advertisement message for which no certification path is available triggers the authorization delegation discovery process.

Therefore, it can be said that the SEND capability for router authorization relies on certificate authority (CA) implementation for hosts to trust routers. Also for routers to be trusted, they need some public key infrastructure (PKI) [START_REF]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile[END_REF][START_REF]Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile[END_REF][START_REF]Internet X.509 Public Key Infrastructure: Certification Path Building[END_REF] implementation so that they can get a certificate from the CA. Both points can be considered as implementation challenges.

Bindings-related Security

i. Spoofed BU or BA Scenario If the attacker is located on the same link as the MN and is able to passively monitor the MN's traffic, then it can learn e.g. the MN's home address (HoA) and HA's address. The attacker can send a spoofed BU to the HA on behalf of the MN.

On the other hand, if the attacker is located on the same link as the HA and is able to intercept the traffic destined to the HA, then it can be aware of any BU sent to the HA. The attacker can reply to the MN sending the BU by a spoofed BA on behalf of the HA.

Threats Through a spoofed BU, the MN's entry in the HA's binding cache is modified. The MN's HoA could be mapped to the attacker's address or another address.

Then, the traffic from the CN(s) to the MN is routed to the attacker or elsewhere. This is a serious threat that can be considered as a DoS attack.

On the other hand, when pretending to be the HA, the attacker can intercept, modify, or even stop forwarding the MN's traffic to its destination. The latter as well as if the attacker rejects the BU lead to a DoS attack. In addition, if the attacker modifies some important parameters in the BA such as the BA lifetime, it can introduce several serious problems. For example, a very short lifetime results in a very high refreshing rate which consumes the wireless link resources. On the other hand, if the claimed lifetime is more than the real one in the HA's binding cache, the MN would not send a binding refresh during the binding lifetime and hence the HA may delete the MN's entry from the binding cache.

Requirements Concluded requirements are the following. i) The HA has to authenticate any BU received by it before making any changes to the binding cache entries.

ii) The HA has also to verify that the BU is sent by a node authorized to create binding cache entries for the specific HoA included in the BU. iii) Moreover, the BU message protection is required.

The same requirements apply also to the BA message when received by the MN.

Note that these requirements are not specific to DDM but should be fulfilled in MIPv6 also. MIPv6 specifies the usage of IPsec [START_REF]Security Architecture for the Internet Protocol[END_REF] protocol in order to protect the signaling between the MN and its HA [START_REF]IETF RFC 3775[END_REF][START_REF]Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents[END_REF]. However, MIPv6 assumes a prior relationship (e.g. business relationship) and pre-established IPsec security association (SA) between the MN and its HA. In other words, the IPsec SA is assumed to be configured manually. In DDM context, such assumption is probably not possible since the MN uses new HAs as anchors. There might not be any prior knowledge between the MN and a new anchoring HA. Thus, dynamic configuration of IPsec SA is required as described hereafter.

Mitigation When the MN attaches to a new HA that might be used as an anchor in the future, the MN has to establish the required IPsec SA with this new HA before detaching from it and undergoing an IP handover (since it will not be possible after). After the IP handover, the MN has to send a BU to that HA. For the BU security, the MN has to use the established IPsec SA. Similarly, the HA has to use the same IPsec SA for the BA security.

As noted, the IPsec SA is not configured manually but instead it is established dynamically on the fly. Dynamic configuration of IPsec SA can be achieved through the usage of Internet key exchange (IKEv2) protocol [START_REF]Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF], as specified in RFC 4877 [START_REF]Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture[END_REF].

In addition, an MN must be prevented from using its SA to send a BU on behalf of another MN using the same HA. In order to achieve this, each SA should be linked to a specific HoA. Upon receiving a BU, the HA checks security policy database (SPD) to assure that the sender is using the right SA for the claimed HoA. This introduces to the dynamic configuration of IPsec SA the following condition. The MN has to use its HoA at the new HA as an identifier during the SA@MN: IP@HA1 Shared secret IPsec dynamic configuration IP@HA2 BA (using SA@MN)

HoA: IP@HA1, CoA: IP@HA2, IPsec: SA@HA1, K flag=1

HA1 checks if SA@HA1 corresponds to IP@HA1 It also shows that the shared secret between the MN and the HA is linked at each entity to the other entity in order to prevent an MN from sending a BU on behalf of another MN. Finally, it is worth mentioning that the MN has to set the K flag in the BU. The K flag concerns the key management mobility capability. When set in the BU, the K flag allows the protocol used to establish the IPsec SA, i.e. IKEv2, to survive IP handovers by updating dynamically the IKEv2 endpoint at the HA. Otherwise, it should be rerun upon each IP handover.

An alternative of the dynamic configuration of IPsec SA is to rely on RFC 4285 [START_REF]IETF RFC 4285[END_REF], the authentication protocol for MIPv6. This protocol defines a MIPv6specific mobility message authentication option that can be added to MIPv6 signaling messages and relies on an authentication server (e.g. authentication, authorization, and accounting (AAA) home server). Instead of requiring an IPsec SA, the protocol requires an SA between the MN and the authentication server. The protocol [START_REF]IETF RFC 4285[END_REF] states that "in cases where the assignment of the HA is dynamic and the only static or long-term SA is between the MN and a backend authentication server, the mobility message authentication option is desirable."

ii. BU flooding Scenario The attacker can keep sending fake BUs to the HA. When sent at a very high rate, these BUs could flood the HA.

Threat BUs flooding might create an unnecessary state at the HA. It might cause the binding cache memory to be full of fake entries. This could prevent creating BU entries for valid MNs due to binding cache memory limitation. This is considered as a DoS attack.

Requirements This threat is not specific to DDM. It has been addressed in MIPv6 also.

Mitigation Upon a BU reception, the HA has to verify the authentication and authorization of the sender before creating a state or a binding cache entry. The HA has to reject BUs sent by non-authenticated or non-authorized nodes.

Location Management

Introduction

In mobile IPv6 (MIPv6) as well as proxy mobile IPv6 (PMIPv6), the MN has always a permanent IP address, the home address (HoA). This allows the MN to be reachable at the IP level, at any location and at any time.

On the other hand, in DDM as well as other DMM schemes, the MN changes its primary IP address frequently due to the dynamic aspect. The MN might have several IPv6 addresses simultaneously but none of these addresses is permanent. This raises the location management issue in DDM and DMM schemes.

MIPv6-based Reachability

One of the approaches could be to let the MN keep (at least) one permanent IP address, i.e. a home address HoA, and hence the MN is always reachable at the IP level at that HoA. Consequently, the MN needs (at least) one permanent anchor, i.e. a centralized HA. It is then required that the MN updates the associated HA upon each IP handover by sending a BU. However, when the MN is not attached to that HA, tunneling mechanisms are required for all the data packets sent by or destined to this address.

In fact, this approach is nothing but a mixture of DDM and MIPv6 as follows:

• The concept of centralized HA that provides a permanent HoA is used for incoming sessions/calls to support MN's reachability at the IP level.

• On the other hand, distributed mobility anchors as well as dynamic anchoring concepts are used for all other sessions initiated by the MN itself.

However, similar issues to the ones addressed to current IPv6 mobility protocols (in the DMM problem statement) will be raised, but only for incoming sessions/calls. Incoming sessions will suffer non-optimal routing and tunneling overhead. Moreover, the permanent HA will be a single point of failure for all incoming sessions/calls.

In addition, let us assume now mobile CNs and not stationary ones and that these CNs apply the same approach for reachability. Then, the incoming sessions to the MN are tunneled via its permanent HA and the outgoing sessions are tunneled via the CNs' permanent HAs. As far as the MN communicates with mobile CNs, MIPv6 is used more and DDM/DMM is used less.

Regardless, this approach provides stable IP address for the MN and hence supports reachability at IP level. It is up to the operator to opt this approach or not.

SIP-based Reachability

Here, we consider another approach based on the session initiation protocol (SIP) [START_REF]SIP: Session Initiation Protocol[END_REF] as a candidate for reachability support in DDM/DMM. SIP is a well-known protocol that has been studied, deployed, and complemented through many extensions. SIP can provide reachability at the application level for SIP-based sessions only. However, the main motivation behind this approach is the fact that most incoming sessions' types (e.g. voice over IP (VoIP) and text messaging) are expected to be SIP-based sessions; hence, application level reachability is sufficient in most of the cases.

In addition, SIP is an end-to-end protocol, i.e. data packets are transmitted directly between the MN and its CNs without tunneling. SIP can also support terminal mobility for SIP-based sessions without any need for tunneling mechanisms. Hence, issues such as non-optimal routing and tunneling overhead are avoided.

Recall on SIP default mode

SIP introduces several logical entities to the network. For each domain e.g. example.com, there is an SIP proxy and also a Registrar Server (RS) which is the location server in SIP. These logical entities are usually co-located when deployed [START_REF]SIP: Session Initiation Protocol[END_REF]. Therefore, we assume hereafter that they are co-located in a single entity and we call this entity SIP server. SIP identifies each user by a unique SIP uniform resource identifier (URI), e.g. alice@example.com. In order to associate the SIP-URI with the current IP address, the user sends a REGISTER to the SIP server which writes the binding and replies by an OK. This binding is valid for a specified lifetime (the default lifetime value is 3600 seconds [START_REF]SIP: Session Initiation Protocol[END_REF]). Hence, it should be periodically refreshed. In addition, when changing the IP address (e.g. upon crossing from one cell to another and undergoing an IPhandover), the user is required to perform the REGISTER procedure with the SIP server.

To sum up, the MN updates its location upon IP handovers and also periodically for refreshing. This may increase the loads of location updates (REGISTER) on the location server (registrar server). Such increase is not consistent with the DMM requirements on scalability [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF]. Therefore, reducing the location updates rate as much as possible is crucial. For this objective, we propose to benefit the concept of location areas (LA) as described hereafter.

Location Areas Concept

Location management is one of the fundamental issues in mobile networks. The network must track the location of its subscribers, i.e. the MNs, in order to forward incoming calls to the relevant cell within the network. Usually, the exact cell where the MN is present is not stored but instead several cells are grouped together to form a Location Area (LA). Then, the network consists of several LAs and whenever the MN moves to (or switches on at) a new LA it updates its location at a central location server. The MN can detect that it has entered a new LA as every cell transmits its LA identity while the MN is attaching to it. In order to avoid database inconsistencies, the MN also updates its location periodically at the location server even if it has not moved to a new LA, i.e. refreshing. On the other hand, since the MN's movements between the cells of the same LA is not updated at the location server, the network needs to page the MN for incoming calls; it pages the MN in all the cells of the LA where the MN is currently located and whose information is stored in the location server.

In order to approach the location management issue in DDM/DMM, the concept of LAs mentioned above can be inherited and used. Clearly, there is a need of a signaling protocol that can manage the location updates and location servers. Instead of proposing a new protocol, we adopt the use of SIP as discussed above.

As the location areas concept is not a new one, we clarify hereafter our contributions that are twofold. First, we consider the recent DMM schemes that rely on flat IPv6 mobile networks. Second, we compute the location updates loads on the location server not only considering the MN's movement but also the periodic refreshing. The load on the location server is one of the most important requirements of DMM as these loads affect the scalability. To the best of our knowledge, these two contributions have not been addressed in the literature.

SIP with Location Areas

We consider SIP for MNs location management in DDM/DMM. First, we assume that both the MN and the CN are SIP users. Hence, they have an SIP stack (or at least a minimum subset of SIP functions) and they are identified with SIP-URIs. The MN should have the ability to send a REGISTER message to the SIP server in order to update its location. The CN should have the ability to send an INVITE message to the SIP server in order to initiate a session. Each domain consists of several LAs. Upon initialization, at periodic intervals and when joining a new LA, the MN sends REGISTER messages to the SIP server of its domain. The REGISTER messages associate MN's SIP-URI with the MN's current IP address. The SIP server writes this association or binding in a database, called the location service, so that it can be used later to locate the users of its domain. The SIP server knows the IP addresses of all the cells in an LA. Thus, whenever the MN is called, the SIP server sends the paging messages to all cells of the LA where the MN is currently present. This is in order to find out the cell where the MN is currently attached.

We consider the following scenarios:

• Scenario 1: The MN is switched-on in cell1 in LA1.

• Scenario 2: The MN moves from cell1 to cell2 in the same location area LA1.

• Scenario 3: The MN then moves from cell2 in LA1 to cell3 in a different location area LA2.

• Scenario 4: The MN is attached to celli in LAj; a CN initiates a session with it. Fig. 7.2 illustrates the location update in scenarios 1, 2, and 3. In scenario 1, the MN is switched-on in cell1 in LA1. The MN sends a router solicitation (RS) to the access router (AR) of cell1, which replies by a router advertisement (RA). Then, the MN configures an IP address. The MN registers this IP address by sending a REGISTER to the SIP server. The SIP server replies by an OK confirming the registration. The MN refreshes its registration periodically.

In scenario 2, the MN moves from cell1 to cell2, both in LA1. Upon the IP-handover, the RS and RA messages are also exchanged between the MN and the AR of cell2. Although the MN configures a new IP address, it does not send a REGISTER to the SIP server since it is still in LA1. However, the MN refreshes its registration periodically even when not crossing its LA.

In scenario 3, the MN moves from cell2 in LA1 to cell3 in LA2. While attaching to the AR of cell3, the MN notices that it has changed its LA since each AR announces its LA identifier. After configuring a new IP address, the MN updates its registration by sending a REGISTER to the SIP server. This registration should be refreshed periodically as well.

To sum up, the MN updates its location by sending a REGISTER to the SIP server for two reasons. The first is LA-crossing, i.e. when the MN moves from an LA to another. The second is refreshing, i.e. when the lifetime of the current registration ends while the MN is still in the same LA.

Location updates load on SIP Registrar Server

Here, we carry out a comparative performance analysis on the default mode of SIP without LAs (i.e. each cell is an LA) and SIP with LAs. We consider the location update load on the SIP Registrar Server (RS) as a performance metric. It is defined as the average number of registration requests per second per MN and denoted by LU RS .

In SIP, the MN sends a registration request upon an IP-handover (i.e. cell-crossing) and for refreshing. Then, LU RS in SIP can be expressed as follows:

LU RS (sip) = µ c + η register c (7.1)
where µ c is the cell-crossing mean rate and η register c is the refreshing mean rate of REGISTER during a cell residence time (cf. Chapter 2).

On the other hand, when considering LAs, the MN sends a registration request when crossing from one LA to another and also for refreshing. Then, LU RS in the proposed scheme (SIP+LA) can be expressed as follows:

LU RS (sip + la) = µ a + η register a (7.2)
where µ a is the LA-crossing mean rate and η register a is the refreshing mean rate of REGISTER during an LA residence time (cf. Chapter 2).

Note that although the LA-crossing rate is less than the cell-crossing rate, the refreshing rate in SIP+LA is more than in SIP. Thus, it is not obvious to compare the signaling load in both cases. Consequently, we study the impact of several parameters on the signaling loads in order to evaluate the proposed scheme. Hereafter, we consider the MN's speed, cell's radius, registration lifetime period, and number of cells per LA as parameters.

Numerical Results

We present and discuss here the numerical results. We investigate the impacts of several parameters on the location updates load, such as the MN's speed, cell's radius, registration lifetime, and number of cells per LA. The default values of the system parameters are listed hereafter.

• number of rings per LA: K = 3 ⇒ number of cells per LA: N = 37;

• cell's radius: R ≈ 4000 m ⇒ cell's area: A c = 40 km 2 ;

• MN's average speed: v = 3 m/s;

• registration lifetime period: T reg = 3600 s [START_REF]SIP: Session Initiation Protocol[END_REF].

Note that these values are consistent with the considered values in the previous chapters.

Impact of MN's speed

First, we examine the impact of the MN's speed v by varying its value from 1 to 40 m/s (see Fig. 7.4). As v increases, the cell-crossing and LA-crossing rates increase. This increases the handover registrations and decreases the refreshing ones. However, it appears that the handover rate dominates the refreshing rate and hence the location updates load increases. It appears that introducing the concept of LAs to the SIP registration reduces significantly the location updates load. This reduction is more crucial for higher speeds, since the highly mobile MNs experience more frequent handovers.

Impact of cell's radius

Now, we vary the cell's radius R from 600 to 9000 m (see Fig. 7.5). This shows the impact of varying the cell's area A c from 1 to 200 km 2 . For very large cells, the location updates load in both cases is asymptotic and tends to be more stable. This is due to the non-frequent handovers. However, the MN frequently experiences handovers with small cells. Thus, grouping several cells into one LA can limit the effect of frequent handovers and can significantly reduce the signaling load due to registrations.

Impact of registration lifetime

We here investigate the effects of refreshing on the signaling load (see Fig. 7.6). We set v and R to their default values. Hence, the handover rate is constant. We then vary the value of registration lifetime period T reg from 0.5 to 5 hours. As the lifetime increases, the refreshing rate decreases and hence the registrations decrease. For longer lifetimes, the location updates load becomes more stable due to infrequent refreshing. On the other hand, short lifetimes increase the refreshing rate and hence the registrations increase even for non-mobile users. Nevertheless, the proposed scheme significantly reduces the location updates load than that in the original SIP.

Impact of number of cells per LA

Now, we fix the handover and refreshing rates by setting v, R and T reg to their default values. We then examine the impact of the LA size (see Fig. 7.7) by varying the number of cells per LA from 7 cells (1 ring) to 1261 cells (20 rings). This metric has no impact on original SIP since there is no LAs. It also has a limited impact on the proposed scheme, SIP with LAs. Starting from 91 cells per LA (5 rings) and more, there is a very slight variation in the location updates load. In fact, starting from a specific threshold in the size of LA, the increase in the refreshing rate is approximately equivalent to the decrease in the LA-crossing rate and hence, their sum tends to be stable. As a result, the operator can adopt the threshold value for the number of cells per LA since there is no significant advantage in adopting higher values.

Conclusions and Perspectives

In this thesis, we have addressed the rapid increase in mobile data traffic issue through designing novel distributed dynamic mobility management. Beside protocol design, we have also dedicated a significant part of the thesis for the comparative performance analysis of the existing mobility management schemes as well as the proposed one.

After reviewing thoroughly the existing architectures of mobile networks and mobility protocols, we have extracted the distributed mobility management (DMM) problem statement. We have also presented the DMM history, focusing on the most relevant work that is dynamic mobility anchoring (DMA).

As we aim at adapting and extending some of the existing mobility protocols, we have started by investigating them. First, we have defined an analytical framework for protocols modeling and analysis. In this framework, i) we have developed the analytical models and their parameters, and ii) we have defined the analysis criteria and developed their expressions in a general form that can be applied to any protocol. Then, we have carried out a comparative analysis on the global mobility schemes: mobile IPv6 (MIPv6), session initiation protocol (SIP), and their integration mixed MIPv6-SIP (MMS). We have also carried out a similar analysis on the local mobility schemes: proxy mobile IPv6 (PMIPv6) and dynamic mobility anchoring (DMA). Based on the conclusions of these two analyses, we have defined the requirements and objectives of a new mobility scheme.

We have proposed a novel distributed dynamic mobility management scheme. It is mainly based on MIPv6 with an optional extension for the joint use with SIP. The main proposal is called distributed dynamic MIPv6 (DDM) and its extension is called joint DDM-SIP (JDS). First, we have defined two new concepts: the distributed mobility management and the dynamic mobility management. Then, we have detailed the protocol operations in several scenarios. We consider both local and global mobility scenarios. We also consider both full and partial deployment scenarios. Finally, we have introduced the joint use of DDM and SIP, describing the requirements and source address selection algorithm. Later, we have studied the security considerations for DDM as well as the reachability support and how to adapt the location management to the proposed scheme.

After proposing the new scheme, we have carried out a qualitative analysis and a quantitative analysis. We have discussed the advantages of DDM compared to the existing protocols and other proposed schemes. We have also shown that DDM and JDS reduces significantly the mobility costs, the handover latency, the packet loss, and the end-to-end delay. Considering the following points, mobile network operators are highly encouraged to consider DDM in order to cope with the rapid increase in mobile data traffic.

• DDM avoids current scalability issues such as network bottlenecks and single point of failures and attacks, that are expected to grow in the near future especially with the ongoing deployment of fourth generation (4G) telecommunications system.

• DDM helps significantly in optimizing the network resources and their consumption (i.e. loads on the network), which is crucial with the shortly-appearing heavy services such as mobile video.

• DDM enhances significantly the quality-of-service in IP networks, which is crucial with the ongoing migration towards packet-switched voice over IP (VoIP).

• DDM is essential for the migration towards flat architectures and for the evolutionary trend of moving the content delivery networks (CDN) closer to the user.

• DDM deployment is recommended in parallel with the ongoing migration towards All-IPv6 network.

On the other hand, one of the DDM (and DMM in general) challenges is the deployment monetary cost of a distributed architecture. However, this is not certain since the general-purpose IP equipment is generally much cheaper than other technologydependent equipment due to economies of scale [START_REF] Sim | Seamless IP mobility support for flat architecture mobile WiMAX networks[END_REF]. Abundant options for network management tools for IP networks are available at low cost as well. In addition, DDM supports partial deployment scenarios (as already discussed). However, a complete economical study on the benefits of distributed architecture versus the deployment monetary cost is needed.

Another DDM challenge is the impact on the user's terminal and the need for its modification. In order to tackle this challenge, the operator should not propose the new "mobility service" solely since it is not likely that customers will accept to pay for this. Instead, the mobility service should be proposed with a complete package of "always-on services" that rely on mobility. Hence, it is recommended to carry out a complete services study to market well the mobility service, which is a tool and not a goal from the user's standpoint.

An alternative to partially avoid terminal modification could be as follows. As mentioned in Chapter 6, the MIPv6-based DMM (i.e. the proposed scheme DDM) and the PMIPv6-based DMM (i.e. DMA) can be integrated together. While the latter provides mobility support within the home operational domain, the former provides mobility support when the user departs from that domain. Consequently, the mobilityunaware users can enjoy mobility support within the home operational domain (but not outside it). However, the performance should be evaluated again as well as the deployment complexity, if any.

Besides, our study on the joint use of IP mobility protocols with SIP encourages towards generalizing it to other upper-layers protocols that can support mobility. The motivations behind choosing SIP, among other upper-layers protocols, are many. SIP provides both session-continuity and reachability for SIP-based sessions in an end-toend manner. SIP-based mobility support is well investigated and tested. SIP is already deployed in current mobile networks. On the other hand, SIP fails to support TCP sessions with mobility. Recently, the "TCP extensions for multipath operation with multiple addresses" protocol has been standardized [START_REF]TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. This protocol is expected to natively provide mobility support. However, it should be well investigated, tested, and evaluated before being proposed as a mobility scheme.

Although security is one of the essential aspects in mobile networks, it is not the main topic of our study but a secondary one. We have addressed the security considerations of the proposed scheme in Chapter 7 but we do not carry out any evaluations. Moreover, we propose a solution track based on existing security protocols but we do not propose any enhancement or extensions. Hence, a complete study on the security considerations of all the DMM schemes is needed.

When considering a centralized mobility anchor, there is no room to select another anchor. After distributing the mobility anchors, the mobility anchor selection issue shows up naturally. In current approaches, the user always selects the current access router (which acts as an anchor) to anchor the new sessions. In some cases, this might not be the optimal choice if we consider the application, user's mobility, and network contexts. We are carrying out ongoing efforts to define several use-case scenarios for the mobility anchor selection in DMM [I1]. After, the selection mechanisms and protocol operations should be specified and analyzed.

Software defined networking (SDN) is a new paradigm of networking. It is the current trend to separate control and data planes and to provide a more flexible architecture. SDN makes the network programmable, giving the operator more control on its infrastructure for customization and optimization. We are carrying out ongoing efforts to define an SDN-based DMM scheme [P7, P8]. The new scheme should be analyzed and evaluated compared to the other DMM schemes. A combination between both SDN-based DMM and non-SDN DMM should be studied as well. After, the implementation should be tested to validate the scheme.

Last but not least, the most widely deployed mobile networks are based on the 3GPP standards. The deployment of a new mobility protocol is hence highly related to the protocol's compatibility with the 3GPP mobile networks. First, it is essential to address the 3GPP mobile networks need for a new DMM scheme. Then, it is required to adapt the DMM schemes to the 3GPP architectures. For these reasons, we are carrying out ongoing efforts to apply practically the DMM schemes on the 3GPP mobile networks [P8, D1, D2]. In particular, we consider the evolved packet system (EPS) architecture in a dense deployment scenario, i.e. the DMM gateways are deployed densely. We also consider the usage of WiFi, resulting in heterogeneous networks. Deploying DMM in 3GPP mobile networks should be specified, analyzed, evaluated, and tested thoroughly before being deployed.

Appendix: Résumé en Français

Résumé en Français

Résumé

Les architectures des réseaux actuels ainsi que les protocoles de gestion de mobilité sont généralement déployés de manière centralisée. Par ailleurs, ces protocoles sont conçus pour être toujours activés, même s'il n'y pas besoin. Comme le nombre des utilisateurs mobiles et le volume de leur trafic augmentent, ces architectures centralisées sont susceptibles de rencontrer des problèmes de passage à l'échelle ainsi que des problèmes de performances. Récemment, les opérateurs de réseaux mobiles rencontrent une augmentation rapide du trafic de données mobile. Pour y faire face, une nouvelle tendance est d'aplatir les architectures de réseaux et donc les protocoles de gestion de mobilité IP doivent être adaptés à cette évolution. Par conséquent, il est nécessaire de définir des nouveaux mécanismes de gestion de mobilité qui sont distribués et actives de manière dynamique.

Cette thèse concerne la conception, l'analyse et l'évaluation des nouvelles architectures de réseaux IPv6 et des protocoles de mobilité distribués et dynamiques. En particulier, nous étudions la DMM (Distributed Mobility Management). Tout d'abord, nous classons les protocoles de mobilité existants et effectuons une analyse comparative sur chaque catégorie. Ensuite, nous proposons un nouveau protocole de gestion distribuée et dynamique de mobilité basé sur MIPv6 (Mobile IPv6), avec une extension optionnelle pour l'utilisation conjointe avec SIP (Session Initiation Protocol). Après, nous effectuons une analyse de performance en termes de coûts de mobilité, du handover, et de la qualité de service. Enfin, nous étudions les impacts sur d'autres aspects tels que la sécurité et la joignabilité.

Mots Clés : Gestion Distribuée de Mobilité, Gestion Dynamique de Mobilité, Réseaux Mobiles, IPv6, MIPv6, PMIPv6, SIP, Conception de Protocole, Analyse de Performance, Architecture de Réseau.

Introduction

Les opérateurs de réseaux mobiles font face à une augmentation rapide du trafic de données mobile. Les statistiques des opérateurs montrent que 2012 a vu transiter plus trafic de données mobile que toutes les années précédentes combinées [START_REF]The Mobile Economy 2013[END_REF]. Entre 2012 et 2013, ils montrent que le trafic de voix n'a augmenté que deux pour cent, mais le trafic de données a doublé sur les réseaux mobiles [START_REF]The Mobile Economy 2013[END_REF][START_REF]Mobile Economy Europe 2013[END_REF][START_REF]GSMA Intelligence (collected data directly from the mobile networks operators)[END_REF][START_REF] Ericsson | Ericsson Mobility Report[END_REF]. Aujourd'hui, les réseaux mobiles de données à haut débit, tels que la 4G, sont largement déployés dans le monde entier. Les utilisateurs mobiles peuvent profiter de la transmission à haute débit. Cela stimule l'utilisation des smartphones et par conséquence engendre une augmentation très importante de charges sur les réseaux mobiles. Un ordinateur portable typique devrait générer 11 Go par mois, une tablette 3,1 Go, un smartphone 2 Go d'ici la fin de 2018 [START_REF] Ericsson | Ericsson Mobility Report[END_REF]. Non seulement le trafic de données des utilisateurs actuels est en augmentation, mais aussi le nombre d'abonnements et d'utilisateurs [START_REF]The Mobile Economy 2013[END_REF][START_REF]Mobile Economy Europe 2013[END_REF][START_REF]GSMA Intelligence (collected data directly from the mobile networks operators)[END_REF][START_REF] Ericsson | Ericsson Mobility Report[END_REF].

En conséquence, les opérateurs de réseaux mobiles anticipent une explosion du trafic de données mobile [START_REF]The Mobile Economy 2013[END_REF][START_REF] Ericsson | Ericsson Mobility Report[END_REF][START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF]. Ils effectuent donc plusieurs efforts pour lutter contre ce défi, en particulier dans les organismes de normalisation. Plusieurs nouvelles technologies apparaissent. La convergence des réseaux fixe-mobile, le déchargement du trafic de données mobile, l'architecture de réseau décentralisée, les réseaux SDN (Software Defined Networks), l'informatique en nuage, et bien d'autres sont des tentatives en cours pour faire face au défi de la nouvelle ère des réseaux mobiles de donnée.

En 2010, Orange et d'autres ont poussé le sujet à l'IETF pour discussion. Le sujet a gagné l'intérêt de l'industrie des télécommunications et également plusieurs instituts universitaires. A l'IETF, il a été jugé nécessaire d'étendre les protocoles de mobilité de l'IETF, tels que MIPv6 (Mobile IPv6) [START_REF]IETF RFC 3775[END_REF] ou PMIPv6 (Proxy Mobile IPv6) [START_REF]IETF RFC 5213[END_REF], plutôt que de proposer un nouveau protocole. Par conséquent, Orange a tenté [START_REF] Seite | Dynamic Mobility Anchoring[END_REF][START_REF] Seite | Distributed Mobility Anchoring[END_REF] d'adapter DMA pour qu'il soit un prolongement de l'un des protocoles de mobilité de l'IETF : le protocole de PMIPv6.

Cependant, le désir de la conception d'un protocole de DMM qui se fonde sur les protocoles de mobilité existants n'était pas satisfait. Pour cette raison, Orange Labs en collaboration avec Télécom Bretagne a proposé en Octobre 2010 cette thèse pour atteindre cet objectif. Cette thèse a été réalisée à Orange Labs sous un contrat CIFRE (Conventions Industrielles de Formation par la REcherche).

Pendant cette thèse, j'ai contribué au projet interne d'Orange LETSMOVE, aux projets européens MEVICO [START_REF]Mobile Networks Evolution for Individual Communications Experience (MEVICO) Project[END_REF] et CROWD [START_REF]Connectivity management for eneRgy Optimised Wireless Dense networks (CROWD) Project[END_REF] (et leurs livrables), à la standardisation d'IETF (groupe de travail DMM), ainsi que de nombreuses collaborations industrielles et académiques comme avec Intel Corporation, Samsung, et l'Université d'Aveiro. En outre, j'ai effectué plusieurs publications internationales et soumis une demande de brevet.

En résumé, cette thèse concerne la conception, l'analyse et l'évaluation de nouvelles architectures de réseaux IPv6 et des protocoles de mobilité qui sont à la fois distribués et dynamiques.

La thèse est divisée en trois parties.

Partie I

Dans le chapitre 1, nous étudions attentivement les différentes architectures de réseaux mobiles de données existantes, y compris les architectures de 3GPP [START_REF]3rd Generation Partnership Project, 3GPP[END_REF] (à partir du GPRS (General Packet Radio Service) et jusqu'au EPS (Evolved Packet System)), 3GPP2 [START_REF][END_REF] et WiMAX mobile [19]. Nous étudions aussi les pratiques actuelles des protocoles de mobilité IP existantes, notamment MIPv6 (Mobile IPv6) et PMIPv6 (Proxy Mobile IPv6). En général, ces architectures et protocoles sont déployés d'une manière hiérarchique et centralisée. De plus, ils sont conçus pour être toujours activés, indépendamment des contextes de mobilité et services. En outre, nous considérons le support de mobilité aux couches supérieures par SIP (Session Initiation Protocol) [START_REF]SIP: Session Initiation Protocol[END_REF][START_REF] Schulzrinne | Application-layer mobility using SIP[END_REF] car il est défini de bout-en-bout et se comporte de manière très différente.

Tout au long de ces études, nous extrayons la problématique de la gestion distribuée et dynamique de mobilité DMM (Distributed Mobility Management). Au lieu d'être centralisée, la gestion de mobilité doit être distribuée afin d'éviter le goulot d'étranglement du réseau et le point unique de défaillance. Au lieu d'être toujours activé, la gestion de mobilité doit être activée et désactivée de façon dynamique dans le but de réduire la consommation des ressources du réseau et afin d'obtenir une meilleure performance.

Comme DMM est considéré à l'IETF (depuis 2010, quand j'ai commencé cette thèse), puis intégré à un groupe de travail, nous présentons son histoire dans cette première partie. Nous présentons et discutons également les avantages et les inconvénients du travail le plus pertinent pour notre étude : DMA (Dynamic Mobility Anchoring). DMA est un schéma de gestion de mobilité qui est fondé, dans une certaine mesure, sur PMIPv6 mais s'appuie sur une architecture distribuée.

Les contributions principales de ce chapitre sont doubles. La première consiste à examiner en profondeur les architectures de réseaux mobiles et protocoles de mobilité existants. La seconde consiste à extraire la problématique de DMM.

Partie II

Comme il est nécessaire d'étendre les protocoles de mobilité existants, nous visons dans cette partie à étudier de manière approfondie les points forts et faibles de chaque protocole. Nous considérons cela comme une étape essentielle avant de proposer une nouvelle extension ou nouveau protocole. Dans le chapitre 2, nous développons un cadre analytique pour la modélisation et l'analyse des protocoles. En outre, nous définissons une variété de critères d'analyse qui peuvent examiner à fond les protocoles de mobilité. Nous définissons plusieurs métriques pour l'analyse des coûts afin d'évaluer la consommation des ressources du réseau. Nous définissons également des métriques pour l'analyse du handover et la qualité de service afin d'examiner à la fois la performance de plan de commande (contrôle) et plan de données.

Par rapport aux autres études de la littérature, les contributions principales sont les suivantes. La première consiste à développer analytiquement tous les aspects de protocole (par exemple, taux de rafraîchissement) ainsi que les aspects liés à DMM (par exemple, le nouveau trafic contre le trafic de handover) qui ne sont pas abordées avant. La seconde consiste à définir différents critères d'analyse qui peuvent étudier tous les aspects des protocoles de mobilité à partir de plusieurs points de vue. La troisième consiste à développer pour chaque métrique d'analyse une expression analytique générale qui peut être appliquée à n'importe quel protocole de mobilité.

A cette étape, nous considérons l'analyse des coûts comme la priorité parce que notre préoccupation principale est l'augmentation du trafic mobile de données. Nous réalisons deux analyses comparatives des coûts :

• Dans le chapitre 3, nous considérons les protocoles de gestion de mobilité globale (c.à.d. peut soutenir la mobilité globale dans tout l'Internet IPv6) : MIPv6, SIP, ainsi que leur intégration qui est appelé MMS (Mixed MIPv6-SIP).

• Dans le chapitre 4, nous considérons les protocoles de gestion de mobilité locale (c.à.d. peut soutenir la mobilité locale dans un seul domaine opérationnel) : PMIPv6 et DMA.

Nous détaillons les opérations, les procédures, et les échanges de signalisation de chaque protocole et puis nous développons les modèles analytiques des coûts de la mobilité. Nous étudions ensuite l'impact de différents paramètres sur les coûts.

Les contributions principales de ces deux analyses sont les conclusions et les perspectives que nous tirons après chaque analyse. Grâce à ces conclusions, nous ouvrons la voie à proposer des améliorations ou même un nouveau protocole. Par exemple, nous démontrons les avantages de l'utilisation conjointe de la mobilité IP et SIP. Nous mentionnons également l'intérêt de disposer de scénarios où l'autre utilisateur de communication est agnostique à la mobilité. De plus, nous examinons les avantages attendus des architectures distribuées, à la fois sur les plan de commande (contrôle) et le plan de données.

Partie III

Grâce aux analyses des protocoles de mobilité existants, nous concluons à leurs insuffisances et proposons un nouveau protocole. Nous analysons ensuite la performance de notre proposition et étudions l'impact sur d'autres aspects de réseaux. Les résultats de cette partie ont contribué à [P2, P3, P5, P7, P8, P9, D1, D2, I1, I2].

Dans le chapitre 5, nous proposons un protocole de gestion distribuée et dynamique de mobilité. Le protocole proposé est principalement fondé sur le protocole MIPv6, appelé DDM (Distributed Dynamic MIPv6), avec une extension optionnelle pour l'utilisation conjointe avec SIP, appelé JDS (Joint DDM-SIP).

Au début, nous illustrons un scénario de cas d'usage. Ensuite, nous définissons nos exigences et objectifs, compte tenu des conclusions de toutes les analyses précédentes. Selon les exigences, nous définissons les deux concepts du protocole proposé: la gestion distribuée de mobilité et la gestion dynamique de mobilité. Le premier peut être atteint en confinant le soutien de mobilité et par la distribution des fonctions d'ancrage de mobilité au niveau des routeurs d'accès, gardant le reste du réseau ignorant aux événements de mobilité et à leur soutien. Le dernier peut être accompli par l'activation du soutien de mobilité IP uniquement en cas de besoin, c.à.d. lorsqu'à la fois l'utilisateur mobile subit un handover IP et le service applicatif a besoin du soutien de mobilité IP.

A coté de la proposition d'un nouveau protocole de mobilité, les contributions principales sont les suivantes.

• DDM soutient à la fois les deux scénarios de mobilité locale et mobilité globale. L'utilisateur mobile peut se déplacer non seulement dans son domaine opérationnel, mais aussi entre les différents domaines opérationnels et les différents réseaux d'accès. Cela est intéressant parce que l'Internet sans fil et mobile est composé de plusieurs réseaux d'accès.

• En outre, DDM considère les deux scénarios de déploiement complet et partiel des fonctions de mobilité sur les routeurs d'accès. L'opérateur de réseau mobile peut décider de déployer les fonctions de mobilité, soit au niveau de chaque routeur d'accès ou à certains d'entre eux seulement. Cela permet un compromis entre la performance et le coût monétaire de déploiement. Cela facilite également la phase de migration de l'architecture, ce qui permet une migration étape par étape.

• En outre, nous introduisons l'utilisation conjointe de DDM et SIP, JDS. En JDS, SIP prend en charge la mobilité des sessions SIP et DDM prend en charge la mobilité des autres sessions. La motivation derrière cette utilisation conjointe est de réduire encore les coûts et d'obtenir une meilleure performance si possible, en notant que SIP est un protocole de bout-en-bout qui ne repose pas sur l'ancrage ou les mécanismes des tunnels.

Après la proposition d'un nouveau protocole, il est essentiel de l'analyser et l'évaluer en comparaison avec d'autres protocoles. Il est également essentiel d'étudier ses effets sur d'autres aspects de réseaux.

Dans le chapitre 6, nous effectuons une analyse qualitative et une analyse quantitative. A côté de DDM, nous considérons DMA, MIPv6, PMIPv6 et SIP. L'analyse qualitative étudie les caractéristiques principales et les effets des différents protocoles sur le réseau et le terminal d'utilisateur. Elle présente également les avantages principaux de DDM par rapport aux autres protocoles comme MIPv6 et DMA. L'analyse quantitative comprend une analyse des coûts, une analyse du handover, et une analyse de qualité de service. Nous étudions l'impact de nombreux paramètres sur les différentes métriques d'analyses.

En conséquence, toutes les évaluations de performance encouragent à l'adaptation du protocole proposé DDM. Nous montrons que DDM réduit de manière significative les coûts de la mobilité et donc la consommation des ressources du réseau. Nous montrons également que DDM réduit de manière significative la latence du handover et le délai de bout en bout, offrant une meilleure performance et une meilleure qualité de service à l'utilisateur.

Dans le chapitre 7, nous présentons deux études complémentaires qui sont effectuées afin de compléter et de perfectionner le protocole proposé. La première concerne les considérations de sécurité. Nous étudions à la fois la sécurité à la couche de liaison et la sécurité liée à la procédure de BU (Binding Update). Nous proposons ensuite l'utilisation de certains protocoles et mécanismes existants pour surmonter les problèmes identifiés. La seconde étude concerne le soutien de la joignabilité. Nous étudions la possibilité du soutien de la joignabilité à la couche IP par MIPv6 ainsi qu'à la couche applicative par SIP. Nous introduisons ensuite le concept de zones de localisation à SIP afin de réduire les charges des mises à jour de localisation sur les serveurs SIP. Nous comparons, à l'aide d'un modèle analytique, ces charges entre le mode par défaut de SIP et celui proposé.

Fig. 1 . 1 ,

 11 Fig. 1.1, Fig. 1.2, and Fig. 1.3 illustrate the GPRS, UMTS, and EPS networks architectures[START_REF]Network architecture[END_REF], respectively. The architectures of GPRS and UMTS are very similar to the extent that they are sometimes referred to as 2G-GPRS and 3G-GPRS, respectively. Their radio access network (RAN) is composed of two types of entities that act as base station and controller. Their packet core network is composed of three types of entities, the serving GPRS support node (SGSN), the gateway GPRS support node (GGSN), and the home location registrar (HLR).

Figure 1 . 1 :Figure 1 . 2 :Figure 1 . 3 :

 111213 Figure 1.1: GPRS network architecture.

Fig. 1 .Figure 1 . 4 :Figure 1 . 5 :

 11415 Fig. 1.4 shows the GTP tunnels in EPS network architecture. GTP-C tunnels are used on the PGW-SGW and SGW-MME interfaces. GTP-U tunnels are used on the PGW-SGW and SGW-eNodeB interfaces. *

Figure 1 . 6 :

 16 Figure 1.6: Inter-SGW intra-MME handover in EPS.

Figure 1 . 7 :Figure 1 . 8 :Figure 1 . 9 :Figure 1 .

 1718191 Figure 1.7: Mobility management hierarchy in 3GPP networks architectures.

Figure 1 . 11 :

 111 Figure 1.11: 3GPP2 mobile network architecture.

Figure 1 . 12 :

 112 Figure 1.12: Mobile WiMAX network architecture.

Figure 1 . 13 :

 113 Figure 1.13: Mobile IPv6 architecture and mobility management.

Figure 1 . 14 :

 114 Figure 1.14: Proxy Mobile IPv6 architecture and mobility management.

Figure 1 . 17 :

 117 Figure 1.17: IPv6 mobile network with flat architecture.

Figure 1 . 18 :

 118 Figure 1.18: DMA architecture and mobility management.

CHAPTER 2

 2 Analysis Models and Criteria 2.

Figure 2 . 1 :

 21 Figure 2.1: The network model.

  of N hexagonal-shaped cells in the form of K rings.

Figure 2 . 2 :

 22 Figure 2.2: The network divided into location areas.

Figure 2 . 3 :

 23 Figure 2.3: The time diagram of refreshing.

Figure 2 . 4 :Figure 2 . 5 :

 2425 Figure 2.4: State transition diagram for M/M/1/1 queue.

Figure 2 . 6 :

 26 Figure 2.6: Transmission cost concept.

Figure 3 . 2 :

 32 Figure 3.2: Mobility management in SIP.

Figure 3 . 3 :

 33 Figure 3.3: Mobility management in MMS.

Figure 3 . 4 :

 34 Figure 3.4: Home and visited networks.

Figure 3 . 5 :Figure 3 . 6 :

 3536 Figure 3.5: Impact of R on Signaling Cost (T bu = 420 s, T register = 3600 s).

Figure 3 . 7 :

 37 Figure 3.7: Impact of R on Processing Cost (T bu = 420 s, T register = 3600 s).

Figure 3 . 8 :

 38 Figure 3.8: Impact of N cn on Signaling Cost.

Figure 3 . 9 :Figure 3 .

 393 Figure 3.9: Impact of N cn on Data Cost.

Figure 4 . 1 :

 41 Figure 4.1: Mobility Management in PMIPv6.

Figure 4 . 2 :

 42 Figure 4.2: Mobility Management in DMA (option 2).

Figure 4 . 3 :

 43 Figure 4.3: Impact of N cn on Signaling Cost.

Figure 4 . 4 :Figure 4 . 5 :

 4445 Figure 4.4: Impact of N cn on Data Cost.

Figure 4 . 6 :Figure 4 . 7 :Figure 4 . 8 :

 464748 Figure 4.6: Impact of R on Signaling Cost.

Figure 4 . 9 :Figure 4 .Figure 4 . 11 :

 494411 Figure 4.9: Impact of ξ on Signaling Cost.

Figure 5 . 1 :

 51 Figure 5.1: The scenario's topology.

Fig. 5 .Figure 5 . 2 :

 552 Fig. 5.2 illustrates an example on global mobility between different operational domains, some of them deploy the HA functionalities fully and others partially.

Figures 5. 3

 3 Figures 5.3 and 5.4 illustrate an example on mobility management in DDM. In this example, the MN is attached to an HA and then moves towards another HA. This example can represent the local mobility scenario as well as some situations in the global mobility scenario (the latter is discussed later). In other terms, it can also represent the full deployment scenario where the DDM functionalities are deployed at each AR. Hereafter, we detail the DDM operations and mechanisms.

  Figures 5.3 and 5.4 illustrate an example on mobility management in DDM. In this example, the MN is attached to an HA and then moves towards another HA. This example can represent the local mobility scenario as well as some situations in the global mobility scenario (the latter is discussed later). In other terms, it can also represent the full deployment scenario where the DDM functionalities are deployed at each AR. Hereafter, we detail the DDM operations and mechanisms.

Figure 5 . 3 :Figure 5 . 4 :

 5354 Figure 5.3: Mobility management in DDM.

  IP-handover from HA2 to AR and then initiation of session S3.(b) IP-handover from AR to HA3 and then initiation of session S4.

Figure 5 . 5 :

 55 Figure 5.5: Global mobility support in DDM.

1 :

 1 MN prepares IP header(s) of a data packet for transmission; if data packet ∈ { SIP-based sessions } then Original IP header: SA = current IP address DA = relevant CN address ; No tunneling header ; else Original IP header: SA = relevant HoA DA = relevant CN address ; Tunneling IP header: SA = current IP address DA = relevant HA address ; end Algorithm Source address selection in JDS.

  rs and C invite cn (cf. Chapter 3) are respectively the unit costs of the REGISTER procedure with the RS and the INVITE procedure with a CN.

  s = 40/3600 s -1 (i.e. 40 sessions per hour for an MN) -1/µ s = 240 s = 4 min, and N p/s = 1000 packets (which is equivalent to an average throughput of 13 kbps per session for an MN) δ = 400 bytes (average IPv6 data packet size) τ = 40 bytes (IPv6 tunnel header size) θ = 24 bytes (additional type 2 routing header size)

Figure 6 . 1 :

 61 Figure 6.1: Impact of N cn on the Signaling Cost.

Figure 6 . 2 :Figure 6 . 3 :

 6263 Figure 6.2: Impact of N cn on the Data Cost.

Figures 6. 6

 6 Figures 6.6 and 6.7 show the variation of data cost and tunneling cost as a function of R, respectively. The cell's radius has no impact on the data and tunneling costs in MIPv6. This is due to its static design; all the traffic is managed similarly in MIPv6. In DDM, as R increases, the proportion of sessions that experience only one cell increases and hence the percentage of new traffic increases. Consequently, the data and tunneling costs decrease. In fact, this is due to the dynamic design in DDM in distinguishing the new and handover traffics. Nevertheless, DDM outperforms both schemes of MIPv6.

  Figures 6.6 and 6.7 show the variation of data cost and tunneling cost as a function of R, respectively. The cell's radius has no impact on the data and tunneling costs in MIPv6. This is due to its static design; all the traffic is managed similarly in MIPv6. In DDM, as R increases, the proportion of sessions that experience only one cell increases and hence the percentage of new traffic increases. Consequently, the data and tunneling costs decrease. In fact, this is due to the dynamic design in DDM in distinguishing the new and handover traffics. Nevertheless, DDM outperforms both schemes of MIPv6.

Figure 6 . 4 :

 64 Figure 6.4: Impact of cell's radius on the Signaling Cost.

Figure 6 . 5 :Figure 6 . 6 :

 6566 Figure 6.5: Impact of cell's radius on the Processing Cost.

Figure 6 . 7 :

 67 Figure 6.7: Impact of cell's radius on the Tunneling Cost.

Figure 6 . 8 :Figure 6 . 9 :

 6869 Figure 6.8: Impact of network scale on the Data Cost.

Figure 6 .

 6 Figure 6.10: Impact of HA to AR deployment ratio on the Data Cost.

Figure 6 . 11 :

 611 Figure 6.11: Impact of HA to AR deployment ratio on the Tunneling Cost.

  ) T LU (dma2) = 2 d ar,db (M inf o ) + d ar,ar (M pbu ) + d ar,ar (M pba ). (6.19)

Figure 6 . 12 :

 612 Figure 6.12: Impact P f on the handover latency.

Figure 6 . 13 :

 613 Figure 6.13: Impact ξ on the handover latency.

Fig. 6 .

 6 Fig.6.14 shows the impact of the sessions arrival mean rate λ s on packet loss N P L . Due to shorter handover latency, the DMM schemes reduce the packet loss significantly compared to existing protocols.

  CNs for an MN at a time N cn

Figure 6 . 14 :

 614 Figure 6.14: Impact of N cn on the packet loss.

Figure 7 . 1 :

 71 Figure 7.1: IPsec dynamic configuration using IKEv2.

Fig. 7 .

 7 Fig. 7.3 illustrates scenario 4. A CN initiates a session with the MN by sending an INVITE. The INVITE message is routed through the SIP server of the CN's domain to the SIP server of the MN's domain. The latter sends the paging messages to all cells of the LA where the MN is currently present. Only the cell where the MN is currently attached forwards the INVITE message to the MN. Then, the session can be established as usual in SIP.

Figure 7 . 4 :

 74 Figure 7.4: Impact of MN's speed.

Figure 7 . 5 :

 75 Figure 7.5: Impact of cell's radius.

Figure 7 . 6 :Figure 7 . 7 :

 7677 Figure 7.6: Impact of lifetime period.

  Pour ce faire, nous définissons un cadre d'analyse ; nous classons les protocoles différents et puis nous effectuons une analyse comparative pour chaque catégorie. Cette partie est partiellement publiée dans [P1, P4, P6].

Table 1 .

 1

	1: Cisco survey on mobile		12				11.2
	Internet time at home, at work and on
	the move [44]. U.S. U.K. Germany France Italy South Africa Mexico	at home at work on the go 37.8% 19.6% 42.6% 45.6% 17.8% 36.6% 43.4% 15.3% 41.3% 33.1% 21.7% 45.2% 39.6% 21.4% 39.0% 48.6% 21.4% 28.2% 27.6% 44.2% 30.0%	Exabytes per month	10 2 4 6 8	0.9	1.6	2.8	4.7	7.4
	Brazil Korea India	36.7% 33.7% 45.9%	24.7% 31.7% 30.4%	38.6% 23.7% 34.6%		0	2012 2013 2014 2015 2016 2017
	China Average	30.1% 38.4%	32.7% 24.0%	37.2% 37.5%	Figure 1.16: Cisco forecast on mobile data traffic [5].

Table 2 .

 2

1: Average hop distances. x and y h x,y MN and AR, i.e. wireless link h wl = ω AR and another AR in the same domain h ar,ar AR and a centralized entity, e.g. LMA in PMIPv6, DB in DMA h ar,central AR and the home network, e.g. HA in MIPv6, RS in SIP h ar,home Internet h internet

Table 3 .

 3 1: MIPv6 messages and their sizes.

	Message Source-Destination Notation Size (bytes)
	BU	MN-HA	M bu	136
	BA	HA-MN	M ba	128
	HoTI	MN-HA	M hoti	128
	HoTI	HA-CN	M hoti ′	56
	HoT	CN-HA	M hot ′	64
	HoT	HA-MN	M hot	136
	CoTI	MN-CN	M coti	56
	CoT	CN-MN	M cot	64
	BU	MN-CN	M bu ′	72
	BA	CN-MN	M ba ′	72

Table 3 .

 3 2: Data packets and overheads sizes.

	Description	Notation Size (bytes)
	IPv6 data packet	δ	400 (on average)
	IPv6-in-IPv6 tunneling overhead τ	40
	IPv6 type 2 routing header	θ	24

Table 3 .

 3 3: SIP messages and their sizes.

	Message	Source-Destination Notation Value (bytes)
	REGISTER MN-RS	M register 465
	OK	RS-MN	M ok	450
	INVITE	MN-CN	M invite	490
	OK	CN-MN	M ok ′	420
	ACK	MN-CN	M ack	256

Table 4 .

 4 1: Packets and overhead sizes.

	Description	Notation Size (bytes)
	IPv6 data packet	δ	400 (on average)
	IPv6-in-IPv6 tunneling overhead τ	40
	Signaling message	M	76

  .2 and Table4.1):

	C packet dma-direct = δh wl + δh ar,cn ,	(4.13)
	C packet dma-indirect = δh wl + (δ + τ )h ar,ar + δh ar,cn .	(4.14)

  the wireless hop is equivalent to 2 hops) h ar,ar = √ N ≈ 6 hops (number of hops between two ARs) h ar,central = 12 hops (number of hops between an AR and a centralized entity, e.g. h ar,db , h ar,lma , h ar,dns ) h internet = 16 hops (number of hops through the Internet, e.g. h ar,ha , h ar,rs , h ar,cn , h ha,cn , h lma,cn )

  d ar,cn (δ) + P h d wl (δ + τ ) + d ar,ar (δ + τ ) + d ar,cn (δ) (6.24) and in DMA (same for both options) as follows: T E2E (dma) = P n d wl (δ) + d ar,cn (δ) + P h d wl (δ) + d ar,ar (δ + τ ) + d ar,cn (δ) .

	(6.25)

  6.16 replies by showing the impact of the average hops distance between two ARs h ar,ar (illustrated by network scale) on end-to-end delay. It is clear that the impact of h ar,ar on the end-to-end delay in DMM schemes is limited. DDM and DMA are still performing better than MIPv6 and PMIPv6 even for extreme far ARs.

	(ms)
	E2E End-to-End Delay T						MIP MIP+RO
							SIP
							PMIP
							DMA
							DDM
	0.1	0.2	0.3	0.4	0.5	0.6	0.7	0.8
		Probability of wireless-link failure P f
	Figure 6.15: Impact of P f on the end-to-end delay.
	(ms)
	E2E End-to-End Delay T						MIP MIP+RO
							SIP
							PMIP
							DMA
							DDM
	0.2		0.4		0.6	0.8		1
			Network Scale ξ
	Figure 6.16: Impact of ξ on the end-to-end delay.

† Note that this IPv6-network is under an operator control, which means that the operator can exceptionally use some control gateways if it is more suitable to keep some control functions separated from the ARs. For instance, the operator can use a control gateway for location management to provide reachability.

‡ NEMO extends MIPv6 to enable a mobile router and its sub-network to move and attach to different points in the Internet.

Cependant, le défi présenté vient du fait que les architectures de réseaux mobiles actuels sont déployées de manière hiérarchique et centralisée. En raison du backhauling du trafic de données, une passerelle centralisée fait face à un nombre de requêtes par seconde élevé, des exigences de bande passante élevées, ainsi que des charges de traitement élevées. Cela se traduit par un goulot d'étranglement du réseau et un point unique de défaillance, qui sont indésirables. Cela est également traduit par des voies de communication longues entre les utilisateurs et les serveurs, ce qui gaspille les ressources du réseau et entraîne des retards indésirables. Par conséquent, la nouvelle tendance des opérateurs de réseaux mobiles est d'aplatir l'architecture du réseau.Une fonction essentielle dans les réseaux de données mobiles est la gestion de mobilité. Elle s'appuie sur des protocoles de mobilité afin de fournir la continuité des sessions ainsi que la joignabilité pour les utilisateurs mobiles. Les utilisateurs peuvent profiter des communications d'Internet non interrompus tout en se déplaçant. Les protocoles de mobilité existants ont été conçus pour les architectures de réseau actuel, en s'appuyant sur une entité centralisée. Comme les architectures de réseau évoluent et deviennent « à plat », les protocoles de mobilité doivent être adaptés et étendus pour une telle évolution.Dans ce contexte, l'opérateur de télécommunications Orange[START_REF]The telecommunications operator Orange (France Telecom formerly[END_REF] a lancé en 2008 plusieurs projets qui tiennent compte de la gestion distribuée de mobilité DMM (Distributed Mobility Management). Les efforts d'Orange ont abouti à une proposition appelée DMA (Dynamic Mobility Anchoring)[START_REF] Bertin | A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures[END_REF][START_REF] Bertin | Distributed or Centralized Mobility?[END_REF][START_REF] Bertin | An Evaluation of Dynamic Mobility Anchoring[END_REF]. Au début, DMA n'était pas fondée sur les protocoles de mobilité de l'IETF[10].

DATA DATA DATA Session with CN 2: MIPv6 BT mode Session with CN 1: SIP-based Home Registrations Optional if CN 2 is MIPv6-client Session with CN 2: MIPv6 RO mode DATA DATA DATA CN

• Bidirectional tunneling (BT) mode, which is the default mode of MIPv6; the MN may use only the BT mode during all of the communication.

• Route optimization (RO) mode, which cannot be activated unless the CN is an MIPv6 client. This introduces limitations to the usage of RO.

Hereafter we describe both modes of MIPv6 (see Fig. 3.1).

MIPv6 in bidirectional tunneling mode (MIP)

Upon acquiring a new care-of IP address, the MN sends a Binding Update (BU) to the HA. This binding is valid for a specified lifetime, hence it should be refreshed. The HA replies by a Binding Acknowledgment (BA).

In this mode, the MN receives/sends data packets from/to the CN via the HA. An IP-in-IP tunnel is established between the MN and the HA. This requires adding a tunneling overhead (IPv6 header) to each data packet transmitted between these two entities.

MIPv6 in route optimization mode (MIP+RO)

The MN initiates the return routability (RR) procedure, which consists of exchanging four messages between the MN and CN as shown in Fig. 3.1. Due to security reasons, the maximum allowed lifetime value of this procedure is 420 seconds [START_REF]IETF RFC 3775[END_REF]. Then, the

Impact of the cell's radius

Now we investigate the impact of the cell's radius R. We vary R from 600 to 6250 m. This means that the cell's area varies between 1 and 100 km 2 . Fig. 6.4 and Fig. 6.5 show the variation of the signaling and processing costs as a function of R. As the cell's radius increases, the handover rate decreases and hence the signaling and processing costs decrease too. MIP+RO has the highest signaling cost and MIP has the highest processing cost, both due to the high refreshing rate in MIPv6. Note that DDM clearly outperforms the other schemes, reducing the signaling significantly and distributing the processing.

Summary

In this chapter, we have carried out two different studies that are complementary to our distributed dynamic MIPv6 (DDM) proposal.

In the first, we have investigated the security aspects in DDM. We have identified several scenarios, considering both link-layer and binding-related security aspects. After analyzing the possible threats, we have discussed the needed requirements in order to avoid them. We have then approached the mitigations for each scenario.

In the second, we have proposed and analyzed an SIP-based location management approach adapted for DDM (as well as the evolving DMM schemes). After addressing the location management issue in DDM, we have introduced the proposed scheme which relies on gathering each group of cells into a location area in order to reduce the location updates loads on the registrar server of SIP. We took into consideration not only the handover rate but also the registration refreshing rate. Through investigating the impact of several parameters, we have shown that the proposed scheme reduces significantly the loads on the SIP registrar server.

List of Publications

International Publications: