Lorsqu’un UE ouvre une application vidéo, le trafic utilisateur réel doit transiter du gNB vers l’UPF avant d’atteindre le réseau de données. Le plan de contrôle établit la PDU Session, attribue les adresses et installe les règles de transfert, mais le protocole qui transporte réellement les paquets IP utilisateur à travers le plan utilisateur d’accès et de cœur 5G est GTP-U. Comprendre GTP-U ne consiste pas seulement à retenir « port UDP 2152 » et « TEID ». En 5G, un même tunnel N3 peut transporter plusieurs QoS Flows, tandis que la supervision du chemin, le traitement des tunnels inconnus et le nettoyage du plan utilisateur après des événements de mobilité reposent également sur les messages de gestion GTP-U. Considérer la pile de protocoles, les tunnels, les TEID, les QFI et les procédures de gestion comme un chemin utilisateur complet permet de mieux comprendre comment le trafic 5G atteint réellement l’UPF.

Où se situe GTP-U dans l’architecture 5G ?

GTP-U signifie GPRS Tunnelling Protocol for the User Plane. Dans l’architecture du plan utilisateur 5G, il sert principalement à encapsuler et à transporter le trafic utilisateur des couches supérieures entre les nœuds du plan utilisateur.

Du point de vue du 5G Core, les deux interfaces les plus courantes utilisant GTP-U sont N3 et N9. N3 relie le gNB à l’UPF et transporte le trafic utilisateur entre le réseau d’accès radio et le 5G Core. N9 est utilisé entre UPF. Au sein du RAN, Xn-U entre gNB peut également utiliser GTP-U.

Cette architecture diffère nettement de celle du plan de contrôle 5G. Des fonctions réseau comme l’AMF et le SMF utilisent des interfaces orientées services qui reposent largement sur HTTP/2, tandis que le chemin du plan utilisateur continue d’utiliser GTP-U pour transporter le trafic réel de l’abonné. Le passage à une Service-Based Architecture en 5G ne signifie donc pas que le plan utilisateur lui-même soit passé à HTTP.

GTP-U fonctionne au-dessus d’UDP et continue d’utiliser le port UDP 2152. Si l’on observe la pile de protocoles en partant du paquet applicatif de l’utilisateur vers les couches inférieures, sa structure peut être comprise comme suit.

Le trafic applicatif devient d’abord un paquet TCP ou UDP, puis un paquet IP appartenant à l’UE. Une fois entré dans le plan utilisateur 5G, ce paquet utilisateur d’origine est encapsulé dans GTP-U. Un en-tête UDP externe, un en-tête IP externe et une trame Ethernet de couche inférieure sont ensuite ajoutés pour le transport entre les extrémités GTP-U.

Une capture de paquets peut donc contenir deux ensembles d’adresses IP différents. Les adresses IP internes décrivent la communication entre l’UE et le serveur applicatif du réseau de données, tandis que les adresses IP externes sont utilisées entre les extrémités de tunnel GTP-U, par exemple le gNB et l’UPF. Confondre les en-têtes IP internes et externes est une source fréquente d’erreur lors du dépannage du trafic N3.

Quelle est la différence entre un GTP Path, un tunnel et un TEID ?

GTP Path, GTP Tunnel, Tunnel Endpoint et TEID sont des termes étroitement liés, mais ils décrivent des niveaux différents du modèle de transport GTP-U.

Un GTP Path peut être vu comme le chemin de communication sans connexion entre deux extrémités de tunnel GTP. Si un gNB et un UPF peuvent échanger des paquets GTP-U sur le réseau IP, un GTP Path existe entre ces extrémités. Plusieurs tunnels GTP-U peuvent partager le même Path.

Un GTP Tunnel représente un tunnel logique du plan utilisateur plus spécifique. Un tunnel GTP-U est identifié par une combinaison du TEID, de l’adressage IP et des informations de transport UDP, tandis que l’extrémité de tunnel elle-même est identifiée par l’adresse IP du nœud et le port UDP.

