i

Abstract

Service continuity is an important component in mobile communications. With the coexistence of different access network technologies and the emergence of multiinterface mobile devices, service providers should maintain the ongoing communication when the mobile travels among heterogeneous networks. Services like IPTV, video on demand or voice over IP are widely proposed by operators for which service continuity should be guaranteed. This thesis is devoted to service continuity of real-time applications in heterogeneous networks. We tackle this problem from two perspectives: session mobility and terminal mobility. Although these two mechanisms have the same purpose which is ensuring service continuity when changing the terminal or the access network, each technique has its own challenges and constraints.

As far as session mobility is concerned, a new signaling protocol has been proposed to transfer the session between different terminals. This protocol has been implemented in video streaming scenarios and evaluated in a testbed. Moreover, we address the problem of media adaptation, especially renegotiation of QoS parameters since session might be transferred to a new terminal with different capabilities than the original one. QoS renegotiation can be extended to cover the case where some internal parameters are degraded during the session in the same terminal.

For terminal mobility, we propose a new handover mechanism using IEEE802. [START_REF] Smith | 3G wireless with WiMAX and WIFI 802[END_REF] with Fast handover for Mobile IPv6. The purpose of this proposal is to reduce the handover delay and the dedicated buffer in access routers. In addition, an optimization is proposed for Fast handovers for Mobile IPv6 in order to maximize the probability of its predictive mode. In the same context, mobility in IMS is considered and an appropriate solution is proposed to answer IMS requirements. Finally, we conduct a comparison study between different mobile IP variants in the case of vertical handover.

Based on this comparison, we give some guidelines that should help in choosing the most efficient protocol following specific parameters. The proposed solutions and studies have been evaluated analytically or/and using a simulation tool.

iii

Résumé

La continuité de service est un élément important dans les communications mobiles. Avec la coexistence de différentes technologies d'accès au réseau et l'émergence de dispositifs mobiles avec plusieurs interfaces réseau, les fournisseurs de services doivent maintenir la communication en cours lorsque les mobiles voyagent entre des réseaux hétérogènes. Des services comme l'IPTV, vidéo à la demande ou la voix sur IP sont largement proposés par les opérateurs pour lesquels la continuité de service doit être garantie. Cette thèse est consacrée à la continuité du service pour des applications temps réel dans des réseaux hétérogènes. Nous abordons ce problème de deux perspectives: la mobilité de session et la mobilité de terminal. Bien que ces deux mécanismes aient le même but qui est d'assurer la continuité de service lors du changement de terminal ou de réseau d'accès, chaque technique a ses propres défis et contraintes.

En ce qui concerne la mobilité de session, un nouveau protocole de signalisation a été proposé pour transférer la session entre les différents terminaux d'un utilisateur. Ce protocole a été conçu pour les scénarios de streaming vidéo. Son implémentation a permis la validation du protocole proposé ainsi que son évaluation. En outre, nous traitons le problème de l'adaptation des flux multimédias, notamment la renégociation des paramètres de la qualité de service puisque la session pourrait être transféré à un nouveau terminal avec des capacités différentes que le terminal d'origine. Cette renégociation peut être étendue pour couvrir le cas où certains paramètres internes sont dégradés au cours de la session dans le même terminal.

Quand à la mobilité de terminal, nous proposons un mécanisme basé sur l'utilisation de la nouvelle norme IEEE802.21 et du protocole de mobilité FMIPv6. Le but de cette proposition est de réduire le délai du handover et la taille de l'espace mémoire dédiée au niveau des routeurs d'accès. En outre, une optimisation est proposée pour FMIPv6 afin de maximiser la probabilité de son mode prédictive. Dans le même contexte, la mobilité dans l'IP Multimédia Subsystem (IMS) est considéré et une solution adaptée est proposée pour répondre aux exigences de l'IMS. Enfin, nous iv menons une étude comparative entre les différentes variantes de Mobile IP dans le cas de handover vertical. En se basant sur cette comparaison, nous donnons quelques directives qui devraient aider à choisir le protocole le plus efficace suivant des paramètres spécifiques. Les solutions proposées et les études ont été évaluées avec des méthodes analytiques et/ou en faisant appel à des simulations. v Currently France is among the countries that have a big number of deployed public WIFI access points with more than 30000 access points in 2010 [1]. Therefore, it occupies the third place after USA and china. This number does not take into account the shared connection done over the box offered by certain Internet Service Provider to their customers to enjoy internet connection when they are away from home (ex: "Free WiFi", "Neuf WiFi"). The total number of public WiFi access points deployed in the world reaches 310000 in 2010 according to the same study, with a growth rate of 20%.

List of Figures

In parallel to network development, mobile devices too know a complete transformation. Mobile phones, personal data assistant (PDA), Internet tablets, laptops…etc, acquire more and more hardware capabilities in terms of processing speed, memory space, communication interfaces and storage space. These capabilities allow mobile devices not only to communicate through different network technologies, but also to choose the most convenient one in case of several available networks; this latter characteristic is known as Always Best Connected (ABC). This means that at any time the mobile should be connected to the best available network. "Best" can refer to many criterions such as cost, bit rate, user preferences…etc. The mobile should decide which network will meet requirements of its applications at a given moment. Moreover, the user can even choose the right device to use depending on his situation. Transferring the current session between different terminals gives o high degree of liberty to the user and realizes a real service ubiquity. Nevertheless, the coexistence of multiple access network technologies raises the problem of interworking and mobility management across them. Fortunately, the wide use of IP in all access and core networks makes it possible for the users to roam between different access networks while enjoying their services. However, the growing of multimedia and real-time applications usage by internet customers imposes additional constraints to mobility management protocols. Such kind of application requires a great attention to maintain the same level of quality of service. For example, in real-time applications, handover delay should be kept as short as possible to guarantee seamless service continuity.

Problem Statement

Mobility management in IP networks is gaining more and more interest from research community and service providers. The reason for this interest is the emergence of new advanced technologies in both access networks and mobile devices. From the one hand, wireless access networks are in a constant progress in terms of offered bandwidth and quality of service provisioning. On the other hand, mobile devices have known a tremendous development in terms of hardware and software capabilities which allow them to perform more complicated tasks rather than just making a phone call as the early invented mobile phones. Nevertheless, the new applications are no more based on circuit switched networks since IP has proved to be a convincing protocol for interworking between different networks and hence, adopted by the community as the protocol of infrastructure convergence and service integration. Therefore, many service providers converted there core networks to be operable on IP, and the new services are IP based as well. Voice over IP (VoIP) and IPTV are the most successful IP based services provided by many operators as part of their quadruple play service (i.e. internet, telephony, TV and mobility). Nonetheless, mobility here is limited to the access technology that the operator has chosen to carry the service on. In other words mobility is managed in a very controlled way. This restriction tightens the liberty of the user in choosing the access network he/she prefers and excludes the possibility of coexistence with other technologies even belonging to the same operator. For example, a user who is using his mobile phone to watch a TV program using 3G network would prefer to take advantage of a WIFI hot spot connection when in airport waiting room to enjoy a better quality with lower cost. Roaming between heterogeneous networks without any interruption in the current session is a challenging task; especially with the real time character of the ongoing communication. Such task is complicated because of two reasons: i) changing access interface requires an intervention from the user since the network can only ensure horizontal handovers if supported. ii) The second reason is the inner problem of IP address function duality; the connection shall break if the IP address changes during the session. Moreover, new services should be created for session mobility support. In other words, in order to make session transfer between different terminals, new mechanisms should be defined and supported by both terminal and network.

Motivation

Continuity of service is the most important challenge that operator should face in order to offer ubiquitous service. If network heterogeneity is beneficial from user point of view, it complicates more the task for the service provider. On the one hand, solving service continuity problem will allow the operators to diversify their access network and take advantage of low cost infrastructure while maintaining the same level of QoS. On the other hand they will grant more flexibility for users to choose their favorite network or even transport the current session to a different terminal with better hardware capabilities.

The need of supporting service continuity is particularly important in applications that have certain continuity in time. For example web browsing is less stringent to service continuity since it is a discontinuous application: the user requests a web page and waits for the answer then starts reading the displayed information. At the opposite, when the application takes place for a while such in case of file download or video streaming the continuity of the service is obligatory otherwise the service will stop. The way mobility is supported is again related to the application it self. The user will not be affected by a high handover delay in case of file download since the result is not perceptible until completion of the download. On the contrary, any excessive delay in achieving the required mobility operation will affect the quality of delay sensitive applications like video streaming. Although many works have been conducted in the area of mobility, still problems are not completely solved.

Contributions

In this thesis we address the problem of service continuity in heterogeneous networks from two perspectives: session mobility and terminal mobility. Although these mobility services have the same purpose which is assuring service continuity when changing the terminal or the access network, but each technique has its own challenges and constraints.

Session Mobility

A new signaling protocol has been proposed for session mobility support between different terminals. The protocol has been implemented for video streaming scenario and evaluated in a testbed. In this context, we address also the problem of media adaptation especially renegotiation of QoS parameters since session might be transferred to a new terminal with different capabilities than the original one. QoS renegotiation can take place in either session transfer or during the session in the same terminal when change in some internal parameters occurs. Change in such parameters affects the quality of experience of the user if no measures are taken to adapt the media accordingly.

Terminal Mobility

Contribution 1:

After studying the state of the art related to mobility techniques and protocols, we made a classification of terminal mobility protocols over IP in terms of operation steps.

These steps are summed up in four major sub-operations that are not necessarily present in all mobility protocols. This classification is particularly interesting in the analysis and diagnosis of any mobility protocol and help in designing new protocols.

Contribution 2:

We propose a new handover mechanism using the new standard IEEE802.21 together with Fast handover for mobile IPv6. This scheme is different from the classical paradigms which are mobile initiated and network initiated handovers. Actually we put the mobile and the network in collaboration relationship and the result is a new paradigm: mobile initiated-network terminated handover.

Contribution 3:

We tackle the operation mode of FMIPv6 in order to maximize the probability of its predictive mode. This contribution can be considered as a continuation of the previous one. When the previous contribution is more based on layer 2 mechanisms to improve the handover performance, this one bring enhancement to the mobility protocol itself to maximize the probability of a successful proactive handover Contribution 4:

In the context of IMS we propose a new hybrid mobility management protocol based on both network layer and application layer mobility protocols. This approach avoids redundancy of functionality and network entities. In addition it shows better results compared to the classical approaches. Actually this is one of the direct results of the mobility analysis in IMS under the methodology made in contribution 1. Therefore we bring the missing part in mobility operation without making any redundancy.

Contribution 5:

We conduct a comparison study of mobile IP variants in a vertical handover scenario. This work came from the fact that new protocols claim improving performance of handover. If this is true for horizontal handovers it is not always true in case of vertical handover. Through this study we show that multi interface users can perform seamless handovers with classical mobility protocols better than sophisticated ones. Chapter 3: in this chapter we tackle session mobility issue. This chapter is divided in two parts. The first part presents the proposed session mobility protocol "SESSAMO". This lightweight peer to peer protocol is designed for session mobility in video streaming. Performance evaluation of the new signalling protocol is conducted through a testbed. The second part treats the problem resulting from the mechanism of session transfer which is media adaptation. A mechanism of renegotiating the new QoS parameters depending on the capabilities of each terminal is proposed. It is based on SDPng and MPEG21 standards. In the same perspective we extend the use of renegotiation mechanism to adapt the media within the same terminal when a change of capabilities occurs during the session.

Structure of The Thesis

Chapter 4: after an overview of mobility protocols we draw some conclusions from the way most of IP mobility protocols work. Actually, any mobility management protocol operating in network layer, transport layer or application layer follows more or less the same sub-operations to achieve seamless transitions. In this chapter we enumerate these steps and give a recapitulation of most known mobility protocols following the defined steps.

Chapter 5: in this chapter a new handover mechanism is presented and evaluated.

Based on collaboration between the mobile node and the network, this scheme allows a fast handover with minimum buffered packets. MIH is used in efficient manner with FMIPv6 to perform intelligent handovers for both heterogeneous and homogeneous networks. The choice of MIH comes from its independence regarding access network technology and its manageability by upper layers, particularly FMIPv6. A theoretical study is conducted in order to compare the performance of the new scheme with the classical ones. A set of simulations are executed as well in network simulator 2.

Simulation results confirm the theoretical ones.

Chapter 6: here is yet another improvement to the previous handover process. But this time it concerns FMIPv6 operation itself. It seems that predictive mode is tied to the result of FBACK message which should be received by the mobile node in the old link; otherwise, the reactive mode is activated. In order to avoid this mode we propose to forward the FBACK message to the new location of mobile node through the established tunnel. Therefore the only case FMIPv6 operates in the reactive mode is when the fast binding update is not received correctly by the old access router. We show through analytical study that this small modification in FMIPv6 protocol has a good effect on maximizing the probability of predictive mode success.

Chapter 7: in this chapter mobility in IMS is tackled. As one of IMS purposes is to provide access network independent services, the question of service continuity between heterogeneous network technologies is important but still unsolved. We first analysed the existing signalling protocols within IMS and than deduced that the missing part towards a seamless handover is the handover smoothing step as we stated in the classification done in chapter 4. Then we propose to use FMIPv6 to perform the missing operation. Thus we use two mobility protocols: SIP at the application layer and FMIPv6 at the network layer. This mechanism does not only avoid redundancy in the network but improve the performance of the handover as well. Through an analytical study we show the advantages of our proposal over previous proposed solutions. Chapter 8: in this chapter we present a comparative study of mobile IP variants in vertical handover. We demonstrate through this comparison that the choice of the best mobility protocol is not obvious as it might appear. In fact, having multiple interfaces, the mobile node can perform faster handovers with the conventional MIPv6 than FMIPv6. We show that the choice of the best variant of mobile IP depends on certain parameters. We finally give some guidelines that should help in choosing the most convenient mobility protocol.

STATE OF THE ART: WIRELESS ACCESS

NETWORKS AND MOBILITY PROTOCOLS

This chapter is divided in two parts: the first part gives an overview of the most known access technologies from different standard bodies (i.e. IEEE family and ITU-T family). The second part investigates legacy mobility protocols from different perspectives. Mobility protocols are classified to micro and macro mobility protocols following their administrative range. Macro mobility protocols in their turn are classified following the layer at which they operate. Wireless local area networks (WLAN) have gained a big success in the last decade. This success is due to the easy deployment of this type of networks and its low cost compared to wired solutions. Moreover, the offered bandwidth in such network is still increasing with the improvement of modulation schemes and the use of smart antennas along with advanced error correction schemes. From 802.11b to 802.11n, the bit rate passed from few mega bits per second to several hundreds. Hereafter we give an overview of the famous IEEE 802.11 releases.

Overview of Access

IEEE802.11b

802.11b [2] is the first standardized WLAN technology operating in the 2,4GHz unlicensed band. The bandwidth is divided into channels of 22MHz. The physical layer uses Direct Sequence Spread Spectrum technique and Binary Phase Shift Keying (BPSK), Differential Quadrature Phase Shift Keying (DQPSK), and Complementary Code Keying (CCK) as modulation schemes for 1Mbps, 2Mbps and (5Mbps, 11Mbps) bit rates respectively. The medium access control is based on carrier sense multiple access with collision avoidance (CSMA/CA).

IEEE802.11a

IEEE 802.11a [START_REF]IEEE Std 802.11a™-1999: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHz Band[END_REF] is an amendment to 802.11 standard which operates in the 5GHz licensed band. It was designed for higher bandwidth applications than those provided by IEEE 802.11b. The maximal offered bit rate is 54Mbps using orthogonal frequency division multiplexing (OFDM). Modulation schemes start from BPSK for bit rate of 6Mbps and ends with 64-QAM for 54Mbps bit rate.

IEEE802.11g

The goal of 802.11g [START_REF]IEEE Std 802.11g™-2003 Part 11: Wireless LAN Medium Access Control (MAC) and Physical[END_REF] was to provide a high throughput in the 2,4GHz band while maintaining compatibility with IEEE 802.11b. The resulting standard provides optional data rates of up to 54Mbps, and backwards compatibility with 802.11b devices to protect investments in legacy WLAN installations. It uses OFDM (the same technology used in 802.11a but in the spectrum of 802.11b) and CCK.

IEEE802.11n

The goal of the IEEE802.11n standard [START_REF]2009 IEEE Standard for Local and metropolitan area, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Enhancements for Higher Throughput[END_REF] is to increase the peak throughput, making data flow as fast as possible. The bit rate is up to 600Mbps using 40 MHz channel. The IEEE802.11n standard group makes use of Multiple-Input/Multiple-Output (MIMO) and OFDM in several configurations and provides also backwards compatibility with already installed systems in the same frequency.

IEEE802.16

The IEEE 802.16 family was originally designed to provide fixed broadband wireless access for residential and enterprise use in a point-to-multipoint (PMP) architecture. Allowing high bandwidth and rapid deployment of wireless systems, the IEEE 802.16 was immediately recognized as an interesting alternative to the conventional broadband access solutions like Digital Subscriber Line (xDSL) and Fiber To The Home (FTTH), especially in rural areas and developing countries that suffer from the lack of telephony infrastructure. Simple maintenance, scalability and speed of installation will offer better revenue for service providers.

IEEE802.16d

Also known as fixed WiMAX [START_REF][END_REF], it was approved as an upgrade to the IEEE 802.16a [START_REF]IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems[END_REF] standard. The design of a Non Line Of Sight (NLOS) system drove the design of its physical layer, which operates in the 2-11 GHz range. The channel bandwidth is variable from 1.25MHz to 20MHz, which uses 256-carrier OFDM scheme and grants access to different subscriber stations (SS) using Time-Division Multiple Access (TDMA) method. The standard supports multiple modulation levels, including BPSK, Quadrature Phase Shift Keying (QPSK), 16-Quadrature Amplitude Modulation (QAM) and 64-QAM. The modulation in the same sector is adaptive and allows subscribers to adjust the channel modulation scheme according to Signal to Noise Ratio (SNR) of the radio link. When the SNR is good the system can switch to the highest throughput modulation (ex 64-QAM). If fading occurs, the system can shift to a lower throughput modulation without dropping the connection.

IEEE802.16e

IEEE 802.16e [START_REF]IEEE Standard Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs)[END_REF] is the mobile version of WIMAX, it is intended to enable a single base station to support both fixed and mobile broadband wireless access. It provides high data rate Wireless Metropolitan Area Network (WMAN). This standard employs a scalable OFDMA system with 2048-carrier, which can scale the Fast Fourier Transform (FFT) size depending on the channel conditions. As IEEE 802.16e supports mobility, it must cope with two problems not faced by the previous standards: Power Saving and Handover. Mobile WIMAX uses OFDMA. Resources are granted to SS by assigning different subsets of carriers in different time slots.

WPAN Family

Wireless personal area networks (WPANs) are focused on a very limited range that can reach several meters. It is called personal because it concerns only the space around a single person or object. The purpose of WPAN standards is to define networks with low-cost, low power, short range and very small size. The IEEE 802.15 working group has defined three classes of WPANs that are differentiated by data rate, battery drain and quality of service (QoS). The high data rate WPAN (IEEE 802.15.3) [10] is suitable for multi-media applications that require very high QoS. Medium rate WPANs (IEEE 802.15.1/Blueetooth) will handle a variety of tasks ranging from cell phones to PDA communications and have QoS features suitable for voice communications. The low rate WPANs (IEEE 802.15.4/LR-WPAN) [11] is intended to serve a set of industrial, residential and medical applications with very low power consumption and cost requirement not considered by the other WPANs and with low needs for data rate and QoS. The low data rate enables the LR-WPAN to consume very little power.

ZigBee is an example of the IEEE802.15.4 that is used in multiple sensor applications.

For these devices to interoperate and communicate over IP networks, a common packet format must be defined to encapsulate layer 3 protocols. Bluetooth Network Encapsulation Protocol (BNEP) [START_REF]Bluetooth Network Encapsulation Protocol (BNEP) Specification[END_REF] encapsulates packets from various networking protocols, which are transported directly over the Bluetooth Logical Link Control and Adaptation Layer Protocol (L2CAP) [START_REF]Bluetooth Core", Specification of the Bluetooth System[END_REF] 1.5.2. Mobile Network Systems

1G

The first commercial cellular network was the Nordic mobile telephone (NMT) deployed in Scandinavian countries in 1981, followed by the advanced mobile phone service (AMPS) in USA in 1983. The European system was known as total access communication system (TACS). These analog wireless systems are referred to as first generation or 1G. They use FDMA as medium access scheme by allocating a 30KHz wide channel for each user.

2G

The need for proposing mobile service to wide number of customers pushed the use of digital system instead of analog one. Hence the global system for mobile communication (GSM) was developed by the European Telecommunications Standard Institute (ETSI), whereas, in North America an equivalent system was developed under the name of IS-95 CDMA known also as cdmaone. 2G systems have known the introduction of the frequency plan which is the reuse pattern of the frequency used in the cells as long as they are not adjacent. GSM system is based on time division multiple access (TDMA) with carrier bands of 200KHz whereas IS-95 system use code division multiple access CDMA.

General Packet Radio Service (GPRS) is the support of data services developed by ETSI. It is referred to as 2.5G cellular system. It defines a packet transmission system that overlays GSM and interworks with internet. A GPRS terminal is assigned an IP address and charged on the basis of transferred data. GPRS can reach a bit rate of 115kpbs by allocating the eight GSM slots to transmit or receive data packets. Data traffic and voice traffic are split by the Base Station Controller (BSC). On the one hand, it sends data packets to the Serving GPRS Support Node (SGSN) and routed afterwards toward packet data network via the Gateway GPRS Support Node (GGSN). On the other hand, voice communications are routed to the circuit switched network via the Mobile service Switching Center (MSC). An enhancement of the data rate of GSM/GPRS consists of changing the modulation scheme from Gaussian Minimum Shift Keying (GMSK) to 8 Phase Shift Keying (8-PSK). The resulting product is called Enhanced Data Rates for GSM Evolution (EDGE). However, the maximum offered rate is only 384kbps which keeps EDGE in the 2.5G category [START_REF] Smith | 3G wireless with WiMAX and WIFI 802[END_REF].

3G

