Wi-Fi HotSpot dans un réseau opérateur : de la solution isolée à l'intégration dans le BNG

Qu’est-ce qu’un Wi-Fi HotSpot et pourquoi un opérateur en a-t-il besoin ?

Un Wi-Fi HotSpot dans un réseau opérateur est un mécanisme permettant de fournir un accès public à internet avec gestion des sessions utilisateur. Contrairement au Wi-Fi domestique — où un appareil reçoit une adresse IP et commence immédiatement à transmettre du trafic — une couche de traitement supplémentaire apparaît ici, liée à l’identification de l’abonné et au contrôle de son état.

Cette couche n’affecte pas la connexion elle-même, mais détermine la manière dont le trafic est ensuite traité. L’opérateur doit savoir qui accède au réseau, dans quel état se trouve l’utilisateur et quelles restrictions lui sont appliquées.

Lorsqu’un appareil se connecte au réseau, il reçoit d’abord une adresse IP ; toute tentative d’ouvrir un site web est alors interceptée. L’utilisateur est redirigé vers un Captive Portal, effectue l’autorisation, et ce n’est qu’ensuite que les restrictions sont levées.

Architecture pour l’autorisation Wi-Fi via Captive Portal

La gestion de l’autorisation est du ressort du DPI. C’est lui qui est responsable de la redirection, qui enregistre l’état de l’abonné et qui bascule le mode de traitement du trafic.

Scénario HotSpot isolé

Composants de l’architecture d’un HotSpot

Du point de vue de l’architecture, un HotSpot peut être mis en œuvre de deux façons. Dans un cas, il est déployé comme solution autonome ; dans l’autre, il devient partie intégrante d’un BNG. La différence entre les deux ne réside pas dans la mécanique d’autorisation au niveau du DPI, mais dans la façon dont le système est intégré aux autres composants.

Dans le premier scénario, le HotSpot est déployé comme un environnement séparé avec sa propre infrastructure. Il comprend :

• Un serveur DHCP qui attribue des adresses IP ;
• Le DPI, qui gère les accès ;
• Un portail web Captive Portal pour l’autorisation.

L’abonné parcourt l’intégralité du processus à l’intérieur de ce schéma : il se connecte au Wi-Fi, obtient une adresse, effectue sa première requête et, au lieu de la ressource demandée, arrive sur la page d’autorisation. Après confirmation de son identité, le DPI lève les restrictions et l’utilisateur obtient l’accès à internet.

Architecture du scénario HotSpot isolé

Ce modèle est utilisé lorsqu’il faut lancer un service rapidement ou résoudre une tâche locale sans modifier l’infrastructure existante.

Cependant, dans un tel système, l’utilisateur ayant complété l’autorisation reste à l’intérieur de l’environnement, de sorte que tout changement lié aux tarifs ou aux politiques doit être mis en œuvre séparément.

Cas d’usage : HotSpot sur un site public

Cette approche est souvent choisie pour des sites indépendants où il est important d’organiser rapidement l’accès. Par exemple, un opérateur de télécommunications a déployé un Wi-Fi public sur le territoire d’un grand espace en plein air. Il s’agissait d’une zone distribuée avec un grand nombre de points d’accès et une forte densité de connexions. Les utilisateurs se déplaçaient entre les points d’accès et se connectaient depuis différents appareils, tandis que l’ensemble du schéma restait isolé.

Dans cette tâche, le HotSpot a été déployé comme un environnement séparé. Tout le trafic des abonnés passait par le DPI, où les restrictions initiales étaient définies et où les utilisateurs étaient redirigés vers la page d’autorisation. Après confirmation de l’identité, les restrictions étaient levées et l’utilisateur accédait à internet.

En termes de méthodes d’autorisation, le système ne se limitait pas à une seule option. Outre le parcours classique par SMS, d’autres mécanismes étaient utilisés : par appel entrant ou sortant, par bons de connexion (vouchers), via des systèmes externes et des API, ainsi que via des comptes utilisateurs — par exemple, des comptes d’entreprise ou intégrés à d’autres services. Dans certains cas, l’utilisateur se voyait proposer un choix de méthode d’autorisation directement sur la page du portail.

Le HotSpot dans le modèle abonné

Fonctionnement d’un Wi-Fi HotSpot au sein d’un BNG

Dans le deuxième scénario, le HotSpot n’est pas séparé en un système autonome. Il est intégré dans le BNG — le point par lequel transite le trafic des abonnés. La connexion de l’utilisateur commence toujours par le Captive Portal. Mais après l’autorisation, l’utilisateur est traité de la même façon que n’importe quel autre abonné du réseau. Sa session est enregistrée, et les tarifs, restrictions et politiques gérés depuis un système de facturation centralisé lui sont appliqués.

Architecture du scénario HotSpot au sein du BNG

