Architectures pour la mobilité et la qualité de service dans les systèmes satellites DVB-S2/RCS

Architectures pour la mobilité et la qualité de service dans les systémes satellites DVB-S2/RCS

MIH : un standard pour faciliter l’échange d’informations entre les couches 

Le groupe de travail IEEE 802.21 [78] définit actuellement le standard MIH pour optimiser les mécanismes de mobilité en assistant les handover entre différentes technologies d’accès (IEEE 802.3, 802.11, 802.16, 3GPP, etcÖ) mais aussi à l’intérieur d’une m’me technologie d’accès. Pour ce faire, le standard permet d’utiliser des informations provenant aussi bien du terminal mobile que de l’infrastructure réseau et de les échanger via des interactions spécifiques entre les couches inférieures (Physique et Liaison) et les couches supérieures (Réseau, Transport et Application). Ces échanges d’informations se font à travers une entité appelée ´ fonction MIH ª (ou MIHF) qui interagit avec les couches inférieures au travers de points d’accès au service (SAPs, Service Access Points) spécifiques à chaque média et avec les couches supérieures au travers d’une interface unifiée, nommée MIH-SAP. Pour cela, trois différents services sont définis: • Le MIES (Media Independent Event Service) qui fournit des services aux couches supérieures en signalant les événements locaux (au sein du terminal) et distants (en provenance d’éléments du réseau). Ainsi les événements locaux se propagent depuis les couches inférieures vers la MIHF puis vers les couches supérieures d’un terminal tandis que les événements distants peuvent se propager depuis un élément du réseau vers la couche MIH ou une couche supérieure du terminal. Ces événements peuvent par exemple ‘tre du type : Link Up (lien connecté), Link Down (lien déconnecté), Link Handover Imminent (changement de lien imminent), etc. • Le MICS (Media Independent Command Service) dont les commandes peuvent ‘tre échangées de faÁon locale ou distante (terminal/réseau ou réseau/réseau entre l’ancien et le nouveau réseau au cours d’un handover par exemple) depuis les couches supérieures vers le MIHF puis vers les couches inférieures. Ce service utilise les informations fournies par le MIES pour exécuter des commandes telles que MIH Handover Initiate (terminal/réseau : initie les handovers et envoie une liste des réseaux et points d’accès suggérés) ou encore MIH Handover Prepare (réseau/réseau : la MIHF de l’ancien réseau prévient celle du nouveau de se préparer à une procédure de handover). • Le MIIS (Media Independent Information Service) qui fournit une architecture et des mécanismes permettant à la MIHF de collecter des informations sur les réseaux environnants. Ces informations peuvent concerner le type de réseau (GSM, 802.11e, etc.), le canal à utiliser, l’adresse MAC du point d’accès, le débit, la QoS ou encore la sécurité ainsi que d’autres informations concernant les services des couches supérieures. Ces informations sont disponibles aussi bien pour les couches supérieures que pour les couches inférieures. Les interactions locales entre ces différents services et la MIHF sont illustrées par la Figure 23.

 Le multi-homing et l’utilisation d’interfaces multiples : un pas vers la mobilité sans interruption 

