Dans cet article, nous expliquons comment nous avons déployé notre propre banc de laboratoire émulant un réseau d’opérateur mobile, quels composants nous avons utilisés et quels scénarios nous validons dans cette infrastructure.
Pourquoi nous avions besoin de notre propre banc de test
Une vérification complète de l’interaction entre les composants n’est possible que dans des conditions aussi proches que possible de l’exploitation réelle : avec du trafic utilisateur réel, un système de facturation fonctionnel et une interaction complète entre les éléments du réseau.
En pratique, tester de nouvelles fonctionnalités sur l’infrastructure d’un opérateur est presque toujours difficile. L’accès au banc peut être temporaire, les ressources sont souvent occupées par d’autres tâches et l’environnement lui-même n’est pas disponible pour un débogage prolongé et reproductible.
C’est pourquoi nous avons décidé de construire notre propre environnement de laboratoire, qui nous permet de reproduire de façon autonome les scénarios principaux, de tester les intégrations et d’identifier les erreurs avant le déploiement chez le client.
Structure du banc de test
Architecture du cœur de réseau
Le banc est basé sur l’architecture EPC classique avec séparation des plans selon le modèle CUPS (Control and User Plane Separation).
Cette séparation peut être décrite comme « logique et données » : le plan de contrôle détermine quels services sont disponibles pour l’abonné, tandis que le plan utilisateur assure la transmission effective du trafic.
Le cœur est composé de plusieurs composants interconnectés :
| Service | Fonction |
| MME | gère l’enregistrement de l’abonné dans le réseau et les procédures d’attachement |
| HSS | stocke les données des abonnés, y compris les profils SIM et les paramètres de service |
| SGW | transfère le trafic utilisateur entre le réseau radio et le PGW |
| PGW/PCEF | fournit l’accès internet à l’abonné, attribue les adresses IP et applique les règles de tarification |
Schéma d’implémentation selon le concept CUPS
Le plan utilisateur est pris en charge par le DPI de VAS Experts dans le rôle d’UPF (User Plane Function). Dans notre implémentation, le DPI ne se contente pas de transmettre le trafic : il classifie également les applications et les protocoles, enregistre le trafic par catégorie et applique les politiques de l’opérateur en temps réel.
Pour étendre les fonctionnalités du banc, nous avons connecté l’infrastructure de nos partenaires de Media-Tel, qui ont fourni les composants PCRF et OCS.
Intégration avec le système de facturation
La tarification est gérée par les composants du partenaire Media-Tel. Le PCRF gère les politiques de service — tarifs, restrictions, QoS. L’OCS assure la tarification en ligne et la déduction du solde en temps réel.
Notre PCEF communique avec les deux systèmes via le protocole Diameter à travers les interfaces Gx et Gy.

