{"id":14996,"date":"2026-10-15T14:15:56","date_gmt":"2026-10-15T11:15:56","guid":{"rendered":"https:\/\/vasexperts.com\/?p=14996"},"modified":"2026-10-15T14:41:55","modified_gmt":"2026-10-15T11:41:55","slug":"gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance","status":"publish","type":"post","link":"https:\/\/vasexperts.com\/es\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/","title":{"rendered":"\u00bfSe pierde con la falla? C\u00f3mo calcular de antemano las p\u00e9rdidas en la contabilizaci\u00f3n del tr\u00e1fico"},"content":{"rendered":"En este art\u00edculo analizaremos cada uno de ellos, mostraremos c\u00f3mo estimar y limitar las p\u00e9rdidas, y qu\u00e9 m\u00e9tricas conviene monitorear para detectar un problema a tiempo.\r\n<h2>C\u00f3mo funciona la contabilizaci\u00f3n en un gateway de servicios<\/h2>\r\nUn gateway de servicios est\u00e1 formado por nodos de procesamiento y nodos de control. En la contabilizaci\u00f3n del tr\u00e1fico participan varios componentes:\r\n<ul>\r\n \t<li>Nodo de procesamiento (DPI): componente del gateway de servicios en el plano de usuario (user plane) por el que pasa f\u00edsicamente el tr\u00e1fico de los suscriptores.<\/li>\r\n \t<li>Nodo de control (<a href=\"\/es\/products\/pcef-policy-and-charging-enforcement-function\/\">PCEF<\/a>): componente del gateway de servicios en el plano de control (control plane) que env\u00eda a los nodos de procesamiento los umbrales de cada grupo de contabilizaci\u00f3n y recibe los reportes de consumo.<\/li>\r\n \t<li>Billing (OCS): sistema de tarificaci\u00f3n externo. Otorga cuotas de tr\u00e1fico y recibe los reportes de consumo.<\/li>\r\n \t<li>PCRF: sistema externo de gesti\u00f3n de pol\u00edticas. Define la pol\u00edtica de servicio del suscriptor y el conjunto de grupos que el suscriptor tiene permitido usar. En ocasiones, el PCRF tambi\u00e9n cumple la funci\u00f3n de OCS.<\/li>\r\n<\/ul>\r\n<noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/network_architecture_en-1.svg\" alt=\"arquitectura de red\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15000\"><\/noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/network_architecture_en-1.svg\" alt=\"arquitectura de red\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15000 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/network_architecture_en-1.svg\">\r\nFigura 1. Arquitectura del gateway de servicios\r\n \r\n[important]Una cuota es el volumen que el sistema de tarificaci\u00f3n otorg\u00f3 a una sesi\u00f3n para un grupo de contabilizaci\u00f3n. Un umbral es el volumen a partir del cual el nodo de procesamiento env\u00eda un reporte. El nodo de control fija el umbral seg\u00fan la cuota recibida del OCS.[\/important]\r\n \r\nLa unidad b\u00e1sica de contabilizaci\u00f3n es el grupo de contabilizaci\u00f3n. Agrupa el tr\u00e1fico de varios servicios que se tarifican de la misma manera, y el DPI reporta su volumen total. Por ejemplo, un grupo \u201cstreaming de video\u201d con los identificadores RG 10 y SI 0 (Rating Group y Service Identifier) puede reunir el tr\u00e1fico de YouTube y de otros servicios de video.\r\n \r\nEl DPI clasifica los paquetes, los asigna a grupos de contabilizaci\u00f3n y lleva un contador de volumen para cada grupo. El PCEF obtiene los datos de volumen a partir de los reportes del DPI. Adem\u00e1s, el PCEF almacena el estado de las sesiones: cr\u00e9ditos otorgados, volumen consumido y plazos de validez de las cuotas.\r\n \r\nEl PCRF tambi\u00e9n define los l\u00edmites de velocidad de cada grupo de contabilizaci\u00f3n. El OCS otorga vol\u00famenes para cada grupo permitido y recibe los reportes de consumo.\r\n \r\nEl ciclo de contabilizaci\u00f3n comienza en el PCRF. Este le indica al PCEF qu\u00e9 grupos de contabilizaci\u00f3n est\u00e1n disponibles para el suscriptor. El PCEF solicita al OCS vol\u00famenes para cada grupo permitido y env\u00eda al DPI el conjunto de grupos con sus l\u00edmites y umbrales.\r\n \r\n<noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/sequence_reporting_en-1.svg\" alt=\"ciclo de contabilizaci\u00f3n\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15001\"><\/noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/sequence_reporting_en-1.svg\" alt=\"ciclo de contabilizaci\u00f3n\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15001 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/sequence_reporting_en-1.svg\">\r\nFigura 2. El ciclo de contabilizaci\u00f3n\r\n \r\nCuando el consumo de un grupo alcanza el umbral, el DPI env\u00eda un reporte al PCEF. El reporte tambi\u00e9n puede enviarse antes si el PCEF lo solicita. El PCEF transmite los datos al OCS o al PCRF y recibe a cambio una nueva cuota o un nuevo conjunto de reglas, que luego env\u00eda al DPI. Toda la comunicaci\u00f3n entre el DPI y el OCS pasa por el PCEF.\r\n \r\nEl punto d\u00e9bil de este ciclo es el intervalo entre reportes. Hasta que llega un reporte, ni el PCEF ni el OCS tienen datos sobre el consumo acumulado. Ese consumo existe solo en los contadores del DPI. Si un nodo falla o una sesi\u00f3n se traslada durante un rebalanceo, el volumen no reportado se pierde. Esta es la causa de fondo de las p\u00e9rdidas de contabilizaci\u00f3n.\r\n<h2>Punto uno: falla del nodo de procesamiento<\/h2>\r\nCuando un nodo falla, cierta p\u00e9rdida es inevitable, ya que el nodo no alcanza a enviar los datos acumulados. Pero el tama\u00f1o de la p\u00e9rdida se puede calcular de antemano:\r\n \r\n<noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/loss_formula_3_en-1.svg\" alt=\"f\u00f3rmula de p\u00e9rdida\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15002\"><\/noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/loss_formula_3_en-1.svg\" alt=\"f\u00f3rmula de p\u00e9rdida\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15002 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/loss_formula_3_en-1.svg\">\r\n \r\nLa f\u00f3rmula da una estimaci\u00f3n para un nodo con carga completa. En el intervalo entre dos reportes, un nodo as\u00ed cursa un volumen igual a su capacidad multiplicada por la duraci\u00f3n del intervalo. En promedio, la falla ocurre a la mitad de ese intervalo, por lo que se pierde aproximadamente la mitad de ese volumen.\r\n \r\nAs\u00ed se ve para un nodo con una capacidad de 200 Gbps.\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>Intervalo promedio entre reportes<\/td>\r\n<td>P\u00e9rdida por falla del nodo<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>5 minutos<\/td>\r\n<td>unos 3,75 TB<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>1 minuto<\/td>\r\n<td>unos 750 GB<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>30 segundos<\/td>\r\n<td>unos 375 GB<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nLas cifras parecen grandes, pero a la escala de un nodo no es mucho. La p\u00e9rdida econ\u00f3mica final depende de la frecuencia con que fallan los nodos y de c\u00f3mo se tarifica el tr\u00e1fico perdido.\r\n \r\nSeg\u00fan la f\u00f3rmula, la p\u00e9rdida es proporcional al intervalo entre reportes. El DPI env\u00eda un reporte cuando una sesi\u00f3n consume un volumen igual al umbral. Cuanto menor es el umbral, m\u00e1s r\u00e1pido se alcanza, m\u00e1s seguido se env\u00edan los reportes y m\u00e1s corto es el intervalo, lo que significa una p\u00e9rdida menor.\r\n \r\nEl volumen no reportado de cada sesi\u00f3n nunca supera su umbral. Por lo tanto, la p\u00e9rdida por falla de un nodo de procesamiento nunca supera la suma de los umbrales de todas las sesiones de ese nodo. As\u00ed, las p\u00e9rdidas pueden controlarse mediante los umbrales, que a su vez fija el nodo de control PCEF.\r\n \r\nPor defecto, el PCEF fija el umbral igual a la cuota del OCS. En ese caso, la suma de umbrales de un nodo equivale a la cuota multiplicada por el n\u00famero de sesiones. Eso es lo que se perder\u00e1 en el peor de los casos si el nodo falla. Para reducir este riesgo, el operador puede limitar de antemano las p\u00e9rdidas posibles.\r\n<h2>Presupuesto de riesgo<\/h2>\r\nPara ello, el PCEF de VAS Experts cuenta con un presupuesto de riesgo: el volumen m\u00e1ximo que es aceptable perder si falla un nodo. El operador puede configurarlo para el nodo en su conjunto y, por separado, para cada grupo de servicios. Cuando hay un presupuesto configurado, el PCEF verifica que la cuota otorgada a un suscriptor, multiplicada por el n\u00famero de sesiones que usan ese servicio, no lo supere.\r\n \r\nSi se supera el presupuesto, la cuota se divide: el nodo de procesamiento recibe un umbral de reporte menor. El PCEF suma por s\u00ed mismo los reportes intermedios y env\u00eda un reporte al OCS solo cuando se ha consumido toda la cuota.\r\n \r\n<noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/quota_threshold_decision_en-1.svg\" alt=\"decisi\u00f3n sobre el umbral de la cuota\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15003\"><\/noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/quota_threshold_decision_en-1.svg\" alt=\"decisi\u00f3n sobre el umbral de la cuota\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15003 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/quota_threshold_decision_en-1.svg\">\r\nFigura 2. Divisi\u00f3n de la cuota para ajustarse a un presupuesto de p\u00e9rdida definido\r\n<h3>Ejemplo de c\u00e1lculo<\/h3>\r\nEl sistema de tarificaci\u00f3n otorg\u00f3 una cuota de 100 MB. Hay dos escenarios posibles:\r\n<ol>\r\n \t<li>La cuota, considerando el n\u00famero de sesiones, cabe dentro del presupuesto de riesgo. El nodo de control fija un umbral de 100 MB. Al alcanzarse el umbral, el PCEF env\u00eda un reporte al sistema de tarificaci\u00f3n y solicita una nueva cuota.<\/li>\r\n \t<li>La cuota supera el presupuesto de riesgo. El nodo de control fija un umbral de 10 MB, y el nodo de procesamiento env\u00eda un reporte intermedio cada 10 MB. En cuanto la suma de los reportes intermedios llega a 100 MB, el nodo de control env\u00eda un reporte al sistema de tarificaci\u00f3n y solicita una nueva cuota.<\/li>\r\n<\/ol>\r\nEn lugar del presupuesto de riesgo, se puede usar una opci\u00f3n simplificada. La cuota se divide entre un coeficiente fijo o se limita a un valor constante. El ajuste se aplica a todos los servicios a la vez o a cada uno por separado. La opci\u00f3n simplificada no considera el n\u00famero de sesiones. Limita la p\u00e9rdida por sesi\u00f3n y no la del nodo de procesamiento en su conjunto. Su ventaja es que no requiere c\u00e1lculos, por lo que es un punto de partida pr\u00e1ctico para la implementaci\u00f3n.\r\n<h2>Dos frecuencias de reporte en lugar de una<\/h2>\r\nEn nuestra soluci\u00f3n, la divisi\u00f3n de la cuota la realiza el PCEF. El PCEF env\u00eda la configuraci\u00f3n a los nodos DPI mediante PFCP. Este protocolo permite asignar a un nodo DPI un umbral de reporte menor que la cuota. El PCEF determina el tama\u00f1o del umbral y lo ajusta al presupuesto de riesgo configurado. Por ejemplo, supongamos que el operador defini\u00f3 que en un nodo no pueden acumularse m\u00e1s de 100 GB de tr\u00e1fico no reportado del grupo \u201cstreaming de video\u201d. Si solo un suscriptor usa el servicio, el PCEF le asignar\u00e1 un umbral de 50 GB. Si hay un mill\u00f3n de suscriptores, el DPI reportar\u00e1 cada sesi\u00f3n aproximadamente cada 100 KB.\r\n \r\nSin divisi\u00f3n, el umbral es igual a la cuota, por lo que el DPI reporta al PCEF con la misma frecuencia con que el PCEF reporta al OCS. Con la divisi\u00f3n, estas dos frecuencias se separan y se configuran de forma independiente.\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><strong>Reportes<\/strong><\/td>\r\n<td><strong>Qu\u00e9 define la frecuencia<\/strong><\/td>\r\n<td><strong>Resultado<\/strong><\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Del nodo de control al sistema de tarificaci\u00f3n (del PCEF al OCS)<\/td>\r\n<td>La cuota otorgada por el sistema de tarificaci\u00f3n<\/td>\r\n<td>La carga sobre el sistema de tarificaci\u00f3n no cambia<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Del nodo de procesamiento al nodo de control (del DPI al PCEF)<\/td>\r\n<td>El presupuesto de riesgo<\/td>\r\n<td>La p\u00e9rdida por falla de un nodo de procesamiento no supera el presupuesto de riesgo<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nSin divisi\u00f3n, el operador tiene que elegir. Los reportes frecuentes reducen las p\u00e9rdidas por falla, pero cargan al OCS. Los reportes poco frecuentes alivian al OCS, pero aumentan las p\u00e9rdidas. Con la divisi\u00f3n, solo se vuelven m\u00e1s frecuentes los reportes del nodo de procesamiento al nodo de control. Este intercambio ocurre dentro del gateway de servicios y cuesta menos que la comunicaci\u00f3n con el sistema de tarificaci\u00f3n.\r\n<h2>Tres condiciones para que el mecanismo funcione correctamente<\/h2>\r\n<h3>Los reportes intermedios no se env\u00edan al sistema de tarificaci\u00f3n<\/h3>\r\nLos reportes intermedios no se transmiten al OCS. El OCS recibe un reporte cuando se ha consumido toda la cuota, y tambi\u00e9n cuando la cuota vence o la sesi\u00f3n termina. Los reportes intermedios multiplicar\u00edan la carga sobre el OCS por el n\u00famero de partes en que se divide la cuota, que es justamente lo que la divisi\u00f3n busca evitar.\r\n<h3>La acci\u00f3n por agotamiento de cuota se ejecuta solo despu\u00e9s de consumir toda la cuota<\/h3>\r\nEl sistema de tarificaci\u00f3n puede asignar una acci\u00f3n para cuando se agota la cuota: bloqueo o redirecci\u00f3n. Un umbral intermedio solo dispara el env\u00edo de un reporte, mientras que la acci\u00f3n se ejecuta cuando se ha consumido toda la cuota. Si la acci\u00f3n estuviera vinculada al umbral intermedio, un suscriptor con una cuota de 100 MB quedar\u00eda bloqueado despu\u00e9s de apenas 10 MB.\r\n<h3>La divisi\u00f3n tiene un l\u00edmite inferior<\/h3>\r\nCuanto m\u00e1s peque\u00f1a es cada parte de la cuota, m\u00e1s reportes hay, y si la cuota se divide demasiado, el intercambio interno tambi\u00e9n se convierte en una carga considerable. Por eso el umbral tiene un valor m\u00ednimo. Si ni siquiera con ese m\u00ednimo se puede respetar el presupuesto de riesgo, el PCEF genera una advertencia: no es aceptable superar el presupuesto sin notificar al operador.\r\n<h2>Punto dos: rebalanceo<\/h2>\r\nLas p\u00e9rdidas durante un rebalanceo son menos visibles que las p\u00e9rdidas por falla. Cuando la distribuci\u00f3n de suscriptores entre nodos se calcula en funci\u00f3n de la lista de nodos activos, cualquier cambio en esa lista traslada algunas sesiones a otros nodos. El suscriptor pierde la conexi\u00f3n, y eso se nota. Pero el volumen acumulado en el nodo anterior desde el \u00faltimo reporte desaparece junto con la sesi\u00f3n.\r\n \r\nEl rebalanceo no solo se produce por fallas, sino tambi\u00e9n por la incorporaci\u00f3n planificada de un nodo DPI, una operaci\u00f3n habitual para ampliar la capacidad. Es decir, los datos de contabilizaci\u00f3n se pierden justamente cuando, en apariencia, se est\u00e1 mejorando la red.\r\n \r\nDescubra c\u00f3mo crecer sin afectar a los suscriptores en nuestro art\u00edculo <a href=\"\/es\/blog\/mobile-networks\/scaling-in-a-cups-architecture-how-to-grow-without-disrupting-subscribers\/\">Escalamiento en el modelo CUPS: c\u00f3mo crecer sin afectar a los suscriptores<\/a>.\r\n \r\nPara que el volumen no se pierda, la sesi\u00f3n se traslada al nuevo nodo de forma controlada:\r\n<ol>\r\n \t<li>El PCEF crea una sesi\u00f3n en el nodo de destino, le transfiere los servicios y perfiles del suscriptor y fija el umbral en la cuota restante.<\/li>\r\n \t<li>El tr\u00e1fico del suscriptor se conmuta al nodo de destino.<\/li>\r\n \t<li>El PCEF termina la sesi\u00f3n en el nodo de origen, y este env\u00eda un reporte final.<\/li>\r\n \t<li>El PCEF suma los vol\u00famenes contabilizados por ambos nodos y fija un nuevo umbral en el nodo de destino.<\/li>\r\n<\/ol>\r\n<noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/session_migration_en-1.svg\" alt=\"traslado de una sesi\u00f3n\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15004\"><\/noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/session_migration_en-1.svg\" alt=\"traslado de una sesi\u00f3n\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15004 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/10\/session_migration_en-1.svg\">\r\nFigura 3. Traslado de una sesi\u00f3n sin perder datos de contabilizaci\u00f3n: suma de vol\u00famenes y umbral absoluto en el nodo de destino\r\n \r\nCon este tipo de traslado no se pierde nada. El nodo de origen termina la sesi\u00f3n de forma normal y, antes de hacerlo, env\u00eda todo el volumen acumulado. Tampoco hay doble contabilizaci\u00f3n. Cada byte lo contabiliza solo uno de los dos nodos, y el nuevo umbral del nodo de destino se fija como un valor absoluto calculado a partir del consumo total en ambos nodos, no como un incremento sobre lo que el nodo de destino ya contabiliz\u00f3.\r\n \r\nEl traslado controlado tiene una ventaja m\u00e1s. La conexi\u00f3n del suscriptor no se interrumpe y el consumo se conoce con exactitud. Esto significa que no es necesario cerrar y volver a abrir la sesi\u00f3n de tarificaci\u00f3n. Con un gran n\u00famero de sesiones, la diferencia es significativa. Cerrar y volver a abrir una sola sesi\u00f3n de tarificaci\u00f3n requiere cuatro mensajes: una solicitud y una respuesta para cerrarla, y una solicitud y una respuesta para abrirla. Si se retira de servicio un nodo de procesamiento con cuatro millones de sesiones cerr\u00e1ndolas y volvi\u00e9ndolas a abrir, el sistema de tarificaci\u00f3n recibir\u00e1 hasta diecis\u00e9is millones de mensajes. Con un traslado controlado, no hay ning\u00fan intercambio con el sistema de tarificaci\u00f3n.\r\n \r\n[product id=\u00bb10980\u2033 type=\u00bbdark\u00bb]\r\n<h2>Punto tres: conmutaci\u00f3n del nodo de control<\/h2>\r\nEl PCEF mantiene en memoria el estado de las sesiones de tarificaci\u00f3n: cuotas otorgadas, vol\u00famenes consumidos, plazos de validez de las cuotas y n\u00fameros de las solicitudes enviadas al sistema de tarificaci\u00f3n. Con la divisi\u00f3n de cuotas, ah\u00ed tambi\u00e9n se guardan los totales acumulados de los reportes intermedios. Cuando un nodo de control falla, otro nodo de control asume sus sesiones. Sin ese estado, el nuevo nodo no sabe cu\u00e1nta cuota queda ni cu\u00e1ndo vence. Por eso el estado de las sesiones se guarda en un almacenamiento compartido, accesible para todos los nodos PCEF. Este almacenamiento debe cumplir dos requisitos.\r\n<h3>Los plazos de validez de las cuotas se guardan como hora absoluta de vencimiento, no como tiempo restante<\/h3>\r\nUn registro que dice \u201cla cuota es v\u00e1lida por 400 segundos m\u00e1s\u201d no le sirve a un nuevo nodo de control, porque no sabe cu\u00e1ndo se cre\u00f3 el registro. Un registro que dice \u201cla cuota es v\u00e1lida hasta las 14:32:07\u201d es inequ\u00edvoco en cualquier momento. Este requisito supone que los relojes de todos los nodos PCEF est\u00e1n sincronizados.\r\n<h3>El n\u00famero de solicitud al sistema de tarificaci\u00f3n se guarda en el almacenamiento antes de enviar la solicitud, no despu\u00e9s<\/h3>\r\nCada solicitud al OCS dentro de una sesi\u00f3n recibe su propio n\u00famero. El OCS descarta como duplicada una solicitud con un n\u00famero ya utilizado. Supongamos que un nodo de control envi\u00f3 una solicitud y fall\u00f3 antes de guardar el n\u00famero en el almacenamiento. El nuevo nodo de control tomar\u00e1 del almacenamiento el \u00faltimo n\u00famero guardado y lo reutilizar\u00e1. El OCS descartar\u00e1 la solicitud, no se otorgar\u00e1 una nueva cuota y la sesi\u00f3n se quedar\u00e1 sin cuota. Para evitarlo, basta con guardar primero el n\u00famero de solicitud en el almacenamiento y solo despu\u00e9s enviar la solicitud. Esto es f\u00e1cil de implementar en el c\u00f3digo. Lo dif\u00edcil es detectar el error. Ocurre rara vez y parece una falla aleatoria que afecta a un solo suscriptor.\r\n<h2>Punto cuatro: cambio del conjunto de reglas durante una sesi\u00f3n<\/h2>\r\nEl PCRF puede cambiar el conjunto de reglas en plena sesi\u00f3n, por ejemplo, al pasar de un plan tarifario diurno a uno nocturno. El volumen contabilizado antes del cambio debe tarificarse seg\u00fan las reglas anteriores. De lo contrario, el tr\u00e1fico consumido con el plan diurno se tarificar\u00e1 con la tarifa nocturna.\r\n \r\nEl mecanismo es simple, pero requiere un orden estricto de pasos:\r\n<ol>\r\n \t<li>El DPI recibe las nuevas reglas del PCEF.<\/li>\r\n \t<li>El DPI env\u00eda un reporte del volumen acumulado.<\/li>\r\n \t<li>El DPI aplica las nuevas reglas.<\/li>\r\n \t<li>El DPI confirma al PCEF el cambio de reglas.<\/li>\r\n<\/ol>\r\nLa confirmaci\u00f3n se env\u00eda despu\u00e9s del reporte, as\u00ed que, cuando el PCEF se entera del cambio de reglas, todo el volumen correspondiente a las reglas anteriores ya est\u00e1 contabilizado.\r\n \r\nEntre el env\u00edo del reporte y la aplicaci\u00f3n de las nuevas reglas hay un intervalo en el que la configuraci\u00f3n de contabilizaci\u00f3n no est\u00e1 definida. Durante ese tiempo debe estar vigente una regla por defecto que bloquee el tr\u00e1fico del suscriptor:\r\n \r\n[important]Un bloqueo breve es preferible a dejar pasar tr\u00e1fico sin contabilizar.[\/important]\r\n \r\n<h2>No espere a la conciliaci\u00f3n con el billing<\/h2>\r\nLos errores de contabilizaci\u00f3n no se manifiestan de inmediato, y al final del per\u00edodo de facturaci\u00f3n ya no es posible rastrear su causa. Para detectar un problema a tiempo, monitoree estas seis m\u00e9tricas.\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><strong>M\u00e9trica<\/strong><\/td>\r\n<td><strong>Qu\u00e9 significa un aumento<\/strong><\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Diferencia entre el n\u00famero de sesiones de tarificaci\u00f3n abiertas y cerradas<\/td>\r\n<td>Algunas sesiones no terminan de forma normal y su consumo final no se reporta<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>N\u00famero de sesiones trasladadas sin reporte final<\/td>\r\n<td>Aumentan los casos de volumen perdido<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Intervalo promedio entre reportes de las sesiones activas<\/td>\r\n<td>Aumenta el multiplicador de la f\u00f3rmula de p\u00e9rdida por falla de un nodo de procesamiento<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Suma de los umbrales de todas las sesiones de un nodo de procesamiento<\/td>\r\n<td>Aumenta el l\u00edmite superior de la p\u00e9rdida si este nodo falla. Acercarse al presupuesto de riesgo es motivo para revisar la divisi\u00f3n de cuotas<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>Retraso de los nodos respecto a las actualizaciones de la tabla de distribuci\u00f3n de sesiones<\/td>\r\n<td>Los nodos usan una tabla de distribuci\u00f3n desactualizada. El tr\u00e1fico del suscriptor puede llegar a un nodo DPI que ya no atiende su sesi\u00f3n<\/td>\r\n<\/tr>\r\n<tr>\r\n<td>N\u00famero de reportes de un nodo de procesamiento que ya no atiende la sesi\u00f3n<\/td>\r\n<td>Aumenta el n\u00famero de reportes tard\u00edos<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nLa \u00faltima m\u00e9trica requiere una explicaci\u00f3n. Cuando una sesi\u00f3n se traslada a otro nodo DPI, el nodo anterior puede enviar un reporte con retraso. Por ejemplo, el reporte se envi\u00f3 antes de la conmutaci\u00f3n, pero lleg\u00f3 al PCEF despu\u00e9s. Ese reporte contiene tr\u00e1fico real del suscriptor que todav\u00eda no se ha contabilizado en ninguna parte. Si el PCEF lo descarta solo porque ese nodo ya no atiende la sesi\u00f3n, el volumen se perder\u00e1. Es decir, el gateway de servicios perder\u00e1 datos de contabilizaci\u00f3n por s\u00ed mismo, sin que haya ninguna falla. Por eso los reportes tard\u00edos deben aceptarse y sumarse al consumo de la sesi\u00f3n a la que pertenecen.\r\n<h2>Conclusi\u00f3n<\/h2>\r\nLas p\u00e9rdidas en la contabilizaci\u00f3n del tr\u00e1fico ocurren en cuatro situaciones, y solo una de ellas es inevitable: la falla de un nodo de procesamiento. El nodo no alcanza a enviar el volumen acumulado, y ese tr\u00e1fico queda fuera de la contabilizaci\u00f3n. Pero incluso en este caso la p\u00e9rdida puede mantenerse bajo control: su l\u00edmite superior es igual a la suma de los umbrales del nodo y, con el presupuesto de riesgo, el operador decide cu\u00e1nto est\u00e1 dispuesto a perder. En nuestra soluci\u00f3n, el PCEF ajusta por s\u00ed mismo los umbrales a ese presupuesto, de modo que el l\u00edmite de p\u00e9rdida ante la falla de cualquier nodo se conoce de antemano y la carga sobre el OCS no aumenta.\r\n \r\nEn las otras tres situaciones, las p\u00e9rdidas pueden evitarse si desde el principio se establece el orden correcto de las operaciones:\r\n<ul>\r\n \t<li>durante el rebalanceo, las sesiones se trasladan a otro nodo de procesamiento de forma controlada;<\/li>\r\n \t<li>los plazos de validez de las cuotas se guardan como hora absoluta;<\/li>\r\n \t<li>el n\u00famero de solicitud se guarda antes de enviar la solicitud;<\/li>\r\n \t<li>el volumen acumulado se reporta antes del cambio de reglas.<\/li>\r\n<\/ul>\r\nTodo esto es f\u00e1cil de prever. En cambio, encontrar la causa de una discrepancia despu\u00e9s de la conciliaci\u00f3n con el billing es casi imposible.\r\n \r\n[product id=\u00bb14167\u2033 type=\u00bbdark\u00bb]","protected":false},"excerpt":{"rendered":"<p>Los puntos donde se pierden datos de contabilizaci\u00f3n son pocos. Se pueden enumerar, calcular de antemano el tama\u00f1o de la p\u00e9rdida en cada uno y convertir esa p\u00e9rdida de una propiedad del sistema en un par\u00e1metro configurable. Son cuatro: la falla de un nodo de procesamiento, el rebalanceo, la conmutaci\u00f3n del nodo de control y el cambio del conjunto de reglas.<\/p>\n","protected":false},"author":7,"featured_media":14997,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[102,46],"tags":[],"class_list":["post-14996","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mobile-networks","category-solution"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v24.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>\u00bfSe pierde con la falla? C\u00f3mo calcular de antemano las p\u00e9rdidas en la contabilizaci\u00f3n del tr\u00e1fico - 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\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/\",\"url\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/\",\"name\":\"P\u00e9rdidas en la contabilizaci\u00f3n de tr\u00e1fico: presupuesto de riesgo en PCEF \u2014 VAS Experts\",\"isPartOf\":{\"@id\":\"https:\/\/vasexperts.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#primaryimage\"},\"thumbnailUrl\":\"\/wp-content\/uploads\/2026\/10\/accounting.jpg\",\"datePublished\":\"2026-10-15T11:15:56+00:00\",\"dateModified\":\"2026-10-15T11:41:55+00:00\",\"author\":{\"@id\":\"https:\/\/vasexperts.com\/#\/schema\/person\/e437e05016391b857d85b493b3173d59\"},\"description\":\"Analizamos cuatro causas de p\u00e9rdidas de contabilizaci\u00f3n en un gateway de servicios: falla del nodo DPI, rebalanceo, cambio de PCEF y de reglas, y c\u00f3mo limitarlas\",\"breadcrumb\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#breadcrumb\"},\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#primaryimage\",\"url\":\"\/wp-content\/uploads\/2026\/10\/accounting.jpg\",\"contentUrl\":\"\/wp-content\/uploads\/2026\/10\/accounting.jpg\",\"width\":850,\"height\":354,\"caption\":\"traffic accounting\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#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\":\"Gone When It Fails? How to Calculate Traffic Accounting Losses in Advance\"}]},{\"@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\/e437e05016391b857d85b493b3173d59\",\"name\":\"Elena Rudich\",\"url\":\"https:\/\/vasexperts.com\/es\/blog\/author\/elena-rudich\/\"},{\"@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":"\u00bfSe pierde con la falla? C\u00f3mo calcular de antemano las p\u00e9rdidas en la contabilizaci\u00f3n del tr\u00e1fico - 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\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/","url":"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/","name":"P\u00e9rdidas en la contabilizaci\u00f3n de tr\u00e1fico: presupuesto de riesgo en PCEF \u2014 VAS Experts","isPartOf":{"@id":"https:\/\/vasexperts.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#primaryimage"},"image":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#primaryimage"},"thumbnailUrl":"\/wp-content\/uploads\/2026\/10\/accounting.jpg","datePublished":"2026-10-15T11:15:56+00:00","dateModified":"2026-10-15T11:41:55+00:00","author":{"@id":"https:\/\/vasexperts.com\/#\/schema\/person\/e437e05016391b857d85b493b3173d59"},"description":"Analizamos cuatro causas de p\u00e9rdidas de contabilizaci\u00f3n en un gateway de servicios: falla del nodo DPI, rebalanceo, cambio de PCEF y de reglas, y c\u00f3mo limitarlas","breadcrumb":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#primaryimage","url":"\/wp-content\/uploads\/2026\/10\/accounting.jpg","contentUrl":"\/wp-content\/uploads\/2026\/10\/accounting.jpg","width":850,"height":354,"caption":"traffic accounting"},{"@type":"BreadcrumbList","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/gone-when-it-fails-how-to-calculate-traffic-accounting-losses-in-advance\/#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":"Gone When It Fails? How to Calculate Traffic Accounting Losses in Advance"}]},{"@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\/e437e05016391b857d85b493b3173d59","name":"Elena Rudich","url":"https:\/\/vasexperts.com\/es\/blog\/author\/elena-rudich\/"},{"@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\/14996"}],"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\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/comments?post=14996"}],"version-history":[{"count":9,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/posts\/14996\/revisions"}],"predecessor-version":[{"id":15012,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/posts\/14996\/revisions\/15012"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/media\/14997"}],"wp:attachment":[{"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/media?parent=14996"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/categories?post=14996"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vasexperts.com\/es\/wp-json\/wp\/v2\/tags?post=14996"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}