Le multi-homing permet à un terminal d’établir une connexion avec plusieurs adresses au niveau de chaque extrémité (éventuellement répartie sur plusieurs interfaces). Initialement utilisé pour permettre l’équilibrage de charge ou encore la redondance, cette caractéristique peut s’avérer très utile dans le cadre de la mobilité. En effet, un utilisateur qui se déplace entre différentes technologies d’accès peut configurer sa nouvelle interface alors que l’ancienne est toujours active et permet encore de recevoir et de transmettre des données : c’est ce qu’on appelle le principe du ´ make before break ª. Cependant, ce principe est soumis à plusieurs conditions : • L’ancien et le nouveau réseau doivent avoir une zone de chevauchement commune. • Le passage par cette zone doit ‘tre suffisamment long pour permettre la configuration de la nouvelle interface et éventuellement la mise à jour de la localisation du terminal mobile. • Le déplacement entre deux réseaux ayant la m’me technologie d’accès ne peut ‘tre réalisé que si le terminal mobile possède deux interfaces de cette technologie d’accès. En considérant que ces conditions sont remplies ou que le changement de réseau implique deux technologies d’accès distinctes, le temps d’interruption peut donc ‘tre fortement réduit. Plusieurs études ont ainsi été menées pour analyser l’impact du multi-homing sur les solutions de mobilité. Au niveau de la couche réseau, [83] propose une extension à Mobile IPv6 en permettant à un MN qui se déplace vers un nouveau réseau, de continuer à communiquer à travers sa CoA1 (interface 1) tout en configurant une CoA2 sur son interface 2 et de mettre à jour son association avec son HA et son CN. Dès que cette association est faite, le CN et le HA voient cette nouvelle association comme si le MN avait changé d’adresse sur la m’me interface et les communications passent par la nouvelle interface. Dans ce cas là, les deux interfaces sont enregistrées auprès du m’me HA mais ne peuvent ‘tre utilisées simultanément. Pour permettre à un MN d’enregistrer plusieurs CoA simultanément, [84] a proposé l’utilisation d’un BID (Binding Identification number) associé à chaque nouvelle CoA. Une proposition a ensuite été faite pour adapter cette possibilité d’enregistrer plusieurs CoA à FMIPv6 [85]. Au niveau de la couche transport, on a déjà pu constater que les solutions utilisant SCTP se basent essentiellement sur ce concept de multi-homing. Enfin, au niveau application, plusieurs solutions ont été proposées en se basant essentiellement sur le nouvel en-t’te ´ JOIN ª défini dans [86] permettant, entre autres, d’ajouter un nouveau participant à une session multimédia (ou d’audioconférence). Ainsi, [87] décrit un mécanisme dans lequel un client SIP mobile, équipé de deux interfaces et se déplaÁant vers un nouveau réseau, envoie un message INVITE comprenant l’en-t’te JOIN à son ancien proxy qui va alors intercepter et dupliquer les messages audio (et video) de la session pour les envoyer vers les deux interfaces simultanément. Une fois, le changement de réseau accompli, le MN envoie un re-INVITE à son CN pour qu’il puisse communiquer directement. Ce mécanisme est assez proche de ceux définis par FMIPv6. Dans [88], le reINVITE est directement envoyé au CN avec l’en-t’te JOIN depuis la seconde interface. Le CN envoie alors un message BYE vers la première interface du MN et la communication reprend en utilisant la deuxième interface du MN. Dans tous les cas, ces solutions permettent de réduire considérablement le temps d’interruption et les pertes observées lors de changements de réseau et m’me, dans certains cas, de les annuler totalement pour fournir une véritable mobilité sans interruption, et donc imperceptible pour l’utilisateur. Cependant, comme on l’a déjà précisé, pour un déplacement entre deux réseaux IP distincts mais étant équipé de la m’me technologie sans fil (par exemple le Wi-Fi), un problème se pose car il faudrait que le terminal mobile soit équipé de deux interfaces Wi-Fi et, si l’on généralise, il faudrait qu’il soit équipé de deux interfaces de chaque technologie sans fil ce qui semble peu acceptable principalement en termes de consommation d’énergie.

 Conclusion sur la mobilité 