The evolution towards third generation cellular system was driven by the need of high bit rate and quality of service in order to serve multimedia content like video. QoS is an inherent feature of WIMAX. Scheduling mechanisms are implemented in both base station and mobile terminal to match QoS requirement of the application to the available time slots and sub carriers. In the uplink, the allocation of the needed resources is done accurately thanks to bandwidth request/bandwidth grant paradigm prior to data transmission. Five QoS categories are defined following the requirements of the application; these categories are listed in Table 2. 3G systems introduce new IP-based services for mobile users. Some of the new services such as video streaming applications need certain level of QoS in order to provide acceptable quality of experience for the user. 3GPP has released special technical specification [16] for QoS support in UMTS. In this specification, five QoS classes have been defined (see Table 3).

QoS Mapping in Heterogeneous Environment

It is very important to guaranty the same QoS level for the user when roaming between heterogeneous networks. The absence of such support will affect the quality of experience of the user. This task is not simple since each network has its own definition and categorization of service classes as it has been shown in the above paragraphs.

Though, an approximation of the QoS level can be made by mapping service classes from each network technology according to the served application. Table 4 gives the proposed mapping for UMTS, WIMAX and 802.11e standards.

Overview of Mobility Mechanisms

Types of Mobility

There are several types of mobility following the action taken by the user and the use case. Some mobility types are considered as an extra service while others are indispensable. Hereafter, the four main mobility types are introduced.

Personal Mobility

We talk about personal mobility when a single user is located at different terminals using the same logical address. Two cases are possible: one address for many potential terminals and many addresses reaching one terminal. Mapping between the different terminals and the logical address may need a dedicated server. An example of such server is the SIP registrar which maps the URI to the different IP addresses. If a user would like to be reachable on a mobile phone, a PC and a wireless device, he/she may use these devices either at the same time or alternate between them.

Service Mobility

Service mobility allows users to maintain access to their services while moving or changing devices and service providers. Services like address books, call logs or presence service can be maintained in the new location of the user. Service mobility adds certain difficulties for home service provider such as media adaptation and QoS provisioning in the new network in order to maintain service delivery at an acceptable level. This kind of mobility needs prior agreement between service providers. It should also be possible to update and customize these service definitions from the new location (new terminal or network).

Terminal Mobility

This is the most considered type of mobility in research since it is a mandatory service in wireless networks. Terminal mobility allows a device to move between different networks while continuing to communicate with its corresponding peers.

Terminal mobility management protocols can intervene in different levels in the protocol stack in order to ensure uninterrupted service. Several issues should be faced by the terminal mobility protocols in order to keep acceptable perceived quality of experience regarding the ongoing communication.

Session Mobility

Session mobility allows a user to maintain a media session while changing terminals. For example, a user watching a video film in a laptop may want to continue the session in his high definition screen. Here again, media adaptation should be supported by the content provider, otherwise the QoS of the media will be affected.

Another scenario of session mobility is when the user wants to split the media to be played in different devices, for example, playing the audio stream in a speaker phone and the video stream in a video projector.

Layer 2 Mechanisms

Layer 2 mobility management consists mainly of ensuring access to network resources in the target network.

Mobility in Mobile Systems

Handover management in GSM networks is known as mobile-assisted handover (MAHO) because it is handled entirely by the network. More specifically the BSC and MSC are in charge of this task. When the mobile moves from one BTS to another within the same BSC the handover coordination is done by the BSC. In the case this handover is done towards another BTS which is under control of a different BSC, the handover is coordinated by the MSC. Continuous signal measurements are collected by the BSC and MSC and used in deciding which mobile should perform the handover and which cell it should handover to.

IEEE 802.11r

This standard specifies fast Basic Service Set (BSS) transitions. The main target of the IEEE 802.11r standard [START_REF]IEEE Standard Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: Fast Basic Service Set (BSS)[END_REF] is to reduce handoff time in order to avoid connectivity failures and packet losses while users move from a serving Access Point (AP) to a target AP. This handoff time is due to the re-authentication process that occurs in the target AP. IEEE 802.11r avoids the re-authentication process. This is especially relevant for real time applications. Coordination between serving AP and target AP takes place before traffic is routed between them.

Mobile WIMAX

Handover is handled in mobile WIMAX by using MAC messages. Various handover strategies are defined [START_REF] Kumar | mobile broadcasting with WIMAX, principles, technology and applications[END_REF].

• Hard handoff (HHO): in this handoff method, the mobile station breaks contact with the serving base station before making connection with the new one. This approach is a break-before-make approach but the handover delay is kept less than 50 ms.

• Fast base station switching (FBSS): this is a soft handover method where the mobile station is in contact with all active base stations within its coverage called "active set". When the mobile decides to change its serving base station or "anchor base station" it sends a message in a special channel called channel quality indicator. This method requires a perfect synchronization between base stations.

• Macro diversity handover (MHDO): in this method the handover is made more seamlessly than FBSS because the mobile has simultaneous communication with all base stations of the active set.

Layer 3 Mechanisms

Mobility is an intrinsic issue of IP protocol. This problem comes from the fact that the design of TCP/IP stack gives two roles to the IP address simultaneously. The first role is the localization. Therefore, any node in internet is reachable with its IP address which appears in the destination field of the packet. As the internet is organized in hierarchical structure and the routing protocol uses principally the network address part of the IP address to decide which route to follow, it is not acceptable for a node to have an IP address which is not homogeneous with its sub-network. Otherwise, the packet destined to this node will never be delivered. The second role of IP address is the identification of the application, especially when using TCP as transport protocol.

Actually every application uses the couple (IP address, port number) as unique identifier for the end to end communication. Any change in one of these two parameters leads to a breaking in the application flow. Discussion about the duality of the IP address has been addressed during the specification of IPv6, but the IETF members did not succeed in separating the localization from the identification in IPv6. Although some proposals try to overcome this problem like Locator/ID Separation Protocol (LISP) [START_REF] Farinacci | Locator/ID Separation Protocol (LISP)[END_REF] and Host Identity Protocol (HIP) [START_REF] Moskowitz | Host Identity Protocol[END_REF], they are not widely deployed. Instead of treating the source of the problem, the whole research community is concerned about finding solutions for the symptoms. In the following we give an overview of the most known mobility management schemes in the network layer.

Micro Mobility

When a terminal changes frequently its subnet within the same domain we talk about micro mobility.

1. [START_REF]IEEE Standards for Local and Metropolitan Area Networks: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. Medium Access Control (MAC), Quality of Service Enhancements[END_REF] In IDMP, the MN acquires two types of CoA: Local care-of address (LCoA) which identifies the MN's attachment to the subnet and Global care-of address (GCoA).

The MN should inform its MA about any change in the LCoA. While MN updates its data packets to the home address as if the MN is still in the home network. These packets are intercepted by the HA and encapsulated towards the FA. Then they are decapsulated in the FA and forwarded to the MN (see Figure 3). In Co-located CoA the tunnel is established between the HA and the MN without passing through the FA. Limitations of MIPv4:

The main drawback of MIPv4 is its high handover delay. This delay comes from the fact that the MN should wait for advertisements of FA, and then register to the FA before the tunnel can be established and eventually forward packets. The result of such long handover delay is the loss of some data packets. Secondly routing through the HA is inefficient in case the MN is far away from the HA and leads to a high end to end delay and high overhead, this phenomena is known as triangular routing. Finally, HA is a single point of failure on which the whole system operation depends. Moreover traffic of all MNs go through the HA which can lead to bottle neck creation in the home network.

Mobile IPv6

Although mobile IPv6 [START_REF] Johnson | RFC 3775 -Mobility Support in IPv6[END_REF] maintains the same functioning principle of the previous version, it introduced some improvements. Taking advantage from the IPv6 structure, a mobility header was defined for MIPv6 as an extension header which entails FA suppression. In addition, the route optimization is used as a fundamental support rather than an extension, and the correspondent node is updated securely by using the new return routability procedure. Moreover, neighbor discovery is used instead of address resolution protocol (ARP), thus decoupling MIPv6 from the link layer. MIPv6 operates in two modes: reverse tunneling and route optimization. In reverse tunneling mode, the MN receives the new CoA by means of router solicitation and router advertisement, then updates its binding with the HA which creates the bidirectional tunnel. Afterwards, CN and MN communicate directly without going through HA. Route optimization allows avoiding triangular routing.

Hierarchical Mobile IPv6

Hierarchical mobile IPv6 [START_REF] Soliman | Hierarchical Mobile IPv6 Mobility Management[END_REF] was introduced to reduce both the amount and delay of signaling messages between the MN and the HA/CN. A new entity called Mobility Anchor Point (MAP) is introduced to maintain tracking of the MN within a defined domain using a new care of address called Regional Care-of-Address (RCoA).

MN should register its RCoA within the HA when moving to another network in a different domain (see Figure 5). In case of intra-MAP mobility, the only operation that the MN should perform, is binding update (BU) of its new acquired on-Link CoA with the MAP. Data packets are tunneled twice in HA and MAP before being forwarded to the MN.

Proxy Mobile IPv6

MIPv6 needs the intervention of the mobile to achieve mobility operation.

Network-based mobility is another approach to solve the IP mobility issue. A proxy mobility agent performs the signaling with the HA and does the mobility management on behalf of the MN. For this reason, this mobility management protocol is referred to as Proxy Mobile IPv6 (PMIPv6) [START_REF] Gundavelli | Proxy Mobile IPv6[END_REF]. PMIPv6 was recently adopted as mobility management protocol for packet data networks in 3GPP (TS 29.275) and 3GPP2 (3GPP2 X.S0057-0) and PMIPv6 [START_REF] Yokota | Fast Handovers for Proxy Mobile IPv6[END_REF] but can also be used with upper layer protocols like SIP [START_REF] Boutabia | A hybrid mobility mechanism for heterogeneous networks in IMS[END_REF].

Upper Layer Mechanisms

In this section we give an overview of upper layer mobility management protocols. These protocols manage mobility in transport level or application level. At the opposite of layer 3 mechanisms, upper layers protocols get the end points more involved in the mobility operation.

TCP migrate

The objective of TCP migrate [START_REF] Snoeren | TCP Connection Migration[END_REF] is to handle mobility at the transport level.

Where in conventional TCP, the connection shall break with any change in the couple A second solution is to use a dedicated rendezvous server (RVS) which takes in charge the mapping between HI/HIT and IP address while DNS maintain the mapping between the FQDN, HI/HIT and the corresponding RVS which are more static entries. When a host changes its IP address without being in communication (i.e. pre-session mobility), the mobile host updates its RVS to map its HI/HIT to the new IP address. In case of mid-session mobility scenario, the mobile host sends a HIP update message to the corresponding host to update the destination of the packets. This operation is transparent for the application since the connection identifier (i.e. HI/HIT) has not been changed during the session. Security between peers in HIP is strengthened by using Diffie-