Le TEID, ou Tunnel Endpoint Identifier, est l’un des champs les plus importants de GTP-U. Dans l’en-tête de base GTPv1-U, le TEID occupe quatre octets. Lorsqu’un paquet GTP-U atteint le nœud récepteur, celui-ci utilise le TEID avec son contexte local de tunnel afin de déterminer à quel tunnel du plan utilisateur appartient le paquet et quelle PDU Session ou quel contexte de transfert doit le traiter.

C’est aussi pourquoi un TEID ne doit jamais être interprété isolément. La même valeur numérique de TEID peut apparaître dans différents contextes de tunnel. Si les paquets appartiennent à des extrémités GTP différentes ou à des directions différentes, ils ne font pas nécessairement partie du même tunnel.

Deux autres termes sont utiles lorsqu’on examine la charge utile elle-même. Un T-PDU correspond aux données utilisateur d’origine des couches supérieures, tandis qu’un G-PDU est le T-PDU après ajout de l’en-tête GTP-U. Ce qui traverse N3 n’est donc pas uniquement le paquet IP brut de l’UE, mais un G-PDU encapsulé par GTP-U.

GTP-U ne se limite pas non plus au transport des données utilisateur. Il dispose de ses propres messages de gestion. Par conséquent, voir le port UDP 2152 dans une capture ne signifie pas automatiquement que le paquet appartient au trafic applicatif utilisateur. Echo Request, Echo Response, Error Indication, End Marker et d’autres messages GTP-U utilisent le même cadre protocolaire.

Pourquoi la 5G a-t-elle besoin du QFI si elle dispose déjà du TEID ?

Si l’on découvre GTP-U d’abord sous l’angle de la 4G, il est facile de supposer que l’identification du TEID suffit à identifier le bearer. En 5G, cette hypothèse n’est plus complète.

L’architecture QoS 4G repose sur les EPS Bearers. Les différents bearers disposent de leurs propres contextes de transport du plan utilisateur et de leurs propres tunnels GTP-U ; le tunnel et le TEID permettent donc naturellement de distinguer les différents trafics de bearer.

La 5G fait évoluer le modèle QoS vers PDU Session plus QoS Flow. Une PDU Session peut contenir un ou plusieurs QoS Flows, et un DRB peut également transporter un ou plusieurs QoS Flows. Toutefois, N3 ne crée pas un tunnel GTP-U distinct pour chaque QoS Flow au sein d’une même PDU Session.

Autrement dit, le TEID peut identifier le tunnel GTP-U associé à la PDU Session, mais plusieurs QoS Flows peuvent malgré tout partager ce même tunnel.

Cela soulève une autre question : comment le nœud récepteur sait-il à quel QoS Flow appartient un paquet donné ?

C’est l’une des principales raisons d’être de l’en-tête d’extension PDU Session Container. La 5G utilise cet en-tête d’extension GTP-U pour transporter des informations de plan utilisateur liées à la PDU Session, notamment le QFI, ou QoS Flow Identifier.

Le QFI est un identifiant sur 6 bits utilisé pour identifier un QoS Flow. Lors de l’analyse du trafic 5G N3, le TEID et le QFI peuvent donc être compris à deux niveaux distincts :

Le TEID identifie le tunnel GTP-U ou le contexte de la PDU Session, tandis que le QFI identifie le QoS Flow précis transporté dans ce tunnel.

Le PDU Session Container en liaison descendante peut également transporter des informations telles que RQI et PPI. RQI est utilisé pour la signalisation liée au Reflective QoS, tandis que PPI est associé au Paging Policy Differentiation et peut permettre un traitement de paging différent selon le type de trafic au sein d’une même PDU Session.

Le bit E de l’en-tête de base GTP-U indique si un Extension Header suit. Tous les paquets GTP-U ne transportent donc pas nécessairement les mêmes en-têtes d’extension. La présence d’un PDU Session Container dépend du paquet et de la fonction exécutée.

