Comment construire un système UDR pour 300 Gbit/s de trafic : cas d’un opérateur de la région Asie-Pacifique

August 24, 2026
4.9 sur 5
Comment construire un système UDR pour 300 Gbit/s de trafic : cas d’un opérateur de la région Asie-Pacifique
Un grand opérateur de télécommunications de la région Asie-Pacifique recherchait une solution pour générer des User Detail Records (UDR) à partir de l’analyse du trafic des abonnés. La solution devait collecter les données des sessions utilisateurs à partir du trafic mobile HTTP et HTTPS, les associer aux informations sur les abonnés et transmettre les enregistrements générés aux systèmes internes de l’opérateur.

Le projet a été mis en œuvre par VAS Experts avec un intégrateur local. VAS Experts a développé la partie logicielle de la solution et fourni une assistance technique experte, tandis que le partenaire a déployé la solution sur l’infrastructure du client.

Objectifs du projet

L’opérateur utilisait auparavant une solution Sandvine pour traiter les données du trafic utilisateur. Après l’arrêt du support de cette solution et en l’absence de possibilité d’en étendre les fonctionnalités, l’opérateur avait besoin de son propre système de génération d’UDR, capable de fonctionner avec l’infrastructure réseau existante et de préparer automatiquement les enregistrements destinés aux systèmes internes.

Génération automatique des UDR

La principale tâche consistait à collecter automatiquement les données des sessions utilisateurs à partir du trafic HTTP et HTTPS et à générer des fichiers UDR distincts toutes les 15 minutes. Les fichiers générés devaient être transférés vers l’infrastructure interne de l’opérateur. Pour obtenir les données des abonnés, le système devait également traiter les informations RADIUS Accounting provenant du PGW.

Jusqu’à 300 Gbit/s de trafic et 3 millions d’abonnés

Le système devait traiter le trafic mobile provenant de deux sites, pour un volume total pouvant atteindre 300 Gbit/s et 3 000 000 d’abonnés. Cela nécessitait la prise en charge d’interfaces Ethernet 100G et la répartition du traitement entre plusieurs nœuds DPI. L’opérateur devait également pouvoir augmenter la capacité de traitement à mesure que le trafic augmentait, sans devoir repenser l’ensemble du système.

Fonctionnement continu

Outre les exigences fonctionnelles, une attention particulière a été accordée à la fiabilité et à la conservation des données. L’architecture devait rester opérationnelle en cas de défaillance de composants individuels, tandis que les UDR générés devaient être conservés pendant 90 jours.

Solution

Le projet comprenait une licence prenant en charge le traitement bidirectionnel du trafic et l’exportation des statistiques via IPFIX.

Une licence adaptée à l’échelle du projet
D’une configuration de base à une plateforme DPI haute performance, choisissez le niveau de licence adapté et faites-le évoluer au fur et à mesure de la croissance du réseau. En savoir plus sur les options de licence Stingray

La partie matérielle de la solution reposait sur la plateforme serveur ITPOD et comprenait deux nœuds DPI et deux serveurs QoE. Quatre interfaces 100G étaient utilisées sur chaque nœud DPI pour connecter le trafic.

La solution a été déployée sur des serveurs x86 standard.

Interaction réseau entre les sites
Figure 1 — Schéma de l’interaction réseau entre les sites

Du trafic miroir aux données de session

Le trafic miroir provenant de deux centres de données était envoyé vers la plateforme DPI, où les flux bidirectionnels L2–L7 étaient reconstruits et agrégés en enregistrements de session unifiés. Afin d’associer l’activité réseau à un abonné spécifique sans modifier l’infrastructure AAA existante de l’opérateur, une intégration avec RADIUS Accounting a été mise en place. Le DPI génère un identifiant de session à partir de l’adresse IP, tandis que le système AAA fournit le compte d’abonné correspondant. La plateforme met ces données en correspondance et conserve l’association entre la session réseau et l’abonné même lorsque l’adresse IP change.

Enrichissement des données des sessions utilisateurs

La correspondance obtenue est utilisée pour enrichir les données relatives à l’activité réseau.

Les données RADIUS et fullflow sont mises en correspondance à l’aide du MSISDN (Mobile Station International Subscriber Directory Number), qui sert de clé de correspondance. Il permet d’ajouter aux données de la session réseau les informations du compte ainsi que d’autres attributs de l’abonné mobile.

Les informations sur l’abonné sont ajoutées aux données agrégées fullflow et clickstream, qui contiennent les paramètres des sessions utilisateurs et des événements réseau.

Cela permet de créer un contexte unifié dans lequel les données techniques de la session sont associées à un abonné spécifique. Les données déjà agrégées peuvent ainsi être utilisées pour générer les UDR sans avoir à analyser de nouveau les paquets réseau individuels.

Génération des UDR à partir des données AAA, FullFlow et Clickstream

Figure 2 — Génération des UDR à partir des données AAA, FullFlow et Clickstream

Pourquoi des structures distinctes et un filtrage étaient nécessaires

L’étape suivante consistait à générer les UDR à partir des données enrichies fullflow et clickstream.

Comme les UDR ne nécessitent qu’une partie des informations collectées, l’architecture comprend une couche de normalisation et de filtrage. Des structures distinctes pour la génération des UDR ont été créées à partir des données fullflow et clickstream, ainsi que des règles permettant de sélectionner les champs nécessaires. Cela a permis de limiter l’enregistrement final aux paramètres requis par l’opérateur et d’exclure les données superflues lors de la préparation.

Le système est ainsi devenu plus facile à gérer en termes de composition des UDR et peut évoluer en fonction des changements de besoins.

Génération des UDR et évolutivité du système

Les données générées et filtrées sont agrégées dans des fichiers UDR texte toutes les 15 minutes, avec un traitement distinct du trafic HTTP et HTTPS. Les fichiers sont ensuite automatiquement transférés vers l’infrastructure de l’opérateur.

Deux nœuds DPI actifs sont utilisés pour assurer la fiabilité du système, tandis qu’un ensemble de pièces de rechange et d’équipements est prévu pour permettre une reprise rapide.

La solution peut être mise à l’échelle progressivement : dans un premier temps, les performances de l’infrastructure existante sont augmentées, puis, lorsque sa capacité est atteinte, de nouveaux nœuds DPI peuvent être ajoutés.

Résultats

À l’issue du déploiement, l’opérateur dispose d’un système de génération de User Detail Records qui répond pleinement aux exigences de performance et d’intégration.

La solution permet :

  • d’analyser jusqu’à 300 Gbit/s de trafic mobile HTTP et HTTPS ;
  • de générer automatiquement des UDR distincts pour HTTP et HTTPS toutes les 15 minutes ;
  • d’associer les sessions utilisateurs aux données RADIUS Accounting ;
  • de prendre en charge les interfaces Ethernet 100G ;
  • de disposer d’une architecture tolérante aux pannes avec redondance des composants clés ;
  • de poursuivre la mise à l’échelle sans modifier l’architecture globale du système.

Le système a passé avec succès les tests d’acceptation utilisateur (UAT), a été mis en production et transféré au support technique.

Retour du client

Il était important pour nous de remplacer la solution précédente par notre propre système de génération d’UDR, capable de gérer de grands volumes de trafic mobile. Nous souhaitons également souligner la collaboration avec l’équipe de VAS Experts et le partenaire local. Les spécialistes ont pris en compte nos exigences, nous ont aidés à réaliser les tests UAT et à mettre le système en production.

Nous disposons désormais d’un outil clair et facile à gérer pour travailler avec les UDR, qui nous permet de continuer à faire évoluer le système sans dépendre de la solution précédente.