{"id":14891,"date":"2026-10-05T09:00:38","date_gmt":"2026-10-05T06:00:38","guid":{"rendered":"https:\/\/vasexperts.com\/?p=14891"},"modified":"2026-10-02T21:09:07","modified_gmt":"2026-10-02T18:09:07","slug":"scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers","status":"publish","type":"post","link":"https:\/\/vasexperts.com\/fr\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/","title":{"rendered":"Mise \u00e0 l\u2019\u00e9chelle dans une architecture CUPS : comment augmenter la capacit\u00e9 sans perturber les abonn\u00e9s"},"content":{"rendered":"<h2>Architecture du cluster : Control Plane et User Plane<\/h2>\r\nAu sein du cluster, les composants sont r\u00e9partis entre le Control Plane et le User Plane.\r\n\r\nLe User Plane assure les fonctions de traitement du trafic : r\u00e9ception, traitement et transmission du trafic des abonn\u00e9s.\r\n\r\n[product id=\u00a0\u00bb19\u2033 type=\u00a0\u00bbdark\u00a0\u00bb]\r\n\r\nL\u2019une des fonctions cl\u00e9s du User Plane est le DPI, un syst\u00e8me de classification du trafic par sessions et applications. Les n\u0153uds DPI re\u00e7oivent les paquets, traitent les connexions, appliquent les politiques n\u00e9cessaires et collectent les statistiques de consommation des abonn\u00e9s. Ce sont ces n\u0153uds qui sont ajout\u00e9s lorsque la capacit\u00e9 doit \u00eatre augment\u00e9e ou retir\u00e9s du service pour maintenance.\r\n\r\n<a href=\"\/wp-content\/uploads\/2026\/10\/cluster-architecture.svg\"><noscript><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/cluster-architecture.svg\" alt=\"Architecture du cluster de VAS Experts avec Control Plane et User Plane\" width=\"806\" height=\"305\" class=\"alignnone size-full wp-image-14892\"><\/noscript><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/cluster-architecture.svg\" alt=\"Architecture du cluster de VAS Experts avec Control Plane et User Plane\" width=\"806\" height=\"305\" class=\"alignnone size-full wp-image-14892 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/cluster-architecture.svg\"><\/a>\r\n\r\nFigure 1 \u2014 Architecture du cluster\r\n\r\nLe Control Plane stocke l\u2019\u00e9tat des sessions des abonn\u00e9s et attribue le User Plane. En fonction du nombre de n\u0153uds actifs, il d\u00e9termine quel n\u0153ud dessert un abonn\u00e9 donn\u00e9, quels param\u00e8tres et services lui sont associ\u00e9s et effectue la migration de la session lorsque cette affectation change.\r\n<h2>Le principe fondamental dont tout d\u00e9coule<\/h2>\r\nCommen\u00e7ons non pas par la mise \u00e0 l\u2019\u00e9chelle elle-m\u00eame, mais par la contrainte qui la rend plus complexe.\r\n\r\nLa classification du trafic et la comptabilisation par service exigent que <strong>les deux directions d\u2019une connexion soient trait\u00e9es par le m\u00eame n\u0153ud DPI (User Plane)<\/strong>.\r\n\r\nDe plus, l\u2019unit\u00e9 de service n\u2019est pas une <a href=\"\/fr\/resources\/glossary\/ip-address\/\">adresse IP<\/a> individuelle, ni m\u00eame une seule connexion. Un abonn\u00e9 peut utiliser plusieurs services simultan\u00e9ment, avoir plusieurs connexions, utiliser <a href=\"\/fr\/resources\/glossary\/ipv4\/\">IPv4<\/a> et <a href=\"\/fr\/resources\/glossary\/ipv6\/\">IPv6<\/a> ou partager l\u2019acc\u00e8s \u00e0 Internet avec d\u2019autres appareils. Ainsi, un m\u00eame abonn\u00e9 peut avoir plusieurs connexions et adresses, mais du point de vue du service, elles appartiennent toutes \u00e0 une seule session de service. Cette session devient l\u2019unit\u00e9 de mise \u00e0 l\u2019\u00e9chelle : toutes les connexions associ\u00e9es \u00e0 l\u2019abonn\u00e9 doivent \u00eatre trait\u00e9es ensemble par le m\u00eame n\u0153ud de traitement du trafic et le m\u00eame n\u0153ud de contr\u00f4le.\r\n<div class=\"note\">\r\n\r\n[important]Cela conduit \u00e0 la r\u00e8gle principale\r\n\r\nL\u2019unit\u00e9 de mise \u00e0 l\u2019\u00e9chelle n\u2019est ni un flux, ni une adresse, ni une connexion individuelle, mais la session de service elle-m\u00eame avec tous ses param\u00e8tres : connexions, adresses IPv4 et IPv6, offre tarifaire, quota et donn\u00e9es de comptabilisation. Il s\u2019agit de l\u2019unit\u00e9 de distribution, qui ne peut pas \u00eatre r\u00e9partie entre plusieurs n\u0153uds.[\/important]\r\n\r\n<a href=\"\/wp-content\/uploads\/2026\/10\/diagram_en.svg\"><noscript><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/diagram_en.svg\" alt=\"Diagramme d\u2019une session de service\" width=\"355\" height=\"356\" class=\"alignnone size-full wp-image-14893\"><\/noscript><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/diagram_en.svg\" alt=\"Diagramme d\u2019une session de service\" width=\"355\" height=\"356\" class=\"alignnone size-full wp-image-14893 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/diagram_en.svg\"><\/a>\r\n\r\n<\/div>\r\nFigure 2 \u2014 Session de service : toutes les connexions et adresses d\u2019un abonn\u00e9 constituent une seule unit\u00e9 de service\r\n\r\nSi les paquets appartenant \u00e0 la m\u00eame <a href=\"\/fr\/resources\/glossary\/tcp\/\">connexion TCP<\/a> arrivent sur des n\u0153uds diff\u00e9rents, cela peut entra\u00eener une interruption de la connexion, la perte du contexte de classification et la r\u00e9partition d\u2019une m\u00eame session entre plusieurs n\u0153uds pour la comptabilisation du trafic.\r\n\r\nC\u2019est particuli\u00e8rement visible dans le cas du <a href=\"\/fr\/resources\/glossary\/nat\/\">NAT<\/a>. Si la traduction d\u2019adresse et de port est stock\u00e9e sur l\u2019ancien n\u0153ud alors que le paquet suivant arrive sur un nouveau n\u0153ud, ce dernier ne trouvera pas l\u2019entr\u00e9e correspondante et le trafic sera abandonn\u00e9. Pour une connexion \u00e9tablie, cela entra\u00eene une interruption.\r\n<h2>Deux m\u00e9thodes pour r\u00e9partir les abonn\u00e9s entre les n\u0153uds et leurs diff\u00e9rences<\/h2>\r\nComment r\u00e9partir les nouvelles sessions entre les n\u0153uds de mani\u00e8re \u00e0 ce que les paquets de chaque session donn\u00e9e arrivent toujours sur le m\u00eame n\u0153ud ?\r\n<h3>Hachage par identifiant d\u2019abonn\u00e9<\/h3>\r\nUne m\u00e9thode courante et efficace consiste \u00e0 calculer un hash \u00e0 partir de la paire IMSI\/APN de la session PDN de l\u2019abonn\u00e9. Nous prenons l\u2019identifiant de l\u2019abonn\u00e9, IMSI+APN, calculons son hash, comparons le r\u00e9sultat \u00e0 la liste des n\u0153uds actifs et obtenons le num\u00e9ro du n\u0153ud auquel la session doit \u00eatre envoy\u00e9e. Comme un abonn\u00e9 poss\u00e8de un seul IMSI, toutes ses sessions dans le m\u00eame APN, quelle que soit l\u2019adresse IP utilis\u00e9e (IPv4 ou IPv6), sont dirig\u00e9es vers le m\u00eame n\u0153ud de traitement. Cette m\u00e9thode ne n\u00e9cessite pas de synchroniser l\u2019\u00e9tat entre les n\u0153uds : tant que chacun dispose des m\u00eames informations sur la composition du cluster, ils calculent ind\u00e9pendamment le m\u00eame hash et le m\u00eame num\u00e9ro de n\u0153ud.\r\n\r\nLorsqu\u2019un nouveau n\u0153ud est ajout\u00e9, un algorithme tel que Maglev ou Randevu reconstruit la distribution afin que le routage ne change que pour une partie minimale des abonn\u00e9s \u2014 environ 1\/(N+1) du total lorsque le cluster passe de N \u00e0 N+1 n\u0153uds. Les autres continuent d\u2019\u00eatre trait\u00e9s par les m\u00eames n\u0153uds.\r\n\r\nMais cette m\u00e9thode pr\u00e9sente \u00e9galement une limitation fondamentale : l\u2019algorithme ne tient pas compte de l\u2019\u00e9tat actuel de la session sur le n\u0153ud.\r\n\r\nD\u00e8s qu\u2019un nouveau n\u0153ud est ajout\u00e9 au cluster, le r\u00e9sultat du hash change pour certains abonn\u00e9s. L\u2019algorithme dirige alors leurs nouvelles connexions vers un autre n\u0153ud. Dans le m\u00eame temps, l\u2019ancien n\u0153ud peut encore contenir le contexte de service de ces abonn\u00e9s : informations sur les connexions, compteurs de consommation et autres donn\u00e9es n\u00e9cessaires au traitement des sessions en cours. Le nouveau n\u0153ud ne dispose pas encore de cet \u00e9tat. Si la nouvelle distribution est appliqu\u00e9e imm\u00e9diatement, les sessions actives se retrouveront sur des n\u0153uds qui ne poss\u00e8dent pas leur contexte. Il ne suffit donc pas de garantir que chaque connexion individuelle arrive sur le bon n\u0153ud. <strong>Le contexte associ\u00e9 \u00e0 l\u2019abonn\u00e9 doit lui aussi rester intact.<\/strong>\r\n<h2>Affectation initiale et migration contr\u00f4l\u00e9e<\/h2>\r\nLe hachage ne r\u00e9sout qu\u2019une partie du probl\u00e8me : la distribution initiale. La question suivante est : \u00ab Que faire des sessions qui sont d\u00e9j\u00e0 actives ? \u00bb Pour r\u00e9soudre ce probl\u00e8me, il est utile de distinguer deux processus : l\u2019affectation initiale des nouvelles sessions et la migration contr\u00f4l\u00e9e des sessions existantes.\r\n<h3>Migration contr\u00f4l\u00e9e<\/h3>\r\nLe hachage continue d\u2019\u00eatre utilis\u00e9 pour les nouvelles sessions : il r\u00e9partit rapidement et uniform\u00e9ment la charge et sert \u00e9galement de m\u00e9canisme de secours si le Control Plane est temporairement indisponible. En revanche, les sessions actives n\u00e9cessitent un m\u00e9canisme distinct permettant de les redistribuer progressivement.\r\n\r\nCette fonction est assur\u00e9e par <a href=\"\/fr\/resources\/glossary\/pcef\/\">PCEF<\/a>, un composant du Control Plane. Lorsque le nombre de n\u0153uds DPI change, PCEF parcourt toutes ses sessions. Pour chacune d\u2019elles, il compare l\u2019affectation actuelle au n\u0153ud avec l\u2019affectation cible calcul\u00e9e \u00e0 l\u2019aide d\u2019un hachage coh\u00e9rent en fonction du nouveau nombre de n\u0153uds. Si elles diff\u00e8rent, PCEF bascule la session vers le n\u0153ud cible. C\u2019est ainsi qu\u2019une migration progressive du User Plane est mise en \u0153uvre.\r\n\r\n[product id=\u00a0\u00bb10980\u2033 type=\u00a0\u00bbdark\u00a0\u00bb]\r\n\r\nAinsi, lorsqu\u2019un nouveau n\u0153ud de traitement du trafic est ajout\u00e9, le Control Plane n\u2019a pas besoin de recalculer l\u2019ensemble du syst\u00e8me depuis le d\u00e9but. Il peut s\u00e9lectionner uniquement les sessions concern\u00e9es par la migration.\r\n\r\nLa mise \u00e0 l\u2019\u00e9chelle du Control Plane lui-m\u00eame \u2014 c\u2019est-\u00e0-dire des instances PCEF \u2014 fonctionne de mani\u00e8re similaire. Lorsque leur nombre augmente, chaque PCEF actif parcourt les sessions qu\u2019il dessert actuellement et lib\u00e8re celles qui, selon le nouveau hash, doivent d\u00e9sormais appartenir \u00e0 l\u2019instance nouvellement ajout\u00e9e. Si le nombre d\u2019instances PCEF diminue \u2014 par exemple parce qu\u2019une instance tombe en panne \u2014 les instances restantes parcourent non seulement leurs propres sessions, mais toutes les sessions du stockage partag\u00e9. Elles identifient celles qui se retrouvent sans propri\u00e9taire et prennent en charge celles qui, selon le hash actuel, leur appartiennent d\u00e9sormais.\r\n\r\n<a href=\"\/wp-content\/uploads\/2026\/10\/two-methods-for-distributing-subscriber-sessions-across-nodes.svg\"><noscript><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/two-methods-for-distributing-subscriber-sessions-across-nodes.svg\" alt=\"Comparaison de deux m\u00e9thodes de r\u00e9partition des sessions d\u2019abonn\u00e9s entre les n\u0153uds\" width=\"547\" height=\"418\" class=\"alignnone size-full wp-image-14894\"><\/noscript><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/two-methods-for-distributing-subscriber-sessions-across-nodes.svg\" alt=\"Comparaison de deux m\u00e9thodes de r\u00e9partition des sessions d\u2019abonn\u00e9s entre les n\u0153uds\" width=\"547\" height=\"418\" class=\"alignnone size-full wp-image-14894 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/two-methods-for-distributing-subscriber-sessions-across-nodes.svg\"><\/a>\r\n\r\nFigure 3 \u2014 Deux m\u00e9thodes de r\u00e9partition des sessions d\u2019abonn\u00e9s entre les n\u0153uds\r\n\r\nPar exemple, un op\u00e9rateur ajoute un nouveau n\u0153ud DPI. Les nouvelles connexions commencent imm\u00e9diatement \u00e0 lui \u00eatre attribu\u00e9es. Le Control Plane s\u00e9lectionne ensuite progressivement certaines sessions actives et les d\u00e9place depuis les n\u0153uds surcharg\u00e9s. Une fois l\u2019\u00e9tat pr\u00e9par\u00e9, l\u2019affectation est modifi\u00e9e et le trafic suivant emprunte le nouveau chemin.\r\n\r\nPour l\u2019abonn\u00e9, rien ne change fondamentalement : l\u2019appel vid\u00e9o continue, le t\u00e9l\u00e9chargement d\u2019un fichier ne doit pas recommencer et les donn\u00e9es de comptabilisation d\u00e9j\u00e0 accumul\u00e9es sont conserv\u00e9es.\r\n\r\nLe load balancer du UP lui-m\u00eame ne prend pas la d\u00e9cision de redistribuer les sessions. Il re\u00e7oit la commande, pr\u00e9pare l\u2019\u00e9tat de la session et poursuit le traitement apr\u00e8s le basculement. Il s\u2019agit d\u2019une diff\u00e9rence fondamentale avec une architecture dans laquelle chaque n\u0153ud calcule ind\u00e9pendamment son affectation \u00e0 l\u2019aide d\u2019un hash.\r\n\r\nLes r\u00f4les sont ainsi clairement s\u00e9par\u00e9s : le Control Plane calcule l\u2019affectation cible et effectue la migration, tandis que le User Plane traite le trafic conform\u00e9ment \u00e0 cette affectation.\r\n\r\nPour en savoir plus sur le Control Plane et le User Plane, consultez l\u2019article \u2014 <a href=\"\/fr\/blog\/mobile-networks\/cups-for-pcef-pgw-why-separate-the-control-plane-and-user-plane-in-the-mobile-core\/\">CUPS pour PCEF\/PGW : pourquoi s\u00e9parer le Control Plane et le User Plane dans le c\u0153ur de r\u00e9seau mobile<\/a>.\r\n<h2>Le co\u00fbt du contr\u00f4le<\/h2>\r\nPour que la migration contr\u00f4l\u00e9e fonctionne correctement, il faut garantir la coh\u00e9rence des donn\u00e9es utilis\u00e9es par PCEF pour prendre ses d\u00e9cisions, contr\u00f4ler la vitesse de migration et g\u00e9rer les sessions dont l\u2019\u00e9tat ne peut pas \u00eatre migr\u00e9 en toute s\u00e9curit\u00e9, comme dans le cas du NAT.\r\n<h3>Coh\u00e9rence des informations sur les n\u0153uds<\/h3>\r\nLes n\u0153uds du User Plane ne calculent pas eux-m\u00eames les affectations : ils les re\u00e7oivent du Control Plane et les appliquent lors du traitement du trafic. Il est donc important de s\u2019assurer que chaque n\u0153ud travaille bien avec la version \u00e0 jour.\r\n\r\nChaque fois que le nombre de n\u0153uds change, PCEF calcule le n\u0153ud cible pour chaque session en fonction du nouveau nombre de n\u0153uds DPI, qu\u2019il r\u00e9cup\u00e8re dans Consul. Si plusieurs instances PCEF sont pr\u00e9sentes dans le cluster, il est important qu\u2019elles voient toutes le m\u00eame nombre de n\u0153uds au m\u00eame moment. Dans le cas contraire, diff\u00e9rentes instances PCEF peuvent calculer des n\u0153uds cibles diff\u00e9rents pour une m\u00eame session et la distribution ne sera plus coh\u00e9rente.\r\n<h3>La migration prend du temps<\/h3>\r\nLa migration d\u2019une seule session prend une fraction de seconde, mais il peut y avoir des millions de sessions et elles doivent \u00eatre migr\u00e9es s\u00e9quentiellement, et non toutes en m\u00eame temps. La migration prend du temps, mais les sessions actives restent ininterrompues.\r\n<h3>Tout ne peut pas \u00eatre migr\u00e9<\/h3>\r\nEnfin, toutes les sessions ne sont pas aussi facilement migrables. Certaines parties de leur \u00e9tat peuvent \u00eatre copi\u00e9es en toute s\u00e9curit\u00e9 vers un autre n\u0153ud, tandis que d\u2019autres sont \u00e9troitement li\u00e9es au mat\u00e9riel sp\u00e9cifique sur lequel la session a \u00e9t\u00e9 cr\u00e9\u00e9e. Le NAT est l\u2019un de ces cas : l\u2019entr\u00e9e de traduction d\u2019adresse et de port existe uniquement dans la m\u00e9moire d\u2019un n\u0153ud donn\u00e9 et ne peut pas \u00eatre simplement recr\u00e9\u00e9e sur un autre n\u0153ud sans risquer de perdre des connexions d\u00e9j\u00e0 \u00e9tablies.\r\n\r\nCes sessions sont donc g\u00e9r\u00e9es autrement : non pas par migration, mais par terminaison naturelle. Le n\u0153ud cesse d\u2019accepter de nouvelles sessions, tandis que les sessions existantes continuent d\u2019y \u00eatre trait\u00e9es jusqu\u2019\u00e0 leur fin naturelle.\r\n<h2>Comment v\u00e9rifier que cela fonctionne : trois crit\u00e8res mesurables<\/h2>\r\nTout ce qui est d\u00e9crit ci-dessus \u2014 le hachage bas\u00e9 sur l\u2019IMSI et la migration contr\u00f4l\u00e9e \u2014 vise \u00e0 garantir trois propri\u00e9t\u00e9s pr\u00e9cises qui peuvent \u00eatre mesur\u00e9es sur du trafic r\u00e9el plut\u00f4t que simplement d\u00e9clar\u00e9es.\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><strong>Propri\u00e9t\u00e9<\/strong><\/td>\r\n<td><strong>Comment la v\u00e9rifier<\/strong><\/td>\r\n<td><strong>En cas de non-respect<\/strong><\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Les deux directions d\u2019une session sur le m\u00eame n\u0153ud<\/td>\r\n<td>V\u00e9rifier que le trafic entrant et sortant d\u2019une m\u00eame session est trait\u00e9 sur le m\u00eame n\u0153ud<\/td>\r\n<td>La comptabilisation et la classification par service peuvent \u00eatre incompl\u00e8tes<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Migration sans perte de paquets<\/td>\r\n<td>V\u00e9rifier que le trafic continue sans interruption pendant la migration de la session<\/td>\r\n<td>L\u2019abonn\u00e9 peut subir une interruption de connexion<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Migration sans perte des donn\u00e9es de comptabilisation<\/td>\r\n<td>V\u00e9rifier que le volume total comptabilis\u00e9 sur le n\u0153ud d\u2019origine et le nouveau n\u0153ud correspond \u00e0 la consommation r\u00e9elle<\/td>\r\n<td>Une erreur de comptabilisation peut n\u2019appara\u00eetre qu\u2019au moment de la g\u00e9n\u00e9ration du rapport final<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nLa troisi\u00e8me propri\u00e9t\u00e9 m\u00e9rite une attention particuli\u00e8re. Lors d\u2019une migration contr\u00f4l\u00e9e, le n\u0153ud d\u2019origine transmet les donn\u00e9es finales de consommation avant la fin de la session. Le Control Plane les combine avec les donn\u00e9es du nouveau n\u0153ud et ajuste le seuil de consommation. Les donn\u00e9es ne sont ainsi ni perdues ni comptabilis\u00e9es deux fois.\r\n\r\nIl n\u2019est pas non plus n\u00e9cessaire de fermer puis de rouvrir la session de tarification. L\u2019abonn\u00e9 continue \u00e0 utiliser le service sans interruption, tandis que la comptabilisation de la consommation se poursuit en tenant compte des donn\u00e9es des deux n\u0153uds.\r\n<h2>Ce que cette approche de mise \u00e0 l\u2019\u00e9chelle apporte<\/h2>\r\nLe principal avantage de cette approche est que l\u2019op\u00e9rateur peut modifier la composition de l\u2019infrastructure sans redistribuer massivement les sessions actives. Un nouveau n\u0153ud peut \u00eatre utilis\u00e9 imm\u00e9diatement pour les nouvelles connexions, tandis que les sessions existantes peuvent \u00eatre migr\u00e9es progressivement selon les besoins.\r\n\r\nCela produit plusieurs effets pratiques :\r\n<ul>\r\n \t<li>La capacit\u00e9 peut \u00eatre augment\u00e9e sans arr\u00eater le r\u00e9seau. Le nouveau n\u0153ud commence imm\u00e9diatement \u00e0 accepter des connexions, tandis que les sessions actives sont migr\u00e9es en arri\u00e8re-plan.<\/li>\r\n \t<li>La charge est r\u00e9\u00e9quilibr\u00e9e de mani\u00e8re cibl\u00e9e. Un n\u0153ud surcharg\u00e9 est d\u00e9charg\u00e9 exactement dans la mesure n\u00e9cessaire, plut\u00f4t que par un recalcul complet des connexions.<\/li>\r\n \t<li>L\u2019\u00e9tat de l\u2019abonn\u00e9 reste intact. Les connexions, adresses, offre tarifaire, quota et comptabilisation par service restent associ\u00e9s \u00e0 l\u2019abonn\u00e9 au lieu d\u2019\u00eatre r\u00e9partis entre plusieurs n\u0153uds.<\/li>\r\n \t<li>Les op\u00e9rations de maintenance planifi\u00e9es ne se transforment pas en basculements d\u2019urgence. Lorsqu\u2019un n\u0153ud est retir\u00e9 du service, ses sessions peuvent \u00eatre migr\u00e9es \u00e0 l\u2019avance vers d\u2019autres n\u0153uds au lieu d\u2019interrompre toutes les connexions simultan\u00e9ment.<\/li>\r\n<\/ul>\r\nLa croissance du r\u00e9seau se mesure en t\u00e9rabits, tandis que le r\u00e9sultat de la mise \u00e0 l\u2019\u00e9chelle se ressent au niveau d\u2019une connexion individuelle. Une architecture dans laquelle l\u2019unit\u00e9 de distribution n\u2019est ni un flux ni m\u00eame une session individuelle, mais l\u2019abonn\u00e9 avec tout ce qui lui est associ\u00e9, ne permet tout simplement pas de n\u00e9gliger cette exigence au stade de la conception.\r\n\r\n[product id=\u00a0\u00bb14175\u2033 type=\u00a0\u00bblight\u00a0\u00bb]","protected":false},"excerpt":{"rendered":"<p>Lors de la mise \u00e0 l\u2019\u00e9chelle horizontale du User Plane, de nouveaux n\u0153uds de traitement du trafic sont ajout\u00e9s au cluster. Mais il n\u2019est pas possible de redistribuer tout le trafic depuis le d\u00e9but. Les sessions actives doivent conserver leur \u00e9tat et continuer \u00e0 \u00eatre trait\u00e9es sur le m\u00eame n\u0153ud. Les nouvelles connexions et les sessions existantes sont donc distribu\u00e9es selon des r\u00e8gles diff\u00e9rentes, tandis que les sessions actives sont migr\u00e9es progressivement.<\/p>\n<p>Dans cet article, nous expliquons pourquoi des interruptions peuvent se produire et comment fonctionne la mise \u00e0 l\u2019\u00e9chelle du User Plane lorsque l\u2019augmentation de capacit\u00e9 ne se traduit pas par des perturbations pour les abonn\u00e9s.<\/p>\n","protected":false},"author":24,"featured_media":14898,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[102],"tags":[],"class_list":["post-14891","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mobile-networks"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v24.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>VAS Experts<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/\",\"url\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/\",\"name\":\"Scaling in a CUPS Architecture: How to Grow Without Disrupting Subscribers\",\"isPartOf\":{\"@id\":\"https:\/\/vasexperts.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#primaryimage\"},\"thumbnailUrl\":\"\/wp-content\/uploads\/2026\/10\/cups-banner.jpg\",\"datePublished\":\"2026-10-05T06:00:38+00:00\",\"dateModified\":\"2026-10-02T18:09:07+00:00\",\"author\":{\"@id\":\"https:\/\/vasexperts.com\/#\/schema\/person\/3c1682319461407059bf9279091a9116\"},\"description\":\"How can you scale the User Plane in CUPS without disrupting sessions? We explain hashing, DPI node distribution, controlled migration, and accounting preservation.\",\"breadcrumb\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#primaryimage\",\"url\":\"\/wp-content\/uploads\/2026\/10\/cups-banner.jpg\",\"contentUrl\":\"\/wp-content\/uploads\/2026\/10\/cups-banner.jpg\",\"width\":850,\"height\":354},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"\u0413\u043b\u0430\u0432\u043d\u0430\u044f \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0430\",\"item\":\"https:\/\/vasexperts.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Scaling in a CUPS Architecture: How to Grow Without Disrupting Subscribers\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/vasexperts.com\/#website\",\"url\":\"https:\/\/vasexperts.com\/\",\"name\":\"VAS Experts\",\"description\":\"VAS Experts\",\"inLanguage\":\"fr-FR\",\"publisher\":{\"@id\":\"https:\/\/vasexperts.com\/#organization\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/vasexperts.com\/#\/schema\/person\/3c1682319461407059bf9279091a9116\",\"name\":\"Darya Aulova\",\"url\":\"https:\/\/vasexperts.com\/fr\/blog\/author\/darya-aulova\/\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/vasexperts.com\/#organization\",\"name\":\"VAS Experts\",\"url\":\"https:\/\/vasexperts.com\/\",\"logo\":\"https:\/\/vasexperts.com\/assets\/img\/svg\/logo.svg\",\"sameAs\":[\"https:\/\/www.linkedin.com\/company\/vas-experts\",\"https:\/\/www.youtube.com\/channel\/UCGYfhhZvmE2XbrCyerzRbGA\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"VAS Experts","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/","url":"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/","name":"Scaling in a CUPS Architecture: How to Grow Without Disrupting Subscribers","isPartOf":{"@id":"https:\/\/vasexperts.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#primaryimage"},"image":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#primaryimage"},"thumbnailUrl":"\/wp-content\/uploads\/2026\/10\/cups-banner.jpg","datePublished":"2026-10-05T06:00:38+00:00","dateModified":"2026-10-02T18:09:07+00:00","author":{"@id":"https:\/\/vasexperts.com\/#\/schema\/person\/3c1682319461407059bf9279091a9116"},"description":"How can you scale the User Plane in CUPS without disrupting sessions? We explain hashing, DPI node distribution, controlled migration, and accounting preservation.","breadcrumb":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#primaryimage","url":"\/wp-content\/uploads\/2026\/10\/cups-banner.jpg","contentUrl":"\/wp-content\/uploads\/2026\/10\/cups-banner.jpg","width":850,"height":354},{"@type":"BreadcrumbList","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"\u0413\u043b\u0430\u0432\u043d\u0430\u044f \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0430","item":"https:\/\/vasexperts.com\/"},{"@type":"ListItem","position":2,"name":"Scaling in a CUPS Architecture: How to Grow Without Disrupting Subscribers"}]},{"@type":"WebSite","@id":"https:\/\/vasexperts.com\/#website","url":"https:\/\/vasexperts.com\/","name":"VAS Experts","description":"VAS Experts","inLanguage":"fr-FR","publisher":{"@id":"https:\/\/vasexperts.com\/#organization"}},{"@type":"Person","@id":"https:\/\/vasexperts.com\/#\/schema\/person\/3c1682319461407059bf9279091a9116","name":"Darya Aulova","url":"https:\/\/vasexperts.com\/fr\/blog\/author\/darya-aulova\/"},{"@type":"Organization","@id":"https:\/\/vasexperts.com\/#organization","name":"VAS Experts","url":"https:\/\/vasexperts.com\/","logo":"https:\/\/vasexperts.com\/assets\/img\/svg\/logo.svg","sameAs":["https:\/\/www.linkedin.com\/company\/vas-experts","https:\/\/www.youtube.com\/channel\/UCGYfhhZvmE2XbrCyerzRbGA"]}]}},"_links":{"self":[{"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/posts\/14891"}],"collection":[{"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/users\/24"}],"replies":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/comments?post=14891"}],"version-history":[{"count":5,"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/posts\/14891\/revisions"}],"predecessor-version":[{"id":14911,"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/posts\/14891\/revisions\/14911"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/media\/14898"}],"wp:attachment":[{"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/media?parent=14891"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/categories?post=14891"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vasexperts.com\/fr\/wp-json\/wp\/v2\/tags?post=14891"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}