Taches
Avant l’introduction des exigences reglementaires en matiere de DPI, l’operateur utilisait des outils internes de gestion du trafic bases sur FreeBSD et des utilitaires Unix standards. Ces solutions couvraient les besoins de base a un stade precoce du developpement du reseau, lorsque l’identification a grande echelle des utilisateurs Wi-Fi et la gestion centralisee des abonnes n’etaient pas encore necessaires.
La situation a change avec l’introduction des exigences de DPI et de filtrage du trafic. L’operateur avait besoin d’une solution evolutive de niveau operateur (carrier-grade). Apres evaluation du marche, la plateforme Stingray de VAS Experts a ete selectionnee.
La cooperation a commence en 2014 et a marque la transition vers une gestion centralisee du reseau.
Deploiement initial de Stingray
Au stade initial, Stingray a ete utilise comme plateforme DPI pour repondre aux exigences reglementaires. Le systeme fournissait egalement la classification du trafic, des analyses et des capacites de protection de base, y compris la protection contre les attaques DDoS.
Initialement, le trafic etait traite sur un noeud DPI dedie, mais au fil du temps l’operateur a progressivement commence a utiliser des capacites supplementaires de la plateforme.
Migration vers un BNG logiciel et integration avec Hydra Billing
L’authentification des abonnes etait initialement mise en oeuvre a l’aide de solutions BNG materiel Cisco utilisant les protocoles de tunnelisation PPTP et L2TP.
A mesure que la base d’abonnes augmentait, cette architecture est devenue un facteur limitant : un seul equipement prenait en charge environ 1 500 sessions, avait un debit limite et ne passait pas bien a l’echelle. En consequence, l’infrastructure ne pouvait plus gerer le nombre croissant de connexions ni l’augmentation du trafic.
Apres l’introduction de la fonctionnalite BNG dans Stingray, l’operateur a progressivement migre l’authentification des abonnes vers la nouvelle architecture, en commencant par des segments reseau individuels puis en l’etendant a l’ensemble du reseau.
L’integration avec le systeme Hydra Billing etait necessaire pour un deploiement complet et a pris environ trois ans. Une logique basee sur API a ete mise en oeuvre pour l’authentification, la comptabilisation des abonnes et la gestion des tarifs. La majeure partie du travail de developpement a ete realisee du cote de l’operateur, apres quoi le systeme a ete mis en production.
En consequence, Stingray est devenu profondement integre au systeme de facturation et est maintenant utilise dans des scenarios cles : authentification IPoE, gestion des tarifs, CG-NAT et identification Wi-Fi.
Utilisation de CG-NAT
CG-NAT est egalement implemente dans Stingray et est utilise pour le traitement du trafic des abonnes. Aux premieres etapes d’exploitation, des limitations de performance sous forte charge necessitaient occasionnellement des redemarrages de service.
Avec la sortie de la version 13, la stabilite du CG-NAT s’est nettement amelioree et aucun probleme operationnel n’a ete observe depuis. Le systeme fonctionne actuellement en mode de production stable.
Priorisation et gestion du trafic
Dans le cadre de l’exploitation de Stingray, l’operateur a utilise des mecanismes de priorisation du trafic. Par exemple, le trafic ICMP a ete affecte a une classe de service distincte, ce qui a reduit les demandes de support des clients entreprises. Des politiques de traffic shaping ont egalement ete appliquees au trafic torrent sur les liaisons montantes.
Lorsque le volume total de trafic a atteint environ 70 Gbit/s, la priorisation sur les liens dorsaux a ete desactivee en raison de l’augmentation de la charge CPU. Toutefois, la priorisation au niveau des abonnes reste utilisee.
Mise a l’echelle et performances
Depuis son deploiement, l’operateur a progressivement fait evoluer la plateforme Stingray, passant d’une configuration de base a une solution de niveau BNG 240. L’architecture est centralisee : tout le trafic des abonnes passe par un seul noeud DPI. La mise a l’echelle est realisee verticalement en augmentant les ressources de calcul du serveur.
Le systeme est deployee sur un serveur AMD avec 128 coeurs, dont jusqu’a 120 sont utilises apres optimisation. La croissance du trafic a ete stimulee a la fois par l’expansion organique des abonnes et par l’acquisition de fournisseurs supplementaires. Des augmentations significatives du trafic ont ete observees pendant les periodes de forte demande de services haut debit fixes.
Les contraintes de l’infrastructure reglementaire sont egalement restees un facteur limitant ; certains goulets d’etranglement ont ete resolus apres la modernisation des equipements.
Dans les versions plus recentes de Stingray (ligne 14.x), l’efficacite du traitement du trafic a ete amelioree, reduisant l’impact des charges de pointe. A l’avenir, l’operateur prevoit l’introduction d’un equilibreur de charge afin de permettre une mise a l’echelle horizontale.
Deploiement du Wi-Fi Hotspot de VAS Experts
Les systemes d’identification Wi-Fi ont commence a etre developpes en 2014. Initialement, une authentification basee sur SMS etait utilisee, mais elle s’est revelee economiquement inefficace en raison du cout eleve des messages.
L’operateur est ensuite passe a une authentification via des appels sortants des utilisateurs. La solution a ete mise en oeuvre a l’aide d’une combinaison de systemes de facturation, d’un serveur web et d’equipements reseau Cisco, et a ete utilisee pendant plusieurs annees. Apres la migration vers Hydra, le systeme d’identification Wi-Fi a necessite une modernisation. Les solutions basees sur le cloud ont ete exclues en raison de la dependance a des services externes et de l’instabilite potentielle dans des conditions de filtrage de trafic reglementaire.
En consequence, un deploiement local base sur Stingray Wi-Fi Hotspot a ete selectionne. Lors de la mise en oeuvre, la logique d’authentification a du etre modifiee : au lieu d’un modele standard base sur des codes, un schema d’appel sortant initie par l’utilisateur a ete utilise.
Une complexite supplementaire est apparue en raison du comportement des portails captifs sous Android et iOS, notamment la gestion du passage a un appel telephonique et le retour de l’utilisateur au navigateur apres authentification.
Au debut du deploiement, plusieurs iterations ont ete necessaires pour adapter le module au nouveau flux de travail. Les taches supplementaires comprenaient la personnalisation de l’interface (branding, logos, elements publicitaires). La plupart des problemes ont ete resolus de maniere iterative en collaboration avec l’equipe de developpement. Bien que la configuration soit effectuee via une interface graphique, celle-ci etait nouvelle pour l’equipe de l’operateur, ce qui a necessite une adaptation des processus internes.
Dans la configuration actuelle, le Wi-Fi Hotspot fonctionne de maniere stable et est utilise en parallele avec le systeme precedent.
Indicateurs actuels du service
- Environ 3 000 nouvelles authentifications sont enregistrees par jour
- Plus de 5 000 connexions Wi-Fi sont enregistrees quotidiennement, dont environ 3 000 sont traitees via Stingray
- L’authentification est conservee sur l’appareil pendant jusqu’a 2 semaines ; par consequent, une re-authentification n’est pas toujours necessaire
- Apres authentification, les utilisateurs peuvent se connecter depuis n’importe quel endroit dans la zone de couverture sans repeter la procedure de connexion
L’operateur considere l’identification Wi-Fi comme un avantage concurrentiel et la propose gratuitement dans le cadre de son offre de services.
Plans de developpement
L’operateur prevoit un developpement ulterieur de l’infrastructure et des fonctionnalites basees sur Stingray. Les principales priorites incluent la mise a l’echelle verticale de la plateforme pour soutenir la croissance continue des abonnes et l’extension des capacites d’authentification IPoE avec une integration plus profonde dans le systeme de facturation.
Une attention particuliere est accordee au developpement du Wi-Fi Hotspot local. Il est important non seulement d’assurer un fonctionnement stable du service, mais aussi de simplifier sa gestion. En particulier, une personnalisation plus flexible du portail captif est requise, avec la possibilite de modifier rapidement le design, d’ajouter des logos et des elements publicitaires, et d’editer les pages HTML sans intervention des developpeurs.
Un autre axe concerne l’extension des capacites analytiques. L’operateur a besoin de rapports sur les connexions a differents points d’acces, tels que les cafes, restaurants et hotels, afin de comprendre combien d’abonnes se connectent a chaque emplacement et comment l’infrastructure Wi-Fi est utilisee.
En outre, les plans incluent l’achevement de la migration de tous les clients Wi-Fi vers la nouvelle plateforme et la poursuite du developpement des outils de gestion du trafic, y compris la priorisation et le controle de nouveaux types de trafic. A l’avenir, l’operateur envisage egalement des modules NetFlow et QoE pour les clients entreprises.
La migration vers la plateforme Stingray nous a permis de faire evoluer le reseau sans goulets d’etranglement, de deployer un Wi-Fi Hotspot stable pour les abonnes et d’ameliorer la gestion du trafic. La solution repond pleinement a nos exigences et nous aide a developper de nouveaux services clients.
