Comment faire pour retransmettre efficacement et très rapidement des paquets qui peuvent arriver de différents PGateway et qui sont destinés à différents terminaux, c'est-à -dire qu'il y a des chances qu'il faut les envoyer à différents eNode B, comment faire donc pour traiter ces paquets très rapidemen ? Telle est la question à laquelle nous allons répondre dans cette vidéo. Pour bien comprendre cette question, il faut se remettre en mémoire le fait que dans un réseau, nous avons des millions d'utilisateurs. Tous ne sont pas sur le même eNode B, nous avons des milliers ou des dizaines de milliers d'eNode B, tous ne sont pas servis par le même Serving Gateway mais nous avons quelques Packet Gateway, en général 2 ou 3, peut-être une dizaine de Packet Gateway. Il faut être capable de gérer différents tunnels. Dans ce petit exemple simple, on voit qu’entre le PGateway et le SGateway, il y a 2 tunnels et que le SGateway va devoir envoyer les paquets envoyés sur ce tunnel vers un tunnel à destination d'eNode B2 et les paquets envoyés sur le tunnel du bas à destination de l'eNode B1. Il y a donc des traitements différents pour les 2 tunnels entre le Serving Gateway et le Packet Gateway, traitement différent au sein du Serving Gateway. On veut être capable de faire ce traitement très rapidement. Si nous sortons du monde des télécommunications, nous savons que lorsqu'il y a des échanges entre des sociétés, chaque société va affecter un numéro de dossier à un échange particulier. Nous avons ici un petit exemple avec Universal Aspects ldt et Lunar Rock Productions ldt, chacun gère des numéros de dossier et quand elles écrivent un courrier à une autre société en rapport à une affaire particulière, elles mettent notre référence, la référence du destinataire et notre référence, la référence de l'expéditeur. Eh bien on va utiliser un peu le même principe dans le cas des réseaux mobiles. Chaque société peut être vue comme un équipement, par exemple le Serving Gateway. Le Serving Gateway a un certain nombre de tunnels qui peuvent venir de différents autres équipements. Il va numéroter l'extrémité de chaque tunnel et utiliser un numéro unique, ici 101-102-103-104 pour les 4 tunnels qui lui arrivent. On appelle ce numéro le TEID, pour Tunnel Endpoint IDentifier, Endpoint signifiant extrémité. Chaque tunnel possède donc 2 identificateurs puisque par exemple, ce tunnel est établi entre le Serving Gateway et le Packet Gateway. Vu du Serving Gateway, il s'appelle 101, vu du Packet Gateway, il est numéroté 32 000. La numérotation à l'intérieur pour un équipement est unique. Mais rien n'empêche qu'un numéro soit utilisé, le même numéro soit utilisé par 2 équipements différents. Le TEID dans le cas de GTP, est codé sur 32 bits, c'est-à -dire 4 octets. Il faut mettre un numéro de tunnel, un TEID dans chaque paquet puisque le but, c'est de faciliter le traitement. La première solution que nous pouvons voir est de mettre le TEID alloué par l'expéditeur dans l'antenne GTP. Si nous considérons un paquet qui arrive au PGateway, ce paquet est mis dans un autre paquet et au niveau GTP, dans l'en-tête nous allons mettre le numéro de tunnel. Si nous mettons le 16538, ce que devra faire le Serving Gateway, c'est identifier d'où vient ce paquet puisque ici, on a utilisé l'identification de l'expéditeur, chaque expéditeur ayant sa propre identification, il faut retrouver quel est émetteur de ce paquet, retrouver quel est le tunnel local correspondant au couple donc adresse du PGateway TEID. Le traitement est donc complexe puisque le récepteur doit connaître le TEID utilisé par l'entité qui est en vis-à -vis pour ce tunnel. Il faut donc analyser le TEID et l'adresse. Ce n'est pas une bonne méthode. On peut regarder la deuxième possibilité, c'est de mettre le TEID alloué par le destinataire dans l'en-tête. Ici, on va avoir un traitement qui va devoir être géré par l'expéditeur. Si l'expéditeur veut envoyer un paquet sur l'extrémité de tunnel 16538 pour lui, il va devoir retrouver le TEID correspondant alloué par le Serving Gateway dans mon exemple et faire la conversion 16538 en 102 de façon à transmettre un paquet avec le TEID du destinataire 102. L'avantage, c'est que le traitement est très simple au récepteur, il reçoit un paquet sur le tunnel 102. Il le traite en fonction de ce qui est demandé. On peut remarquer qu'ici, il y a forcément unicité. Le 102 étant alloué par le Serving Gateway, il n'y a qu'un 102 qui arrive au Serving Gateway. On a donc un léger surcroît de complexité à l'émetteur et une simplification considérable dans le récepteur. La 3e possibilité, c'est celle qu'on a vue dans l'exemple des lettres administratives, c'est de mettre les 2 identités, les 2 TEID 102 et 16538, comme on a mis les 2, eh bien on peut utiliser côté du récepteur uniquement celui du destinataire, le 102. Donc finalement on a des traitements côté récepteurs qui sont aussi simples, l'en-tête est un petit peu plus long, l'avantage, c'est que si un équipement peut changer la valeur du TEID en cours de route, il peut le faire sans traitement supplémentaire, c'est-à -dire que si on veut passer du 16538 au 3333 pour le PGW pour une raison ou une autre, eh bien il suffit qu'il laisse le 102, qu'il mette ici 3333 dans l'en-tête et le récepteur va se dire, ah ! Mon autre extrémité a changé, je stocke la nouvelle valeur pour ce tunnel. Cette solution est non retenue pour GTP mais elle est utilisée dans un protocole que nous verrons dans une autre vidéo entre l'eNode B et le MME.