Ce premier chapitre a tout d’abord permis de préciser la terminologie utilisée dans le domaine de la mobilité dans les réseaux de communication. Ainsi, nous avons pu détailler les principaux types de mobilité existants ainsi que leur cadre d’application pour pouvoir ensuite positionner plus précisément notre étude vers la mobilité de terminal qui soulève actuellement le plus grand nombre de problématiques. On a aussi pu constater que la mobilité de terminal, elle-m’me, pouvait ‘tre vue de différentes manières : ainsi, d’un point de vue administratif, elle peut ‘tre intra ou interdomaine et d’un point de vue technologie d’accès, elle peut ‘tre intra ou inter-technologie. Cependant, le critère qui nous importe le plus est de savoir si la mobilité d’un utilisateur implique ou non un changement d’adresse IP, et, le cas échéant, si ce changement peut ‘tre géré localement à l’intérieur d’un réseau d’accès ou non. Nous avons donc aussi pu préciser quelle terminologie nous allions utiliser. Ensuite, nous avons parcouru les différents niveaux du modèle en couche pour détailler le fonctionnement des principaux standards ou protocoles permettant la gestion de la mobilité de terminal, depuis la couche physique jusqu’à la couche application. Ainsi, les technologies d’accès Wi-Fi et WiMAX, qui explicitent le fonctionnement des couches 1 et 2, ont été détaillées pour comprendre les principes de base permettant à un terminal mobile de s’associer à un point d’accès (ou à une station de base) et d’en changer en cours de communication. Cependant, on a vu que ces deux solutions nécessitaient naturellement des mécanismes de niveau réseau ou supérieurs pour permettre la gestion d’une mobilité locale ou globale, impliquant un changement d’adresse IP. Les solutions appartenant aux couches supérieures, indépendantes de la technologie d’accès utilisée, ont donc été parcourues, chacune avec leurs avantages et leurs défauts. Ainsi, les protocoles de la couche réseau présentent l’avantage de pouvoir s’adapter à tout type d’application de faÁon transparente mais nécessitent des changements importants dans l’infrastructure réseau. De plus, la phase de tunnel bidirectionnel s’avére pénalisante dans bien des cas, particulièrement lorsque l’on considère l’utilisation d’IPv4 puisque l’optimisation de route n’est alors pas réalisable. Il faudrait donc attendre la mise en place d’IPv6 pour que ces solutions soient pleinement efficaces. De son cÙté, l’architecture HIP présente un concept innovant en séparant identification et localisation d’un utilisateur mais les changements nécessaires semblent trop importants pour ‘tre mis en úuvre. Enfin, aux niveaux transport et application, la plupart des solutions proposées présentent l’avantage de relancer la communication directement entre les correspondants et de ne pas nécessiter l’ajout de nouveaux éléments au réseau mais le principal inconvénient est qu’elles ne s’appliquent pas à tous les types d’applications. Par contre, ces dernières solutions situées au dessus de la couche réseau permettraient une transition douce entre IPv4 et IPv6 puisqu’elles sont toutes compatibles avec ces deux protocoles. Enfin, des améliorations ont été proposées pour permettre d’une part l’échange d’informations entre les technologies d’accès et les protocoles de niveau réseau ou supérieur avec MIH et d’autre part l’adaptation des solutions de mobilité à un utilisateur possédant plusieurs interfaces et pouvant les utiliser simultanément.  

Table des matiéres