(
Hellman key exchange for mutual authentication. It also limits man in the middle and denial of service attacks.

Voice Call Continuity

Voice Call Continuity (VCC) [START_REF]Voice Call Continuity (VCC) between Circuit Switched (CS)and IP Multimedia Subsystem (IMS);stage 2 (Release 7)[END_REF] is an IMS application that provides capabilities

Session Initiation Protocol

Session initiation protocol [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF] is an IETF standard intended to initiate, control and terminate multimedia sessions. It supports several types of mobility as it was claimed in [START_REF] Schulzrinne | Application-layer mobility using SIP[END_REF]. SIP is an applicative protocol that controls the session but is

SESSION MOBILITY FOR VIDEO STREAMING 1.7. Introduction

Nowadays, telecom operators are making a remarkable progress in providing a wide offer of broadband access to answer the high demand for high bit rate applications.

Nevertheless, user requirements do not stop at providing high rate connection, but exceeds it to ensuring transparent service portability among his equipments. The user would like to choose among his devices those which respond at best his needs and constraints. From small smart phones to large screen devices, the customer enjoys its entertainments or business meetings according to its current situation. Service continuity over different terminals known as session mobility is a challenging operation in terms of handover latency, context transfer and media adaptation. Moreover, this transfer requires synchronization between the involved terminals.

In this chapter we present "SESSAMO", a new lightweight session mobility protocol for streaming applications using RTSP. This solution is transparent to the network and does not require any changes in the client or server streaming application.

The solution is detailed and a set of measurement results are presented. In addition, we present a new method to renegotiate session parameters following terminal capacities in order to adapt the flow accordingly. Renegotiation proposal is based on the use of SDPng and MPEG-21.

Principle of Session Mobility

The goal of session mobility is to give the users the possibility of switching from one terminal to another when enjoying the same multimedia session without any interruption. This operation proved to be useful for users who are in mobility. A typical scenario of session mobility is a user who is using his personal data assistant (PDA) to watch his favorite game when he is outside. The PDA is connected to internet via the public land mobile network (PLMN) which provides 3G service. Once at home the user would like to take advantage of his broadband access and his high definition screen to watch the same media without any service initialization or interruption. Session transfer can be either controlled by the device from which the session is transferred (see Figure 8), this mode is called push mode, or by the device to which the session is transferred, this mode is called pull mode.

Service Continuity and its Constraints

Service continuity means that there should be no interruption when the media stream is transferred between the two devices. Therefore, session mobility adds a temporal constraint to the transfer operation. Handover delay is the period of time elapsed from the instant when the user chooses to switch to the new device by triggering the transfer (ex: button push) and the time instant when the stream starts playing in the target device. In other words, handover delay represents the reactiveness of the transfer mechanism. In the ideal case there should be no time difference between the instant when the media disappears from the first device and the instant it appears again in the target device. In practice the handover delay is not null due to the delay in transmitting signaling packets and data packets between the involved entities (i.e. media server, target device and originating device). Nevertheless, handover delay should be minimized in order not to disturb user's quality of experience. Service continuity adds another constraint related to synchronization of the media between the two devices. An accurate session transfer requires that the stream starts in the target device from the instant it was left off in the first device. This issue is a direct consequence of the handover delay. Solving this issue is important in order to preserve the consistency of the service. This means that we must be sure that the user doesn't miss any sequence of the media and minimize any overlapping in the played material (i.e. play a sequence already displayed in the originating device).

Media Adaptation

Another challenge of session mobility is adaptation of the media being transferred. The variety of devices and their capacities makes it obligatory for the media streams played by these devices to be adapted to their capacities and connectivity rate.

For instance the media stream played by the high definition screen is not suitable for a mobile device without any adaptation; otherwise the system will be overloaded and the quality will be very poor.

The difficulty of media adaptation resides in how to adapt the media streams contained on servers to the big variety of screens, CPU capacities, network rates, batteries drain…etc. This process involves a number of tasks where signaling procedures are not completely defined. To achieve this task two procedures are distinguished: negotiation and adaptation. Negotiation is initiated by the client and takes place at the beginning of the session or during the session when one of the parameters change. Adaptation is the action taken by the server after the negotiation in order to make the necessary changes on the served streams.

Related Work 1.11.1. Mobile IP

MIP is not suitable for session mobility although it can be a considered as a candidate solution. MIP can achieve session mobility since the new terminal has a new IP address and MIP can redirect data packets from the old address to the new address which is actually a new terminal. Nevertheless, not only the session will be transferred, but every thing that was destined to the origination device will be routed to the new device. This is not the objective of session transfer in video streaming where the transfer concerns only the stream itself

Real Time Streaming Protocol

Real Time Streaming Protocol (RTSP) [START_REF] Schulzrinne | Real Time Streaming Protocol 2.0[END_REF] is an application level protocol providing signaling service for real-time data delivery such as audio and video.

Management of the session is provided by a set of methods implementing the classical control player actions such as play, record, pause and stop. Other methods are concerned about describing and negotiating session parameters. RTSP does not provide any data delivery by itself, but relies on transport protocols such as Real-time transport protocol (RTP) [START_REF] Schulzrinne | RTP: A Transport Protocol for Real-time Applications[END_REF]. RTSP operation is based on the client/server approach where the client sends request to the server, and the server answers the client requests. Figure 9 illustrates RTSP session establishment and termination. As far as session mobility is concerned, RTSP does not provide any mechanism for session transfer. For this reason external mechanisms should take in charge this operation. At the opposite of RTSP, SIP provides a built-in method for session transfer between different user agents. REFER [START_REF] Shacham | SIP session mobility[END_REF] is an extension method that allows a client to transfer the session to a third party. Many other works are based on the use of SIP session mobility to provide a framework for session transfer as [42][43].

Proposed Session Mobility Mechanism

As the purpose of our study is providing service continuity for video streaming, we will choose the RTSP as basis of our solution. RTSP is more suitable for this kind of service rather than SIP which is more adequate for interactive applications like telephony and videoconference services. Therefore, a new mechanism for session mobility should be defined and integrated to the streaming application.

Session Mobility Operation

Session mobility allows the user to maintain its session when changing end terminals. The action is started when the user pushes the button to indicate that he/she wants to switch the flow from the first terminal to the second one. A request is immediately sent to the remote terminal. This message contains a description of the current session in an SDP like format. If the new terminal accepts the solicitation, the application sends a command to launch the viewer and the negotiation procedure between the new terminal and the server starts. After negotiation, the target device requests the flow from the server. At the end of this phase, the target terminal begins receiving the flow with requested characteristics; subsequently it sends a message to the first terminal to indicate that the process succeeded. Ending the old session can follow two approaches: make-before-break and break-before-make. Make-before-break approach consists of making sure that the stream is received by the target device before stopping it from the originating one, therefore the acknowledgement is sent only if the data packet is arriving. Whereas break-before-make approach consists simply of acknowledging the transfer request at its reception by target device therefore, the session is stopped in the originating device without any guaranty that the actual session was transferred successfully. Finally, the original RTSP entity sends a TEARDOWN message to the server to stop receiving the flow.

Protocol Description

SESSion And MObility (SESSAMO) protocol is a simple protocol that takes place between the two devices in a peer to peer relationship. It means that both devices implement server and client modules. SESSAMO is based on the exchange of text messages [START_REF] Crocker | Standard for the Format of ARPA Internet Text Messages[END_REF] like HTTP and RTSP. Two main kinds of messages are identified:

request messages and response messages. The first conveys command information, whereas the second one transports the status of the operation result. The general format of a SESSAMO message is as following:

Header 1 CRLF Header 2 CRLF ...

Header n CRLF

A header is always composed of two elements: the header identifier and the value or attribute. Inside the message, the header can take any order. On the other hand, there is a reduced set of headers so that total length of the message does not exceed the Maximum Transfer Unit (MTU).

Hereafter the list of the headers defined for session transfer:

• "type: session ": this header determines the type of the message.

• "sequence: sequence number": this header indicates the sequence number n of the header. It is useful for controlling message loss and message duplication as well as for security.

• "time: time in seconds": this header specifies the time instant t in seconds at which a session has to start from.

• "service: URL": this header specifies the URL (Uniform Resource Locator) from where the session can be obtained. This is the location of the media server serving the current streaming.

• "status: code": this header reports the result of the requested operation. When status code is equal to 1, the operation was successful, whereas 0 means that the operation has failed.

Implementation

We use the open source library live555 [START_REF]Live Networks inc[END_REF] under linux for RTSP protocol and VLC [46] as a video player in the end devices. Live555 is used as video server and also included as a module during the compilation of VLC player for client support of RTSP.

SESSAMO coordinates between the two entities participating in session mobility

operation: the originating device (OD) and the target device (TD). SESSAMO is a peer to peer protocol, for this reason any device that supports session mobility has two kinds of programs: SESSAMO server which listens in permanence to requests coming from other terminals, and client part that can transfer the session from the current terminal.

Thereby, SESSAMO is operating in push mode. Client program is equipped with a graphical user interface to coordinate the operation between both entities. It includes a set of graphical resources to establish the operating parameters. On the one hand, it controls VLC to accomplish commands such as play, stop, pause…etc. On the other hand, it retrieves status reports about the current video session, such as the last received RTP timestamp. This information is used later in the session transfer operation in order to achieve the session handover accurately. The exchange of information required by the protocol is always started by OD. This occurs when the user pushes the key "transfer of current session" (see Figure 10). This action makes the SESSAMO protocol send a request message to TD. This message contains the necessary information to retrieve the video session. If the TD does not receive a response before RTT seconds, it retransmits the same message; the operation is repeated if necessary but not more than seven times.

After seven attempts, the communication with the TD is considered as impossible.

Database of videos/servers session transfer button List of videos

List of target terminals

Local terminal configuration

Data base of target terminals

Testbed

The goal of this testbed is to validate and test the efficiency of our solution in a real video streaming scenario. The testbed is composed of a PC playing the role of the video server; the TD is represented by a laptop, and Nokia 770 internet tablet is the OD (see testbed snapshot in Figure 11). The internet tablet is connected via WIFI to the LinkSys access point which is linked to the other entities through an Ethernet Hub. The tablet is playing the role of the mobile device and the laptop is the high capability device. SESSAMO client and server are developed in C language. As Nokia internet tablet has a different environment (i.e. ARM processor) we compile SESSAMO program using scratchbox [47] (see Figure 12) which is a cross-compiler provided by Nokia allowing the development and compilation of new applications destined to work on that tablet.

Performance Evaluation

In order to evaluate the performance of our session mobility solution we consider the different time instances illustrated in Figure 13. We are interested in measuring the following periods of time: session handover delay (t shd ), session overlap time (t so ) and starting time of the player (t stp ). t 0 : the instant of time at which the user pushes the "transfer session" button.

t 1 : the time instant when SESSAMO request message arrives to TD. t shd is equal to t 0 -t 3 and it corresponds to the period of time that goes from the instant t 0 when the user pushes the button "session transfer" until the time instant t 3 when the video packets start arriving to TD. In practice, this period of time is difficult to measure because it involves the clocks of different terminals. Nevertheless, we propose the following approximation:

t shd = t 3 -t 1 + RTT/2.
As far as the video session overlap time t os is concerned, it indicates the duration of the video sequence that will be played in both devices prior to finish the original session. As the starting time of the session on the TD is equal to the instant of pushing the transfer button, t so corresponds to t 6 -t 0 . Finally, the starting time of the RTSP player t stp is interesting because it gives as an indication about the effect of this operation on session transfer performance. It should be noted that player launching is not related to the mechanism of the mobility itself, but depends on the operating system and hardware capabilities of the terminal. Indeed, the starting time of each RTSP player varies considerably. It goes from some fractions of second to several seconds. t stp can be obtained by means of t stp = t 2 -t 1 .

The experimentation was conducted ten times for each scenario and the mean value of each metric is calculated.

Make Before Break Scenario

Figure 14: make before break scenario Make before break approach as illustrated in Figure 14 consists of establishing the session on the TD before the acknowledgement is sent back to the OD.

Acknowledgement here means that data traffic is arriving and the session was transferred with success. The advantage of this scheme is the guarantee that the stream is really received by the OD, if this latter can not establish the session with the video server, the acknowledgment will not be sent back and the session will not be terminated on the OD. Table 6 summarizes results of session transfer. The handover delay is short and the transfer is almost instantaneous for the user. The disadvantage of this scheme is that video session overlap is high. To be noted that the starting time t stp of the RTSP player represents 97% of the total session handover delay.

Break Before Make Scenario

Figure 15: break before make scenario

In break before make scenario (see Figure 15) the acknowledgment is sent immediately after reception of transfer request, and subsequently the session is terminated on the OD. The advantage of this approach is that video overlap is reduced compared to the previous scheme as shown is Table 7. As for session handover delay is almost equal to the make before break handover delay since the principal cause of this delay is VLC starting time with more than 97%. The drawback of this scenario is that a silence time occurs during the transfer operation, especially when the handover delay high.

Table 7: break before make results

Delay value in ms

Session handover delay 499

Video session overlap 9

VLC starting time 487 1.12.5.

Synchronization Issue

An ideal session mobility mechanism should provide perfect synchronization between the two devices. In other words TD should resume the session exactly from the same instance the user has triggered transfer button. This problem is not noticeable in small networks as in the case of our testbed where the delay between the different entities is negligible. But when it comes to large networks, congested networks or busy servers, the delay can be significant. Therefore, the overlap will be important in case of make before break and silence time will be high in case of break before make. In such conditions, make before break approach seems to be more adequate, because at least the user can continue watching the media on the old device until the service is established on the new one. As for video session overlap, it can be compensated by seeking the video in a farther point compared to the button push point. This difference in time should be equivalent to the estimated handover delay.

Renegotiation of QoS Parameters

The challenge now is to cope with the variety of mobile devices. Indeed, we can find in the market different devices that have different screen sizes, CPU powers, operating systems, network interfaces, supported codecs, battery powers…etc. A server offering a given service has to be capable of satisfying each device according to its own capacities. Signaling protocols such as RTSP and SIP transport in their message payload the QoS constraints imposed by clients and their capacities. Media servers transcode or re-quantize data content accordingly. It is obvious that the media adaptation is a must in case of session mobility as we transfer the flow from one terminal to another.

Nevertheless, we tackle the problem of QoS management in session mobility in different phases. The first phase is the negotiation that takes place at the beginning of the session; the second one is the adaptation during the session when some parameters change in the same terminal such as battery level and connection rate. The third phase is the re-negotiation when transferring the session. The particularity of our work resides in the manner these tasks are achieved by means of SDPng/MPEG-21 and RTSP. In particular, QoS service adaptation is not based on a classical approach where server adapts the flow without any participation from the client. Indeed, in our approach the client drives the server to obtain the most suitable QoS.

It should be noted that adaptation to network conditions is not the subject of our study. We focus on the parameters that are related to the terminal itself. If the quality of the video is degrading because of congestion in the route down to the terminal, other end to end techniques should intervene to adapt the media accordingly. Real time control protocol RTCP [START_REF] Schulzrinne | RTP: A Transport Protocol for Real-time Applications[END_REF] is one of the possible solutions to control the flow using the periodic reports. These reports are sent back to give the server an idea about the available bandwidth along the route to the terminal.

Related Work

In this section we give a description of the most relevant standards that treat media negotiation.

Session Description Protocol new generation (SDPng)

SDPng [START_REF] Kutscher | Session Description and Capability Negotiation[END_REF] is a description protocol for multimedia sessions. It is an applicationindependent framework transported by other signaling protocols such as SAP (session announcement protocol), RTSP, SIP…etc. the main innovation of SDPng compared to the conventional SDP [START_REF] Handley | SDP: Session Description Protocol[END_REF] is its extensibility by using XML, which gives the possibility to describe the different terminal characteristics and user preferences. SDPng description is an XML document divided into 5 parts: capabilities, definitions, configuration, constraints and session information. We are interested in constraints parts, in order to accomplish multimedia adaptation. The constraints section allows expressing constraints on combination of terminal configuration. This feature is intended for specialized devices with strict limitations. To be noted that SDPng base specification is only a container for constraints and does not define them.

MPEG-21

Digital Items are defined as structured digital objects, including standard representation, identification and metadata. They constitute the fundamental unit of distribution and transaction within the MPEG-21 [START_REF]Information Technology -Multimedia Framework (MPEG-21) -Part 7: Digital Item Adaptation[END_REF] framework.

QoS Management

We propose in this work a scheme using SDPng/MPEG-21 in the context of mobile multimedia applications that works under the client-server paradigm. Here, SDPng and MPEG-21 are employed to specify the QoS requirements exposed by the client application at different stages of the session's life, specifically, QoS negotiation and renegotiation stages. Negotiation is the first operation that takes place before streaming starts. The purpose of this operation is to inform the server about the characteristics of a given device in order to serve an adequate coded stream. As far as renegotiation is concerned, we consider two cases where it can take place. The first one occurs when a session moves from one terminal to another (i.e. session mobility) which has different capabilities than the first one. The second one arises when a "stable" session taking place over a given terminal suffers from an unexpected deficiency (battery level is low, system resources overload…etc.). In both cases, the application has to adapt its behavior according to the new circumstances in order to maintain its operation at an acceptable QoS level. In classical approaches, the server decides about the adaptation procedures to be used, relying on the information reported by the client.

This information essentially describes the instantaneous network state in terms of the end-to-end delay and the packet loss ratio. One should notice that the client does not directly participate with the server to take decisions about the adaptation process because it only reports its perception about the network QoS. Indeed, the server adapts its behavior under a "best effort" scheme hoping that adaptation will be the best choice for the client. Our proposition contrasts with classical approaches because it gives a more active role to the client.

Specification of Qos Aspects for Session Mobility

In distributed multimedia applications, QoS management is implemented to provide the final user with acceptable service. A very important aspect of QoS management is QoS specification, which should be conveyed to the server. This specification is composed of a set of parameters designated to describe accurately the QoS requirements of a distributed application. As we stated above, the tools that we use in our work are SDPng and MPEG-21. These standards take into account the new generation of applications that operate in a highly heterogeneous mobile context, but at this time they are not completely defined. Here are the main interesting parameters of which degradation can seriously damage the running session:

• Display properties: it includes colors properties and resolution of the frame.

Resolution can be determined by the size of the window displaying the video not necessary the full screen resolution.

• Battery level: when the battery reaches critical levels, power consumption has to be reduced, i.e. the server can eliminate the video stream and keep only the audio.

• Memory space: in case of overload in the terminal, memory space becomes insufficient to run all applications.

• CPU utilization: in case the terminal is running other applications simultaneously with the media session, the CPU utilization is increased as it is shared among all applications and consequently causes a degradation of the perceived quality of the stream.

• Network interface bit rate: changing access network in ubiquitous mobile environment is a potential operation. With cross layer protocols, the application can be informed about an imminent handover as well as the new access network characteristics.

.2. Session Remote Control

Session remote control is another case where a session needs to be negotiated. To clarify this concept, we consider a client who is watching a video of his favorite game in a PDA. Afterwards, he desires to record it with a better quality on his hard disk placed in his home to watch it later (see Figure 19). SESSAMO protocol can also be used in this case even if this is not a real session mobility scenario. The characteristics are specified from the PDA and sent via the SESSAMO request. These parameters are retrieved by the set-top-box and used to negotiate the session with the server. Moreover, the set-top-box uses RECORD method in establishing the new session with the server offering the media stream. In this case, the QoS negotiation can be started with better quality, via a wired network and without real-time presentation constraints, because it will be played later locally.

Renegotiation 1.13.5.1. Session Mobility

When a session moves from one terminal to another with different characteristics, a renegotiation process is required (see Figure 20). Renegotiation of the new parameters is achieved by the new terminal itself. It specifies its constraints in the SDPng message and sends it to the server. In response, the server adapts the media flow according to the new constraints and transmits it to the new terminal.

Parameter Change

The idea of QoS renegotiation within multimedia session is based on the exchange of RTSP messages containing information about the current status of the terminal capabilities. SET_PARAMETER is the RTSP message that we choose to conclude this task, because it is used to convey parameters related to the operation of the received service. SET_PARAMETER method is used to report QoS indicators within the current session in an SDPng like message from the client to the server as showed in Figure 21.

Using this information, the server can decide whether an adaptation operation is required. It should be noted that during the session only parameters that has been changed are concerned by the notification. The second approach proposes to adapt the application to the available network resources. In the global Internet, adaptation of the flow from the application seems to be a more realistic solution. In order to implement the adaptation capability, the application should support some additional functionality. From a network perspective, a periodic feedback containing the current reception status of the flow allows the server to adjust the bit rate accordingly. A standardized protocol named RTCP (Real Time Control Protocol) is currently used to perform this task. The reported network state information allows the server to reduce or increase the bit rate in order to alleviate the losses in the sent flow. Of course, the losses rate will be reduced but the QoS perceived by the user will also be degraded, but in a controlled manner. There are several techniques allowing a server to adapt the flow to the available network resources, such as quantization, re-quantization [START_REF] Assuncao | Post-processing of MPEG2 coded video For transmission at lower bitrates[END_REF], transcoding [START_REF] Vetro | Video Transcoding Architectures and Techniques: an Overview[END_REF] [55], frame dropping, multilayer encoding [START_REF] Rejaie | Layered Quality Adaptation for Internet Video Streaming[END_REF]…etc.

Acknowledgment

The contribution presented in this chapter is proposed to solve one of the problems posed by the European project SUMO-ITEA [57]. The primary target of SUMO (Service Ubiquity in Mobile and Wireless Realm) is providing service continuity for rich media terminals. Practical solutions have been proposed to solve service continuity for both terminal mobility and session mobility. SESSAMO solution was one of the adopted solutions for session mobility, and a demo was presented during the final review.

Conclusion

Session mobility is an optional service that can be offered by the operator or even by content provider to their customers in order to give them more flexibility and portability regarding their interaction with the served media. In this chapter, we

proposed a new solution to support session mobility in video streaming services.

SESSAMO is a lightweight protocol that operates between the concerned terminals and conveys the needed information for the target terminal to resume the session.

SESSAMO has been implemented in a real life scenario using commercial mobile device. Moreover performance of the proposed solution has been conducted and the results show that this solution makes efficient and fast handovers. Indeed, achieving session transfer is a challenge in itself, but it has some "side effects" that should be treated as well. In fact when transporting the session from one terminal to another it is more likely that the latter has different hardware and software capabilities. Therefore, some measures have to be taken in order to adapt the served stream to the current terminal capacities. In order to cope with IP limitations in mobile communications, a number of approaches have been proposed. Although they tackle the problem from different perspectives, they agree on the way they handle it. Indeed, the main approaches rely on a number of procedures that can be classified into: movement detection and address allocation, traffic redirection, global location tracking update and handover smoothing (see Figure 22). These four procedures and the problems they address are analysed in more detail in the following paragraphs.

Movement Detection and Address Allocation

First of all, a mobile node needs to detect its movement among different networks.

Traffic Redirection

This phase consists of redirecting packets destined to the MN's old address to its new location. This operation is needed for maintaining the ongoing communication because of the hierarchy nature of addressing in internet and routing protocols. In general, routing tables in intermediary routers are built based on the network address not on the host address. The reason behind this choice is minimizing routing table size and consequently making routing decision as fast as possible. Traffic redirection can be guaranteed by the network or the end points; in other words, re-routing packets to the new location can be done with or without the intervention of the communicating nodes.

Network Based Traffic Redirection

This method is transparent for the application in MN and its CNs. Designed network entities are in charge of gathering packets addressed to the old MN's address and resend them to the new address. Usually tunnelling is used to carry out this operation without altering the original IP packets. MN should inform the redirection network entity about its current location permanently. For example, home agent plays this role in MIPv4, it intercepts packets and encapsulates them to the foreign agent.

End Point Based Traffic Redirection

In this scheme, end points are involved in the redirection of the traffic. At the opposite of the previous method, here the application of both MN and CN has to cope with IP address change. Therefore MN should inform all its CNs about the new acquired address and CNs in their turn, update the destination address in the sent packets. Route optimization in MIP is an illustration of this type of redirection. Indeed, end point traffic redirection is more efficient than network based one, because of the non optimized route taken by the packets (i.e. they reach the home network first before being redirected by the home agent).

Global Location Tracking Update

This operation is achieved to maintain the reachability of the MN at global network level. In fact, any node in the global network is reachable by its address. Hence any change of this address should be known to all nodes willing to communicate with this node, not only those who are already in communication with it. Practically MN can not inform all nodes in the global network about its location by itself, but instead, a designated server holds the current MN IP address. DNS server is an example of such server; it maintains mapping between the fully qualified domain name (FQDN) of a

given host and its IP address. Home agent in MIP plays also this role by mapping CoA to home address.

Handover Smoothing

This is an optional operation that aims to make the disruption caused by the handover process less perceptible by the user. Indeed, during steps 1 and 2 the MN is not receiving any packet because it does not have any valid address and the traffic is not redirected until the concerned entities are updated. Those packets are lost because they are sent to the old address. An improvement of user experience during the handover consists of preserving these packets from loss and relaying them to the client in the new location. Two solutions have been proposed in the literature to perform handoff smoothing. The first one is tunnelling as it is used in low latency handoffs in mobile IPv4 [START_REF] Malki | Low-Latency Handoffs in Mobile IPv4[END_REF] and FMIPv6 for example. This technique proposes to establish a tunnel between the old and new network, then forward the packet through the tunnel during a period of time long enough to perform the needed updates. The second one is bicasting [START_REF] Joo | mSIP: Extension of SIP for Soft Handover with Bicasting[END_REF][62]which consists of duplicating the flow sent from the CN to both old and new addresses. Hence, at least one instance of the packet will reach the MN wherever it is located. Of course, each solution has its advantages and disadvantages in terms of overhead and resource utilization but it should be noted that this operation is limited in time and covers only the handover period.

The above operations are the most important operations in mobility management protocols over IP. We notice here that not all of them are implemented by mobility protocols nor they are necessarily executed in that order. Some of them are more critical than the others. For example, from the ongoing communication point of view, the more important operation after acquiring a new address is handover smoothing followed by traffic redirection. Whereas the global location tracking update is not critical since it is important for future communications.

Case Study

In this section, we take the example of two mobility management protocols from different perspectives and study them following the analysis done previously. We show through this case study that the most representative approaches for handling node mobility (i.e. Mobile IP and SIP) follow the steps stated earlier. Afterwards we draw a summary overview of the most relevant mobility protocols regarding the same analysis.

Network Layer Perspective: Mobile IP

The main goal of Mobile IP is to avoid upper layers being worried about address changing due to node mobility.

Movement Detection and Address Allocation

CoA in MIPv4 is attributed by the new FA, which periodically broadcasts a Router Advertisement message containing CoA related information. MN receives an advertisement when it joins the new network and proceeds to the registration with the FA in order to obtain a CoA. The speed of movement detection depends on the periodicity of the advertisements. In other words, the more frequent the advertisement is broadcasted, the faster movement is detected and consequently faster the handover is performed. However, this improvement in handover performance comes with a cost which is an increasing in the signalling overhead of MIPv4. This drawback is avoided in MIPv6 by introducing router solicitation procedure. In this version of MIP, as soon as MN joins a new network it requests explicitly a solicitation rather than waiting for the advertisement. As a response to the solicitation, the access router sends a router advertisement immediately.

Traffic Redirection

In MIP, traffic can be redirected either using network based traffic redirection method or end point based traffic redirection method.

Network based method:

Home agent is the pillar entity that performs traffic redirection, since all traffic destined to MNs are routed through it. Ordinary operation mode of MIP carried out using tunnelling mechanism between HA and FA in case of FA-Coa or between HA and MN in case of co-located CoA. Indeed packets sent from the CN are destined to the home address, while MN is not in its home network, packets are intercepted by the HA using layer 2 mechanisms (i.e proxy arp). Afterwards, those packets are encapsulated in a new IP header which has HA address as source address and CoA as destination address. In case of FA-CoA the tunnel is established between the HA and FA, whereas it ends at MN in case of co-located CoA. This method has two major drawbacks: the first one is that the HA is a single point of congestion from where all traffic should be encapsulated and routed. This operation is CPU consuming and requires high performance hardware especially when the number of MN is high. The second negative point is that routing is not optimal since packets do not follow the normal route towards the destination but instead they are routed first to the HA and then from the HA to the MN. This operation is known as triangular routing.

End point based method:

In order to overcome the drawbacks of network based redirection method, IETF has proposed an optimization to MIP operation called route optimization. In this mechanism MN does not rely on the network (i.e. HA and FA) to redirect its packets from the old destination to the new one, but performs the necessary updates directly with its CNs. In other words, the tunnel is established between the MN and its CNs without any intervention from the HA. Consequently, all packets sent from the CN will be routed by the intermediary routers directly to the new destination assigned by the CN in the outer IP packet. This optimization comes with a cost which is the involvement of CNs in the MIP protocol whereas in the previous method they were not involved. If nobody responds with an ICMP Echo reply within certain interval of time, the DHCP server will answer with Offer message. There are some proposals to reduce the number of packets from four to only two [START_REF] Park | Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)[END_REF] and others suggest to remove DAD. Finally, Dynamic Registration and Configuration Protocol (DRCP) [START_REF] Mcauley | Dynamic Registration and Configuration Protocol (DRCP) for Mobile Hosts[END_REF] is proposed to replace the conventional DHCP to meet requirements of real time applications.

Traffic Redirection

The procedure allowing redirecting the traffic from old to new address is known as mid-call mobility procedure in the context of SIP. The principle is the following: smoothing. It should be noted that SIP mobility engenders many messages exchange before re-establishing the session which cause a significant handover delay [START_REF] Nakajima | Handoff Delay Analysis and Measurement for SIP based mobility in IPv6[END_REF]. Hence a handover smoothing mechanism is required in order to provide seamless service continuity. Bicasting the stream [START_REF] Joo | mSIP: Extension of SIP for Soft Handover with Bicasting[END_REF] towards both destinations (old and new address) is one of the solutions proposed to perform the handover smoothing for SIP. Table 8 provides a summary of the most known mobility protocols over IP and classifies their operation in accordance with the above study.

when

Summary

Conclusion

In this chapter we analyzed the procedure of mobility management protocols over IP and we deduced that most of them follow the same logic in tackling mobility problem. Four main sub operations are identified: movement detection and address allocation, traffic redirection, global location tracking update, and handover smoothing.

These sub-operations are not necessarily implemented in every mobility protocol but some of them are mandatory and others are optional. Moreover, cooperation between different protocols even belonging to different layers is possible in order to achieve seamless handovers. We believe that this classification is very useful in analyzing and designing new mobility protocols. To demonstrate the validity of our classification, we took the example of MIP and SIP and we showed from their thorough analysis that they are compliant with the proposed classification. Finally, a summary of other mobility protocols and their compliance with the proposed classification is given.

COLLABORATIVE HANDOVER MECHANISM FOR REAL-TIME SERVICES 1.24. Introduction

Next generation networks intend to offer pervasive and ubiquitous services to the customers wherever they are and whatever the application they are using. To achieve this goal, service continuity across homogenous and heterogeneous networks must be guaranteed. Thanks to mobile IP and its variants, continuity of service in all IP networks can be ensured. MIPv6 was designed by the IETF to provide mobile nodes (MN) with the possibility of maintaining the ongoing communication when changing the access network and MN's IP address. Although MIPv6 presents some improvements compared to MIPv4, its long handover delay makes it unsuitable for real time applications.

FMIPv6 tries to reduce this delay by using link layer triggers to perform address acquisition before layer 2 handover. Moreover, FMIPv6 prevents packet loss by creating a tunnel between the Previous Access Router (PAR) and the New Access Router (NAR) to forward packets until the correspondent node and the Home Agent update the Care of Address (CoA). However, FMIPv6 shows some limitations in fastmoving terminals. On the one hand, the terminal has not enough time to exchange all messages with PAR in the initiation phase. On the other hand, access routers require a big buffer size to buffer packets sent to the MN between the moment of FBack transmission and the moment of unsolicited neighbour advertisement (UNA) reception respectively by PAR and NAR.

In this work we use MIH services more efficiently in different steps of FMIPv6, not only in the discovery step. MIH services are solicited by AR each time it cannot ascertain the transmission of a message and learns the MN situation by an event subscription. This scheme increases the probability of FMIPv6 predictive mode by reducing the handover initiation delay. Moreover, by using link event indications the mobile will be served until its physical disconnection, and as soon as it connects to the new network, packets will be forwarded from the new access router without waiting for attachment announcement from FMIPv6. Therefore buffer size dedicated to buffer tunneled packets to the new MN's location is reduced. Another advantage of this proposal is ping pong effect resiliency. Indeed, handover is initiated by the MN but finalized by the network allowing cancellation of the already initiated handover which was triggered by a "false alarm".

We show through analytic analysis and simulation, that our scheme reduces handover delay as well as packet loss in both predictive and reactive handovers. In addition, buffer size needed to buffer packets in access routers during the handover is smaller. Finally, the proposed mechanism avoids excessive ping pong events among wireless networks.

FMIPv6 Limitations

The benefit of FMIPv6 resides in its predictive mode. Any failure in performing this mode leads to reactive mode which adds more delay in handover. Therefore, in case of mobiles in fast movement, It is likely that MN will not be connected to the previous network long enough to send and receive all FMIPv6 messages. Thereby, the terminal should accomplish the initiation step in short period of time in order not to loose any FMIPv6 message. Actually solicitation message is sent only after layer 2 trigger which results in a long initiation time. Moreover, if the connection is broken before the reception of the FBack message, all packets will be lost until connecting to the new network and creating the tunnel between NAR and PAR. The other important delay which prolongs service breaking period is between the moment MN receives FBack and the moment it disassociate from the old network, all packets destined to MN during this period are forwarded to NAR and buffered, whereas MN can still receive these packets on the old link. In fact FMIPv6 proposes also to start buffering packets and forward them (i.e. buffer and forward) at the same time upon receiving FBU even before creating the tunnel. This solution is good to ensure that all packets addressed to MN during FMIPv6 operation will be received either in the old or the new location. In fact this solution can be considered as a bicast solution addressed in chapter 4 where the traffic is sent to both old and new addresses. Nevertheless this solution has at least two drawbacks: it increases the overhead and needs a mechanism in MN operating system to avoid packet duplication in case it takes place.

Related Work