Que se passe-t-il réellement pour un paquet utilisateur N3 ?

Les concepts précédents deviennent beaucoup plus faciles à comprendre lorsqu’on les replace dans un flux réel de paquets montants.

Supposons qu’un UE accède à un service vidéo en ligne. L’UE génère d’abord le trafic applicatif, transporté sur TCP ou UDP puis placé dans un paquet IP normal. Dans cet en-tête IP interne, l’adresse source est l’adresse IP attribuée à l’UE, tandis que l’adresse de destination appartient au serveur applicatif sur Internet.

Lorsque le paquet atteint le gNB, le gNB ne transfère pas simplement le paquet IP de l’UE directement vers l’UPF. Il applique une encapsulation GTP-U en fonction du contexte courant du plan utilisateur de la PDU Session.

L’en-tête GTP-U contient le TEID correspondant. Si le paquet doit identifier un QoS Flow particulier, le PDU Session Container peut également transporter le QFI. Le gNB ajoute ensuite l’en-tête UDP, avec le port de destination 2152, puis l’en-tête IP externe.

À ce stade, les adresses IP externes ne décrivent plus la communication entre l’UE et Internet. Elles représentent la relation de transport entre l’interface N3 du gNB et l’interface N3 de l’UPF.

Lorsque le paquet atteint l’UPF, le processus est inversé. L’UPF reçoit le paquet à partir des informations de transport externes, lit le TEID pour retrouver le bon contexte de tunnel du plan utilisateur, traite le QFI et les autres informations d’extension si nécessaire, retire l’encapsulation GTP-U, puis transfère le paquet IP original de l’UE vers le réseau de données.

Lors du dépannage du trafic N3 avec Wireshark ou un autre outil d’analyse de paquets, une méthode utile consiste à progresser de l’extérieur vers l’intérieur. Vérifiez d’abord les adresses IP externes du gNB et de l’UPF, puis le port UDP 2152, ensuite le TEID, le PDU Session Container et le QFI lorsqu’ils sont présents, et seulement après l’IP interne de l’utilisateur, TCP ou UDP et le trafic de couche applicative.

Cette méthode est souvent plus efficace que de commencer par le paquet applicatif, car de nombreux défauts N3 proviennent du contexte du tunnel, du TEID ou des extrémités, plutôt que de l’application de l’utilisateur elle-même.

Pourquoi GTP-U a-t-il besoin de ses propres messages de gestion ?

Bien que GTP-U soit un protocole du plan utilisateur, il ne se limite pas aux messages G-PDU de données utilisateur. Il définit aussi des messages de gestion des chemins et des tunnels qui contribuent à maintenir opérationnel le transport du plan utilisateur.

Echo Request et Echo Response vérifient la disponibilité du chemin

Un Echo Request sert à vérifier si le GTP Path et le nœud GTP pair sont joignables et opérationnels. Le pair répond par un Echo Response.

Ces messages testent la relation de base entre deux extrémités GTP. Si un gNB échoue de manière répétée à recevoir des Echo Responses d’un UPF, le problème peut ne plus être limité à un UE ou à une PDU Session : il peut indiquer un défaut du GTP Path lui-même ou du nœud pair.

GTP-U définit également le message Supported Extension Headers Notification, qui permet à un nœud d’indiquer les en-têtes d’extension GTP qu’il prend en charge. Cela devient important lorsque des fonctions du plan utilisateur 5G dépendent d’en-têtes d’extension comme le PDU Session Container.

Error Indication traite les TEID inconnus

Si une extrémité GTP reçoit un G-PDU mais ne trouve aucun EPS Bearer local ni contexte de PDU Session correspondant au TEID reçu, et que ce TEID n’est pas nul, elle peut envoyer une Error Indication au pair.

Cela indique au nœud émetteur qu’il transfère des données vers un tunnel du plan utilisateur que le côté récepteur ne reconnaît plus.

Si des messages Error Indication apparaissent à répétition pendant le dépannage, il faut d’abord vérifier que les deux extrémités ont un état TEID cohérent et qu’une mise à jour de PDU Session, une procédure de mobilité ou un changement de chemin du plan utilisateur n’a pas désynchronisé les deux côtés.

End Marker aide à terminer une commutation de chemin du plan utilisateur

L’End Marker est généralement associé à la mobilité et à la commutation de chemin du plan utilisateur. Il indique que le dernier G-PDU sur l’ancien chemin GTP-U a été envoyé et que le trafic utilisateur suivant ne doit plus emprunter ce chemin précédent.

Par exemple, lorsqu’un UE se déplace d’un gNB source vers un gNB cible, le chemin du plan utilisateur du cœur de réseau peut lui aussi changer. Le trafic ne doit pas continuer indéfiniment sur l’ancien chemin, sinon les anciens et nouveaux chemins pourraient se chevaucher et provoquer des problèmes d’ordre des paquets ou de transfert.

L’End Marker n’est donc pas simplement une notification de « suppression de tunnel ». Il agit plutôt comme une borne de fin de l’ancien chemin du plan utilisateur, indiquant au côté récepteur que le dernier paquet de ce chemin a déjà été transmis.

Pris ensemble, ces mécanismes rendent le rôle de GTP-U beaucoup plus clair. Il ne s’agit pas simplement d’un protocole qui ajoute un TEID devant le paquet IP de l’utilisateur. Il fournit un cadre complet de tunnellisation du plan utilisateur qui peut être identifié, surveillé, géré et mis à jour au gré des changements d’état du réseau.

Une séquence pratique de dépannage GTP-U en 5G consiste donc à confirmer d’abord que les extrémités GTP et le Path sont sains, puis à vérifier le TEID et le contexte du Tunnel, à examiner le PDU Session Container et le QFI le cas échéant, et enfin à progresser vers le trafic utilisateur d’origine. Si le problème survient pendant une mobilité ou une mise à jour de chemin, les messages Error Indication et End Marker doivent également être examinés.

En suivant cet ordre, une capture N3 composée d’un grand nombre de paquets UDP 2152 devient un chemin de transfert du plan utilisateur que l’on peut reconstruire couche par couche.

Questions fréquentes

Chaque paquet sur le port UDP 2152 transporte-t-il du trafic utilisateur ?

Non. Les messages G-PDU transportent les données du plan utilisateur via GTP-U et le port UDP 2152, mais les messages de gestion GTP-U tels que Echo Request, Echo Response, Error Indication, End Marker et Supported Extension Headers Notification utilisent également le même cadre protocolaire. Il faut vérifier le GTP-U Message Type pour déterminer ce que le paquet représente réellement.

Un TEID doit-il être unique à l’échelle de tout le réseau 5G ?

Non. Un TEID ne doit pas être considéré comme un identifiant globalement unique dans tout le réseau. L’identification d’un tunnel GTP-U dépend également de ses extrémités, de l’adressage IP, des informations de transport et de la direction. Le dépannage doit donc prendre en compte le contexte complet du tunnel plutôt que de comparer les seules valeurs TEID.

Chaque paquet GTP-U 5G contient-il un PDU Session Container ?

Non. Le PDU Session Container est un en-tête d’extension GTP-U, et sa présence dépend du paquet et de la fonction exécutée. Le bit E de l’en-tête de base GTP-U indique si d’autres Extension Headers suivent ; tous les paquets N3 n’ont donc pas la même structure d’en-tête.

Un End Marker signifie-t-il que toute la PDU Session a été libérée ?

Pas nécessairement. Un End Marker indique principalement que le trafic sur un chemin utilisateur GTP-U particulier est arrivé à son terme et il apparaît couramment lors d’une commutation de chemin après des événements de mobilité. Il marque la fin du trafic sur ce chemin, et non la procédure complète de libération de la PDU Session.