Le BNG dans ce schéma est responsable de la gestion des sessions : il vérifie les accès, applique les règles et interagit avec la facturation. Le DPI dans ce schéma continue de gérer le trafic — permettant l’identification des applications et la gestion au niveau des flux.

En conséquence, le HotSpot devient l’un des modes de connexion d’un abonné — au même titre que l’accès domestique ou un segment d’entreprise. Cela simplifie la gestion : les règles sont définies en un seul endroit et s’appliquent à tous les abonnés, y compris les utilisateurs Wi-Fi.

Vous trouverez plus de détails sur la mécanique du Captive Portal dans la documentation.

Cas d’usage : Migration du HotSpot dans le BNG

En pratique, ces scénarios existent rarement comme options totalement indépendantes. Le plus souvent, l’un devient le prolongement de l’autre au fur et à mesure de l’évolution du réseau. La solution isolée est d’abord utilisée, ce qui permet de lancer le service rapidement sans modifier l’infrastructure. Au fil du temps, des exigences en matière de comptabilisation des abonnés, de gestion des tarifs et de contrôle centralisé apparaissent, et c’est à ce moment-là que la logique du HotSpot est transférée dans le BNG.

Dans le cas d’un client de VAS Experts, cette transition a pris plusieurs années et était liée non seulement au développement du Wi-Fi, mais aussi à la croissance de l’ensemble du réseau. Dans les premières étapes, des solutions disparates étaient utilisées, qui finissaient par ne plus pouvoir faire face à l’augmentation de la charge. Les limites se manifestaient dans le nombre de sessions, les performances et la complexité de la gestion.

Migration vers Stingray BNG logiciel et intégration avec la facturation Hydra

Au départ, le Wi-Fi HotSpot existait comme un service séparé. À mesure que le réseau de l’opérateur s’est développé, la décision a été prise de l’intégrer dans le BNG afin de le gérer dans le cadre du modèle abonné commun. Cela a nécessité une intégration avec la facturation et une refonte du mécanisme d’autorisation.

Avec l’introduction de la plateforme Stingray, le DPI a d’abord été ajouté comme élément autonome chargé de l’analyse et du filtrage du trafic. L’opérateur a ensuite initié l’utilisation complète de Stingray en tant que BNG et mis en place une autorisation basée sur RADIUS avec la facturation Hydra. Cette étape a pris un temps considérable : la logique d’interaction a dû être implémentée via une API, combinant autorisation, comptabilisation et règles tarifaires dans un seul système.

Flux d’authentification de l’utilisateur dans le système de contrôle d’accès
En parallèle, le mécanisme d’identification Wi-Fi lui-même a été revu. Initialement, l’autorisation par SMS était utilisée, mais à mesure que le coût des messages augmentait, elle devenait économiquement non viable. L’opérateur est donc passé à un schéma basé sur un appel sortant de l’abonné.

Le point d’interaction avec l’utilisateur est resté au sein du Captive Portal de VAS Experts. Le portail prend en charge différents scénarios d’autorisation — du SMS et des appels aux systèmes externes et aux API — et est configuré selon le modèle d’exploitation spécifique de l’opérateur. L’interface est également personnalisée pour le client : l’opérateur peut adapter la page d’autorisation à sa propre marque, ajouter des logos, des éléments publicitaires et modifier les parcours utilisateurs.

Le HotSpot est devenu partie intégrante de l’architecture globale. L’autorisation est restée identique — via le Captive Portal —, mais désormais la session de l’utilisateur est traitée dans le cadre du modèle commun, en tenant compte des tarifs, des règles d’accès et de l’état de l’abonné.

Comment les opérations réseau ont évolué

En 2025, l’opérateur a achevé la migration du Wi-Fi HotSpot dans le BNG. Le système traite désormais des milliers de connexions par jour : environ 3 000 nouvelles autorisations et plus de 5 000 connexions Wi-Fi quotidiennes, dont une part significative passe par Stingray. L’autorisation est conservée sur l’appareil jusqu’à deux semaines, de sorte que les utilisateurs peuvent se déplacer entre les points d’accès sans se réauthentifier.

HotSpot isolé vs. HotSpot dans le BNG
Le fonctionnement sous charge a également évolué. Auparavant, le HotSpot autonome gérait une partie de la logique de façon indépendante ; désormais, l’ensemble du trafic passe par un point unique où les mécanismes de gestion sont déjà configurés. Cela rend le comportement du réseau plus prévisible à mesure que le nombre de connexions augmente.

Le traitement des sessions est devenu centralisé. La logique d’autorisation, de tarification et de gestion des accès n’est plus dupliquée entre les systèmes, mais fonctionne dans un environnement unique. Cela a simplifié les modifications : les nouvelles règles s’appliquent immédiatement à tous les abonnés, y compris les utilisateurs Wi-Fi.

En outre, le HotSpot n’est plus une source de données isolée. Les informations sur les connexions sont utilisées conjointement avec le reste des statistiques du réseau, ce qui offre une vision plus complète de la charge et du comportement des abonnés.