Nous avons vu dans la vidéo précédente un certain nombre de choses sur le handover. La question que nous avons maintenant est finalement, e handover, comment ça marche réellement dans le réseau ? C'est ce que nous allons voir dans cette vidéo. Tout d'abord, le scénario que nous considérons. Nous avons toujours notre vue réseau avec un eNode B, un serving gateway, P gateway, MME, et les différents tunnels et connexions entre ces équipements. Et nous considérons un terminal qui est initialement sous la couverture d'un eNode B qui s'appelle source eNode B et qui va vers la cellule couverte par un autre eNode B qui s'appelle target eNode B. Nous supposons que ces deux eNode B peuvent échanger des messages via l'interface X2. Et également que le target eNode B peut dialoguer avec le MME. Target eNode B et source eNode B sont supposés également connectés au même S gateway. Un petit point avant de rentrer dans les procédures, sur la pile de protocoles. Nous avons ici la pile de protocoles vu pour l'accès. Le schéma est un peu complexe. On peut revoir les vidéos des semaines précédentes. Ce que fait l'interface X2, c'est d'ajouter une pile de protocoles entre deux eNode B. Cette interface est basée sur IP. Au-dessus de IP, nous trouvons SCTP, protocole de transport spécialisé dans les messages, et au-dessus, nous avons un protocole X2AP, qui est voisin sur bien des aspects de S1AP. Ce protocole est utilisé uniquement dans le plan contrôle, afin de permettre le reroutage des paquets du source eNode B au target eNode B. Nous avons également un plan utilisateur avec IP, bien sûr, UDP et GTPU. Voyons maintenant comment le handover se déroule. Nous avons un terminal qui est en train d'échanger des données, et la personne s'éloigne de la station de base. Lorsque le signal reçu par le terminal est en dessous d'un certain seuil, la station de base eNode B va demander au terminal de rapatrier les mesures radio qu'il fait sur la station de base courante et les voisins. C'est ce que nous voyons ici, la demande et le rapatriement, au fur et à mesure, des mesures justement. Cela peut se passer en parallèle avec le flux de données, sans le perturber. Si la personne continue à s'éloigner, le source eNode B va décider de faire un handover, de transférer la connexion radio, et va choisir le target eNode B, l'eNode B cible, en fonction des mesures renvoyées par le mobile. Le source eNode B va donc envoyer une demande de handover, c'est un message X2AP. Le target eNode B vérifie qu'il est capable d'accueillir ce nouvel abonné, que la cellule par exemple n'est pas saturée. C'est le contrôle d'admission. Et ensuite, le target eNode B va choisir un préambule qui va être utilisé après, dans la phase d'accès aléatoire. Ce préambule est renvoyé dans le message d'acquittement. Handover Request Acknowledge. Lorsque le source eNode B reçoit ce message, il sait qu'il peut donner l'ordre au terminal de changer de cellule. C'est ce qu'il fait avec un message RRC Connexion Reconfiguration. Il indique le nouveau RNTI du terminal, éventuellement, l'identité de l'eNode B qui est le target eNode B et le préambule qui a été indiqué. Dès ce moment-là , les données qui arrivent, qui peuvent continuer à arriver de l'extérieur, sont renvoyées, retransmises sur le tunnel X2AP, le tunnel de données. Le target eNode B va mettre en mémoire dans un buffer les paquets qui arrivent. En effet, le terminal n'est pas encore forcément présent sur la nouvelle cellule. Il faut d'abord qu'il envoie le préambule alloué. Il y a ensuite une vérification par le target eNode B que c'est bien le préambule attendu, et acquittement par un message Connexion reconfiguration complete. À partir de ce moment-là , de cet échange-là , la connexion radio est bien réétablie. Le flux de données va donc passer du serving gateway vers le source eNode B, du source eNode B vers le target eNode B, et ensuite vers le terminal. Sur la voie montante, comme le serving gateway est le même, les données peuvent être envoyées directement du target eNode B au serving gateway. On peut remarquer qu'à cet instant là , le handover est exécuté et que le MME n'est pas encore au courant de ce handover. Pour ré-aiguiller correctement les données, c'est-à -dire éviter d'avoir ce phénomène de retransmission et d'avoir un chemin direct, le target eNode B doit rétablir complètement le tunnel sur la voie descendante entre serving gateway et target eNode B. Comme il n'y a pas d'échange direct entre target eNode B et serving gateway, sauf cas particulier dans le cadre de la signalisation, le target eNode B va renvoyer un message Pass Switch Request au MME. Le but, c'est que le serving gateway soit capable de réétablir ce tunnel. Cela provoque donc un message Modified Bearer Request envoyé par le serving gateway. Le but est d'échanger la valeur de TUID côté de l'eNode B pour réétablir le tunnel target eNode B, serving gateway, tunnel de données, bien évidemment. Afin d'éviter que des messages soient dans des buffers et restent un temps infini dans des buffers, c'est un cas particulier où on a un message de signalisation en GTPU. Il y a un message N marqueur qui est envoyé du serving gateway vers le source eNode B, puis vers le target eNode B pour purger tous les messages qui seraient en attente éventuelle dans un équipement, sur l'ancien chemin indirect. A partir du moment où le message Modified Bearer Request est reçu, la transmission des données sur la voie descendante, comme sur la voie montante, se fait de façon directe. Le handover n'est pas tout à fait fini, car il faut libérer les ressources sur l'ancienne cellule. Le serving gateway, déjà , acquitte cette demande et envoie donc une réponse au MME. Le MME indique au target eNode B que le réétablissement des tunnels directs s'est bien effectué. Et ensuite, le target eNode B indique au source eNode B qu'il peut complètement libérer toutes ces ressources que l'abonné a été complètement récupérer, si on peut dire, dans la nouvelle cellule. Il y a très souvent, on peut l'espérer, le cas qui marche. Mais de temps en temps, par exemple, la cellule cible, le target eNode B, n'est pas en mesure de recevoir un nouvel abonné. Dans ce cas là , le début du scénario est identique au précédent, mais lorsque le message Handover Request est reçu, le contrôle d'admission conduit à un refus et un acquittement négatif Handover Preparation Failure, un avis d'échec est renvoyé au source eNode B. A ce moment-là , le source eNode B peut essayer de détecter s'il n'y a pas un autre eNode B cible qui serait possible, ou peut essayer de garder le plus longtemps possible l'abonné sur l'ancienne cellule. Dans certains cas, on ne va pas réussir et la connexion va être interrompue. Le handover est, comme nous l'avons dit, une opération complexe avec un taux échec qui n'est jamais nul.