Some works proposed enhancements for FMIPv6 to cope with real time applications for fast-moving terminals. In [START_REF] Mussabbir | Optimized FMIPv6 Using IEEE 802.21 MIH Services in VehicularNetworks[END_REF] and [START_REF] Young | Reduction of Handover Latency Using MIH Services in MIPv6[END_REF], MIH is used to reduce access router discovery by using media independent information server to retrieve necessary information of neighbouring networks without using RtSolPr and PrRtadv messages.

But the utilization of MIH is limited to discovery step. [START_REF] Park | Performance analysis of enhancedmobile IPv6 with fast handover over end-to-end TCP[END_REF] and [START_REF] Li | An Enhanced Fast Handover with Low Latency for Mobile IPv6[END_REF] propose schemes to reduce the effect of duplicate address detection (DAD) performed by NAR before sending Hack to PAR. As for [START_REF] Lu | A Novel Buffer Mechanism for Fast Handovers in Mobile IPv6[END_REF], it proposes to use a disassociation message sent to PAR so that it will start buffering from this moment. However, if the signal becomes too weak, this message has no chance to reach the PAR.

Ping pong effect:

Usually Link_Going_Down threshold is higher than Link_Down level of the received signal. Due to unpredictable mobility of the user and variability of the signal strength because of multipath and fast fading [START_REF] Rappaport | Wireless Communications: principles and practice[END_REF], an erroneous movement detection can occur; hence probability of having a ping pong event increases. Erroneous movement detection or ping pong has negative consequences on the quality of the perceived stream since many handovers take place in close periods of time. Some works try to reduce ping pong effect by acting on the handover triggering mechanism itself.

For example, authors of [START_REF] Won-Ik | Ping-Pong Avoidance Algorithm for Vertical Handover in Wireless Overlay Networks[END_REF] try to avoid unnecessary vertical handover by determining the appropriate time at which handover should be initiated.

In our proposition ping pong is avoided in a different way. Our scheme does not rely on signal strength at certain period of time to decide whether to make or not the handover, but the handover is finalized by the network only if the signal is down.

Whenever the signal comes up again after a link going down notification, handover operation is cancelled. Our scheme is independent from the triggering algorithm and allows avoiding ping pong events.

Media Independent Handover Overview

IEEE 802.21 [START_REF]IEEE Standard for local and Metropolitan Area Networks, Part 21: Media Independent Handover Services[END_REF] 23). On the one hand, MIHF is connected to upper layers such as mobility management protocols via service access points called MIH_SAP. On the other hand, MIHF communicates with low layers using media specific service access points called MIH_LINK_SAP. MIHF reports network interface events to upper layers and conveys the resulting commands down to the proper interface. Therefore, upper layer does not deal with the heterogeneity of network interfaces when performing vertical handovers; in stead, they have a unified interface that handles the different network interfaces. Communication between the different components is performed via media independent services. To be noted that amendments to the underlying physical layer are required in order to define primitives of such events. The complete list of link events is given in Table 9. Link_Handover_Complete Link handover L2 handover to a new PoA is completed Media independent command service (MICS) enables higher layers to control lower layers (physical and data link layers). This service carries the decisions taken by upper layers to lower layers on local or remote entity. For example command service can be used by the decision engine to switch the connection from one network interface to another. The list of link commands is given in Table 10. protocol and leaves this specification to implementation. In [START_REF] Rahman | Transport of Media Independent Handover Messages Over IP[END_REF], the authors propose to use UDP as transport protocol for MIH messages because of its speed and simplicity.

Reliability can be provided by the application using retransmission algorithms.

Triggering Mechanisms 1.28.1. Horizontal Handover

Most of predictive algorithms are based on signal strength for handover triggering. There are different algorithms that use the received signal strength information in order to predict whether the link is going down or not. The most known methods are listed below.

• Threshold: in this method RSSI (received signal strength information) is monitored continually, when this parameter goes below a predefined value the handover is triggered.

• Hysteresis: this method uses two kinds of thresholds: entry threshold and exit threshold. Entry threshold is the minimum value of RSSI to enter a particular network, and exit threshold is the value at which the handover is triggered. This scheme reduces the oscillations between the same networks or ping pong events.

• Trend and Least mean square methods [START_REF] Mhatre | Using smart triggers for improved user performance in 802.11 wireless networks[END_REF]: theses mechanisms are based on the history of the RSSI and try to predict the trend of this latter in the near future.

Vertical Handover

The

Collaborative Handover Procedure

FMIPv6 intends to protect data packets from loss. Nevertheless, sending FBU message after link going down event will prevent MN from receiving any packet because they are encapsulated to NAR even if MN is still able to receive packets.

Therefore, we need to trigger the tunnel creation by another mechanism which is separated from FBU transmission. In this work, we propose a collaborative scheme that involves both the terminal and the network. AR and PoA use MIH services to make it possible for the terminal to continue its communication in the previous network even after link going down notification. The actual link down is the only event that should trigger packet forwarding via the tunnel. Such event is also detectable at the PoA which will notify the PAR to start forwarding packets through the tunnel. Preserving packets of the ongoing session is the first priority that we intend to achieve before any other procedures. We consider the mobility scenario shown in Figure 24. MN is connected to the serving network and has connection to the information server. Information server location can be provided by a DHCP server when responding to MN's request at its first connection to the network.

MIH function starts with initialization operation to discover network entities that provide MIH services and its capabilities, then it registers with other MIHF and subscribes to particular set of events either locally or remotely. MN asks information server about neighboring networks by sending MIH_Get_Information request (see Figure 25). The response contains (AP-ID, AR-Info) couples of neighboring access routers. Thus MN knows about its neighboring networks a long time before the handover, not after handover trigger as it is the case in classical FMIPv6. Once the signal becomes weak, MIH layer is notified by Link_going_down event, then proceeds to the execution of the decision algorithm to decide the network to handover to, based on the already available information server response. After L2 handover, MN connects to the new network by attaching to nPoA which notifies this event to NAR, consequently, NAR starts forwarding packets to MN without waiting for UNA message.

The main difference with classical FMIPv6 is that PAR starts redirecting packets only when it receives Link_down_event notification from oPoA; in the other side, NAR forwards packets as soon as MN connects to the new network.

Performance Evaluation

We assume that the processing time in the different entities is null, and message transmission delay between MIH user and MIHF is neglected when this message is locally exchanged.

Handover Latency

FMIPv6 handover initiation delay D init is composed of router solicitation and advertisement delay D adv and fast binding update message exchange delay D fbu which can include DAD operation delay if it is executed by NAR before accepting NCoA. In the case of classical FMIPv6 we have:

D init = D adv + D fbu
Whereas in MIH-FMIPv6, there is no network discovery after handover triggering since this step is done earlier through the information server, so

D init = D fbu
Reducing the handover initiation time increases the probability of performing predictive mode especially in case of fast-moving terminal and restricted overlap areas.

The handover latency D ho is the period of time when the mobile is not receiving any packet. In case of FMIPv6 this delay starts from the transmission of FBack by the PAR until reception of forwarded packets from NAR.

D ho = D pre + D L2 + 2D MN-NAR
Where D MN-NAR is the delay between MN and NAR, this delay is composed of the wireless link delay D MN-PoA and wired link delay D PoA-AR between the PoA and AR. We assume that:

D MN-AR = D MN-PoA + D PoA-AR 
D pre is the delay preceding L2 handover during which MN is not receiving any packets.

In We suppose in case of FMIPv6 that at least D pre is equal to D MN-AR which corresponds to FBack transmission delay. Figure 27 shows that using MIH services within FMIPv6 reduces to the half the handover latency regarding the wireless link delay.

Buffer Size

In FMIPv6 packet loss is avoided by forwarding packets from PAR to NAR. In the case where MN is about to attach to the new PoA when packets already reached PAR they should be buffered until MN announces its attachment by sending UNA message. Buffering is needed when the forwarding delay is less than L2 handover delay plus attachment announce delay:

UNA L2HO NAR - PAR D D D + <
With D PAR-NAR is the delay between PAR and NAR, D L2HO is the L2 handover delay and D UNA is the delay to transmit UNA from MN to NAR. Therefore, when PAR and NAR are far away from each other topologically or L2 handover is fast, there is a chance to accomplish a seamless handover without any buffering. Moreover, as buffering is a very expensive operation for routers, the buffer size dedicated to MN application will be limited to a maximal value. Therefore packets will be lost if this buffer is full. In order to avoid packet loss we should have

UNA L2HO NAR - PAR D D / D + < + BR BS
Where BR is the bit rate of the application and BS is the buffer size Figure 28 shows the amount of lost packets in case of different buffer sizes regarding the distance between PAR and NAR. Assuming that all forwarded packets are buffered before receiving UNA by NAR, the necessary buffer size that should be dedicated to forwarded packets in access router is expressed as follows:

BS = dt t T R ho D ) ( 0 0 + ∫
Where T 0 is the moment MN stops receiving packets from PAR and R(t) is the instantaneous application bit rate. BS is proportional to handover latency, so reducing D ho means also reducing BS. The required buffer size in the access router when the user is receiving a stream with a bit rate of 64 Kbit/s is reduced by 30% with our scheme (see Figure 29).

Packet Loss

We define the critical time D ct as the period of time between T fbu the instant of sending FBU and the instant when PAR starts buffering packets. During this delay, MN is exposed to the risk of loosing packets after an unexpected L2 disconnection. In classical FMIPv6, PAR starts buffering incoming packets only after transmission of FBack at T FBack , so all packets sent between FBU and FBack can be lost. The critical time is:

D ct =T fbu -T FBack
With utilisation of link event subscription, any unexpected disconnection will be notified by the oPoA and indicated to PAR which starts packet buffering. The critical time ends at the instant of subscription response reception T subs which is prior to T FBack :

D ct =T fbu -T subs
In reactive mode, the proposed mechanism avoids packet loss when the link breaks down during exchange between the two access routers. In conventional FMIPv6 packets are buffered only when FBack is received by PAR, so if the mobile is disconnected between the instant PAR receives FBU and the instant it receives FBack, all packets will be lost during this period. The amount of lost packets depends on the delay between PAR and NAR. Even though PAR and NAR might be geographically close to each other, they can be topologically far from each other especially in heterogeneous networks.

Simulation

The proposed mechanism is evaluated using network simulator 2 (ns2.29) [92] with MIH module that was developed by the national institute of standards and technology (NIST) [START_REF]the network simulator NS-2 NIST add-on[END_REF]. We developed FMIPv6 module as a new agent in the mobile node and access routers. In addition MIH is modified to support the proposed enhancement.

Overlap zone 2m

Propagation model tworayground

Mobility model linear

In order to evaluate MIH-FMIPv6 against FMIPv6 as it is described in [START_REF] Mussabbir | Optimized FMIPv6 Using IEEE 802.21 MIH Services in VehicularNetworks[END_REF] (i.e.

reverse address resolution is made locally using IS information), we consider the following scenario: MN is connected with WIFI interface and moves out from WIFI zone and enters to WIMAX sector. MN is receiving CBR (constant bit rate) traffic from a fixed node. Table 11 shows simulation parameters.

Handover Delay

Handover delay is the period of time separating reception of the last packet on the WIFI interface and the first received packet on the WIMAX interface. LGD coefficient handover delay (s) Results of handover delay show that for FMIPv6 protocol, handover delay is increasing when LGD coefficient increases. At the opposite, MIH-FMIPv6 handover delay is not affected by the level of LGD coefficient. This result is compliant with our objectives since the link is still useable even after a link going down event. The high handover delay is due to the connection delay of WIMAX interface. LGD coefficient number of packets LGD coefficient number of lost packets

MIH-FMIPv6 FMIPv6

Buffer Size

MIH-FMIPv6 FMIPv6

FMIPv6

MIH-FMIPv6

Ping Pong Effect

In our proposition the handover is not systematic after sending FBU message, but becomes effective only after physical disconnection of the terminal. The additional time during which MN is connected to the oPoA can correct an erroneous movement detection caused by fast fluctuation of signal strength. Using the received signal strength (RSS) as criteria for choosing the best network, three thresholds are defined for each technology: i) LGD is the threshold from which the FMIPv6 process is triggered by means of FBU message; ii) ThrE is the entry threshold to the network, it corresponds as well to link_up event notification; iii) ThrO is the exit threshold and corresponds also to link_down notification. Figure 33 presents the algorithm that allows avoiding unnecessary handover due to temporary weakness in the signal strength. The advantage of using MIH event service is the control of FMIPv6 protocol. Any improvement in the signal level after a LGD indication deactivates the whole process by cancelling event subscription in both oPoA and nPoA. Cancellation mechanism can be implemented by means of timers, when expired, the event subscription is deleted.

Conclusion

In this chapter, we proposed a collaborative handover mechanism for fast moving mobiles by using FMIPv6 protocol with assistance of MIH services. The collaboration between the mobile node and the network allows performing optimized handovers. First we use the information service to collect neighboring networks information before the handover trigger which reduces handover initiation delay. Then, we used MIH subscription primitives to subscribe to link down and link up events, respectively in old and new point of attachment. This procedure allows old access router to forward packets to MN until its physical disconnection. Thus, we reduce handover latency, critical time and dedicated buffer size in access routers. Results of analytical study and simulation showed that our scheme is efficient and allows reduction of handover delay and buffer size in access routers. Finally we exploit MIH services to avoid undesirable handover because of erroneous movement detection.

MAXIMIZING PREDICTIVE MODE PROBABILITY IN FAST HANDOVERS FOR MOBILE IP 1.34. Introduction

Mobility management across multi technology wireless networks is an important feature for ubiquitous access. In such heterogeneous environment, service providers have to deal with service continuity especially for real time applications like voice over IP. MIPv4 and MIPv6 can not meet requirements of these applications. In order to achieve this goal, IETF proposed FMIPv6 to reduce the handover delay. This fast scheme allows MN to anticipate layer 3 handover by acquiring the IP address proactively and involving access routers of old and new access networks. At the opposite of MIPv6 and SIP where several and distant entities intervene in the session update (i.e. AR, home agent, sip registrar, CN), FMIPv6 involves only access routers which are by nature close to the MN. However the role of the ARs is temporary; they do not replace in any case the role of the home agent. Moreover, movement detection is achieved by using layer 2 events which is faster than layer 3 movement detection scheme. Nevertheless, FMIPv6 should deal with layer 2 information in addition to layer 3 information which makes it a cross layer protocol.

FMIPv6 operates in two modes: predictive mode and reactive mode. FMIPv6 handover is achieved seamlessly when the predictive mode is used. The failure of the predictive mode degrades the handover performance and disrupts the perceived quality.

Although FMIPv6 standard mentions that it relies on L2 events to trigger mobility operation, it does not specify any mechanism to provide this intelligence. We consider handover optimization done in the previous chapter. Therefore, MIH services are used in order to provide FMIPv6 with the necessary information from lower layers to achieve intelligent handover properly. In this chapter, we propose a maximization of FMIPv6 predictive mode probability by forwarding fast binding acknowledgement (FBack) to the MN in the new network after a successful fast binding update (FBU). Normally, MN is not aware of the success of the binding update if the FBack is not received in the old network. But using the mechanism proposed in chapter 5 PAR can track the MN and forward the FBack according to its location. With our enhancement the predictive mode will depend only on the delivery success of one message (i.e. FBU). Consequently, a new state machine has to be defined for MN to take into account the new enhancement.

The impact of the proposed improvement is investigated through an analytical study.

FMIPv6 Analysis

FMIPv6 may fall into reactive mode if the reverse resolution is not successful or because of the non accomplishment of fast binding update (i.e. sending FBU and receiving FBack). If one of these two messages is not delivered correctly, MN should resend FBU from the new link. In a related work [START_REF] Mussabbir | Optimized FMIPv6 Using IEEE 802.21 MIH Services in VehicularNetworks[END_REF] some authors propose to reverse resolve NAR prefix long time before LGD event using Media Independent Information Service. Indeed, this operation will reduce the preparation handover delay and increase the probability of FBU success. However, FBU message itself or FBack can be lost because of unpredicted link down. This leads MN to operate in reactive mode which consists of sending FBU from the new network. Such operation will have many negative consequences on the overall performance of the handover. It does not only increase the handover latency but also may cause packet drops. Packet loss is caused either by the unreachability of the MN in the old link or at least the buffer in the NAR will be overloaded and some packets should be dropped.

Enhanced FMIPv6

MN considers that the predictive mode was unsuccessful once it does not receive FBack in the old link even if the FBU transmission was successful and the tunnel between PAR and NAR was established. In order to increase probability of the predictive mode we propose to forward FBack to MN as soon as it connects to the new network (see Figure 34). In ordinary FMIPv6, forwarding/buffering of data packets is started without any insurance of the current position of MN, this can lead to FBack loss if MN is no more attached to the old link. In the proposal presented in the previous chapter, PoA keeps the AR informed about the position of MN by means of MIH remote service event. Following the location of MN, FBack is delivered accordingly; if it is still in the old link, the message will be delivered directly, if MN is already in the new network FBack will be forwarded via the tunnel.

MN State Machine

In the proposed improvement, MN collaborates with the network (i.e. PoA and PAR) to achieve a seamless handover. However, MN should be aware of its state all the time to have a coherent handover operation. To clarify this point we will take the example of a MN that has lost its connection with the PAR immediately after sending a FBU. Although, FBU was successful and media packets are forwarded to the NAR and buffered, MN assumes a fail of the predictive mode and turns on the reactive mode after L2 handover. In order to overcome this inconsistency we propose a new algorithm (see Figure 35) for MN to be in phase with the network. MN will follow the same retransmission system as in the normal FMIPv6 after receiving the LGD trigger.

Analytical Study

In this study we are interested in the probability of predictive mode success. It should be noted that the reverse resolution of NAR prefix using the discovered PoA MAC address is done before the LGD trigger. Therefore, the success of the predictive mode depends on the delivery success of FBU and FBack messages in the ordinary FMIPv6, whereas in Enhanced FMIPv6 (E-FMIPv6) it depends only on the success of FBU. We assume that the probability of packet drop in the wired network is null in order to focus only on the wireless link. Packet loss and/or packet error is caused essentially in the wireless link by collision, bit error, or unavailable resources in the PoA depending on the used wireless access technology. We consider p as the probability of any incorrect reception of the packet in the wireless link regardless the reason behind this failure.

= + rea P P

Where P pre is the probability of predictive mode and P rea is the probability of the reactive mode.

As depicted in Table 12, all FMIPv6 messages do not exceed the fragmentation limit in the IP layer. Therefore, these messages are encapsulated in only one IPv6 packet. FBU transmission is considered unsuccessful if the FBU message is not received correctly or FBack is not received correctly, then the probability of FBU retransmission is:

