Émulation du mécanisme de Forward pour le handover intra-satellite

changement fréquent d'un UE entre le système satellite et terrestre est limité.

5.4 Émulation du mécanisme de Forward pour le handover intra-

satellite

Dans cette partie, nous nous intéressons au handover intra-satellite. Ce type de handover survient de manière plus fréquente que celui précédemment exposé, puisqu'il fait intervenir des eNB du même segment. En effet, les optimisations de la phase de préparation n'ont pas pour objectif de privilégier certains eNB à l’intérieur d’un même segment. Nous avons utilisé la même méthodologie que pour l'émulation des handovers inter-satellite-terrestre à la seule exception près que nous focalisons notre émulation sur une période plus courte en émulant le téléchargement d'un fichier plus petit qui fait 5Mo, pour nous concentrer sur l’instant du handover.

Figure 66 Principe du mécanisme de Forward du handover intra-satellite

La Figure 66 remémore le principe du mécanisme de Forward du handover intra-satellite alors qu'aucune interface X2 n'est disponible. L'objectif de celui-ci est de transmettre en multicast les données à destination de l'UE, vers les différents eNB, qui ont subi la phase de préparation. Deux variantes vont être émulées. La première ne se préoccupe pas de la gestion des pertes. Ainsi, la durée d'interruption du service pendant la phase d'exécution va engendrer quelques pertes. La deuxième solution assure l'absence de pertes et de paquets dupliqués en mémorisant les paquets qui sont susceptibles d'être perdus lors du handover. Nous considérons dans notre simulation que les terminaux satellite sont co-localisés avec les eNB.

92

Sans mécanisme de Forward

Les courbes suivantes représentent les évolutions de la fenêtre de congestion lorsqu'aucun mécanisme de Forward n'a été mis en œuvre.

Figure 67 Fenêtre de congestion lors d'un handover intra-satellite sans mécanisme de Forward et déclenché après 15s

Figure 68 Fenêtre de congestion lors d'un handover intra-satellite sans mécanisme de Forward et déclenché après 20s

93 La Figure 67 et la Figure 68 représentent l'évolution de la fenêtre de congestion lorsque le handover survient pendant la phase de slow-start. Cependant, dans la Figure 67, il advient au milieu de cette phase alors que dans la Figure 68, il se produit à la fin de cette phase. Dans la Figure 69, le handover est déclenché lors de la phase de congestion avoidance. Nous remarquons que, lorsque le handover se produit lors de la phase de slow-start, TCP recommence la phase de slow-start plus rapidement que lorsqu'il survient pendant la phase de congestion avoidance. La récupération est beaucoup plus longue et entraîne un retard important. En effet, si nous comparons les durées des téléchargements entre la Figure 69 et les Figure 67 et Figure 68, nous remarquons que la différence atteint presqu'une dizaine de secondes.

Avec mécanisme de Forward et pertes

Les figures ci-après représentent l'évolution de la fenêtre de congestion, lors d'un handover avec un mécanisme de Forward qui ne gère pas les pertes dues à l'interruption de connexion pendant la phase d'exécution. Ainsi une dizaine de paquets sont perdus durant le handover.

Figure 70 Fenêtre de congestion lors d'un handover intra-satellite avec mécanisme de Forward et des pertes et déclenché après 15s

Figure 71 Fenêtre de congestion lors d'un handover intra-satellite avec mécanisme de Forward, sans gestion des pertes et déclenché après 20s

94

Figure 72 Fenêtre de congestion lors d'un handover intra-satellite avec mécanisme de Forward, sans gestion des pertes et déclenché après 30s

Les performances du mécanisme de Forward sont honorables. Il permet de réduire la durée du transfert de 5 secondes en comparaison du handover sans mécanisme de Forward. Nous observons, cependant, nettement l'influence de quelques pertes lors du handover et son impact sur la fenêtre de congestion.

Avec mécanisme de Forward sans pertes

La Figure 71 représente l'évolution de la fenêtre de congestion lors d'un handover avec un mécanisme de Forward qui assure un handover sans perte ni duplication de paquets.

Figure 73 Fenêtre de congestion lors d'un handover intra-satellite avec mécanisme de Forward et sans perte

La fenêtre de congestion ne diffère pas en fonction de l'instant de déclenchement du handover. C'est pour cette raison qu'une seule figure est proposée. Nous remarquons que le mécanisme de Forward réalise parfaitement son objectif de rendre le handover invisible pour le protocole TCP. L'absence de perte et de duplication nous assure ainsi les meilleures performances pour les flux TCP pendant le

handover. Le bénéfice en comparaison du mécanisme de Forward avec perte est non négligeable

mais pas décisif. En effet, nous gagnons entre 1 et 2 secondes sur la durée de transfert. Cependant, une fréquence élevée des handovers ferait plus largement perdre en efficacité le mécanisme de

95 fréquence des handovers est un paramètre lié à la phase de préparation qui n'est pas simulée dans ce chapitre.

5.5 Conclusion

Nous avons proposé des mécanismes de Forward qui permettent de remplacer celui défini dans le standard LTE. La modification était nécessaire, puisque celui-ci imposait une surconsommation des ressources satellite et n'était pas efficace, en raison de l'important délai induit par le satellite.

Dans un premier temps, nous avons optimisé le mécanisme de Forward pour un handover inter- satellite-terrestre. Pour vérifier l'intérêt de ce mécanisme, nous avons réalisé ces émulations, en comparant le comportement de TCP avec notre mécanisme de Forward et sans aucun mécanisme de

Forward. Elles ont révélé qu'au regard de la complexité du mécanisme et des bénéfices qu'il apporte,

la balance ne lui est pas favorable. En effet, il implique des modifications trop importantes, en particulier dans le réseau de cœur du segment terrestre pour être réellement intéressant en l'état. Dans un second temps, nous avons proposé une optimisation du mécanisme de Forward dans le cadre d'un handover intra-satellite. Deux variantes ont été proposées. Elles permettent toutes deux de transférer les paquets en multicast, entre toutes les eNB qui sont potentiellement cibles. La différence repose sur la gestion des pertes de paquets lors de la phase d'exécution. La première ne va pas se préoccuper de ces paquets et va alors occasionner un certain nombre de pertes. Celles-ci affectent les paquets qui arrivent aux eNB, tandis que l’UE vient de se détacher de l’eNB source et n’est pas encore connecté à l’eNB cible. La deuxième solution, quant à elle, assure un mécanisme de

Forward sans perte. Les émulations ont mis à jour un réel intérêt de ces deux mécanismes de Forward. Ils sont à l'origine de bénéfices indéniables, en comparaison des performances obtenues en

l'absence de mécanisme de Forward. Cependant, le choix entre les deux mécanismes reste difficile. De nombreux paramètres peuvent être exploités comme la fréquence des handovers qui est dépendante des paramètres de la couche physique et de la phase de préparation, qui ne sont pas abordées dans cette thèse.

Les deux mécanismes de Forward pour le handover intra-satellite sont une réelle réussite. En effet, ils augmentent significativement les performances des applications qui se fondent sur TCP tout en assurant une gestion optimisée des ressources sur le système satellite. La cohérence entre ces mécanismes de Forward et la phase de préparation adaptée au lien satellite nous permet d'envisager une augmentation supérieure des performances pour un système complet.

Nous allons maintenant nous concentrer sur une autre catégorie de réseau hybride, les réseaux instantanés MANET-satellite.

96

Chapitre 6 : MONET : Présentation de