Séparer le plan de contrôle et le plan utilisateur permet de répartir ces fonctions sur des nœuds différents et de les dimensionner indépendamment. Mais la séparation à elle seule ne rend pas le service continu : elle crée seulement une architecture dans laquelle la continuité peut être assurée.
Pour cela, le nœud de transport de données doit devenir remplaçable, et son remplacement doit être une opération pilotée qui n’interrompt pas les sessions actives. Cette approche architecturale s’appelle CUPS. Voyons pourquoi la séparation des plans ne garantit pas à elle seule la continuité des sessions, dans quelles situations cette continuité peut se rompre, comment fonctionne un transfert de session piloté, et où cette approche trouve ses limites.
De quoi se compose la passerelle de service
Au sein de la passerelle de service, on distingue trois entités : les données d’état de l’abonné, la logique de traitement du trafic, et l’interface qui les relie.
Le plan de contrôle sait qui est l’abonné et à quoi il a droit. C’est une couche où les changements sont peu fréquents, mais d’une importance critique.
Le plan utilisateur, lui, ne reçoit qu’une certaine information par session, mais sait ce qui se passe au niveau des paquets. Il classe le trafic selon le service concerné, applique des règles déjà définies et tient des compteurs de consommation pour chaque service. C’est une couche à haute performance, optimisée pour le débit et non pour la conservation de connaissances.
Entre les deux subsiste une interface étroite et explicite : le plan de contrôle envoie des commandes vers le bas, et le plan utilisateur renvoie des rapports d’état et de consommation.
C’est précisément parce que l’interface est étroite qu’un nœud du plan utilisateur devient remplaçable. Il ne stocke rien de permanent, seulement ce qui peut être reconstitué par une commande venue d’en haut. Si ce nœud tombe en panne, brûle, est redémarré ou remplacé par un nouveau, le plan de contrôle renvoie simplement les mêmes commandes, et tout est restauré.
Figure 1 — Entités du plan de contrôle et du plan utilisateur
Où la continuité peut se rompre
Pouvoir changer les nœuds indépendamment ne garantit pas encore que l’abonné ne remarquera pas le remplacement. Un nœud de transport de données doit être retiré du service non seulement en cas de panne, mais aussi de manière planifiée : pour des travaux de maintenance ou une mise à jour.
La différence entre ces deux cas est fondamentale. Pendant des travaux techniques, le nœud continue de fonctionner, il y a donc le temps de préparer d’abord un remplaçant, puis seulement ensuite de déconnecter la source. En cas de panne, ce temps n’existe pas. Le nœud cesse de répondre avant que le réseau ait pu préparer le transfert des sessions. Une partie de l’état est perdue, et il n’est alors plus possible d’exclure totalement une coupure.
D’où une règle simple mais essentielle : tant que le nœud est encore disponible, il faut transférer la session vers le nouveau avant de déconnecter l’ancien. C’est exactement sur cette règle que repose le transfert piloté.
Transfert piloté : d’abord connecter, ensuite déconnecter
Ce principe est connu dans d’autres domaines sous le nom de « make before break » (connecter avant de rompre). Le nouveau nœud est d’abord préparé pour prendre en charge la session, puis le trafic y est basculé, et ce n’est qu’ensuite que l’ancien nœud est déconnecté. C’est là que se révèle le sens de la séparation des plans : le plan de contrôle gère entièrement le transfert de la session, tandis que les nœuds du plan utilisateur ne font qu’exécuter ses commandes.
L’état de l’abonné est stocké dans le plan de contrôle. C’est pourquoi il peut le recréer sur un autre nœud, en transmettant le profil, les règles et les services autorisés. Le nouveau nœud ne reçoit pas l’état directement de l’ancien : les nœuds du plan utilisateur n’interagissent pas entre eux.
Il est important de noter que la session n’est pas simplement « basculée » d’un nœud à un autre. Elle est transférée comme une opération séquentielle, par étapes, avec un point de non-retour. Tant que la séquence n’est pas achevée, le système conserve toujours un nœud prêt à prendre en charge la session. C’est pourquoi un remplacement planifié ne devrait pas entraîner de coupure de connexion.
Figure 2 — Schéma du transfert piloté de session
Et la facturation ?
La continuité du transfert de données ne signifie pas à elle seule la continuité de la comptabilisation. L’abonné peut ne pas remarquer le changement de nœud, mais si un écart apparaît ensuite dans la facturation, le problème n’est résolu qu’à moitié. C’est pourquoi, lors du transfert, il faut préserver non seulement l’état du service, mais aussi les informations de consommation.
On utilise ici les rapports des deux nœuds. Le nouveau nœud reçoit un seuil : le volume de trafic qu’il reste encore permis à l’abonné de consommer. Ce seuil correspond au reliquat du quota connu. Avant de se déconnecter, l’ancien nœud envoie au plan de contrôle un rapport final sur le volume réellement consommé. Le plan de contrôle additionne ces valeurs et établit sur le nouveau nœud un seuil déjà absolu.
Il est important que le volume ne soit pas reconstitué à partir des seuils eux-mêmes. Il est tiré des rapports de consommation réelle. Cela permet d’éviter deux problèmes :
- la perte d’une partie du volume consommé ;
- le double comptage d’un même volume.
Il en découle une autre conséquence : il n’est pas nécessaire de clôturer une session de facturation active simplement parce que le nœud a été remplacé. L’abonné a continué d’utiliser le service, et le volume consommé est connu avec précision. Il n’y a donc aucune raison d’envoyer à la facturation un message de coupure.
Avec 20 millions d’abonnés et cinq nœuds de transport de données, cela devient particulièrement visible. Si un nœud était retiré en fermant les sessions de force, jusqu’à 16 millions de messages pourraient être envoyés vers la facturation. Avec le transfert piloté, ces messages n’apparaissent pas.
Où s’arrête la continuité
Tout mécanisme a des limites d’applicabilité. Une architecture ne doit pas seulement montrer ce qu’elle sait préserver, mais aussi indiquer honnêtement ce qui ne peut pas l’être.
Traduction d’adresses NAT
Notons que le User Plane du PCEF ne dispose pas seulement de la fonction DPI, mais assure aussi le NAT (CG-NAT, NAT64, NAT 1:1).
La traduction d’adresses CG-NAT est un mécanisme dans lequel l’appareil de l’abonné reçoit une adresse IP privée à l’intérieur du réseau de l’opérateur, tandis qu’il sort vers l’extérieur sous une autre adresse, publique. Cela résout le problème de pénurie d’adresses et améliore la sécurité. Mais la correspondance entre l’adresse interne et l’adresse externe est stockée dans la mémoire d’un nœud précis. Si la session est transférée vers un autre nœud, l’adresse publique et le port des connexions déjà établies changeront. Pour ces connexions, cela équivaut à une coupure.
C’est pourquoi ces connexions ne peuvent pas être transférées de façon transparente. On utilise pour elles une interruption naturelle des sessions en cours, avec établissement de nouvelles sessions de trafic : un retrait planifié du nœud implique de faire basculer le trafic d’une adresse privée vers un autre User Plane disposant d’un pool différent d’adresses IP publiques.
Il existe aussi une autre approche : la synchronisation des connexions entre NAT. Dans ce cas, la table de traductions NAT est synchronisée entre plusieurs nœuds. Mais il s’agit alors d’une décision architecturale à part entière, qui influence également le plan d’adressage. On ne peut donc pas la considérer simplement comme un paramètre qui supprimerait automatiquement la limitation.
Répartition du trafic entre plusieurs UP
Le trafic des sessions est bidirectionnel : de l’abonné vers le serveur, et retour. Les sens aller et retour sont équilibrés par des mécanismes différents.
Le trafic sortant est réparti au moyen d’un répartiteur de charge L3, sur la base de l’IPsrc et de l’IMSI. Le trafic entrant est attiré par le User Plane lui-même (DPI+NAT) via des annonces BGP.
Panne d’un nœud
En cas de panne du User Plane, il n’y a pas de transfert piloté : le DPI cesse tout simplement de répondre. Dans ce cas, une partie du volume consommé peut ne pas figurer dans le rapport final. Mais même ici, l’ampleur de la perte possible peut être limitée à l’avance. Elle est déterminée par la somme des seuils fixés sur le nœud. Le plan de contrôle peut fractionner les quotas qu’il délivre, en fixant des seuils de rapport plus petits et en collectant lui-même les données intermédiaires. La facturation reçoit néanmoins la valeur d’origine du quota, une fois que le volume accumulé atteint la valeur nécessaire.
Un budget de risque piloté apparaît ainsi. L’opérateur définit à l’avance quel volume il est acceptable de perdre en cas de panne d’un nœud. La fréquence des rapports des nœuds est déterminée par ce budget, tandis que la fréquence de transmission des informations à la facturation est déterminée par la taille du quota. L’échange avec la facturation lui-même ne devient pas plus fréquent pour autant.
Comment vérifier la continuité
La continuité de service ne peut pas être prouvée par le simple fait que le système n’ait pas envoyé de message d’erreur. Elle doit être mesurée pendant un transfert réel.
Le test ne doit être réalisé que si un trafic réel transite par la session active au moment du transfert. Si une coupure apparaît dans le flux, la continuité n’est pas assurée, quelle que soit la précision avec laquelle le système a journalisé le basculement lui-même. Le test de recette doit donc vérifier le transfert de données lui-même, et non la correction des messages de signalisation.
Ce qu’apporte finalement la séparation des plans
La valeur du CUPS ne se limite pas au dimensionnement indépendant du contrôle et du transfert de données. Ce qui compte bien davantage, c’est que le plan utilisateur devienne remplaçable. Et lorsqu’un nœud peut être remplacé, il devient possible de transformer son retrait, d’un événement de panne, en une opération pilotée.
Pour les travaux planifiés, cela se traduit par une séquence claire : préparer le nouveau nœud, y transférer les sessions, déconnecter l’ancien, et faire correspondre les compteurs. Pour les pannes, il reste un autre mécanisme : un budget de pertes acceptables défini à l’avance.
C’est précisément ici que naît la continuité de service. La séparation permet de piloter l’état des sessions pendant les évolutions de l’infrastructure. La promesse « travaux planifiés sans impact sur les abonnés » cesse alors d’être une formule générale et devient une procédure concrète, avec un résultat mesurable et des exceptions clairement énoncées.