p p p q ) 1 ( - + =
where p is the probability of non correct reception of FMIPv6 message since each FMIPv6 messages is sent in one IPv6 packet (i.e. no fragmentation is needed). Whereas in E-FMIPv6 the probability of retransmission is p q = because the binding success depends only on correct delivery of FBU to the PAR.

q n i pre P n i pre P - = = = + = 1 ) / ( ) 1 / (
Hence the delay of a successful FMIPv6 transaction after i retransmissions is:

NAR PAR PAR MN D D D - - + = 2 2 if i=0 ∑ = - - - × + + = n i i NAR PAR PAR MN backoff D D D 1 1 2 2 2 if i>=1
Where D MN-PAR is the delay between MN and PAR and D PAR-NAR is the delay between PAR and NAR. We assume symmetric delay in uplink and downlink and we neglect the processing delay in PAR and NAR, hence we can write

NAR PAR PAR MN NAR MN D D D - - - + =
Taking into consideration D LGD-LD the estimated remaining time before the link is down, the total transaction delay should be less than D LGD-LD to accomplish a successful predictive mode, which means that the maximum number of retransmissions should be bounded by

        -         - = - - 1 2 log 2 backoff D D n NAR MN LD LGD

Numerical Results

In order to explore the impact of the estimated time before the link is down on the number of possible retransmission of FBU message, we take the following values for the backoff time and MN-NAR delay respectively: backoff=100ms, D MN-NAR =50ms.

In Figure 37 , we can observe that the estimated connection time is a very constraining parameter since even for 3 seconds of remaining time the MN has the right to retransmit FBU only 3 times before the link is down. For this reason MN had better succeed in transmitting FBU in the first attempt.

Conclusion

FMIPv6 is a good solution towards seamless service continuity among different IP subnetworks using different wireless access technologies. Nevertheless, the reactive mode of this protocol penalizes the performance of the handover. In this chapter we focused on the maximization of predictive mode probability by forwarding FBack message to the new location of the MN. This scheme is feasible when MIH services are used in both MN and network side (i.e. NAR and PoA) to localize the MN and then deliver FBack accordingly. This slight modification in the original FMIPv6 has obliged us to adjust the behaviour of MN's state machine in order to achieve the handover coherently. In the analytical study it has been shown that the new changes has brought significant enhancement to the probability of predictive mode.

MOBILITY MANAGEMENT IN

HETEROGENEOUS ACCESS NETWORKS

IN IMS

In this chapter we tackle the mobility issue in IP Multimedia Subsystem (IMS).

Although IMS was designed to integrate different access networks, mobility management among these networks is still unresolved. We propose a novel hybrid mobility management scheme, based on tight cooperation between fast handovers for mobile IPv6 (FMIPv6) and session initiation protocol (SIP) to ensure an uninterrupted real-time service. Moreover, the new Media Independent Handover (MIH) service is integrated into IMS architecture in order to perform intelligent and accurate horizontal and vertical handovers. We investigate two handover cases: selected handover and forced handover. Selected handover takes place when user equipment (UE) is connected to the network via two interfaces at the same time and decides to upgrade the quality of its connection following a given criterion (i.e. cost, bandwidth…etc) without having any difficulty in the previous link. As far as forced handover is concerned, it occurs when the signal reaches a critical level and MN is forced to make a handover in order to maintain the ongoing communication. This case is managed in two phases. The first one or the fast phase is handled by FMIPv6 protocol to preserve as soon as possible packets of the ongoing communication. The second one or the slow phase is handled by SIP protocol to optimize packet delivery route. By doing so, we exploit the benefits of both network layer and application mobility protocols to ensure a continuous session over the two networks without imposing new elements to the network. Through a comparison with other mobility mechanisms, we show in the analytic analysis that our hybrid scheme presents better results in terms of handover latency and packet loss.

Introduction

IMS is a framework for delivering multimedia services over IP networks. It was originally designed by the third Generation Partnership Project (3GPP) as a part of the vision of evolving mobile networks beyond GSM. IMS [START_REF] Gpp | IP Multimedia Subsystem (IMS); stage 2[END_REF] is the new approach adopted by 3GPP towards networks convergence; it was designed to be access independent and ubiquitous. 3GPP adopted the IETF SIP standard for IMS signaling which is considered by nature compatible with internet world. IMS architecture is organized in three horizontal layers that separate user plane, control plane and application plane (see Figure 39). This layering scheme allows isolating the service from network layer by interjecting session control functions for all application types. Therefore any operator can offer a unified interface to service providers to develop a wide range of applications independently.

Nevertheless, mobility management through heterogeneous networks is a new challenge that IMS should face. IMS already provides personal mobility for nomadic users, but still need to deal with service continuity within non 3GPP networks. Indeed, IMS inherits mobile faculties from SIP, however, terminal mobility performance is questionable especially for mid session mobility in heterogeneous networks [START_REF] Dutta | A-IMS architecture analysis and experimental IPv6 testbed[END_REF]. For this reason, 3GPP has integrated only personal mobility into IMS framework and defined different scenarios for session continuity according to the degree of session control.

In order to overcome SIP limitations in providing seamless service continuity,

Related Work

This section gives an overview of IMS architecture and the interworking methods between heterogeneous networks in IMS. Afterwards, some related works to mobility management in IMS are presented and discussed.

IMS Architecture

IMS architecture introduces new elements to establish and control multimedia session. The main components of IMS are the following:

• Proxy-Call Session Control Function (P-CSCF) is considered as the interface between UE and IMS network in order to redirect SIP messages between IMS network and UE.

• Interrogating-Call Session Control Function (I-CSCF) is a SIP proxy server which routes SIP request to the adequate S-CSCF.

• Serving-Call Session Control Function (S-CSCF) is the central point of the IMS control plane. It acts as a SIP registrar which maintains a binding between the user location and the user SIP address.

• Application Server (AS) hosts and executes all services offered by IMS.

• Home Subscriber Server (HSS) dose a similar function as HLR (Home Location Register) in the GSM network. This means that it is a database of all subscribers' profiles.

Interworking

Interworking is the Integration of several heterogeneous access networks. In the context of IMS, interworking is attaching all access networks to the IMS core (see Figure 40). This attachment is done either physically or logically in order to control the session regardless the access network from which UE is connected. There are two levels of integration:

• Tight coupled interworking: also known as 3GPP IP access mode, in this case the WLAN/WMAN is attached physically or via a tunnel to the core network and is totally controlled by the 3GPP network. Two types of IP addresses are necessary in this case. The first one is allocated by the WLAN network and the second one is allocated by the 3GPP network. An IPsec tunnel is established between UE and packet data gateway (PDG) which is placed in the entry of the 3GPP network and receives all the traffic coming from the WLAN.

• Loosely coupled interworking: or IP direct access, in this mode only high level components especially control and signaling information are exchanged between the two networks, i.e. AAA authentication, mobility management, QoS management…etc.

3GPP has detailed functional incremental scenarios to achieve the ultimate goal, which is a 3GPP subscriber with a WLAN radio interface having the same services as when using a 3GPP radio interface (GSM, GPRS, UMTS) with mobility between 3GPP and non-3GPP radio interfaces similar to intra-3GPP mobility. The six scenarios that 3GPP has defined correspond to incremental interworking functionalities from 1 to 6 as shown in Table 13.

Table 13: incremental interworking scenarios

For each scenario there are additional functionalities that should be added to the architecture to support the aimed service. Interworking is the first step towards service continuity in access independent IMS. [START_REF] Gpp | 3GPP system to Wireless Local Area Network (WLAN) interworking,stage 2[END_REF] specifies system description for interworking between 3GPP and WLANs. As for WIMAX interworking with 3GPP, WIMAX forum has proposed an interworking architecture [START_REF]WiMAX -3GPP Interworking[END_REF] based on the same documents as WLAN interworking. It covers both direct IP access (loosely coupled) and 3GPP IP access (tightly coupled), it does not change the previous one, but only add, the missing elements for WIMAX interworking.

Mobility Within IMS

In [START_REF] Chiba | Performance Analysis of Next Generation Mobility Protocols for IMS/MMD Networks[END_REF] three mobility management protocols (MIPv6, SIP, and PMIPv6) are investigated in IMS 3GPP2 context for heterogeneous access networks (i.e. WIFI, CDMA2000). The experimental results show a handover delay of up to 4s for MIPv6 and PMIPv6. This delay reaches 9s when SIP mobility is used.

In [START_REF] Wong | A Multilayered Mobility Management Scheme for Auto-Configured Wireless IP Networks[END_REF] the authors use MIP to handle mobility of TCP traffic, and SIP for real time traffic. MIP and SIP create a kind of redundancy in the network and cause double registration and double binding update. Although the authors of [START_REF] Wang | Mobility Management Architectures based on Joint Mobile IP and SIP Protocols[END_REF] tried to reduce this redundancy by merging entities that have similar functionality, still traffic separation is used which adds more complexity in the network. Moreover using only SIP for real time traffic in IMS framework will introduce a big handover delay.

In [START_REF] Munasinghe | A Unified Mobility and Session Management Platform for Next Generation Mobile Networks[END_REF] MIP and SIP are used for real time traffic consecutively. MIP is used first to reroute the traffic to the new network and than SIP updates the route from the correspondent node by re-registering and re-inviting the session. Here again network entities are redundant due to double use of mobility protocols i.e. Home Agent (HA), Foreign Agent (FA) and sip proxy server. Moreover MIP is known to be unsuitable for real-time applications because of its triangular routing and high handover delay. The corresponding UE will update its destination IP address after receiving a re-invite message which cancels the function of HA. Netcape [START_REF] Udugama | NetCAPE: Enabling Seamless IMS Service Delivery across Heterogeneous Mobile Networks[END_REF] also tries to optimize handover delay by using MIP for underlying traffic redirection.

IHMAS [START_REF] Bellavista | IMS-Compliant management of vertical handoffs for mobile multimedia session continuity[END_REF] is a proactive solution that aims to reduce vertical handoff latency; it predicts vertical handoffs at client side and starts session reconfiguration before handoff management. This proposal adopts an application layer proxy-based approach, for session signaling and data handoff. It uses application server for session continuity that reduces handoff media losses by decoupling session rebinding and data transfer times.

Nevertheless, this solution takes into account only the case of make-before-break, in other words the authors assume that there is always enough time for the UE to prepare the connection to the new network before leaving the original one. While SIP operations (register and invite) in addition to the basic configuration operations need a long time to be achieved.

Media-independent pre-authentication (MPA) is a framework that allows UE to pre-authenticate proactively before layer 2 handover. It allows also a pre-configuration of UE with the appropriate IP address. In addition, the binding update of the corresponding network entities (HA, CN, SIP server etc) is carried out proactively whatever the used MMP. After a handover implying layer 3 modification, UE has to reregister before resuming its communications. Updating the route with SIP proactively has a good impact on handover delay and packet loss, nevertheless, the long time taken by SIP to re-register and update the session is not always easy to predict. Actually, handover predication mechanisms, especially layer 2 triggers such as link going down and link down are the key elements for a successful proactive handover. On the one hand the whole handover procedure is triggered by a warning event (i.e link going down) based on signal strength or QoS degradation. On the other hand, the time between this first warning and the instant of the actual disconnection or QoS degradation notified by link down event is beyond user control. The remaining connection time should be at least equal to all time needed by the mobile to perform successful proactive update. This time is remarkably high in the case of SIP, given the multitude of network elements intervening in re-registration procedure. The handover preparation may go in vain because of unpredicted disconnection; hence the mobile has to update its session reactively once connected to the new network.

Hybrid Mechanism

In this section we will present our solution for IMS mobility using enhanced FMIPv6 and SIP.

MIH Integration to IMS Framework

Media independent handover aims to provide MMPs with intelligence in executing both vertical and horizontal handover. MIH as introduced in chapter 5 is independent of the interface technology. Integrating MIH to IMS is done at both access network and core network. In the access network, MIH is implemented in UE, PoA and AR (or GGSN); whereas the information server (IS) is placed in the core network.

As far as media independent information service (MIIS) is concerned, the communication between IS and the remote MIHF is organized following a request response paradigm. In [START_REF] Dutta | An Experimental Study of Location Assisted Proactive Handover[END_REF], HTTP is used to retrieve the needed information from the IS. The authors of [START_REF] Silvana | SIP and 802.21 for Service Mobility and Proactive Authentication[END_REF] propose SIP to transport MIIS messages, but they don't specify how this information is transported neither the adequate SIP messages to carry them.

Actually, SIP seems to be a good solution for transporting MIIS messages and will facilitate the integration of IS into IMS architecture. We propose to deploy IS as an application server (AS) placed in the core network in order to be accessed from all access networks by authenticated and authorized users. IS has a database of information about access networks. Examples of such information are: geographical location, operator name, PoA MAC address, IP address prefix of its AR, operational channel…etc.

Surrounding networks of a given UE can be determined using its IP address or its GPS coordinates if available. Access to this information is conditioned by the authorization of the HSS which allows only users who are already subscribed to this service to reach the needed information. Moreover, the need for neighboring access network knowledge is done at least once after being connected to the network. Updates of the list of neighboring networks can be done in a regular basis depending on UE mobility behavior. After address configuration and re-registration if necessary, UE should learn about the available wireless networks in its area in order to have a list of candidate networks to handover to in case the signal of the current connection goes down. This anticipation will be very benefic for UE when it needs to reverse resolve the IP address of the AR behind the discovered PoA. Indeed this resolution will be done locally when the handover is imminent, thus reducing the handover preparation delay. In the context of IMS, the list of the neighboring networks will be provided using SUBSCRIBE and NOTIFY messages. It should be noted here that MIH standard does not specify any transport mechanism for information service messages. We propose to carry the info request message on SDP payload of Subscribe and the info response message on notify SDP payload as illustrated in Figure 41.

Hybrid Scheme for IMS Mobility

The goal of any handover scheme is to ensure service continuity with an acceptable perceived quality of experience for the user during the transition. In chapter 4, mobility operations are classified into four main steps: movement detection and address allocation, global location tracking, traffic redirection and handover smoothing. SIP can perform the three first operations by nature. The missing part towards seamless service continuity is the handover smoothing. The idea behind our proposition is to propose a solution based on MIH intelligence to make an appropriate anticipation operation depending on low layers events. Our solution does not imply a big change to the existing network and avoids redundancy among the intervening entities. We will use an enhanced version of FMIPv6 combined with SIP as mobility management protocols.

We consider intra domain inter technology and intra domain intra technology handovers. This means that the whole network including all access networks are controlled by the same administrative authority and the mobile can travel among access networks within the same or different technologies (e.g. WIMAX to WIMAX or WIMAX to UMTS). Access networks are connected to IMS core network either loosely or tightly. The advantage of using FMIPv6 is that there is no need for home agent since the only mission of FMIPv6 is to preserve the current session by forwarding and buffering packets from the old AR to the new AR respectively. In other words, FMIPv6 will take in charge the handover smoothing operation, whereas global location tracking and traffic redirection will be performed by SIP.

Selected Handover

In selected handover, there is no time constraint on handover achievement since the UE continues in receiving the traffic from the current interface and prepares at the same time all needed updates using the new interface. Special care should be taken in the triggering mechanism of such handover. It is even the major criterion that decides on what type of handover has to be carried out. Therefore, basing on the MIH framework, the adequate triggers that should lead to selected handover are of two types: link up and link detected. After notification of the MIHF, decision algorithm is executed and decides whether the new network is better or not. Obviously, UE would prefer to be always best connected, therefore when a better network is detected by any other interface, decision engine compares the offered quality of the new network with the quality of the current network. By the term "quality" we refer to a group of criterions that have been configured in the decision engine and should be taken into account when deciding which network is better. Those criterions can include bandwidth, cost, user preferences… etc. UE performs SIP related updates before switching to the new network. It should be noted that always the first operation is IP address acquisition. This operation can be performed by means of different methods: stateful method (e.g DHCP, PDP) or a stateless method (e.g autoconfiguration). IP address acquisition is done normally like if the UE intends to connect to the network using this interface for the first time without taking into account the ongoing handover. After that, UE starts updating the session. First of all, it should discover the new P-CSCF as it could differ from the old one. An additional optimization in the handover that can be performed using MIH framework is that the information about the new P-CSCF can be provided in the info response that was acquired earlier. Afterwards UE negotiates a security association with the P-CSCF in order to construct an IPsec tunnel to secure communications between UE and P-CSCF. Subsequently, UE starts updating the session by re-registering to the S-CSCF which needs first to re-authenticate UE since it is using a different IP address now. Dual use of IP address and being registered to IMS domain with both of them an allowed operation which is known as multiple registrations. Until now traffic is following the old route towards the old IP address since the interface is still connected.

Eventually, UE sends re-invite to all its corresponding UEs in order to update the destination address of their streams towards the mobile UE. Finally this latter UE can deregister the previous IP address by sending de-register message from the old interface. Message flow corresponding to selected handover scenario is shown in Figure

Forced Handover

Forced handover flow chart is shown in Figure 43. In this scenario UE is constrained to change its connection to a new network using the current interface or a second one which is not already connected. The mechanism is carried out in two phases: fast phase and slow phase.

Fast Phase

Our first priority is to preserve packets of the ongoing session before any other procedure. The first operation is the reverse resolution of the new PoA mac address to acquire the new access router (NAR) prefix. UE uses IS to know about the neighboring networks and their AR prefixes before the handover trigger. After a link going down trigger, UE scans the channels of its interfaces and resolves the NAR address locally using the information provided in the info response of the IS and then constructs a Prospective CoA. After that, FMIPv6 operation is carried out to protect packets from loss. Nevertheless, sending a fast binding update (FBU) message will prevent UE from receiving any packet because they are encapsulated to the NAR. So we need to trigger the tunnel creation by another mechanism which is separated from FBU transmission.

The proposed collaborative scheme in chapter 5 is used here to perform this task.

Therefore, the terminal can continue its communication in the previous network even after link going down notification. The tunnel between the two ARs allows preservation of data packets during layer 2 handover and continuity of the service while performing SIP updates.

Slow Phase

As soon as UE connects to the new access network, it starts updating its SIP session while receiving data packets through the tunnel. It should be noted here that SIP related messages are sent with the new IP address, whereas data packets are encapsulated using the old IP address and sent through the tunnel. The reason behind this distinction is that the corresponding UE may drop data packets if they are sent with a source address witch is different from the one that the session was established with in the first place. Only after receiving re-invite message, correspondent UE takes into account the new destination address. On the contrary, SIP messages should be sent directly without encapsulation because this address will be used in security association establishment between UE and the new P-CSCF. UE starts by discovering its new P-CSCF. This information can also be provided by the IS in the previous information response. Afterwards, UE is re-authenticated, reregistered and finally re-invites the corresponding UE.

Note that this scenario is based on the assumption that FMIPv6 predictive mode is successful. Indeed, FMIPv6 Predictive mode has more chance to succeed than SIP update anticipation, because it only needs to send FBU message. Whereas, the success of SIP session update requires success of several operations. In the case where FBU is not received in the old link, the reactive mode is activated and FBU is sent from the new network.

TCP and UDP Traffic Support

For this hybrid scheme to work well, long sessions like voice calls and multimedia streaming should be transported over a connectionless channel like UDP. For text based web access, traffic model [START_REF] Choi | A behavioral model of Web traffic[END_REF] does not require service continuity since it is an on/off behavior (download and read). But for long TCP connections as in the case of downloading big files using FTP, FMIPv6 tunnel should be kept up until the end of the download. Although FTP sessions inflict a long tunnel establishment time, this scheme is better than MIP where the tunnel is permanent regardless the application currently in use. In FMIPv6, The information about the tunnel establishment time is inserted by the UE in FBU message and transmitted to the NAR by the HI message. The difficulty of this solution resides in the estimation of the remaining TCP connection time and the mechanism to maintain the tunnel established along this period. Actually we need to modify FMIPv6 protocol to add a new mechanism for maintaining and terminating the tunnel between PAR and NAR.

In case of selected handover, the solution is simpler since it suffices that the decision engine postpones the handover execution until all TCP connections are closed.

In such cross layer design, the decision engine is in the center of information flows coming from lower layers (i.e. link events) and upper layer (i.e. TCP/UDP session)

Performance Evaluation

In this section performance of our mobility management scheme is analyzed and compared with SIP and MIP-SIP solutions. The studied performance parameters are handover delay and packet loss.

Handover Latency

In a multimedia entertainment, the handover delay should be reduced to its minimum so that users do not feel any interruption in the session during the handover.

The majority of the media are transported via RTP/UDP where no retransmission is available. Therefore, any lost packet will penalize users' quality of experience.

Handover delay or latency is defined as the time separating the reception of the last packet in the old network and the reception of the first packet in the new network.

The total handover delay D H is the addition of 3 components:

D H = D H2 + D L3 + D MMP
Where D H2 is layer 2 handover delay. We assume equal values of D H2 for both vertical and horizontal handovers since in this scenario the new interface is not up at the time of handover decision.

D L3 is the delay of layer 3 operations; it concerns mainly IP address acquisition D MMP is the delay inflicted by the MMP to update the related entities following the used MMP.

The rest of the notations are reported in Table14 UE acquires the IP address using neighbor discovery protocol, which consists of sending a solicitation to the AR and receiving an advertisement. Then it discovers the new P-CSCF, registers with the S-CSCF and re-invites the corresponding UE which corresponds to the delays D disc , D regis D inv respectively. In case of using SIP as MMP we have:

D L3 = D sol + D adv = 2D UE-AR
We can write D SIP as: We suppose that all paths are symmetric and have the same transmission delay in both directions.

D SIP = D disc + D regis + D inv

MIP-SIP

In MIPv6 the CoA is first acquired from the AR and then binding update is performed within HA. Subsequently packets are forwarded by HA to UE. In MIP-SIP scheme we have:

D L3 = D sol + D adv D MIP = D BU + D ack = 2D UE-AR + 2D UE-HA

E-FMIP-SIP

The advantage of using FMIPv6 is that the IP address acquisition is done proactively. So, D L3 is null in this case.

Upon detecting a link down in the PoA packets are forwarded through a tunnel between PAR and NAR, and buffered at NAR simultaneously with layer 2 handoff.

Once NAR is notified of a link up, packets are delivered. Thus in predictive mode with MIH enhancement (E-FMIP) we have:

D E-FMIP = D LUnot +D AR-UE = D PoA-AR +D AR-UE
as for reactive mode

D FMIPrea = D UNA + D FBU + D HI + D Hack + D FBack = 3D UE-AR + 4D AR

Packet Loss

During the handover some packets may be lost if they are not buffered as in FMIPv6. The amount of lost data is expressed as follows:

PL = dt t T R H D ) ( 0 0 + ∫ Where R(t)
is the application bit rate and T 0 is the instant of the last received packet on the old link. Figure 46 shows that packet loss in our solution is nearly null. More concretely, in a video streaming application that has a bit rate of 1024 kbit/s there are only one or two packets which are lost during the handover. Such a weak number of lost packets does not have a big impact on the perceived quality. On the contrary, the user will miss a long video sequence during the handover when the other MMPs are used.

Conclusion

Interworking between different access networks is an important step towards networks convergence. But IMS mobility over heterogeneous access networks is still an open issue. In order to offer ubiquitous service to 4G customers, telecom operators should resolve vertical handover issue. In this chapter we proposed a hybrid scheme using enhanced FMIPv6 and SIP. This scheme does not impose any new entities on the network as MIPv6 does. A performance evaluation of the proposed solution was carried out and compared to the other schemes. The results show that our hybrid scheme reduces the handover delay and packet loss. However, these results are tightly dependant on the success of the predictive mode of FMIPv6.

PERFORMANCE ANALYSIS OF MOBILE IP VARIANTS IN VERTICAL HANDOVER

Introduction

Mobile IP and its variants present a good solution for mobility in All IP networks.

Choosing one variant or the other depends on many parameters and leads to different results in terms of handover performance. Such decision is crucial when it comes to real time applications such as Voice over IP and video streaming. To maintain service continuity when moving, the mobile should perform horizontal handover when the adjacent network is of the same technology or vertical handover when the new network is different from the previous one. FMIPv6 is desirable for homogeneous networks where the MN has to perform a hard handover. In this case, FMIPv6 prevents the ongoing communications from packet loss and reduces the layer 3 handover by preparing the IP address before the layer 2 handover. Nevertheless, in heterogeneous networks where using two or more interfaces, a classical MIPv6 has also the possibility to acquire a new IP address on the new interface using the conventional neighbor discovery protocol [START_REF] Nordmark | Neighbor Discovery for IP version 6 (IPv6)[END_REF] or any other mechanism. The heterogeneity of networks gives the mobile an important potential of performing seamless handover since we have at our disposal two wireless interfaces which have the possibility to work simultaneously and independently. In fact, the connection can be established in the new link before disassociating from the current point of attachment. This kind of handover is known as make-before-break handover. Nevertheless, make-before-break handovers are not systematic, too late handover triggering can lead to a disrupting transition.

Consequently, the choice of the layer 3 mobility protocol has a direct impact on the performance of the resulting handover. Although the two networks are geographically near from each other, they could be topologically far away from each other. An example of this is the case of two adjacent wireless networks that belongs to different operators.

Packets routed between the two networks should follow the route established by the autonomous system according to a particular policy. In this chapter, we focus our interest on the use of MIPv6, HMIPv6, and FMIPv6 in heterogeneous environment. We show that mobility protocol performance depends essentially on: 1) available time before the link with old network is broken, 2) the delay between visited network and home network or the delay between the visited network and the CN in case of route optimization and finally 3) the delay between previous access network and new access network. When the MN has the possibility to perform a make-before-break handover, MIPv6 and HMIPv6 seem to be the best layer 3 mobility protocols to use. However, when the handover is triggered by a serious fading in the received signal, then the choice will depend on the protocol operation delay before the link is down. Performance evaluation takes into account handover latency, disruption time and packet loss. Finally we give the guidelines for choosing the high-performance protocol according to the numerical results.

Related Work