Schéma Call Flow, connexion et déconnexion
Stations de base : émulateur logiciel et équipement industriel
Deux types de stations de base sont utilisés en laboratoire.
srsRAN est un émulateur logiciel fonctionnant sur un serveur standard équipé d’un module SDR. Cette solution open-source permet de déployer un eNodeB complet et de configurer de manière flexible les paramètres radio : bande de fréquence, largeur de canal, puissance du signal et autres caractéristiques. Le principal avantage de srsRAN est sa flexibilité : la possibilité de modifier rapidement les configurations, d’analyser l’interface radio et de tester des scénarios non standard.
La small cell Baicells est une station de base industrielle. Il s’agit d’un équipement opérateur complet avec prise en charge des canaux voix dédiés. Elle est moins flexible à configurer, mais offre des scénarios proches de la production. Nous utilisons Baicells spécifiquement pour tester les appels VoLTE avec dedicated bearers et QCI=1.
IMS, ePDG et support VoWiFi
Un élément distinct du banc est l’ePDG — le composant qui assure le support du VoWiFi. Lors d’une connexion via Wi-Fi, le smartphone établit un tunnel IPSec sécurisé vers l’ePDG, après quoi le trafic est acheminé vers le cœur de réseau de la même manière qu’une connexion LTE.
Du point de vue de l’utilisateur, le VoWiFi est pratiquement indiscernable de la communication mobile ordinaire : le même numéro de téléphone, les services vocaux et la logique de tarification sont conservés. Cependant, pour le réseau, il s’agit d’un type de trafic distinct qui doit traverser correctement le DPI et le PCEF et être traité selon les mêmes règles que les sessions LTE.
Le support de l’ePDG nous a également permis de tester des scénarios de handover entre LTE et Wi-Fi sans interruption de session.
Difficultés lors du déploiement
Pour déployer le banc, nous avons préparé une infrastructure virtuelle, hébergé nos propres composants PCEF, PGW et ePDG, connecté le DPI et intégré le PCRF et l’OCS de Media-Tel. Le résultat est un réseau mobile de test entièrement fonctionnel.
Schéma simplifié du banc de test
La principale difficulté est apparue lors de l’intégration de la facturation. Pour que le PCEF fonctionne correctement avec le PCRF et l’OCS, un grand nombre de paramètres ont dû être configurés en détail :
- formats des identifiants d’abonnés
- encodages MCC/MNC
- paramètres de session
- règles de quotas
Même de légères divergences entraînaient le rejet des requêtes et des erreurs dont le diagnostic nécessitait une connaissance approfondie des spécifications 3GPP et l’analyse des journaux de sessions Diameter.
Une difficulté supplémentaire est apparue avec srsRAN. La solution présente des limitations — notamment l’absence de support des dedicated bearers, sans lesquels un VoLTE complet est impossible.
Pour contourner cette limitation, nous avons adapté le serveur IMS Kamailio : même si le réseau radio ne crée pas de canal dédié, l’appel vocal continue d’être servi via le bearer par défaut. Pour les besoins des tests, cela s’est avéré suffisant.
Scénarios que nous testons
Après le lancement du banc — que nous avons baptisé VAS Expert Mobile Network — la vérification pratique des scénarios de tarification dans le réseau mobile a commencé.
En premier lieu, nous reproduisons les situations qui surviennent le plus fréquemment lors des intégrations chez les opérateurs.
Épuisement du quota
L’un des tests principaux concerne la gestion des quotas de trafic. Un forfait de 100 Mo est attribué à l’abonné, puis nous vérifions comment le DPI comptabilise le trafic, avec quelle précision le PCEF demande un nouveau quota à l’OCS et comment le système réagit à l’épuisement de la limite. Lors du blocage, nous vérifions la liste blanche — le DNS et les services de l’opérateur doivent rester accessibles.
Exemptions de tarification
Les scénarios de forfaits illimités et de priorisation du trafic sont testés séparément : les cas où certaines catégories d’applications — par exemple, les messageries ou les services de navigation — ne consomment pas le forfait principal de l’abonné. Dans ces cas, le DPI identifie le type de trafic et le PCEF décide de le facturer ou non.
Itinérance
Un téléphone se connecte avec un MCC/MNC différent, après quoi toute la chaîne de composants — du HSS à l’OCS — doit traiter correctement cet abonné. Pour émuler ce scénario, un PLMN différent est chargé sur la carte SIM.
Tests voix et vidéo via IMS
Une catégorie distincte de tests concerne les services voix et vidéo. Le banc reproduit le cycle complet du VoLTE — depuis l’enregistrement SIP via l’IMS jusqu’à l’établissement de la session média et la transmission de la voix entre deux abonnés au sein du réseau.
Commutation entre LTE et Wi-Fi
Un scénario mixte supplémentaire est testé à l’aide de l’ePDG : un abonné est connecté via LTE, l’autre via Wi-Fi, et les deux appareils sont enregistrés dans le même réseau IMS. L’appel doit se dérouler normalement et le flux média doit être transmis sans restriction.
Après la commutation d’un abonné du Wi-Fi vers le LTE, le handover doit s’effectuer sans interruption de session. Pour les services voix et vidéo, ces scénarios sont particulièrement importants, car même une brève interruption de connexion affecte la qualité de la communication.

Résultats du projet
Le banc déployé nous a permis d’améliorer la qualité des tests et d’accélérer le développement des produits mobiles.
Aujourd’hui, le laboratoire est utilisé pour vérifier de nouvelles fonctionnalités, tester des scénarios d’intégration, reproduire des situations réseau complexes et présenter des solutions aux clients.
Dans le cadre de ce projet, nous avons déjà testé avec succès l’interaction de nos solutions avec les plateformes de facturation de Media-Tel, Bercut et FORWARD, et nous avons obtenu un environnement indépendant et complet pour le développement et le débogage continus des produits du cœur mobile.