GTP-C Proxy : pools de PGW multifournisseurs sans reconfigurer SGW et MME

À propos de la solution

Stingray GTP-C Proxy permet de regrouper des PGW de différents fournisseurs dans des pools communs, de répartir les abonnés selon les règles de l’opérateur et de gérer les pannes sans modifier la configuration des SGW et MME : il suffit de faire pointer une seule fois l’APN vers le proxy dans le DNS.

La solution prend en charge GTPv1 et GTPv2, facilite l’évolution du réseau sans reconfigurer les SGW et MME, et conserve l’état des connexions lors du redémarrage du proxy.

Pourquoi un opérateur a besoin de GTP-C Proxy

Des PGW de différents fournisseurs dans un même réseau

GTP-C Proxy regroupe les passerelles dans des pools communs, gérés par des règles unifiées. La configuration existante des SGW et MME reste inchangée.

Sélection du PGW selon les règles de l'opérateur

Les abonnés sont orientés vers les passerelles appropriées en fonction de l'IMSI, du MSISDN, de l'APN, du PLMN, du type d'accès radio (RAT) et de la localisation de l'abonné (ULI), ainsi que de leurs combinaisons. Les poids des pools et les PGW de secours permettent d'adapter la répartition aux exigences du réseau.

Réaction aux pannes sans basculement manuel

Si un PGW tombe en panne, GTP-C Proxy l'exclut du pool et oriente les nouvelles connexions vers des PGW opérationnels disposant d'une version de GTP compatible. L'état des connexions est conservé dans Redis, y compris lors du redémarrage du proxy lui-même.

Transitions entre 2G/3G et LTE

GTP-C Proxy prend en charge GTPv1 et GTPv2 et assure le changement de version du protocole lorsque l'abonné passe d'une génération de réseau à une autre.

Fonctionnement de Stingray GTP-C Proxy

GTP-C Proxy intervient sur le plan de contrôle GTP-C entre le SGW / SGSN et le PGW. Pour le SGW, le proxy se présente comme un PGW, et pour le PGW, comme un SGW. Le DNS de l’opérateur fait pointer l’APN vers le proxy, qui sélectionne le PGW cible selon les règles configurées et lui transmet la signalisation.

Le trafic abonné GTP-U circule directement entre le SGW et le PGW. GTP-C Proxy n’intervient pas dans le chemin des données utilisateur.

L’opérateur dispose ainsi d’un niveau supplémentaire de contrôle sur la sélection des PGW tout en conservant l’architecture existante du réseau d’accès. Les échanges reposent sur des messages GTP standard.

Demandez une démonstration personnalisée et un test de la solution

Mise à l’échelle

Les performances augmentent avec le nombre de threads

Comment l’infrastructure évolue-t-elle ?

GTP-C Proxy évolue à trois niveaux : threads de traitement sur le serveur, instances du proxy et stockage de l’état. Chaque niveau peut être étendu indépendamment.

Threads de traitement

La signalisation est traitée par plusieurs threads de travail attachés aux cœurs du processeur. Sur un banc d’essai de niveau industriel, les performances de traitement atteignent 348 000 opérations Modify Bearer par seconde sur quatre cœurs.

Instances du proxy

Plusieurs instances de GTP-C Proxy partagent un stockage commun et des règles de routage communes. L’état des sessions est stocké de manière centralisée : la panne d’une instance n’entraîne donc pas de perte de connexions. Le basculement entre instances s’effectue via BGP.

Stockage de l’état

Un seul serveur Redis supporte environ 105 000 Modify Bearer/s. Pour une charge plus élevée, on utilise un cluster Redis avec réplicas et basculement automatique en cas de panne du nœud principal.

Règles sans redémarrage

Les pools de PGW, les poids et les règles de routage sont stockés dans un document unique (fichier YAML ou Redis) et appliqués à toutes les instances à chaud, sans redémarrage ni perte de sessions.