It could appear obvious that FMIPv6 by principle performs faster handovers than any other IP based mobility protocol. This is true in horizontal handover but not necessarily true in vertical handover as we will demonstrate. Although many works treats the problem of vertical handover but the majority propose new scheme to perform seamless handover and few of them make comparative study between them as we are suggesting. The authors of [START_REF] Haseeb | Handoff latency analysis of mobile IPv6 protocol variations[END_REF] conducted a study based on simulations to compare different variations of mobile IP but it concerns only the case of horizontal handover. In [START_REF] Polidoro | Performance Evaluation of vertical handover mechanisms in IP networks[END_REF] the authors define a classification of vertical handovers and makes performance evaluation of SIP and MIP.

Vertical Handover Process

Vertical Versus Horizontal Handover

Handover or handoff event is the transition from one point of attachment to another. We talk about horizontal handover when both PoAs belong to the same technology (e.g. WIFI to WIFI). Horizontal handover can be initiated by the mobile or the network as it is the case in 3G and WIMAX networks. Vertical handover takes place when the mobile has more than one interface each one belongs to a particular technology. The ability of roaming between the different networks while continuing the ongoing session is called vertical handover.

Triggering Mechanism

Vertical handover is only possible if the MN is equipped with two or more wireless cards of different technologies (i.e. WIFI, WIMAX, UMTS…etc), when the current network is not providing the required QoS any more or the signal strength is becoming weak, the MN can proceed to a vertical handover.

The vertical handover can be triggered by one of the following events: link_parameters_report, link_going_down (LGD), link_detected and link_up, considering the use of MIH event service. The considered triggers take into account the seamless behavior of the handover. When the mobile experiences difficulties in maintaining an acceptable level of QoS for its ongoing applications, MIH user will be notified of a link going down event or link_parametrs_report event to perform a scan for next network to handover to. Two scenarios are possible: i) the new interface is already up and likely has already acquired its IP address, or ii) the interface is down and the MIH function turns it on by means of link_action command (see chapter 5) with certain execution delay. Handover is performed seamlessly only if the remaining connection time is long enough for handover preparation whatever the used mobility protocol is.

There are many estimation algorithms [START_REF] Yang | Definitive Link Layer Triggers for Predictive Handover Optimization[END_REF] that can predict the link down (LD) event within certain period of time, but the connection can be broken after a severe fading in the signal.

Link detected or link up events could happen at any time in any interface other than the one currently in use. If the new detected network presents a better opportunity for the user in terms of QoS or cost for example, the decision engine may choose to switch to this network.

Address Acquisition

MN starts resolving the new network prefix using the discovered Access Point identifier. When an information server is available there is no need for sending a solicitation message because the resolution is done locally for all mobility protocols.

This step is done in FMIPv6 by sending a PrRtSol to the AR to acquire the prefix address of the AR behind the candidate AP. This operation is known as reverse address resolution. We should note here that this operation is successful only if the PAR has already the correspondent layer 3 information of the candidate AP. Otherwise Candidate Access Router Discovery (CARD) [START_REF] Liebsch | Candidate Access Router Discovery (CARD)[END_REF] should be implemented between ARs to exchange and update access router information. Moreover, when an entry is expired or a MN wants to handover to a new network for the first time, PAR needs to request a CARD server to resolve AR's info for the unknown PoA. Thus, a proxy router solicitation will take an important delay to perform the reverse address resolution. At the opposite, MIPv6/HMIPv6 always requests AR info directly from the NAR without any proxiying process, and just by using the conventional neighbor discovery protocol.

Thus, the resolution operation takes only one RTT.

Performance Evaluation

In this section, we will focus on the following performance parameters: protocol operation delay, handover delay, disruption delay, and packet loss. We consider the mobility scenario in Figure 47.

Protocol Operation Delay

Flow charts of the considered mobility protocols are sketched below. We distinguish between bidirectional tunneling operation of MIPv6 (Figure 48) and route optimization with return routability procedure (Figure 49). We also consider the case of interdomain mobility in HMIPv6 (Figure 50) and predictive mode/reactive mode of FMIPv6 (Figure 51). Protocol operation delay T is the necessary time for the MN to exchange all messages relevant to the mobility protocol before the data flows switch to the new interface. Measuring this delay is important because it should be less than LD estimation time to have a seamless handover. We consider that there is no information server in the network, so that MN should solicit the AR to obtain new network prefix. Where:

t wx is the delay between MN and its AR, it includes wireless link delay and wired link delay between the point of attachment and AR . x=1,2 for the old network and new network respectively.

t n-h is the delay between NAR and HA.

t h-c is the delay between HA and CN.

t n-map is the delay between NAR and MAP (HMIPv6).

t par-nar is the delay between PAR and NAR.

t n-c is the delay between NAR and CN.

HMIPv6 intra domain mobility has the same behavior as MIPv6 with reverse tunneling, because the only operation that the MN should perform is MAP update. This latter plays the role of the HA in the MAP domain.

Handover Delay

Handover delay T' is the delay between the last data packet received on the previous interface and the first data packet received on the new interface.

Handover delay for FMIPv6 will depend on the mode in which this protocol is operating.

T' FMIPpre = t par-nar +t w2 which correspond to forwarding delay of received packets T' FMIPrea =2t w2 +3t par-nar + t par-nar +t w2 =3t w2 +4t par-nar

Handover delay of MIPv6 and HMIPv6 will depend on t Lgd-Ld which is the period between LGD trigger and LD. If this period is sufficient for the mobile to perform the necessary binding update then the handover delay will be null. Otherwise, there will be a disconnection period until the protocol operation achievement.

T' MIP = T MIP -t Lgd-Ld

T' MIPro = T MIPro -t Lgd-Ld if T > t Lgd-Ld T' HMIPro = T HMIPro -t Lgd-Ld

T'= 0 otherwise

Here we neglect the end to end delay difference between old and new route.

Disruption Delay

Handover disruption delay T'' is the delay between the last data packet received by the old interface and the first data packet received by the new interface directly from the CN either by means of tunneling via the HA or directly from the CN when the route optimization is used. We call it disruption delay because during this period, the perceived quality is disrupted because of: 1) layer 2 transition, during which the terminal is not able to receive or transmit any packet, 2) forwarding buffered packets from the old link to the new link is not always done at the same rate as the original flow, moreover, additional end to end delay is added to the delivered packets.

For FMIPv6 handovers, the disruption delay will concern both the current FMIPv6 operation and the following MIPv6 or HMIPv6 updates.

T'' FMIPpre = T' FMIPpre + T MIP (or T HMIP ) T'' FMIPrea = T' FMIPrea + T MIP (or T HMIP )

Disruption time of MIPv6 and HMIPv6 is equal to handover delay T'= T''. A forwarding scheme could be used in the case of HMIPv6 to forward packets from old MAP to the new MAP during the binding update of the different entities. In this case, handover delay and packet loss will be reduced but the disruption time remains unchanged.

Packet Loss

In the downlink, packets sent from HA or CN continue in taking the old route until the HA or CN sends an acknowledgement of the binding update. The following packets are sent to the new location immediately. Data packets are lost during the handover due to two reasons: loss of the connection on the previous interface before accomplishing the updates with HA/CN for MIPv6/HMIPv6, or before receiving FBack message in FMIPv6 (i.e. reactive mode). In FMIPv6 predictive mode there is no packet loss because of packet buffering in the NAR. For the other mobility protocols the number of lost packets is equal to:

dt t R L T ) ( ' 0 ∫ =
where R(t) is the instantaneous bit rate of the active flow. This value is proportional to the handover delay T' and bit rate of applications currently in communication.

The moment from which the MN decides to switch data packets from the old to the new interface is decisive for uplink data packets. During the period when the MN is waiting for the binding acknowledgement in the new interface, packets are still sent using the old interface, therefore with the old address as source address. These packets could be dropped for security reasons at the CN since it was informed that the IP address of its correspondent has been changed, consequently any received data packet with the old address will be rejected. The number of dropped packets due to this inconsistency is proportional to the old route end to end delay. The optimal way to redirect flows with minimal dropped packets is that MN continues sending data using the old interface until the binding update message is sent to HA or CN (following the use of reverse tunnelling or route optimization), at this moment precisely and without waiting for the binding update acknowledgement, it puts all data relevant to the ongoing communications in the new interface. Nevertheless some packets could be lost due to difference in end to end delay between old and new route (i.e. old route end to end delay is bigger than the new route end to end delay). Moreover, reliability of the mobility protocol is affected since MN decides to switch data packets on the new link without having the "evidence" of binding update accomplishment.

Numerical Results And Discussion

Numerical Results

We consider the following values: In order to compare the performance of the different MIP variants in vertical handover, we calculate the protocol operation delay using increasing values of t n-h and fixed value of t par-nar . In a second time, we fixe t n-h and vary t par-nar .

In Figure 52, lower values of t n-h correspond also to HMIPv6 intra mobility domain, and t par-nar is fixed to its average. It is clear that FMIPv6 is not affected by the distance from the home network since it involves only the ARs. We observe that when the MN is not very far from the home network MIPv6 performs shorter handovers than FMIPv6. This is due to the low number of exchanged messages in reverse tunneling mode of MIPv6. But when route optimization is used, protocol operation delay is considerably high in both MIPv6 and HMIPv6. Figure 53, t n-h is fixed to its average value. This figure shows that FMIPv6 is sensitive to the delay between new access network and old access network. Less than certain limit of t par-nar , FMIPv6 has shorter operation delay than MIPv6, but over this limit, especially when the home network is at the same distance from old and new access networks MIPv6 surpass FMIPv6. Moreover when PAR-NAR delay becomes extremely high route optimization use can be also envisaged. To explore the impact of connection remaining time before the old link is broken, we vary LGD-LD time and fix the other parameters and observe its impact on the handover delay. Since the make before break policy is adopted, MN starts establishing the new connection using the new link. Therefore, the handover delay will depend on how long this operation will take which was shown in previous graphs and how long the old link will last in order to allow this establishment simultaneously with data traffic on the old link. In Figure 54, FMIPv6 moves from reactive mode to predictive mode at t Lgd- Ld =235 ms which corresponds to predictive FMIPv6 average value. Surprisingly, we notice that MIPv6 and HMIPv6 even with route optimization have a chance to perform seamless handover with zero delay, thing that predictive FMIPv6 can not ensure whatever the remaining connection delay. This is due to the communication between the two interfaces and forwarding of data packets via access routers instead of direct switching in the case of the other protocols.

Discussion

The table below gives some guidelines that should help in choosing the mobility protocol to use according to the triggering event and the delay between entities intervening in layer 3 handover. Bien que la sécurité n'ait pas été abordée dans cette thèse, elle doit être prise en considération afin de sécuriser toutes les opérations de mobilité aussi bien pour mobilité de session que pour la mobilité des terminaux. En outre les mécanismes de sécurité doivent être conçues de telle manière ne pas compromettre les améliorations apportées aux protocoles de mobilité.

Figure 1 :

 1 Figure 1: Cellular IP operation .......................................................................................

Figure 2 :

 2 Figure 2: IDMP architecture ...........................................................................................

Figure 3 :

 3 Figure 3: Mobile IPv4.....................................................................................................

Figure 4 :

 4 Figure 4: MIPv6 route optimization with return routability ...........................................

Figure 5 :

 5 Figure 5: Hierarchical mobile IPv6 ................................................................................

Figure 6 :

 6 Figure 6: Proxy Mobile IPv6 architecture ......................................................................

Figure 7 :

 7 Figure 7: predictive mode (left) and reactive mode (right) ............................................

Figure 8 :

 8 Figure 8: push mode and pull mode in session mobility ................................................

Figure 9 :

 9 Figure 9: Session establishment and termination in RTSP.............................................

Figure 10 :

 10 Figure 10: SESSAMO client graphical interface............................................................

Figure 11 :

 11 Figure 11: testbed snapshot.............................................................................................

Figure 12 :

 12 Figure 12: SESSAMO running on Nokia 770 ................................................................

Figure 13 :

 13 Figure 13: SESSAMO timing .........................................................................................

Figure 14 :

 14 Figure 14: make before break scenario...........................................................................

Figure 15 :

 15 Figure 15: break before make scenario...........................................................................

Figure 16 :

 16 Figure 16: Concept of MPEG-21 DIA............................................................................

Figure 17 :

 17 Figure 17: Example of SDPng file [52] ..........................................................................

Figure 18 :

 18 Figure 18: Classical QoS negotiation procedure ............................................................

Figure 19 :

 19 Figure 19: Remote control QoS negotiation ...................................................................

Figure 20 :

 20 Figure 20: Session mobility with QoS renegotiation......................................................

Figure 21 :

 21 Figure 21: Message flow of renegotiation process .........................................................

Figure 22 :

 22 Figure 22: Mobility procedure........................................................................................

Figure 23 :

 23 Figure 23: MIH function.................................................................................................

Figure 24 :

 24 Figure 24: Mobility scenario...........................................................................................

Figure 25 :

 25 Figure 25: MIH-FMIPV6 message exchange.................................................................

Figure 26 :

 26 Figure 26: Remote MIH subscription and indication .....................................................

Figure 27 :Figure 28 : 75 Figure 29 : 76 Figure 30 : 78 Figure 31 : 79 Figure 32 : 79 Figure 33 : 80 Figure 34 : 85 Figure 35 : 86 Figure 36 : 88 Figure 37 : 89 Figure 38 : 90 Figure 39 : 93 Figure 40 :Figure 41 :Figure 42 :Figure 43 :Figure 44 :Figure 45 :Figure 49 :Figure 50 :Figure 51 :Figure 52 :Figure 53 :Figure 54 :

 27287529763078317932793380348535863688378938903993404142434445495051525354 Figure 27: Handover delay vs wireless link delay..........................................................

Chapter 2 :

 2 this chapter is devoted to the state of the art of both access network technologies and mobility mechanisms. It gives an overview of nowadays wireless access networks belonging to the different standard bodies. Afterwards, a number of mobility mechanisms and protocols are investigated. They are classified to layer 2 mechanisms, layer 3 mechanisms and upper layer mechanisms.

  Characteristics and requirement of 3G systems are specified in the ITU project called International Mobile Telephony 2000 (IMT-2000). The goal of IMT-2000 is to have one worldwide standard and a common frequency band with a maximum data rate of 2Mbps. Two standards answered the requirements of ITM-2000: UMTS and CDMA2000. Universal Mobile Telecommunications System (UMTS) is the evolution of GSM system managed by third Generation Partnership Project 3GPP. cdmaone evolution has led to CDMA2000 which is managed by the 3GPP2 standard body. Newer standards surpass the requirements of IMT-2000 and are referred to as 3.5G and 3.75G like High Speed Downlink Packet Access (HSDPA) and High Speed Uplink Packet Access (HSUPA) respectively. Long Term Evolution (LTE) and mobile WIMAX are considered as pre-4G technologies or 3.9G. In spite of the high service level provided by these technologies, they offer less than what is expected for 4G networks. 1.5.2.4. 4G ITU has defined in 2002 a new vision for future mobile system called IMTadvanced as requirements for the fourth generation. 4G aims to provide high quality multimedia applications to mobile and fixed terminals. The targeted data rates are 100Mbps in high mobility and 1Gbps for fixed access. ITU has received two proposals that are candidates for IMT-advanced [15]: 802.16m from IEEE and LTE-advanced from 3GPP. These standards are still in progress and should be finalized by 2012. 1.5.3. QoS Provisioning in Wireless Access Networks 1.5.3.1. IEEE 802.11e IEEE 802.11e [6] is an amendment to 802.11 standard introducing quality of service provisioning for different types of traffic in particular VoIP, video, best effort and background traffic. An enhancement is made to the basic Distributed Contention Function (DCF) by defining different behavior for backoff timer and transmission operation time in order to provide the needed resources for high priority traffic. Enhanced Distributed Channel Access (EDCA) defines four access categories (ACs) with different priorities depending on the application as listed in Table1. Table1: traffic classification in IEEE802.11e

  routing is replaced by Cellular IP routing with location management support. Mobile hosts attached to the access network use the IP address of the gateway as their care-of address. Figure1illustrates the path taken by packets addressed to the mobile node. All packets destined to the MN reach first the gateway from which they are routed through the base stations to their respective IP address.

Figure 1 :

 1 Figure 1: Cellular IP operation In Cellular IP, location management and handoff support are integrated with routing. To minimize control messaging, regular data packets transmitted by mobile

Figure 2 :

 2 Figure 2: IDMP architecture Intradomain mobility management protocol (IDMP) [23] is designed to work as a standalone solution. As illustrated in the Figure 2, IDMP architecture relies on two network entities: Mobility Agent (MA) and Subnet Agent (SA). MA is responsible for mobility management in the whole domain and SA is in charge of mobility management within the subnet.

Figure 3 :

 3 Figure 3: Mobile IPv4

Figure 4 :

 4 Figure 4: MIPv6 route optimization with return routability When route optimization is used (Figure 4), the MN should also update the CN after updating the HA. A security mechanism called return routability is introduced in the MIPv6 to secure the binding update with the CN. Home Test Init and Care-of Test messages are sent simultaneously via HA and directly to the CN respectively.

Figure 5 :

 5 Figure 5: Hierarchical mobile IPv6

Figure 7 :

 7 Figure 7: predictive mode (left) and reactive mode (right) FMIPv6 is operating in two modes (see Figure 7): predictive mode when FBack is received in the previous link and reactive mode when FBack fails to attain the MN because of an unexpected link down for example. PAR starts forwarding packets through the tunnel upon receiving an acknowledgement of HI from the NAR without having any indication of FBack reception by the MN. In the case where MN does not receive the FBack because of a link down, it falls into the reactive mode and resends another FBU on the new link.

  to transfer voice communications between the circuit switched domain and packet switched domain via the IP Multimedia Subsystem (IMS). VCC provides functions for voice call origination, termination and transfer between the CS domain and the IMS and vice versa. VCC application is implemented in the user's home network. Its role is to anchor Voice calls from and to a UE to provide voice continuity for the user during transition between the CS domain and the IMS. VCC is composed of a set of functions required for a UE to establish voice calls and control the switching between CS domain and IMS whilst maintaining the active session. The corner stone function in VCC is domain transfer function (DTF) which controls and executes the transfer. It should be noted that VCC does not specify any mechanism for handover in the radio interface but maintains only the continuity of the call between different domains (i.e. CS domain and PS domain).

  independent of data transport. Usually transport parameters (i.e. IP address and port number) are negotiated at the beginning of the session using SIP messages such as INVITE. Any change of those parameters during the session can be updated by sending a re-INVITE message containing the new transport parameters. Afterwards, the RTP packets are sent from the CN with the new destination address. In the context of SIP, this operation is known as mid-call mobility since the mobile move towards a new network during the session. The other type of mobility support is called pre-call mobility. It consists simply of updating the SIP registrar server with the new IP address so that future corresponding nodes can track the mobile node and establish a call with it.

Figure 8 :

 8 Figure 8: push mode and pull mode in session mobility

Figure 9 :

 9 Figure 9: Session establishment and termination in RTSP 1.11.3. Session Initiation Protocol: Refer method SIP supports many types of mobility such as terminal, session, personal and service mobility by exchanging a number of messages between the concerned entities.

Figure 10 :

 10 Figure 10: SESSAMO client graphical interfaceAs far as server program is concerned, it is a daemon running in the background which listens on a special port to the incoming requests from OD and treats them. When the TD receives a request message, it recovers the session description and launches the RTSP player under the following conditions: (1) the video session must be retaken from the point specified by the request message and (2) the video to be negotiated has to be compliant with the TD capabilities.

Figure 11 :

 11 Figure 11: testbed snapshot Table 5 summarizes the different elements of the testbed and their hardware capabilities.

Figure 12 :

 12 Figure 12: SESSAMO running on Nokia 770

Figure 13 :

 13 Figure 13: SESSAMO timing

t 2 :

 2 the time instant when TD starts the service negotiation with the video server.

t 3 :

 3 the time instant when RTP flow is received by TD.

t 4 :

 4 the time instant when SESSAMO response is sent to OD.

t 5 :

 5 the instant at which SESSAMO response is received by OD.

t 6 :

 6 the time instant when OD receives the last packet of audio/video.

Figure 16 :

 16 Figure 16: Concept of MPEG-21 DIA

Figure 17

 17 Figure 17 gives an example of MPEG21-DIA integration in the SDPng document with display and network constraints of the terminal. <constraints> <constraint name="session" xsi:type="sdpng-dia:mpeg21DIA-constraint"> <sdpng-dia:MPEG21-DIA xsi:type="m21-dia:TerminalsType"> <m21-dia:Terminal> <m21-dia:TerminalCapability xsi:type="m21-dia:DisplaysType"> <m21-dia:Display> <m21-dia:DisplayCapability xsi:type="m21-dia:DisplayCapabilityType" colorCapable="true" contrastRatio="700" refreshRate="30"> <m21-dia:Mode> <m21-dia:Resolution horizontal="176" vertical="144"/> </m21-dia:Mode> <m21-dia:ColorBitDepth blue="8" green="8" red="8"/> <m21-dia:CharacterSetCode> US-ASCII </m21-dia:CharacterSetCode> </m21-dia:DisplayCapability> </m21-dia:Display> </m21-dia:TerminalCapability> </m21-dia:Terminal> </sdpng-dia:MPEG21-DIA> </constraint> <constraint name="component" ref="videocomponent001" xsi:type="sdpng-dia:mpeg21DIA-constraint"> <sdpng-dia:MPEG21-DIA xsi:type="m21-dia:NetworksType"> <m21-dia:Network> <m21-dia:NetworkCharacteristic maxCapacity="384000" minGuaranteed="32000" xsi:type="m21-dia:NetworkCapabilityType"/> <m21-dia:NetworkCharacteristic xsi:type="m21-dia:NetworkConditionType"> <m21-dia:AvailableBandwidth average="80000" maximum="256000" minimum="330"/> <m21-dia:Delay delayVariation="66" packetTwoWay="330"/> <m21-dia:Error packetLossRate="0.05"/> </m21-dia:NetworkCharacteristic>

Figure 17 :

 17 Figure 17: Example of SDPng file [52]1.13.4. NegotiationNegotiation takes place at the beginning of the session. During this phase the client communicates with the server to exchange necessary information about the required service and its characteristics. This negotiation is supporter by the RTSP protocol, which actually conveys the SDPng information embedded inside the RTSP messages.

Figure 18 :

 18 Figure 18: Classical QoS negotiation procedure 1.13.4.2. Session Remote Control

Figure 19 :

 19 Figure 19: Remote control QoS negotiation

Figure 20 :

 20 Figure 20: Session mobility with QoS renegotiation

Figure 21 :

 21 Figure 21: Message flow of renegotiation process 1.13.6. Adaptation to Network Conditions The adaptation to network fluctuation does not need any renegotiation because the network is the cause of the problem not the terminal. As far as network communications are concerned, two approaches have been proposed to solve this problem. The first one proposes to enhance the network infrastructure by introducing resource reservation mechanisms. The second approach proposes to adapt the application to the available

N

  ew ro ut e G lo b a l L o c a ti o n u p d a te A d d re s s a c q u is it io n

Figure 22 :

 22 Figure 22: Mobility procedure

1. 21 . 1 . 3 .

 2113 Maintaining The Global Location TrackingHA is responsible for maintaining the global location tracking by making a mapping between the home address and the new acquired CoA. Each time the MN attaches to a new network it should register with the HA via the FA (or directly), in this special moment the HA maps the home address to the new CoA. Therefore, any third mobile willing to communicate with the MN can always use the original home address to reach it.1.21.1.4. Handover SmoothingWhen the MN is performing layer 2 handover and movement detection along with CoA acquisition and HA registration, MN disappears from the network because it is no longer in the home network nor the HA is aware of its movement. Hence, packets addressed to MN in this period will be lost which leads to noticeable degradation of the user's quality of experience. To overcome this discontinuity in the service, fast handover scheme was introduced by Low-Latency Handoffs in Mobile IPv4 and FMIPv6. The goal of this protocol is to prevent packet loss during the aforementioned steps where the MN is not reachable. Packets are tunnelled between old FA and new FA or between old access router and new access router in IPv4 and IPv6 respectively. As soon as the MN attaches to the new network, packets are forwarded right away to the MN. The tunnel is maintained long enough so that MN can achieve its updates with HA/CN.

  the MN reaches a new network and a new address has been acquired, the MN sends a re-INVITE request to the CN. This operation is accomplished without intervention of any intermediate SIP proxies. INVITE request contains an updated session description with new transport parameters including the new IP address. The CN starts sending data to the MN's new location as soon as it gets the re-INVITE message. Thus, SIP implements the end point based traffic redirection scheme. SIP users are identified by a unique URI. Each time the UA joins a new network it should update the SIP registrar by means of register message in order to bind the new acquired IP address with the URI. When future clients want to contact the mobile UA using its URI, they check first (directly or via a SIP proxy) SIP registrar to retrieve the current IP address mapped with URI and then initiates the communication with the mobile UA. 1.21.2.4. Handover Smoothing SIP standard does not specify any mechanism for the purpose of handover

Figure 23 :

 23 Figure 23: MIH function

Figure 24 :

 24 Figure 24: Mobility scenario

Figure 25 :

 25 Figure 25: MIH-FMIPV6 message exchange Decision algorithm is executed by decision engine which takes into account QoS constraints of the application and user preferences. The MIH user (FMIPv6 here) uses the result of this algorithm to send FBU message which contains the NCoA obtained by stateless address configuration using target network prefix. Upon receiving FBU message, PAR sends HI to NAR and MIH_event_subscribe to oPoA's MIHF to subscribe to Link_down_event of MN.

Figure 26 :

 26 Figure 26: Remote MIH subscription and indication

Figure 27 :

 27 Figure 27: Handover delay vs wireless link delay

Figure 28 :

 28 Figure 28: packet loss vs PAR-NAR distance for different buffer sizes

Figure 29 :

 29 Figure 29: Buffer size vs handover delay (D MN-AR =15ms)

  Figure 30 depicts the results of this simulation. Simulation is executed for different values of LGD coefficient with and without the proposed enhancement.

Figure 30 :

 30 Figure 30: Handover delay versus LGD coefficient

Figure 31 :

 31 Figure 31: Buffer size versus LGD coefficientPackets that are forwarded to the new location of MN should be buffered in the NAR since Layer 2 handover delay is too long. Buffer size dedicated to those packets depends on the aforementioned handover delay. This is approved by the pattern of the curves in Figure31that follow the same behavior as in handover delay. FMIPv6 needs an increasing buffer size when LGD coefficient increases since it covers more data packets. As for MIH-FMIPv6 buffer size is reduced and stays constant when LGD coefficient increases.1.31.3. Packet Loss

Figure 32 :

 32 Figure 32: Packet loss versus LGD coefficient Figure 32 shows packet loss during the handover for different values of LGD coefficient. In FMIPv6 packet loss is null because packets are forwarded through the

Figure 33 :

 33 Figure 33: Ping pong avoidance Algorithm

Figure 34 :

 34 Figure 34: FBack forwarding

Figure 35 :

 35 Figure 35: New MN state machine

Figure 36 :

 36 Figure 36: Transition state diagram of FMIPv6 retransmission Figure 36 represents the transition state diagram of retransmission operation in FMIPv6. The probability of successful FBU transmission after i retransmissions does not depend on the number of retransmissions done before the current transmission. This property is called memoryless property, hence

Figure 37 :Figure 38 :

 3738 Figure 37: Number of retransmissions versus estimated LGD-LD time

  another mobility management protocol (MMP) should take over the handover management completely or partially to reduce handover latency as well as the number of lost packets. Many mechanisms were proposed in the literature to provide an alternative to SIP or supporting it in achieving a seamless handover. Nevertheless, these mechanisms have themselves some limitations or inflict a big change to the network. In this chapter we propose a new hybrid scheme integrating two mobility solutions with minimum changes in the network. We consider two scenarios: the first one is called selected handover and the second one is called forced handover. Selected handover takes place when the mobile detects a new network using an interface other than the one currently receiving the stream. Although the mobile does not experience any noticeable degradation in the old network, a new interface gets connected to a network that presents better QoS parameters. Therefore, UE decides to switch the flow from the current interface to the new one. Whereas forced handover is performed where a multi interface UE is obliged to change its point of attachment because of signal fading or QoS degradation. Pre-established thresholds determine the minimal level of signal power required to maintain user experience undisrupted. Under these conditions, our purpose is to minimize handover latency and packet loss with minimal changes in the network. Forced handover consists of two phases; the first phase uses an enhanced FMIPv6 to preserve packets from loss during layer 2 handoff. A tunnel is created between the two access routers in order to forward data packets and buffer them in the new access router. As soon as the UE connects to the new access network, data packets are forwarded to UE on the new link. The second phase uses SIP to update the session and redirect packets to the new destination. We show in the analytical study that the handover performance is improved.

Figure 39 :

 39 Figure 39: IMS layers

Figure 40 :

 40 Figure 40: Interworking architecture in IMS

Figure 41 :

 41 Figure 41: IS integration into IMS

42 .

 42 Message exchange related to IP configuration, security association and I-CSCF/HSS are omitted.

Figure 42 :

 42 Figure 42: Selected handover message exchange

Figure 43 :

 43 Figure 43: The proposed hybrid handover mechanism

D

  P-I Delay between P-CSCF and I-CSCF D I-S Delay between I-CSCF and S-CSCF D S-H Delay between S-CSCF and HSS D P-S Delay between P-CSCF and S-CSCF D UE-HA Delay between UE and HA D PoA-AR Delay between PoA and AR 1.45.1.1. SIP

  with D disc = D UE-P + D P-UE = 2D UE-P and D regist = 4D UE-P + 4D P-I + 4D I-S + 2D I-H + 2D S-H and D inv = 4D UE-P + 4D P-S

Figure 44 :Figure 45 ,Figure 45 :

 444545 Figure 44: Handover delay vs UE-AR delay

Figure 46 :

 46 Figure 46: Packet loss vs application bit rate

Figure 47 :

 47 Figure 47: delays between different entities

Figure 48 :Figure 49 :

 4849 Figure 48: MIPv6 bidirectional tunneling

Figure 50 :Figure 51 :

 5051 Figure 50: HMIPv6 inter domain mobility and route optimization

Figure 52 :

 52 Figure 52: Protocol operation delay vs NAR-HA delay

Figure 53 :

 53 Figure 53: Protocol operation delay vs PAR-NAR delay

Figure 54 :

 54 Figure 54: Handover delay vs LGD-LD time

  l'information peut être fourni par un serveur DHCP dans la réponse à la requête de MN lors de sa première connexion au réseau. La fonction MIH commence avec l'opération d'initialisation par découvrir les entités du réseau qui fournissent des services MIH et leurs capacités, puis elle s'enregistre avec d'autres MIHF et souscrit à des événements localement ou à distance. MN demande au serveur d'informations des informations sur les réseaux voisins en envoyant la requete MIH_Get_Information (voir figure 25). La réponse contient des couples (AP-ID, AR-Info). Ainsi MN connaît ses réseaux voisins longtemps avant le handover, et non après le déclenchement, comme c'est le cas dans FMIPv6 classique. Une fois que le signal devient faible, la couche MIH est notifiée par l'événement Link_going_down, puis procède à l'exécution de l'algorithme de décision pour décider vers quel réseau il faut faire le handover, basée sur la réponse du serveur d'informations déjà disponibles.

Figure 26 explique

 26 Figure 26 explique les procédures de souscription et l'indication d'événements dans les deux entités locales et distantes. FMIPv6 doit inclure l'adresse MAC du MN dans le message MIH de souscription en utilisant l'adresse source du message FBU. Ainsi, MIHF au PoA peut filtrer l'événement Link down de ce MN spécifique. L'événement Link down peut être notifié par le PoA lorsque la connexion est perdue soit explicitement par la procédure de dissociation ou après l'expiration des

Figure 33 1. 59 .1. 61 .

 335961 Figure 33 présentes l'algorithme qui permet d'éviter les handover inutiles en raison de la faiblesse temporaire de l'intensité du signal. L'avantage d'utiliser les services MIH est le contrôle du protocole FMIPv6. Toute amélioration dans le niveau du signal après une indication LGD désactive l'ensemble du processus par l'annulation des inscriptions aux événements dans les deux PAR et NAR. Ce mécanisme d'annulation peut être mis en oeuvre au moyen de temporisateur, quand expiré, l'inscription à l'événement est supprimée.

Table 2

 2

			: traffic classification in WIMAX
	Class of service	description	Type of application
	Best	Effort	Basic service with no guaranty for	Web	browsing,
	(BE)		packet delivery	email,
	non	Real-	Terminals are polled before	File	download
	Time Polling	allocating bandwidth with no	(FTP)
	service		latency constraints
	(nRTPS)
	Real-Time	Terminals are polled before	Video	streaming
	Polling		allocating requested bandwidth and	(MPEG)
	Service		packets should leave the network
	(RTPS)		within certain latency
	extended	This method is in midway between	Voice over IP with
	Real-Time	UGS and RTPS that matches better	silence suppression
	Polling		requirements of VoIP with silence
	Service		suppression
	(eRTPS)
	Unsolicited	Bandwidth is granted without prior	Voice over IP,
	Grant Service	solicitation	video conferencing
	(UGS)
		1

.5.3.3. QoS in UMTS

Table 3 :

 3 traffic classification in UMTS

	Traffic class	Characteristics	Type of application
	Conversational	Preserve time relation between	Voice
	class	information entities of the stream
		with stringent and low delay

Table 4 :

 4 mapping of QoS classes

	Application type	UMTS	802.16	802.11e
	Voice	Conversational	UGS	AC_VO
		class
	Video	Streaming class	RTPS	AC_VI
	Web browsing, file	Interactive class	Best effort,	AC_BE
	download		nRTPS
	Background traffic Background class	Best effort	AC_BK

Table 5 :

 5 Characteristics of testbed elements

	Element	Function	Hardware description
	Nokia 770	Originating	252MHz OMAP, 64 Mo RAM, 802.11b/g
		device
	Laptop Dell Target Device	Dual core1,66GHz CPU, 2Go RAM, Fast
			Ethernet 100Mbps
	PC Dell	Video server	Dual core 3GHz CPU, 1.9Go RAM, Fast
			Ethernet
	LinkSys	Access Point	802.11b/g wireless interface, Fast Ethernet

Table 6

 6

	: make before break results
	Delay	value in ms
	Session handover delay	453
	Video session overlap	455
	VLC starting time	442

  In this context, we proposed a mechanism to negotiate and renegotiate QoS parameters of the session by using SDPng and MPEG-21. Here, SDPng and MPEG-21 are employed to specify the constraints of the client at different stages of the session's life. This description is integrated into the payload of specific RTSP messages following the required operation.

	ANALYSIS OF MOBILITY MANAGEMENT
	PROTOCOLS OVER IP
	1.16. Introduction

Many mobile devices are currently using IP based networks to access a big variety of applications including those needing insurance of holding the session when moving from one network to another. Mobility issue in IP networks comes from the fact that this protocol was not originally designed to handle mobility. Indeed, Internet protocols are not suitable for supporting mobile communications because of their principles of addressing and routing. Any host address must be derived from the network address where it is physically attached and no change in this address during the session is considered. Under such scheme, when a MN moves from its original network to a Foreign Network, it will experience at least the following problems: 1) when it reaches a new network, any communication becomes impossible. Given that its address is not valid in the foreign network, it can not be accepted neither by foreign nodes nor corresponding routers. Obtaining a new valid address from the foreign network is then necessary. 2) The ongoing communication associations are lost due to address inconsistency. 3) Mobile node disappears from the global network. Normally, hosts are found in the network by means of Location Directories (LD). It is a distributed database containing the host name and its corresponding IP address, an example of this database is the well known internet service DNS (Domain Name System). To keep in touch with the global net, MN must inform the LD each time it acquires a new IP address.

  without the existence of any server. After discovering the access router prefix by means of neighbour discovery protocol[START_REF] Nordmark | Neighbor Discovery for IP version 6 (IPv6)[END_REF], MN concatenates the prefix with its interface address which is driven from its MAC address. MN can have several addresses under different appellations depending on its function and the authority that allocated it. In Mobile IP for example, the address allocated in a foreign network is called Care of address where the original one is called home address. Movement detection and address allocation are put together in one operation because they are tightly related. In other words, movement detection can result from the allocation of a new IP address which belongs to a different network than the original one. Inversely,