Introduction générale
I. La Mobilité dans les Réseaux de Communication
I.1. Terminologie de la mobilité
I.1.1. La mobilité personnelle
I.1.2. La mobilité de session
I.1.3. La mobilité de service
I.1.4. La mobilité de terminal
I.1.5. La mobilité de réseau
I.1.6. Positionnement de notre étude sur la mobilité
I.2. Les protocoles de gestion de la mobilité
I.2.1. La gestion de la mobilité dans les technologies de niveau 1 et 2
I.2.2. La gestion de la mobilité au niveau de la couche réseau
I.2.3. La gestion de la mobilité entre les couches réseau et transport : le protocole HIP
I.2.4. La gestion de la mobilité au niveau de la couche transport
I.2.5. La gestion de la mobilité au niveau de la couche application avec SIP
I.2.6. Les améliorations possibles
I.3. Conclusion sur la mobilité
II. La Gestion de la QoS
II.1. Les principes fondamentaux liés à la QoS
II.1.1. Les principales métriques
II.1.2. Exigences de QoS pour les applications audio et vidéo
II.1.3. Exigences de QoS pour les applications de données
II.2. Les principaux modèles existants pour garantir la QoS
II.2.1. Le modéle IntServ
II.2.2. Le modéle DiffServ
II.2.3. DiffServ vs. Intserv
II.3. Protocoles de signalisation pour la QoS
II.3.1. COPS et la notion de gestion de QoS par politique
II.3.2. NSIS : un pas vers la signalisation générique
II.3.3. SIP : le contrôle de session au service de la QoS
II.4. Architecture de QoS pour les réseaux de nouvelle génération
II.5. Mobilité et QoS : les solutions existantes
II.5.1. Le support de la QoS pour Mobile IPv6 et ses extensions
II.5.2. Le support de la QoS pour mSCTP
II.5.3. Conclusion sur la gestion de la mobilité et de la QoS
II.6. Conclusion
III. Propositions d’Architectures pour la Mobilité et la QoS dans un Systéme DVB-S2/RCS
III.1. Les réseaux satellite DVB-S2/RCS
III.1.1. Les principales caractéristiques d’un systéme DVB-S2/RCS
III.1.2. Les éléments d’un systéme DVB-S2/RCS
III.2. Le projet SATSIX
III.3. La QoS dans les réseaux DVB-S2/RCS
III.3.1. Le DAMA : un mécanisme d’allocation de bande passante à la demande
III.3.2. La QoS de niveau IP
III.3.3. La QoS de niveau MAC .
III.3.4. La QoS dans le projet SATSIX
III.3.5. Contributions pour l’amélioration de la gestion de la QoS
III.4. La mobilité dans les réseaux DVB-S2/RCS
III.4.1. Spécification de la mobilité SIP dans un systéme DVB-S2/RCS
III.4.2. Evaluation théorique et recommandations
III.5. Propositions d’architectures de mobilité et de QoS pour les systèmes DVB-S2/RCS
III.5.1. Mobile IPv6 couplé au QoS Agent mobile
III.5.2. FMIPv6 couplé au QoS Agent mobile
III.5.3. SIP pour la gestion de la mobilité et de la QoS pour les applications interactives
III.6. Conclusion
IV. Implémentations et Evaluations
IV.1. PLATINE : la plateforme d’émulation
IV.1.1. Environnement de développement de la plateforme d’émulation
IV.1.2. Les différents éléments de la plateforme
IV.2. Les outils nécessaire à l’évaluation
IV.2.1. Les outils de base
IV.2.2. Les outils pour la capture, le rejeu et l’analyse des flux
IV.2.3. Les outils pour la mobilité
IV.2.4. Les outils pour la QoS
IV.3. Evaluation de l’architecture de QoS dans un système DVB-S2/RCS
IV.3.1. Impact de la gestion des files d’attente : EF vs BE
IV.3.2. Impact des mécanismes liés aux requêtes RBDC
IV.3.3. Modification dynamique des ressources CRA
IV.3.4. Configuration de la file EF pour codec à débit variable
IV.3.5. Priorisation de la signalisation SIP
IV.3.6. Evaluation de notre service Web : le Media Type Repository
IV.4. Evaluation des solutions de mobilité dans un système DVB-S2/RCS
IV.4.1. Comparaison des temps d’interruption
IV.4.2. Probléme d’overhead
IV.4.3. Conclusion sur la mobilité
IV.5. Evaluations des architectures couplant QoS et mobilité
IV.5.1. Mobile IPv6 couplé au QoS Agent mobile
IV.5.2. Gestion de la QoS et de la mobilité pour les applications interactives par SIP
IV.5.3. Conclusion sur les architectures couplant mobilité et QoS
Conclusion Générale
Bibliographie
Publications

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *