UMTS - Protocole de tunneling GPRS

La génération de GPRS Tunneling Protocol (GTP) était pratiquement impossible, mais il n'est pas non plus souhaitable de le donner pour le nouveau système, mais, d'un autre côté, il est tout à fait compréhensible que des améliorations soient également nécessaires pour pouvoir interagir. avec le monde de l'ancien PS en douceur et prend en charge les fonctions nécessaires pour le système le plus récent.

Protocole de tunnel GPRS (GTP)

Le protocole GTP est conçu pour le tunneling et l'encapsulation des unités de données et des messages de contrôle dans GPRS. Depuis sa conception à la fin des années 1990, il a été mis en œuvre à grande échelle et une solide expérience a été acquise.

Le système GTP pour Evolved 3GPP est disponible en deux variantes, contrôle et plan utilisateur. GTP-C gère la signalisation du plan de contrôle, et il est nécessaire en plus du protocole de transfert de données sur la pureté de l'utilisateur, GTP-U; il est appelé plan utilisateur. Les versions actuelles, adaptées à EPS, sont GTPv1 US et GTPv2-C.

La particularité de GTP est qu'il prend en charge la séparation du trafic au sein de son support de tunnel GTP principal, ou en d'autres termes, la capacité de les regrouper et de traiter les transporteurs. Les extrémités des tunnels GTP sont identifiées par des TEID (Tunnel Endpoint identifiers); ils sont affectés au niveau local pour la liaison montante et descendante par des entités homologues et rapportés transversalement entre elles. Les TEID sont utilisés avec une granularité différente par exemple spécifique de connexion PDN sur S5 et S8 et EU sur les interfaces S3 / S4 / S10 / S11.

Plan de contrôle du protocole de tunnel GPRS

GTPv2-C est utilisé sur les interfaces de signalisation EPC (y compris les SGSN d'au moins la version 8). Par exemple -

  • S3 (entre SGSN et MME),
  • S4 (entre SGSN et Serving GW),
  • S5 et S8 (entre Serving GW et PDN GW),
  • S10 (entre deux MME), et
  • S11 (entre MME et Serving GW).

Correspondant à cela, une unité de données de protocole GTPv2-C typique comme le montre la figure ci-dessus, la partie spécifique GTP est précédée d'en-têtes IP et UDP, elle se compose d'un en-tête GTPv2-C et d'une partie contenant des informations GTPv2-C variable en nombre, longueur et format, en fonction du type de message. Comme l'écho et la notification d'une version de protocole ne sont pas pris en charge, les informations TEID ne sont pas présentes. La version est évidemment fermement fixée à 2 dans cette version du protocole.

GTP avait un mécanisme d'en-tête d'extension hérité complexe; il n'est pas utilisé dans la plupart des GTPv2-C. Le type de message est défini dans le deuxième octet (ainsi le maximum de 256 messages peut être défini pour les extensions futures). Le tableau ci-dessous donne un aperçu des messages actuellement définis GTPv2-C. La longueur du message est codée en octets 3 et 4 (mesurée en octets et ne contenant pas les quatre premiers octets eux-mêmes).

TEID est l'ID du point final du tunnel, une valeur unique du côté opposé / récepteur; il permet le multiplexage et le démultiplexage des tunnels à une extrémité dans les cas très fréquents sur un tunnel GTP doit être distingué.

Type de message Message Explication supplémentaire
0 Réservé Ne doit jamais être utilisé (intentionnellement exclu du protocole, pour appliquer un paramètre explicite)
1/2 Demande / réponse d'écho Utilisé pour vérifier si une version GTP prise en charge par le nœud d'envoi.
3 Indication de version non prise en charge Contient la dernière version de GTP prise en charge par le nœud d'envoi.
4/5 Demande / réponse de transfert direct Utilisé pour le message de signalisation de tunnel sur l'interface S101 pour un transfert optimisé, entre l'accès HRPD non et MME
6/7 Demande de notification / réponse Utilisé pour la notification de tunnel sur S101 entre le nœud d'accès HRPD et MME
25/26 Requête SRVCC PS à CS Utilisé pour déclencher et confirmer l'initiation SRVCC entre SGSN / MME et le serveur MSC
27/28 SRVCC PS à CS notification complète Utilisé pour indiquer et confirmer l'achèvement de SRVCC entre le serveur MSC et SGSN / MME
32/33 Créer une demande de session Utilisé pour établir la connectivité entre deux nœuds
34/35 Modifier la demande du porteur Utilisé pour modifier les propriétés d'un seul ou de plusieurs supports, inclure des informations de contexte de support
36/37 Supprimer la demande de session Démarre la session de contrôle GTP
38/39 Demande de notification de modification Utilisé pour signaler les informations de localisation
66/67 Supprimer la commande de support / l'indication d'échec Demandez aux nœuds de supprimer le support et de confirmer à nouveau
68/69 Commande de ressource support / indication d'échec Utilisé pour allouer ou modifier des ressources
73 Indication d'arrêt de la pagination Envoyé de SGW vers le MME ou SGSN
95/96 Créer une demande / réponse de support Demandez aux nœuds d'installer des supports et confirmez
97/98 Mettre à jour la demande de support Utilisé pour informer les nœuds du plan de contrôle à partir du plan utilisateur des changements de support

GTPv1-U amélioré

Seule une amélioration petite mais efficace a été appliquée à GTP-U, et pour cela il n'a pas été jugé nécessaire de renforcer le nombre de versions de protocole. Ainsi, nous attendons toujours GTPv1-U, mais au moins c'est le plus récent Rel. 8.

La pile de protocoles est essentiellement la même que pour GTPv2-C avec uniquement le nom des couches et les protocoles substitués en conséquence. Le mécanisme d'en-tête d'extension est maintenu en place; il permet d'insérer deux éléments si nécessaire.

  • Port source UDP du message de déclenchement (deux octets);

  • PDCP PDU number - lié au transfert de caractéristique sans perte; dans ce cas, les paquets de données doivent être numérotés dans l'EPC (deux octets).

L'amélioration est la capacité à transmettre un «marché final» dans le plan utilisateur. Il est utilisé dans la procédure de transfert inter-eNodeB et donne l'indication que la voie est activée immédiatement après le paquet de données, par exemple, la fonctionnalité n'est pas nécessaire à la pré-Rel.8 car GTP-U ne s'est pas terminé dans l'accès radio nœud (c'est-à-dire pas dans la BS ou NodeB) seuls quelques messages existent. GTPv1-U, et ils sont répertoriés dans le tableau ci-dessus.

Il est clair qu'en fait un type très limité de signalisation est possible via GTPv1-U (mécanismes d'écho et étiquetage d'extrémité). Le seul message que le transfert de données utilisateur réelles est de type 255, le message dit G-PDU; la seule information qu'il transporte, après l'en-tête, est le paquet de données d'origine d'un utilisateur ou d'un équipement PDN externe.

Toutes les instances de tunnels GTP-U ne sont pas répertoriées dans l'architecture de référence (qui visait à capturer les associations qui ne vivaient plus entre les nœuds du réseau); des tunnels temporaires sont possibles -

  • Entre deux GW de desserte, applicable pour le transfert basé sur S1, dans le cas où le service est déplacé GW;

  • Entre deux SGSN, correspond au cas précédent, mais dans l'ancien réseau PS;

  • Entre deux RNC, applicable pour la relocalisation du RNC dans le réseau 3G PS (aucun rapport avec l'EPC, il est mentionné ici juste pour être complet).