En este artículo analizaremos cada uno de ellos, mostraremos cómo estimar y limitar las pérdidas, y qué métricas conviene monitorear para detectar un problema a tiempo.
Cómo funciona la contabilización en un gateway de servicios
Un gateway de servicios está formado por nodos de procesamiento y nodos de control. En la contabilización del tráfico participan varios componentes:
- Nodo de procesamiento (DPI): componente del gateway de servicios en el plano de usuario (user plane) por el que pasa físicamente el tráfico de los suscriptores.
- Nodo de control (PCEF): componente del gateway de servicios en el plano de control (control plane) que envía a los nodos de procesamiento los umbrales de cada grupo de contabilización y recibe los reportes de consumo.
- Billing (OCS): sistema de tarificación externo. Otorga cuotas de tráfico y recibe los reportes de consumo.
- PCRF: sistema externo de gestión de políticas. Define la política de servicio del suscriptor y el conjunto de grupos que el suscriptor tiene permitido usar. En ocasiones, el PCRF también cumple la función de OCS.
Figura 1. Arquitectura del gateway de servicios
La unidad básica de contabilización es el grupo de contabilización. Agrupa el tráfico de varios servicios que se tarifican de la misma manera, y el DPI reporta su volumen total. Por ejemplo, un grupo “streaming de video” con los identificadores RG 10 y SI 0 (Rating Group y Service Identifier) puede reunir el tráfico de YouTube y de otros servicios de video.
El DPI clasifica los paquetes, los asigna a grupos de contabilización y lleva un contador de volumen para cada grupo. El PCEF obtiene los datos de volumen a partir de los reportes del DPI. Además, el PCEF almacena el estado de las sesiones: créditos otorgados, volumen consumido y plazos de validez de las cuotas.
El PCRF también define los límites de velocidad de cada grupo de contabilización. El OCS otorga volúmenes para cada grupo permitido y recibe los reportes de consumo.
El ciclo de contabilización comienza en el PCRF. Este le indica al PCEF qué grupos de contabilización están disponibles para el suscriptor. El PCEF solicita al OCS volúmenes para cada grupo permitido y envía al DPI el conjunto de grupos con sus límites y umbrales.
Figura 2. El ciclo de contabilización
Cuando el consumo de un grupo alcanza el umbral, el DPI envía un reporte al PCEF. El reporte también 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ía al DPI. Toda la comunicación entre el DPI y el OCS pasa por el PCEF.
El punto débil 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ón se traslada durante un rebalanceo, el volumen no reportado se pierde. Esta es la causa de fondo de las pérdidas de contabilización.
Punto uno: falla del nodo de procesamiento
Cuando un nodo falla, cierta pérdida es inevitable, ya que el nodo no alcanza a enviar los datos acumulados. Pero el tamaño de la pérdida se puede calcular de antemano:
La fórmula da una estimación para un nodo con carga completa. En el intervalo entre dos reportes, un nodo así cursa un volumen igual a su capacidad multiplicada por la duración del intervalo. En promedio, la falla ocurre a la mitad de ese intervalo, por lo que se pierde aproximadamente la mitad de ese volumen.
Así se ve para un nodo con una capacidad de 200 Gbps.
| Intervalo promedio entre reportes | Pérdida por falla del nodo |
| 5 minutos | unos 3,75 TB |
| 1 minuto | unos 750 GB |
| 30 segundos | unos 375 GB |
Las cifras parecen grandes, pero a la escala de un nodo no es mucho. La pérdida económica final depende de la frecuencia con que fallan los nodos y de cómo se tarifica el tráfico perdido.
Según la fórmula, la pérdida es proporcional al intervalo entre reportes. El DPI envía un reporte cuando una sesión consume un volumen igual al umbral. Cuanto menor es el umbral, más rápido se alcanza, más seguido se envían los reportes y más corto es el intervalo, lo que significa una pérdida menor.
El volumen no reportado de cada sesión nunca supera su umbral. Por lo tanto, la pérdida por falla de un nodo de procesamiento nunca supera la suma de los umbrales de todas las sesiones de ese nodo. Así, las pérdidas pueden controlarse mediante los umbrales, que a su vez fija el nodo de control PCEF.
Por 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úmero de sesiones. Eso es lo que se perderá en el peor de los casos si el nodo falla. Para reducir este riesgo, el operador puede limitar de antemano las pérdidas posibles.
Presupuesto de riesgo
Para ello, el PCEF de VAS Experts cuenta con un presupuesto de riesgo: el volumen máximo 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úmero de sesiones que usan ese servicio, no lo supere.
Si se supera el presupuesto, la cuota se divide: el nodo de procesamiento recibe un umbral de reporte menor. El PCEF suma por sí mismo los reportes intermedios y envía un reporte al OCS solo cuando se ha consumido toda la cuota.
Figura 2. División de la cuota para ajustarse a un presupuesto de pérdida definido
Ejemplo de cálculo
El sistema de tarificación otorgó una cuota de 100 MB. Hay dos escenarios posibles:
- La cuota, considerando el número 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ía un reporte al sistema de tarificación y solicita una nueva cuota.
- La cuota supera el presupuesto de riesgo. El nodo de control fija un umbral de 10 MB, y el nodo de procesamiento envía un reporte intermedio cada 10 MB. En cuanto la suma de los reportes intermedios llega a 100 MB, el nodo de control envía un reporte al sistema de tarificación y solicita una nueva cuota.
En lugar del presupuesto de riesgo, se puede usar una opción 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ón simplificada no considera el número de sesiones. Limita la pérdida por sesión y no la del nodo de procesamiento en su conjunto. Su ventaja es que no requiere cálculos, por lo que es un punto de partida práctico para la implementación.
Dos frecuencias de reporte en lugar de una
En nuestra solución, la división de la cuota la realiza el PCEF. El PCEF envía la configuración 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ño del umbral y lo ajusta al presupuesto de riesgo configurado. Por ejemplo, supongamos que el operador definió que en un nodo no pueden acumularse más de 100 GB de tráfico no reportado del grupo “streaming de video”. Si solo un suscriptor usa el servicio, el PCEF le asignará un umbral de 50 GB. Si hay un millón de suscriptores, el DPI reportará cada sesión aproximadamente cada 100 KB.
Sin división, 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ón, estas dos frecuencias se separan y se configuran de forma independiente.
| Reportes | Qué define la frecuencia | Resultado |
| Del nodo de control al sistema de tarificación (del PCEF al OCS) | La cuota otorgada por el sistema de tarificación | La carga sobre el sistema de tarificación no cambia |
| Del nodo de procesamiento al nodo de control (del DPI al PCEF) | El presupuesto de riesgo | La pérdida por falla de un nodo de procesamiento no supera el presupuesto de riesgo |
Sin división, el operador tiene que elegir. Los reportes frecuentes reducen las pérdidas por falla, pero cargan al OCS. Los reportes poco frecuentes alivian al OCS, pero aumentan las pérdidas. Con la división, solo se vuelven más 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ón con el sistema de tarificación.
Tres condiciones para que el mecanismo funcione correctamente
Los reportes intermedios no se envían al sistema de tarificación
Los reportes intermedios no se transmiten al OCS. El OCS recibe un reporte cuando se ha consumido toda la cuota, y también cuando la cuota vence o la sesión termina. Los reportes intermedios multiplicarían la carga sobre el OCS por el número de partes en que se divide la cuota, que es justamente lo que la división busca evitar.
La acción por agotamiento de cuota se ejecuta solo después de consumir toda la cuota
El sistema de tarificación puede asignar una acción para cuando se agota la cuota: bloqueo o redirección. Un umbral intermedio solo dispara el envío de un reporte, mientras que la acción se ejecuta cuando se ha consumido toda la cuota. Si la acción estuviera vinculada al umbral intermedio, un suscriptor con una cuota de 100 MB quedaría bloqueado después de apenas 10 MB.
La división tiene un límite inferior
Cuanto más pequeña es cada parte de la cuota, más reportes hay, y si la cuota se divide demasiado, el intercambio interno también se convierte en una carga considerable. Por eso el umbral tiene un valor mínimo. Si ni siquiera con ese mínimo se puede respetar el presupuesto de riesgo, el PCEF genera una advertencia: no es aceptable superar el presupuesto sin notificar al operador.
Punto dos: rebalanceo
Las pérdidas durante un rebalanceo son menos visibles que las pérdidas por falla. Cuando la distribución de suscriptores entre nodos se calcula en función de la lista de nodos activos, cualquier cambio en esa lista traslada algunas sesiones a otros nodos. El suscriptor pierde la conexión, y eso se nota. Pero el volumen acumulado en el nodo anterior desde el último reporte desaparece junto con la sesión.
El rebalanceo no solo se produce por fallas, sino también por la incorporación planificada de un nodo DPI, una operación habitual para ampliar la capacidad. Es decir, los datos de contabilización se pierden justamente cuando, en apariencia, se está mejorando la red.
Descubra cómo crecer sin afectar a los suscriptores en nuestro artículo Escalamiento en el modelo CUPS: cómo crecer sin afectar a los suscriptores.
Para que el volumen no se pierda, la sesión se traslada al nuevo nodo de forma controlada:
- El PCEF crea una sesión en el nodo de destino, le transfiere los servicios y perfiles del suscriptor y fija el umbral en la cuota restante.
- El tráfico del suscriptor se conmuta al nodo de destino.
- El PCEF termina la sesión en el nodo de origen, y este envía un reporte final.
- El PCEF suma los volúmenes contabilizados por ambos nodos y fija un nuevo umbral en el nodo de destino.
Figura 3. Traslado de una sesión sin perder datos de contabilización: suma de volúmenes y umbral absoluto en el nodo de destino
Con este tipo de traslado no se pierde nada. El nodo de origen termina la sesión de forma normal y, antes de hacerlo, envía todo el volumen acumulado. Tampoco hay doble contabilización. 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ó.
El traslado controlado tiene una ventaja más. La conexión 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ón de tarificación. Con un gran número de sesiones, la diferencia es significativa. Cerrar y volver a abrir una sola sesión de tarificación 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ándolas y volviéndolas a abrir, el sistema de tarificación recibirá hasta dieciséis millones de mensajes. Con un traslado controlado, no hay ningún intercambio con el sistema de tarificación.
Punto tres: conmutación del nodo de control
El PCEF mantiene en memoria el estado de las sesiones de tarificación: cuotas otorgadas, volúmenes consumidos, plazos de validez de las cuotas y números de las solicitudes enviadas al sistema de tarificación. Con la división de cuotas, ahí también 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ánta cuota queda ni cuándo 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.
Los plazos de validez de las cuotas se guardan como hora absoluta de vencimiento, no como tiempo restante
Un registro que dice “la cuota es válida por 400 segundos más” no le sirve a un nuevo nodo de control, porque no sabe cuándo se creó el registro. Un registro que dice “la cuota es válida hasta las 14:32:07” es inequívoco en cualquier momento. Este requisito supone que los relojes de todos los nodos PCEF están sincronizados.
El número de solicitud al sistema de tarificación se guarda en el almacenamiento antes de enviar la solicitud, no después
Cada solicitud al OCS dentro de una sesión recibe su propio número. El OCS descarta como duplicada una solicitud con un número ya utilizado. Supongamos que un nodo de control envió una solicitud y falló antes de guardar el número en el almacenamiento. El nuevo nodo de control tomará del almacenamiento el último número guardado y lo reutilizará. El OCS descartará la solicitud, no se otorgará una nueva cuota y la sesión se quedará sin cuota. Para evitarlo, basta con guardar primero el número de solicitud en el almacenamiento y solo después enviar la solicitud. Esto es fácil de implementar en el código. Lo difícil es detectar el error. Ocurre rara vez y parece una falla aleatoria que afecta a un solo suscriptor.
Punto cuatro: cambio del conjunto de reglas durante una sesión
El PCRF puede cambiar el conjunto de reglas en plena sesión, por ejemplo, al pasar de un plan tarifario diurno a uno nocturno. El volumen contabilizado antes del cambio debe tarificarse según las reglas anteriores. De lo contrario, el tráfico consumido con el plan diurno se tarificará con la tarifa nocturna.
El mecanismo es simple, pero requiere un orden estricto de pasos:
- El DPI recibe las nuevas reglas del PCEF.
- El DPI envía un reporte del volumen acumulado.
- El DPI aplica las nuevas reglas.
- El DPI confirma al PCEF el cambio de reglas.
La confirmación se envía después del reporte, así que, cuando el PCEF se entera del cambio de reglas, todo el volumen correspondiente a las reglas anteriores ya está contabilizado.
Entre el envío del reporte y la aplicación de las nuevas reglas hay un intervalo en el que la configuración de contabilización no está definida. Durante ese tiempo debe estar vigente una regla por defecto que bloquee el tráfico del suscriptor:
No espere a la conciliación con el billing
Los errores de contabilización no se manifiestan de inmediato, y al final del período de facturación ya no es posible rastrear su causa. Para detectar un problema a tiempo, monitoree estas seis métricas.
| Métrica | Qué significa un aumento |
| Diferencia entre el número de sesiones de tarificación abiertas y cerradas | Algunas sesiones no terminan de forma normal y su consumo final no se reporta |
| Número de sesiones trasladadas sin reporte final | Aumentan los casos de volumen perdido |
| Intervalo promedio entre reportes de las sesiones activas | Aumenta el multiplicador de la fórmula de pérdida por falla de un nodo de procesamiento |
| Suma de los umbrales de todas las sesiones de un nodo de procesamiento | Aumenta el límite superior de la pérdida si este nodo falla. Acercarse al presupuesto de riesgo es motivo para revisar la división de cuotas |
| Retraso de los nodos respecto a las actualizaciones de la tabla de distribución de sesiones | Los nodos usan una tabla de distribución desactualizada. El tráfico del suscriptor puede llegar a un nodo DPI que ya no atiende su sesión |
| Número de reportes de un nodo de procesamiento que ya no atiende la sesión | Aumenta el número de reportes tardíos |
La última métrica requiere una explicación. Cuando una sesión se traslada a otro nodo DPI, el nodo anterior puede enviar un reporte con retraso. Por ejemplo, el reporte se envió antes de la conmutación, pero llegó al PCEF después. Ese reporte contiene tráfico real del suscriptor que todavía no se ha contabilizado en ninguna parte. Si el PCEF lo descarta solo porque ese nodo ya no atiende la sesión, el volumen se perderá. Es decir, el gateway de servicios perderá datos de contabilización por sí mismo, sin que haya ninguna falla. Por eso los reportes tardíos deben aceptarse y sumarse al consumo de la sesión a la que pertenecen.
Conclusión
Las pérdidas en la contabilización del tráfico 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áfico queda fuera de la contabilización. Pero incluso en este caso la pérdida puede mantenerse bajo control: su límite superior es igual a la suma de los umbrales del nodo y, con el presupuesto de riesgo, el operador decide cuánto está dispuesto a perder. En nuestra solución, el PCEF ajusta por sí mismo los umbrales a ese presupuesto, de modo que el límite de pérdida ante la falla de cualquier nodo se conoce de antemano y la carga sobre el OCS no aumenta.
En las otras tres situaciones, las pérdidas pueden evitarse si desde el principio se establece el orden correcto de las operaciones:
- durante el rebalanceo, las sesiones se trasladan a otro nodo de procesamiento de forma controlada;
- los plazos de validez de las cuotas se guardan como hora absoluta;
- el número de solicitud se guarda antes de enviar la solicitud;
- el volumen acumulado se reporta antes del cambio de reglas.
Todo esto es fácil de prever. En cambio, encontrar la causa de una discrepancia después de la conciliación con el billing es casi imposible.