The discovery of a new network can be achieved by means of layer 2 or layer 3 mechanisms. The accuracy and the speed of this discovery vary from one scheme to another. Layer 2 techniques are known to be more reactive than layer 3 ones, though they add more complexity to the MN's system. For example, mobility management protocol can use quality of the signal sensed on the wireless interface as an indication of leaving one network area and entering a new one. Therefore, MN can prepare the handover as soon as it receives the movement indication. At the opposite, layer 3 techniques rely on receiving special advertisement (e.g. FA and HA advertisements in MIP) or wait for the address configuration to realize that he network to which it was attached has been changed. Address allocation can take place in many ways. The most common method is dynamic host configuration protocol (DHCP), either in IPv4 or IPv6. This method necessitates the existence of a DHCP server which distributes and manages addresses. A stateless address configuration method consists of constructing the address discovering a new network by means of layer 2 mechanisms for example triggers the allocation of a new address.

1.21.2. Application Layer Perspective: SIP

	Handling mobility at network layer requires considerable changes in the MN
	kernel and it concerns all applications built on top of IP layer. Another approach
	consists of providing mobility support only for targeted applications like VoIP. SIP is

one of the famous signalling protocols used in internet that handles terminal mobility for SIP call sessions.

1.

21.2.1. Movement Detection and Address Allocation SIP

  does not provide any special movement detection technique, for this purpose mobile User Agent (UA) relies on the conventional DHCP procedure to acquire a new IP address. Although this TCP/IP-based protocol was not designed to operate in mobile contexts, it is widely employed to support address allocation in access networks. DHCP satisfies most of non real-time applications but it appears to be unsuitable when it deals with real-time ones. The main problem here is related to the number of packets and the long delay that DHCP takes for address allocation. This latter is mainly caused by the address conflict checking mechanism based on ICMP Echo request/reply, this operation is commonly known as duplicate address detection (DAD). A DHCP server sends out an ICMP Echo request to the address in question before responding to Discover message.

Table 8 :

 8 summarizing table

	Mobility	SIP	MIPv4	MIPv6	PMIPv6	TCP-	HIP
	protocol					migrate
	Layer	application Network	Network	network	transport transport
	Movement	DHCP ,	FA	Neighbor	Home network	DHCP	DHCP
	detection	PDP	advertisement	discovery,	prefix
	and		(FA-CoA) -	autoconfiguratio	allocation and
	Address		DHCP (co-	n, DHCPv6	auto-
	allocation		located CoA)		configuration or
					DHCP
	Traffic	Re-invite	Route	Route	Proxy binding	End to	HIP
	redirection	method	Optimization,	Optimization	update	end	update
			Reverse	with RR,
			tunneling	Reverse
				tunneling
	Handoff	Bicast	FMIPv4	FMIPv6	FMIPv6	-	-
	smoothing
	Global	SIP	Home agent	Home agent	Local mobility	-	Rendez
	tracking	registrar			anchor		vous
	agent						server

  or Media independent handover is a new standard that has been approved by IEEE in early 2009. It provides link-layer intelligence and other network information to upper layers in order to perform optimized handovers between heterogeneous networks. Network technologies covered by the standard are both IEEE and non IEEE networks like 3GPP networks. The purpose of this standard is to enhance the experience of mobile users by facilitating handovers between heterogeneous networks.

1.27.1. MIH Services