Tolérance aux pannes

2,03 s au maximum (temps de basculement maximal en cas de panne du nœud principal Redis lors d'un test en charge)

Redémarrage du proxy

L'état est stocké dans Redis : les connexions sont donc conservées.

Panne ou redémarrage d'un PGW

Le PGW défaillant est retiré du pool et les nouvelles connexions sont orientées vers des PGW opérationnels disposant d'une version de GTP compatible. Le redémarrage d'un PGW est détecté grâce aux messages Echo.

Redémarrage du SGW

Les sessions sont conservées et restaurées selon la procédure 3GPP TS 23.007 (section 27).

Surcharge

Les abonnés actifs sont servis en priorité ; les nouvelles connexions sont refusées.

Redondance des instances

Basculement entre les instances du proxy via BGP.

Fonctionnalités de Stingray GTP-C Proxy

Protocoles et routage

GTPv2 sur S5/S8 et GTPv1 sur Gn/Gp.
Continuité de session lors des transitions entre 2G/3G et LTE.
Pools de PGW de différents fournisseurs.
Routage et redistribution des nouvelles connexions entre les PGW, remplacement des paramètres de session et rapports de localisation pour S5/S8 et Gn/Gp.
Conservation des connexions lors du redémarrage du SGW conformément à TS 23.007, section 27.

Fiabilité, capacité et gestion

Performances jusqu'à 348 000 opérations Modify Bearer par seconde sur quatre threads.
Gestion de la charge et temporisateur de surveillance (watchdog).
Interface web, Prometheus et Grafana.
Consultation des sessions et configuration des pools Gn/Gp dans l'interface web.
Livraison sous forme de paquets RPM pour VEOS 8.x et EL8.

Console de gestion unique

Interface web

Sessions, historique du document de routage, état des instances et des PGW, rôles d’administrateur et d’observateur.

Prometheus

Métriques sur les messages, les transactions, les pannes, le stockage et les PGW par version de GTP.

Grafana

Tableaux de bord de supervision intégrés avec authentification via l’interface web.

Prérequis de déploiement

Paramètre	Exigences
OS	VEOS 8.x ou EL8, x86_64 ; glibc 2.28, systemd 239
Livraison	Paquets RPM gtpcproxy et gtpcproxy-web. Installation, mise à jour et retour arrière via dnf
Virtualisation	KVM ou VMware. Des vCPU dédiés en correspondance 1:1 avec les cœurs physiques d’un même nœud NUMA sont recommandés
Réseau	Tampon de réception de la signalisation de 8 Mio : CAP_NET_ADMIN ou net.core.rmem_max d’au moins 8 Mio
Redis	Redis doit répondre sans pauses de plus de 250 ms (par exemple lors d’une migration à chaud de VM). Il est recommandé de migrer la machine virtuelle hébergeant Redis pendant une fenêtre de maintenance
CPU et mémoire	Pour 348 000 Modify Bearer/s : 19 cœurs dédiés au total, dont 4 pour le traitement de la signalisation
Conteneur	Podman (rootless)

Demandez une démonstration gratuite de GTP-C Proxy

Nous vous contacterons, préciserons la tâche, ofrirrons accès à la documentation et répondrons à vos questions.

Nous discutons de la situation actuelle: volume de trafic, équipements disponibles, fonctionnalités dont vous avez besoin.

Nos ingénieurs installent le logiciel sélectionné et l‘adapteront à vos tâches spécifiques. Contrat qu‘après la réussite du test.

Nom *

E-mail *

Numéro de téléphone *

Nom de la compagnie *

Commentaires

J'accepte la Déclaration de confidentialité et Contrat de licence de VAS Experts

Solutions associées

GTP-C Proxy

À propos de la solution

Pourquoi un opérateur a besoin de GTP-C Proxy

Des PGW de différents fournisseurs dans un même réseau

Sélection du PGW selon les règles de l'opérateur