Faut-il absolument une interface X2 pour que le handover fonctionne ? Le handover est-il possible quand le terminal change de MME ? Telles sont les questions auxquelles nous allons répondre dans cette vidéo. Nous regardons les principes généraux du handover basé sur S1 lorsque les deux stations de base sont connectées au même MME et à la même serving gateway. Dans ce cas-là , s'il n'y a pas l'interface X2, nous avons le handover basé sur S1 qui est défini dans les recommandations de la 4G. Si le terminal passe d'une connexion radio avec le source eNodeB à une zone gérée par le target eNodeB, à ce moment-là , le handover est possible. Nous allons avoir établissement d'une connexion SA1AP entre le target eNodeB et le MME, de façon à avertir le target eNodeB qu'un mobile doit être reçu. C'est la demande de handover. Le target eNodeB va répondre aux sources eNodeB. Ensuite, on va pouvoir avoir l'envoi réel du handover vers le terminal et le réétablissement de la connexion radio sur la nouvelle cellule. Il faut réorienter le tunnel du serving gateway vers le target eNodeB. C'est effectué par un certain nombre d'échanges de commandes. La phase ultime, c'est de libérer les anciennes connexions et les anciens ressources sur le source eNodeB. D'un point de vue protocolaire, échange de messages, le handover basé sur S1 est plus simple que le handover basé sur X2. En revanche, étant donné qu'on doit modifier le tunnel et qu'il n'y a pas de tunnel de réacheminement, il est plus probable qu'il y ait quelques pertes de paquets. On peut avoir un handover basé sur X2 lorsque l'on change de servig gateway. On va retrouver une configuration avec plusieurs tunnels établis. Si l'on regarde ce dessin, on voit que le flux de données lorsque le handover commence à être exécuté passe par le serving gateway source pour la voie descendante et est établi directement pour la voie montante. On va avoir ensuite libération du tunnel X2AP, puis libération du tunnel entre serving gateway et ancien eNodeB, et changement du tunnel pour l'aiguiller du P gateway vers le nouveau S gateway, le target S gateway, à la fois tunnel montant et tunnel descendant. Nous voyons ici que l'échange de données se fait maintenant directement, quel que soit le sens de transmission. La phase ultime du handover, c'est bien sûr toujours de libérer les anciennes connexions et les anciens tunnels. On a aussi un handover basé sur X2 lorsqu'il y a un changement de MME. Là encore, c'est un cas rare. Le handover pour changer de S gateway est rare puisqu'un S gateway couvre typiquement une région ou plusieurs régions, et un MME pourrait presque gérer un pays tel que la France. On va voir quelques MME. Le nombre moyen de personnes qui ont des flux établis et qui changent de MME est beaucoup plus faible que le nombre de handover d'une cellule à l'autre. C'est donc pour ça que nous avons indiqué que c'est un cas rare. On peut avoir aussi le handover basé sur S1 avec changement de S gateway. Dans ce cas-là , on a encore une configuration un petit peu plus simple que pour le X2, mais même phénomène, plus de risques de paquets. On va rétablir le tunnel, ré-aiguiller plutôt le tunnel du packet gateway vert le target S gateway. Le handover basé sur S1 avec changement de MME est également prévu et c'est aussi un cas rare. Pour conclure sur le handover, tous les cas d'un handover au sein d'un même réseau sont prévus dans la norme. Il va toujours y avoir un moment où il y a une interruption de connexion radio, l'instant, la durée entre la réception de l'ordre de handover et le rétablissement de la connexion radio sur la nouvelle cellule va provoquer une microcoupure, mais elle peut être de quelques dizaines de millisecondes. Elle n'est donc pas forcément perceptible par l'usager. Si on a un handover basé sur X2, on va voir peut-être quelques paquets en attente, mais ça va être complètement transparent, y compris pour les applications les plus classiques basées sur TCP. Les ruptures de connexion perçues par l'utilisateur, dans la vie courante, sont souvent des handover qui échouent. Dans ce cas, on a une procédure de réétablissement de la connexion en cas de coupure, réétablissement automatique, mais il est probable que, dans ce cas, ça soit perçu par l'utilisateur comme une suspension du réseau pendant quelques secondes.