MIH function is the corner stone of the MIH framework. It is an intermediate logical entity between link layers and upper layers (see Figure

Table 9 :

 9 list of media independent link events

	Link event name	Link event type description
	Link_Detected	State change	Detection of a new access
			network
	Link_Up	State change	L2 connection is established and
			link is available for use.
	Link_Down	State change	L2 connection is broken and link
			is not available for use.
	Link_Going_Down	Predictive	Link conditions are degrading and
			connection loss is imminent
	Link_Parameters_Report	Link parameters Link parameter has crossed the
			pre-specified threshold
	Link_Handover_Imminent Link handover	L2 handover is imminent

Table 10 :

 10 list of media independent link commands

	Link command	Description
	Link_Capability_Discover Query and discover the supported events and
		commands on the link layer
	Link_Event_Subscribe	Subscribe to one or more events form a link
	Link_Event_Unsubscribe	Unsubscribe from a set of link layer events
	Link_Get_Parameters	Get parameters measured by active link such
		as SNR, BER, and RSSI
	Link_Configure_Threshold Configure threshold for link report event
	Link_Action	Request an action on a link layer connection
		(ex: connect, disconnect)

MIHF communicates with its peers for various purposes. MIHF in any network entity becomes a point of service (PoS) when it communicates with local MIHF. This communication may concern information related to different MIHF services (MIIS, MIES, or MICS). MIH messages are transported between remote entities by means of L2 or L3 mechanisms. Nevertheless, the standard does not specify any transport

  above algorithms can not be applied in case of heterogeneous networks since RSSI value follows different standards depending on outdoor or indoor networks.

	Moreover, other criterions might intervene in order to determine the best network to
	connect to, such as offered bandwidth, cost and user preferences. From a list of
	candidate networks, MN should select the best network suitable for the expected QoS
	and user preferences. Selection algorithm or decision algorithms use different
	techniques such as Multiple Attribute Decision Making (MADM) and fuzzy logic multi-
	criteria functions.

Table 11

 11

	: simulation parameters
	Parameter	value
	Mobile speed	3m/s
	application bit rate	49,6kbit/s

  We differentiate two variants of reactive mode: lossless reactive mode and lossy reactive mode. Lossless mode takes place where FBU delivery is successful and the tunnel is established between PAR and NAR by means of HI/HAck, but FBack is not delivered correctly to the MN, packets are not lost during L2 handover since they are forwarded and buffered in NAR until MN attaches to the new network as long as NAR buffer is not overloaded. Whereas in lossy reactive mode, the tunnel was not established between the two ARs because FBU is lost in the wireless link or one of HI/Hack messages is lost. If the FBack is not received before the timer goes off, MN should retransmit FBU and doubles the backoff timer. MN should keep doubling backoff time and retransmitting FBU until it reaches the maximum retransmission retries. If it is the case,

	1.36. Retransmission System
	FMIPv6 is a layer 3 protocol, which means that it has no transport protocol. All
	FMIPv6 messages are encapsulated over IP either in ICMPv6 message or using mobility
	headers. Therefore, there is no way for FMIPv6 to ascertain the correct delivery of a
	message since it does not use a reliable transport protocol like TCP. For this reason a
	backoff mechanism was defined to provide retransmission of lost messages. After
	sending FBU message for example, MN starts a backoff timer with a determined
	timeout.

MN should conclude that FMIPv6 is not supported by the NAR. Usually backoff time corresponds to the round trip delay between MN and NAR, if this delay is not known, a default value is used.

  Whenwaiting for FBack message, backoff timer will be doubled each time FBU is retransmitted. If the link goes down without receiving FBack in the old link, MN can not be sure of the delivery of FBU message after the last retransmission. In fact, MN can not know if the non reception of FBack is caused by the loss of this latter or because FBU was not received correctly by the PAR in the first place. Therefore MN persists in retransmitting FBU until FBack is received. In order not to repeat the exchange HI/Hack between the PAR and NAR since the tunnel was already established as FBU was correctly received by PAR, we propose to send FBack locally from the PAR without any new exchange with the NAR as long as the prospective CoA in the FBU message has not been changed. Thus, PAR will ignore the subsequent FBU sent by MN and resend the FBack again.After a L2 handoff without FBack reception in the old link, MN sends UNA message to NAR and waits for FBack to be forwarded from NAR. This waiting time gives the opportunity to FBack message to reach MN before it resends a new FBU from the new link. Whenever FBack is not received within backoff time, MN concludes that FBU was not successful and the tunnel was not established, consequently, it activates the reactive mode.

Table 12 :

 12 FMIPv6 messages size

MN can operate either in predictive mode or reactive mode, thus we have: 1 pre

Table 14 :

 14 Notation table

	D UE-AR	Delay between UE and AR
	D UE-P	Delay between UE and P-CSCF

Table 15 :

 15 Simulation values

	parameter	t w	Average t n-h	t h-c	Average t par-nar t n-c		t n-map
	Value(ms)	15	80	100	80	100	20

Table 16

 16 SIP and FMIPv6 combination does not only avoid redundancy in the network but improves the performance of the handover as well. Moreover, MIH enhancement can also be applied in the case of IM. This scheme does not impose any new entities on the network as MIPv6 does. Performance evaluation of the proposed solution was carried out and compared to the other schemes. The results show that our hybrid scheme reduces the handover delay and packet loss. However, these results are tightly dependant on the success of the predictive mode of FMIPv6. 'utilisateur ne sera pas affecté par un retard de transfert élevée dans le cas du téléchargement du fichier, car le résultat n'est pas perceptible jusqu'à la fin du téléchargement. Au contraire, tout retard excessif dans la réalisation de l'opération de mobilité aura un impact sur la qualité des applications sensibles aux délais telles que le streaming vidéo ou la voix sur IP. Bien que de nombreux travaux ont été menés dans le domaine de la mobilité, il reste toujours des problèmes qui ne sont pas complètement Par conséquent, la mobilité de session ajoute une contrainte temporelle à l'opération de transfert. Le délai du handover est la période de temps écoulé entre l'instant où l'utilisateur choisit de passer au nouveau dispositif en déclenchant le transfert (ex: appuie sur un bouton) et l'instant où le media commence à être joué dans le dispositif cible. En d'autres termes, le délai de transfert représente la réactivité du mécanisme de transfert. Dans le cas idéal il ne devrait y avoir aucun décalage de temps entre le moment où le média disparaît du premier dispositif et le moment où il apparaît à nouveau sur le dispositif cible. En pratique, le délai de transfert n'est pas nulle en raison du retard dans la transmission de paquets de signalisation et de paquets de données entre les entités concernées (i.e. serveur multimédia, le dispositif cible et originaire). Néanmoins, le retard de transfert devrait être réduit au minimum afin de ne pas perturber la qualité de l'expérience de l'utilisateur. En outre, la continuité de service ajoute une autre contrainte liée à la synchronisation des médias entre les deux appareils. Pour réaliser un transfert de session précis, il faut que le flux commence dans le dispositif cible à partir de l'instant où il a été laissé dans le premier dispositif. Ce problème est une conséquence directe du délai de transfert. Résoudre ce problème est important afin de préserver la cohérence du service.Cela signifie que nous devons nous assurer que l'utilisateur ne manque aucune séquence du média et en même temps minimiser les chevauchements cela veut dire ne pas jouer une séquence déjà affiché dans le dispositif d'origine).[START_REF] Crocker | Standard for the Format of ARPA Internet Text Messages[END_REF] tels que HTTP et RTSP. Deux principaux types de messages sont identifiés: les messages de requête et les messages de réponse. Le premier véhicule la commande, tandis que le second transporte le statut du résultat de l'opération. Le format général d'un message SESSAMO est le suivant: touche "transfert de session en cours" (voir figure10). Cette action permet au protocole SESSAMO d'envoyer un message de demande à DC. Ce message contient les informations nécessaires pour récupérer la session vidéo. Si la DC ne reçoit pas une réponse avant RTT seconde, il retransmet le même message; on répète l'opération si nécessaire mais pas plus de sept fois. Après sept tentatives, la communication avec le DC est considérée comme impossible. 'approche « make before break » comme illustré à la figure 14 consiste à établir la session sur le DC avant que l'accusé de réception est renvoyé au DO. Accusé de réception ici signifie que le trafic de données commence à arriver et la session a été transféré avec succès. L'avantage de ce mode est la garantie que le flux est réellement reçu par l'DO, si ce dernier ne peut pas établir la session avec le serveur vidéo, l'accusé de réception ne sera pas envoyé et la session continuera sur le DO. est le temps de silence qui se produit pendant l'opération de transfert, en particulier lorsque le délai transfert est élevé.

	: guidelines for mobility protocol choice
	Protocol variant	When to use?
	MIPv6	Link up or link detected events, short NAR-HA
		delay, medium tLgd-Ld
	MIPv6 with RO	Link up or link detected events, long tLgd-Ld
	HMIPv6 intra domain mobility Link up or link detected events, short NAR-MAP
		delay, medium tLgd-Ld
	HMIPv6 inter domain mobility Link up or link detected events, long tLgd-Ld
	FMIPv6	Link going down event, short NAR-PAR delay,
		short t Lgd-Ld
	1.53. Conclusion
	At the opposite of horizontal handover, where the use of FMIPv6 is preferable to
	other variants because of its proactivity in acquiring IP address and buffering
	mechanism that prevents packet loss during the link layer handover, vertical handover
	gives the other variants the opportunity to prepare network layer handover using the
	new interface before the old interface disconnection. We showed that handover
	performance depends on the delay between PAR and NAR and the delay between NAR
	and HA/MAP for FMIPv6 and MIPv6/HMIPv6 respectively. As far as handover
	disruption time is concerned, FMIPv6 has always longer period of disruption, because
	the mobile node should perform MIPv6 or HMIPv6 updates after FMIPv6 operation.
	Moreover, the remaining connection time after a link going down event is important in
	determining handover delay and the amount of packet loss. On the one hand, it
	determines whether FMIPv6 operates in predictive or reactive mode. On the other hand,
	the handover delay and packet loss of MIPv6/HMIPv6 are important when the

La Continuité de service est le défi le plus important que l'opérateur doit faire face afin d'offrir un service universel. Si l'hétérogénéité du réseau est bénéfique du point de vue utilisateur, cela complique davantage la tâche du fournisseur du service. D'une part, résoudre le problème de la continuité de service permettra aux opérateurs de diversifier leurs réseaux d'accès et de profiter de l'infrastructure à faible coût tout en conservant le même niveau de qualité de service. D'autre part, ils accordent plus de souplesse aux utilisateurs pour choisir leur réseau favori ou encore le transport de la session en cours à un autre terminal avec des capacités du matériel de meilleure qualité.

streaming vidéo le support de la continuité du service est obligatoire sinon le service s'arrête. La manière dont la mobilité est prise en charge est lié à l'application elle-même. LL'objectif de la mobilité de session est de donner aux utilisateurs la possibilité de passer d'un terminal à un autre au cours de la même session multimédia sans aucune interruption. Cette opération s'est révélée utile pour les utilisateurs qui sont en mobilité.

Un scénario typique de la mobilité de session est un utilisateur qui se sert de son assistant numérique personnel (PDA) pour regarder son jeu préféré quand il est dehors.

Le PDA est connecté à Internet via le réseau mobile terrestre public, qui fournit des services 3G. Une fois chez lui l'utilisateur souhaite profiter de son accès à large bande et son écran haut définition pour regarder le même programme sans l'initialisation ou l'interruption du service. Le transfert de la session peut être commandé par le dispositif à partir duquel la session est transférée, ce mode est appelé mode «poussé», ou par le dispositif vers lequel la session est transféré, ce mode est appelé mode « tiré »l.

La continuité de service signifie qu'il ne devrait y avoir aucune interruption lorsque le flux est transféré entre les deux appareils.

1.56.1. Adaptation du média

Un autre défi de la mobilité de session est l'adaptation des média étant transférés. Vu la variété des dispositifs et leurs capacités, il est obligatoire que les flux multimédia soient adaptés aux dispositifs auxquels ils sont destinés en termes de capacités et débit de connexion. Par exemple, le flux supporté par un écran haute définition ne convient pas à un appareil mobile sans aucune adaptation, sinon le système sera surchargé et la qualité sera médiocre. deux dispositifs dans une relation d'égal à égal. Cela signifie que les deux appareils implémentent les deux modules serveur et client. SESSAMO est basé sur l'échange de messages texte D'autre part, il y a un nombre réduit d'entêtes afin que la longueur totale du message n'excède pas le Maximum Transfer Unit (MTU). 1.56.3. Implémentation Nous utilisons la bibliothèque open source LIVE555 [45] sous linux pour le protocole RTSP et VLC [46] comme un lecteur vidéo sur les terminaux. LIVE555 est utilisé comme serveur vidéo et aussi inclus un module lors de la compilation de VLC pour le support client de RTSP. SESSAMO coordonne entre les deux entités participant à l'opération de mobilité SESSAMO: Le dispositif d'origine (DO) et le dispositif cible (DC). SESSAMO est un protocole d'égal à égal, pour cette raison un appareil qui prend en charge la mobilité session a deux types de programmes: un programme serveur qui écoute en permanence les demandes provenant d'autres terminaux, et un programme du meme endroit ou il a été dans l'ancien terminal. L'échange d'informations requis par le protocole est toujours commencé par DO. Cela se produit lorsque l'utilisateur appuie sur la Ltransfert, il est presque égal à scenario précédent puisque la principale cause de ce retard est temps de démarrage de VLC qui constitue plus de 97% du délai. L'inconvénient de ce scénario

Renégociation des paramètres de la qualité de service

  Le défi maintenant consiste à faire face à la variété de dispositifs mobiles. En effet, nous pouvons trouver dans le marché des dispositifs différents qui ont différentes caractéristiques en termes de taille d'écran, de puissance de calcul, de systèmes d'exploitation, d'interfaces réseau, de codecs pris en charge, de la durée de batterie ... La particularité de notre travail réside dans la manière ces tâches sont réalisées au moyen de SDPng/MPEG-21 et RTSP. En particulier, l'adaptation des paramètres de la qualité de service n'est pas fondée sur une approche classique sur lequel le serveur adapte le débit sans la participation du client. En effet, dans notre approche le client guide le serveur pour obtenir la qualité de service la plus approprié.Il convient de noter que l'adaptation aux conditions du réseau n'est pas l'objet de notre étude. Si la qualité de la vidéo se dégrade en raison de la congestion sur la route vers le terminal, d'autres techniques de bout en bout doivent intervenir pour adapter les médias. RTCP[START_REF] Schulzrinne | RTP: A Transport Protocol for Real-time Applications[END_REF] est l'une des solutions possibles pour contrôler le flux en utilisant les rapports périodiques. Ces rapports sont renvoyés au serveur pour avoir une idée sur bande passante disponible le long de la route au terminal.

etc Un serveur offrant un service donné doit être capable de satisfaire chaque terminal en fonction de ses propres capacités. Les protocoles de signalisation tels que SIP et RTSP transportent dans leur message charge les contraintes imposées par les clients et de leurs capacités et le serveur transcode ou re-quantifie le contenu convenablement. Il est évident que l'adaptation du média est nécessaire en cas de mobilité session.

Néanmoins, nous nous attaquons au problème de la gestion de la QoS dans la mobilité de session dans différentes phases. La première phase est la négociation qui a lieu au début de la session, la seconde est l'adaptation au cours de la session lorsque certains paramètres changent au sein du même terminal, comme le niveau de la batterie et la vitesse de connexion. La troisième phase est la renégociation lors du transfert de la session.

1.

57. Analyse des protocoles de mobilité sur IP Beaucoup

  d'appareils mobiles utilisent actuellement les réseaux IP pour accéder à une grande variété d'applications, y compris ceux qui ont besoin d'assurance de la tenue de la session lors du passage d'un réseau à l'autre. Le problème de la mobilité dans les réseaux IP vient du fait que ce protocole n'a pas été conçu pour gérer la mobilité. En effet, les protocoles Internet ne sont pas adaptés pour supporter les communications mobiles en raison de leurs principes d'adressage et de routage. Toute adresse de l'hôte doit être déduite de l'adresse réseau où il est physiquement attaché et aucun changement dans cette adresse au cours de la session n'est considéré. En vertu de ce régime, quand

	recense les protocoles de mobilité sur IP les plus connus et les classifie selon les étapes
	cité auparavant :
	Protocol de	SIP	MIPv4		MIPv6	PMIPv6	TCP-	HIP
	mobilité							migrate
	couche		applicatio	réseau		réseau	réseau	transpo	transpor
			n					rt	t
	Detection		DHCP ,	FA		Neighbor	Home network	DHCP	DHCP
	de		PDP	advertisemen	discovery,	prefix
	movement			t (FA-CoA) -	autoconfigurati	allocation and
	et			DHCP	(co-	on, DHCPv6	auto-
	allocation			located CoA)		configuration
	d'adresses					or DHCP
	Redirection	Re-invite	Route		Route	Proxy binding	End to	HIP
	du Traffic		method	Optimization,	Optimization	update	end	update
				Reverse		with RR,
				tunneling		Reverse
						tunneling
	Lissage du	Bicast	FMIPv4		FMIPv6	FMIPv6	-	-
	handover
	Agent	de	SIP	Home agent	Home agent	Local mobility	-	Rendez
	localization	registrar				anchor		vous
	global								server
		1
			Afin de faire face aux limitations de l'IP dans les communications mobiles, un
	certain nombre d'approches ont été proposées. Bien qu'elles abordent le problème sous
	des angles différents, ils sont d'accord sur la façon dont ils y font face. En effet, les
	principales approches reposent sur un certain nombre de procédures qui peuvent être
	classés en: détection de mouvement et l'allocation des adresses, redirection de trafic,
	mise à jour de la localisation globale et le lissage du handover. Le tableau suivant

un mobile se déplace de son réseau d'origine à un réseau étranger, il rencontra au moins les problèmes suivants: 1) quand il atteint un nouveau réseau, toute communication devient impossible. Étant donné que son adresse n'est pas valide dans le réseau étranger, il ne peut être acceptée ni par les noeuds étrangère ni routeurs correspondants. L'Obtention d'une nouvelle adresse valable dans le réseau étranger est alors nécessaire. 2) Les associations de la communication en cours sont perdus à cause de incohérence de l'adresse, 3) le noeud mobile disparaît du réseau global. Normalement, les hôtes se retrouvent dans le réseau au moyen d'un répertoire de localisation (RL). Il s'agit d'une base de données distribuée contenant le nom d'hôte et son adresse IP, un exemple de cette base de données est le fameux service DNS (Domain Name System). Pour rester en contact avec le réseau global, le mobile doit informer le RL chaque fois qu'il acquiert une nouvelle adresse IP.

.58. Mécanisme collaboratif de handover

  En outre, la taille du tampon nécessaire pour le tampon de paquets dans les routeurs d'accès lors de la remise est plus petite. Enfin, le mécanisme proposé évite des événements de ping-pong excessifs entre les réseaux sans fil. en une courte période de temps afin de ne pas perdre aucun message FMIPv6. En fait, le message de sollicitation est envoyé après le déclenchement du handover au niveau 2 ce qui entraine une période d'initiation plus longue. En outre, si la connexion est interrompue avant la réception du message FBack, tous les paquets seront perdus jusqu'à ce que la connexion au nouveau réseau soit établit et le tunnel entre NAR et PAR est crée. Le retard important qui prolonge la période d'interruption du service est comprise entre le moment ou MN reçoit FBack et le moment de la dissociation de l'ancien réseau, tous les paquets destinés à MN au cours de cette période sont transmises à NAR mise en mémoire, alors que MN peut encore recevoir ces paquets sur l'ancien lien. En fait FMIPv6 propose également d'entamer la mise en mémoire de paquets et de les transmettre en même temps lors de la réception du FBU avant même la création du tunnel. Cette solution est bonne pour s'assurer que tous les paquets adressés à MN pendant l'opération FMIPv6 seront reçus soit dans l'ancien ou le nouvel emplacement.

	ce délai en utilisant la couche de liaison des déclencheurs pour effectuer l'acquisition
	d'adresses avant de la couche 2 de transfert. En outre, FMIPv6 empêche la perte de
	paquets en créant un tunnel entre le routeur d'accès précédente (PAR) et le Nouveau
	routeur d'accès (NAR) pour transmettre les paquets jusqu'à ce que le noeud
	correspondant et l'agent d'accueil mise à jour le soin d'adresse (CoA). Toutefois,
	FMIPv6 montre certaines limites dans les terminaux en mouvement rapide. D'une part,
	le terminal n'a pas assez de temps pour échanger tous les messages de PAR dans la
	phase d'initiation. D'autre part, routeurs d'accès nécessite une taille de tampon pour
	amortir grands paquets envoyés à la MN entre le moment de la transmission FBack et le
	moment de l'avertissement UNA, respectivement par la RAP et NAR.
	Les réseaux de prochaine génération ont l'intention d'offrir des services
	omniprésents et ubiquitaires aux clients où qu'ils soient et quelle que soit l'application
	qu'ils utilisent. Pour atteindre cet objectif, la continuité de service sur des réseaux homogènes et hétérogènes doit être garantie. Grâce à l'IP mobile et ses variantes, la 1.58.1. Limitations de FMIPv6
	continuité du service dans les réseaux tout IP peut être assurée. MIPv6 a été conçu par L'avantage de FMIPv6 réside dans son mode d'opération prédictif. Toute
	l'IETF pour fournir des noeuds mobiles avec la possibilité de maintenir la défaillance dans l'exécution de ce mode conduit à un mode réactif qui ajoute plus de
	communication en cours lors de la modification du réseau d'accès et l'adresse IP de MN. retard au handover. Par conséquent, en cas de mobile en mouvement rapide, il est
	Bien que MIPv6 présente quelques améliorations par rapport à MIPv4, son retard de
	transfert à long rend impropre pour les applications temps réel. FMIPv6 tente de réduire

Dans ce travail nous utilisons les services MIH plus efficacement aux différentes étapes du FMIPv6, non seulement dans l'étape de découverte. En outre, en utilisant des indicateurs d'événement le mobile sera servi jusqu'à sa déconnexion physique, et dès qu'il se connecte au nouveau réseau, les paquets seront transmis par le nouveau routeur d'accès, sans attendre l'annonce de l'attachement FMIPv6. Par conséquent la taille mémoire dédié aux paquets dans le NAR est réduite. Un autre avantage de cette proposition est la résilience à l'effet ping-pong. En effet, le handover est initiée par le MN, mais finalisé par le réseau permettant l'annulation du handover s'il est déclenché par une "fausse alerte". Nous montrons à travers l'analyse d'analyse et de simulation, que notre régime réduit transfert retard ainsi que la perte de paquets dans les deux relèves prédictive et réactive. probable qu'il ne reste pas connecté au réseau précédent assez longtemps pour envoyer et recevoir tous les messages FMIPv6. Ainsi, le terminal devrait achever l'étape d'initiation En fait, cette solution peut être considérée comme une solution bicast abordées au chapitre 4, où le trafic est envoyé à la fois à l'ancienne et à la nouvelle adresses. Néanmoins, cette solution a au moins deux inconvénients: elle augmente l'overhead et a besoin d'un mécanisme dans le système d'exploitation du MN pour éviter la duplication de paquets au cas où elle a lieu.

1.

58.2. Media Independent Handover

  de recevoir des paquets. Par conséquent, nous avons besoin de déclencher la création de tunnel par un autre mécanisme qui est séparée de la transmission du FBU. Dans ce travail, nous proposons un mécanisme collaboratif qui implique à la fois le terminal et le réseau. Le routeur d'accès et le point d'attachement utilisent les services MIH pour donner au terminal la possibilité de poursuivre sa communication dans le réseau précédent, même après l'évènement LGD. L'événement link down est le seul événement qui doit déclencher la transmission de paquets via le tunnel. Un tel événement est également détectable au niveau du point d'attachement qui va informer le nouveau routeur d'accès pour commencer la transmission des paquets à travers le tunnel. Préserver les paquets de la session en cours est la première priorité que nous avons l'intention de réaliser, avant toute autre procédure. Nous considérons le scénario de la mobilité montré à la figure 24. MN est relié au réseau de service et connecté au serveur d'information. L'emplacement du serveur de

	IEEE 802.21 ou MIH (Media Independant Handover) est un nouveau standard qui
	a été approuvée par l'IEEE au début de 2009. Il fournit des renseignements sur la
	couche de liaison et d'autres informations réseau aux les couches supérieures afin
	d'effectuer des handovers optimisé entre les réseaux hétérogènes. Les technologies de
	réseaux couverts par MIH sont à la fois des technologies IEEE et non IEEE comme les
	réseaux 3GPP. Le but de cette norme est d'améliorer l'expérience des utilisateurs
	mobiles en facilitant le handover entre réseaux hétérogènes.
	1.58.3. Procedure du Handover Collaboratif
	FMIPv6 entend protéger les paquets de données contre la perte. Néanmoins,

l'envoi du message FBU après l'événement link going down empêche MN de recevoir les paquets de données, car ils sont encapsulés et envoyés vers NAR, même si MN est 151 encore capable

Acknowledgments

First of all I want to express my profound gratitude to my supervisor, Pr. Hossam

<constraint name="session" xsi:type="sdpng-dia:mpeg21DIA-constraint"> <sdpng-dia:MPEG21-DIA xsi:type="m21-dia:TerminalsType"> <m21-dia:Terminal> <m21-dia:TerminalCapability xsi:type="m21-dia:DisplaysType"> <m21-dia:Display> <m21-dia:DisplayCapability xsi:type="m21-dia:DisplayCapabilityType" colorCapable="true" contrastRatio="700" refreshRate="30"> <m21-dia:Mode> <m21-dia:Resolution horizontal="176" vertical="144"/> </m21-dia:Mode> <m21-dia:ColorBitDepth blue="8" green="8" red="8"/> <m21-dia:CharacterSetCode> US-ASCII </m21-dia:CharacterSetCode> </m21-dia:DisplayCapability> </m21-dia:Display> </m21-dia:TerminalCapability> </m21-dia:Terminal> </sdpng-dia:MPEG21-DIA> </constraint> <constraint name="component" ref="videocomponent001" xsi:type="sdpng-dia:mpeg21DIA-constraint"> <sdpng-dia:MPEG21-DIA xsi:type="m21-dia:NetworksType"> <m21-dia:Network> <m21-dia:NetworkCharacteristic maxCapacity="384000" minGuaranteed="32000" xsi:type="m21-dia:NetworkCapabilityType"/> <m21-dia:NetworkCharacteristic xsi:type="m21-dia:NetworkConditionType"> <m21-dia:AvailableBandwidth average="80000" maximum="256000" minimum="330"/> <m21-dia:Delay delayVariation="66" packetTwoWay="330"/> <m21-dia:Error packetLossRate="0.05"/> </m21-dia:NetworkCharacteristic>

CONCLUSIONS

In this thesis different aspects of service continuity have been investigated.

Session mobility is an important aspect of service continuity that gives the user more flexibility and liberty when dealing with multimedia services. To achieve this purpose in the context of video streaming, we proposed SESSAMO as a protocol for session transfer between terminals. The main characteristics of this new protocol are its lightweight and its peer to peer character which make it easy in deployment and use.

This protocol was validated by an implementation in commercial mobile device (i.e.

Nokia 770) and the results from the testbed are vey encouraging. Another issue of session mobility which is media renegotiation was also addressed. In order to adapt the media to the new terminal capacity, there should be a way to renegotiate the adequate media format accurately. As SDP is unable to achieve this task, we proposed to use SDPng along with MPEG21-DIA in order to describe terminal context. Different scenarios was defined when renegotiation is needed and special RTSP messages was specified to convey the description according to user situation.