{"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\/es\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/","title":{"rendered":"Escalabilidad en una arquitectura CUPS: c\u00f3mo crecer sin afectar a los abonados"},"content":{"rendered":"<h2>Arquitectura del cl\u00faster: Control Plane y User Plane<\/h2>\r\nDentro del cl\u00faster, los componentes se dividen entre el Control Plane y el User Plane.\r\n\r\nEl User Plane realiza las funciones de procesamiento del tr\u00e1fico: recepci\u00f3n, procesamiento y transmisi\u00f3n del tr\u00e1fico de los abonados.\r\n\r\n[product id=\u00bb19\u2033 type=\u00bbdark\u00bb]\r\n\r\nUna de las funciones clave del User Plane es el DPI, un sistema de clasificaci\u00f3n del tr\u00e1fico por sesiones y aplicaciones. Los nodos DPI reciben paquetes, procesan conexiones, aplican las pol\u00edticas necesarias y recopilan estad\u00edsticas de consumo de los abonados. Estos son los nodos que se a\u00f1aden cuando es necesario aumentar la capacidad o que se retiran del servicio para realizar tareas de mantenimiento.\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=\"Arquitectura del cl\u00faster de VAS Experts con Control Plane y 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=\"Arquitectura del cl\u00faster de VAS Experts con Control Plane y 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\nFigura 1 \u2014 Arquitectura del cl\u00faster\r\n\r\nEl Control Plane almacena el estado de las sesiones de los abonados y asigna el User Plane. En funci\u00f3n del n\u00famero de nodos activos, determina qu\u00e9 nodo atiende a un abonado concreto, qu\u00e9 par\u00e1metros y servicios est\u00e1n asociados a \u00e9l y realiza la migraci\u00f3n de la sesi\u00f3n cuando cambia esta asignaci\u00f3n.\r\n<h2>El requisito del que se deriva todo lo dem\u00e1s<\/h2>\r\nEmpecemos no por la escalabilidad en s\u00ed, sino por la limitaci\u00f3n que la hace m\u00e1s compleja.\r\n\r\nLa clasificaci\u00f3n del tr\u00e1fico y la tarificaci\u00f3n por servicio requieren que <strong>ambas direcciones de una conexi\u00f3n sean procesadas por el mismo nodo DPI (User Plane)<\/strong>.\r\n\r\nAdem\u00e1s, la unidad de servicio no es una <a href=\"\/es\/resources\/glossary\/ip-address\/\">direcci\u00f3n IP<\/a> individual ni siquiera una conexi\u00f3n concreta. Un abonado puede utilizar varios servicios simult\u00e1neamente, tener varias conexiones, utilizar <a href=\"\/es\/resources\/glossary\/ipv4\/\">IPv4<\/a> y <a href=\"\/es\/resources\/glossary\/ipv6\/\">IPv6<\/a> o compartir el acceso a Internet con otros dispositivos. Por lo tanto, un abonado puede tener varias conexiones y direcciones, pero desde el punto de vista del servicio todas pertenecen a una \u00fanica sesi\u00f3n de servicio. Esta sesi\u00f3n se convierte en la unidad de escalabilidad: todas las conexiones asociadas al abonado deben procesarse conjuntamente por el mismo nodo de procesamiento de tr\u00e1fico y el mismo nodo de control.\r\n<div class=\"note\">\r\n\r\n[important]De aqu\u00ed se deriva la regla principal\r\n\r\nLa unidad de escalabilidad no es un flujo, una direcci\u00f3n ni una conexi\u00f3n individual, sino la propia sesi\u00f3n de servicio junto con todos sus par\u00e1metros: conexiones, direcciones IPv4 e IPv6, plan tarifario, cuota y datos de tarificaci\u00f3n. Esta es la unidad de distribuci\u00f3n y no puede dividirse entre varios nodos.[\/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=\"Diagrama de una sesi\u00f3n de servicio\" 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=\"Diagrama de una sesi\u00f3n de servicio\" 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\nFigura 2 \u2014 Sesi\u00f3n de servicio: todas las conexiones y direcciones de un abonado forman una \u00fanica unidad de servicio\r\n\r\nSi los paquetes pertenecientes a la misma <a href=\"\/es\/resources\/glossary\/tcp\/\">conexi\u00f3n TCP<\/a> llegan a nodos diferentes, esto puede provocar la interrupci\u00f3n de la conexi\u00f3n, la p\u00e9rdida del contexto de clasificaci\u00f3n y la divisi\u00f3n de una misma sesi\u00f3n entre varios nodos para la tarificaci\u00f3n del tr\u00e1fico.\r\n\r\nEsto resulta especialmente evidente en el caso de <a href=\"\/es\/resources\/glossary\/nat\/\">NAT<\/a>. Si la traducci\u00f3n de direcci\u00f3n y puerto se almacena en el nodo anterior mientras el siguiente paquete llega a un nodo nuevo, el nuevo nodo no encontrar\u00e1 la entrada correspondiente y el tr\u00e1fico ser\u00e1 descartado. En una conexi\u00f3n establecida, esto provocar\u00e1 una interrupci\u00f3n.\r\n<h2>Dos formas de distribuir los abonados entre los nodos y en qu\u00e9 se diferencian<\/h2>\r\n\u00bfC\u00f3mo distribuir las nuevas sesiones entre los nodos de modo que los paquetes de cada sesi\u00f3n concreta siempre lleguen al mismo nodo?\r\n<h3>Hashing por identificador de abonado<\/h3>\r\nUno de los m\u00e9todos habituales y eficaces consiste en calcular un hash a partir del par IMSI\/APN de la sesi\u00f3n PDN del abonado. Tomamos el identificador del abonado, IMSI+APN, calculamos su hash, comparamos el resultado con la lista de nodos activos y obtenemos el n\u00famero del nodo al que debe enviarse la sesi\u00f3n. Como un abonado tiene un \u00fanico IMSI, todas sus sesiones dentro del mismo APN, independientemente de la direcci\u00f3n IP utilizada (IPv4 o IPv6), se dirigen al mismo nodo de procesamiento. Este m\u00e9todo no requiere sincronizar el estado entre los nodos: siempre que cada uno tenga la misma informaci\u00f3n sobre la composici\u00f3n del cl\u00faster, todos calculan de forma independiente el mismo hash y el mismo n\u00famero de nodo.\r\n\r\nCuando se a\u00f1ade un nuevo nodo, un algoritmo como Maglev o Randevu reconstruye la distribuci\u00f3n de modo que el enrutamiento cambie solo para una parte m\u00ednima de los abonados: aproximadamente 1\/(N+1) del total cuando el cl\u00faster crece de N a N+1 nodos. El resto contin\u00faa siendo atendido por los mismos nodos.\r\n\r\nPero este m\u00e9todo tambi\u00e9n tiene una limitaci\u00f3n fundamental: el algoritmo no tiene en cuenta el estado actual de la sesi\u00f3n en el nodo.\r\n\r\nEn cuanto se a\u00f1ade un nuevo nodo al cl\u00faster, el resultado del hash cambia para algunos abonados. El algoritmo dirige sus nuevas conexiones a otro nodo. Al mismo tiempo, el nodo anterior puede seguir teniendo el contexto de servicio de estos abonados: informaci\u00f3n sobre las conexiones, contadores de consumo y otros datos necesarios para procesar las sesiones actuales. El nuevo nodo todav\u00eda no dispone de este estado. Si la nueva distribuci\u00f3n se aplica inmediatamente, las sesiones activas terminar\u00e1n en nodos que no tienen su contexto. Por lo tanto, no basta con garantizar que cada conexi\u00f3n individual llegue al nodo correcto. <strong>El contexto asociado al abonado tambi\u00e9n debe mantenerse \u00edntegro.<\/strong>\r\n<h2>Asignaci\u00f3n inicial y migraci\u00f3n controlada<\/h2>\r\nEl hashing resuelve solo una parte del problema: la distribuci\u00f3n inicial. La siguiente pregunta es: \u00ab\u00bfQu\u00e9 hacer con las sesiones que ya est\u00e1n activas?\u00bb. Para resolver este problema, conviene separar dos procesos: la asignaci\u00f3n inicial de las nuevas sesiones y la migraci\u00f3n controlada de las ya existentes.\r\n<h3>Migraci\u00f3n controlada<\/h3>\r\nEl hashing se sigue utilizando para las nuevas sesiones: distribuye la carga de forma r\u00e1pida y uniforme y, al mismo tiempo, sirve como mecanismo de respaldo si el Control Plane deja de estar disponible temporalmente. Sin embargo, las sesiones activas requieren un mecanismo independiente que permita redistribuirlas gradualmente.\r\n\r\nDe esto se encarga <a href=\"\/es\/resources\/glossary\/pcef\/\">PCEF<\/a>, un componente del Control Plane. Cuando cambia el n\u00famero de nodos DPI, PCEF recorre todas sus sesiones. Para cada una, compara la asignaci\u00f3n actual al nodo con la asignaci\u00f3n objetivo calculada mediante hashing consistente teniendo en cuenta el nuevo n\u00famero de nodos. Si son diferentes, PCEF cambia la sesi\u00f3n al nodo objetivo. As\u00ed se implementa una migraci\u00f3n gradual del User Plane.\r\n\r\n[product id=\u00bb10980\u2033 type=\u00bbdark\u00bb]\r\n\r\nPor lo tanto, cuando se a\u00f1ade un nuevo nodo de procesamiento de tr\u00e1fico, el Control Plane no necesita recalcular todo el sistema desde cero. En su lugar, puede seleccionar sesiones concretas para la migraci\u00f3n.\r\n\r\nLa escalabilidad del propio Control Plane \u2014es decir, de las instancias de PCEF\u2014 funciona de forma similar. Cuando aumenta su n\u00famero, cada PCEF activo recorre las sesiones que atiende actualmente y libera aquellas que, seg\u00fan el nuevo hash, deber\u00edan pertenecer ahora a la instancia reci\u00e9n a\u00f1adida. Si el n\u00famero de instancias de PCEF disminuye, por ejemplo, porque una de ellas falla, las instancias restantes recorren no solo sus propias sesiones, sino todas las sesiones almacenadas en el almacenamiento compartido. Identifican las que han quedado sin propietario y asumen aquellas que, seg\u00fan el hash actual, ahora les corresponden.\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=\"Comparaci\u00f3n de dos m\u00e9todos para distribuir las sesiones de los abonados entre los nodos\" 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=\"Comparaci\u00f3n de dos m\u00e9todos para distribuir las sesiones de los abonados entre los nodos\" 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\nFigura 3 \u2014 Dos formas de distribuir las sesiones de los abonados entre los nodos\r\n\r\nPor ejemplo, un operador a\u00f1ade un nuevo nodo DPI. Las nuevas conexiones comienzan a asignarse a \u00e9l inmediatamente. A continuaci\u00f3n, el Control Plane selecciona gradualmente algunas sesiones activas y las traslada desde los nodos sobrecargados. Una vez preparado el estado, se cambia la asignaci\u00f3n y el tr\u00e1fico posterior sigue la nueva ruta.\r\n\r\nPara el abonado, nada cambia en lo fundamental: la videollamada contin\u00faa, la descarga de un archivo no tiene que comenzar de nuevo y los datos de tarificaci\u00f3n acumulados se conservan.\r\n\r\nEl propio balanceador de carga de salida del UP (UP load balancer) no toma la decisi\u00f3n sobre la redistribuci\u00f3n. Recibe la orden, prepara el estado de la sesi\u00f3n y contin\u00faa proces\u00e1ndola despu\u00e9s del cambio. Esta es una diferencia fundamental con una arquitectura en la que cada nodo calcula de forma independiente su asignaci\u00f3n mediante un hash.\r\n\r\nDe este modo, las funciones quedan claramente separadas: el Control Plane calcula la asignaci\u00f3n objetivo y realiza la migraci\u00f3n, mientras que el User Plane procesa el tr\u00e1fico de acuerdo con dicha asignaci\u00f3n.\r\n\r\nM\u00e1s informaci\u00f3n sobre el Control Plane y el User Plane en el art\u00edculo \u2014 <a href=\"\/es\/blog\/mobile-networks\/cups-for-pcef-pgw-why-separate-the-control-plane-and-user-plane-in-the-mobile-core\/\">CUPS para PCEF\/PGW: por qu\u00e9 separar el Control Plane y el User Plane en el n\u00facleo m\u00f3vil<\/a>.\r\n<h2>El coste del control<\/h2>\r\nPara que la migraci\u00f3n controlada funcione correctamente, es necesario garantizar la coherencia de los datos que PCEF utiliza para tomar decisiones, controlar la velocidad de migraci\u00f3n y gestionar las sesiones cuyo estado no puede migrarse de forma segura, como ocurre con NAT.\r\n<h3>Coherencia de la informaci\u00f3n sobre los nodos<\/h3>\r\nLos nodos del User Plane no calculan las asignaciones por s\u00ed mismos: las reciben del Control Plane y las aplican al procesar el tr\u00e1fico. Por eso es importante garantizar que cada nodo trabaje realmente con la versi\u00f3n actualizada.\r\n\r\nCada vez que cambia el n\u00famero de nodos, PCEF calcula el nodo objetivo para cada sesi\u00f3n bas\u00e1ndose en el nuevo n\u00famero de nodos DPI, que obtiene de Consul. Si hay varias instancias de PCEF en el cl\u00faster, es importante que todas vean el mismo n\u00famero de nodos en el mismo momento. De lo contrario, diferentes instancias de PCEF pueden calcular distintos nodos objetivo para una misma sesi\u00f3n y la distribuci\u00f3n dejar\u00e1 de ser coherente.\r\n<h3>La migraci\u00f3n requiere tiempo<\/h3>\r\nMigrar una sola sesi\u00f3n lleva una fracci\u00f3n de segundo, pero puede haber millones de sesiones y es necesario migrarlas de forma secuencial, no todas a la vez. La migraci\u00f3n requiere tiempo, pero las sesiones activas no se interrumpen.\r\n<h3>No todo se puede migrar<\/h3>\r\nPor \u00faltimo, no todas las sesiones son igual de f\u00e1ciles de migrar. Algunas partes de su estado pueden copiarse de forma segura a otro nodo, mientras que otras est\u00e1n estrechamente vinculadas al hardware concreto en el que se cre\u00f3 la sesi\u00f3n. NAT es uno de estos casos: la entrada de traducci\u00f3n de direcci\u00f3n y puerto existe \u00fanicamente en la memoria de un nodo concreto y no puede recrearse simplemente en otro nodo sin riesgo de perder conexiones ya establecidas.\r\n\r\nEstas sesiones se gestionan de otra manera: no mediante una migraci\u00f3n, sino mediante una finalizaci\u00f3n natural. El nodo deja de aceptar nuevas sesiones, mientras que las existentes contin\u00faan siendo atendidas en \u00e9l hasta que finalizan de forma natural.\r\n<h2>C\u00f3mo comprobar que funciona: tres criterios medibles<\/h2>\r\nTodo lo descrito anteriormente \u2014el hashing basado en IMSI y la migraci\u00f3n controlada\u2014 existe para garantizar tres propiedades concretas que pueden medirse sobre tr\u00e1fico real, en lugar de limitarse a declararlas.\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><strong>Propiedad<\/strong><\/td>\r\n<td><strong>C\u00f3mo se comprueba<\/strong><\/td>\r\n<td><strong>Si no se cumple<\/strong><\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Ambas direcciones de la sesi\u00f3n en el mismo nodo<\/td>\r\n<td>Se comprueba si el tr\u00e1fico entrante y saliente de una misma sesi\u00f3n se procesa en el mismo nodo<\/td>\r\n<td>La tarificaci\u00f3n y la clasificaci\u00f3n por servicio pueden ser incompletas<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Migraci\u00f3n sin p\u00e9rdida de paquetes<\/td>\r\n<td>Se comprueba si el tr\u00e1fico contin\u00faa sin interrupciones mientras se migra la sesi\u00f3n<\/td>\r\n<td>El abonado puede experimentar una interrupci\u00f3n de la conexi\u00f3n<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Migraci\u00f3n sin p\u00e9rdida de datos de tarificaci\u00f3n<\/td>\r\n<td>Se comprueba si el volumen total de datos contabilizados en el nodo original y en el nuevo coincide con el consumo real<\/td>\r\n<td>Un error de tarificaci\u00f3n puede detectarse solo al generar el informe final<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nLa tercera propiedad merece una atenci\u00f3n especial. Durante la migraci\u00f3n controlada, el nodo original env\u00eda los datos finales de consumo antes de que finalice la sesi\u00f3n. El Control Plane los combina con los datos del nuevo nodo y ajusta el umbral de consumo. De esta forma, los datos no se pierden ni se contabilizan dos veces.\r\n\r\nAl mismo tiempo, no es necesario cerrar y volver a abrir la sesi\u00f3n de tarificaci\u00f3n. El abonado contin\u00faa utilizando el servicio sin interrupciones y el consumo sigue contabiliz\u00e1ndose teniendo en cuenta los datos de ambos nodos.\r\n<h2>Qu\u00e9 aporta este enfoque de escalabilidad<\/h2>\r\nLa principal ventaja de este enfoque es que el operador puede cambiar la composici\u00f3n de la infraestructura sin una redistribuci\u00f3n masiva de las sesiones activas. Un nuevo nodo puede utilizarse inmediatamente para las nuevas conexiones, mientras que las sesiones existentes pueden migrarse gradualmente seg\u00fan sea necesario.\r\n\r\nEsto produce varios efectos pr\u00e1cticos:\r\n<ul>\r\n \t<li>La capacidad puede aumentarse sin detener la red. El nuevo nodo comienza a aceptar conexiones inmediatamente, mientras que las sesiones activas se migran en segundo plano.<\/li>\r\n \t<li>La carga se redistribuye de forma selectiva. Un nodo sobrecargado se descarga exactamente en la medida necesaria, en lugar de recalcular todas las conexiones.<\/li>\r\n \t<li>El estado del abonado se mantiene \u00edntegro. Las conexiones, direcciones, plan tarifario, cuota y tarificaci\u00f3n por servicio permanecen asociadas al abonado en lugar de dividirse entre varios nodos.<\/li>\r\n \t<li>Los trabajos de mantenimiento planificados no se convierten en conmutaciones de emergencia. Cuando un nodo se retira del servicio, sus sesiones pueden migrarse previamente a otros nodos en lugar de interrumpir todas las conexiones al mismo tiempo.<\/li>\r\n<\/ul>\r\nEl crecimiento de la red se mide en terabits, mientras que el resultado de la escalabilidad se percibe a nivel de una conexi\u00f3n individual. Una arquitectura en la que la unidad de distribuci\u00f3n no es un flujo ni siquiera una sesi\u00f3n individual, sino el abonado junto con todo lo asociado a \u00e9l, simplemente no permite pasar por alto este requisito en la fase de dise\u00f1o.\r\n\r\n[product id=\u00bb14175\u2033 type=\u00bblight\u00bb]","protected":false},"excerpt":{"rendered":"<p>Al escalar horizontalmente el User Plane, se a\u00f1aden nuevos nodos de procesamiento de tr\u00e1fico al cl\u00faster. Pero no es posible redistribuir todo el tr\u00e1fico desde cero. Las sesiones activas deben conservar su estado y continuar proces\u00e1ndose en el mismo nodo. Por eso, las nuevas conexiones y las sesiones existentes se distribuyen seg\u00fan reglas diferentes, mientras que las sesiones activas se migran gradualmente.<\/p>\n<p>En este art\u00edculo explicamos por qu\u00e9 se producen interrupciones y c\u00f3mo funciona la escalabilidad del User Plane para aumentar la capacidad sin trasladar las consecuencias de este proceso al abonado.<\/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\":\"es\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@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\":\"es\",\"publisher\":{\"@id\":\"https:\/\/vasexperts.com\/#organization\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/vasexperts.com\/#\/schema\/person\/3c1682319461407059bf9279091a9116\",\"name\":\"Darya Aulova\",\"url\":\"https:\/\/vasexperts.com\/es\/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":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/vasexperts.com\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/"]}]},{"@type":"ImageObject","inLanguage":"es","@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":"es","publisher":{"@id":"https:\/\/vasexperts.com\/#organization"}},{"@type":"Person","@id":"https:\/\/vasexperts.com\/#\/schema\/person\/3c1682319461407059bf9279091a9116","name":"Darya Aulova","url":"https:\/\/vasexperts.com\/es\/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\/es\/wp-json\/wp\/v2\/posts\/14891"}],"collection":[{"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/users\/24"}],"replies":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/comments?post=14891"}],"version-history":[{"count":5,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/posts\/14891\/revisions"}],"predecessor-version":[{"id":14911,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/posts\/14891\/revisions\/14911"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/media\/14898"}],"wp:attachment":[{"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/media?parent=14891"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/categories?post=14891"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/tags?post=14891"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}