El operador enfrenta un problema similar a escala de toda la red. Ante la congestión en horas pico o durante eventos masivos, el núcleo envía perfiles actualizados con ancho de banda reducido y baja la velocidad a todos los suscriptores a la vez. Todos los servicios compiten sin distinción por el recurso restante. El video y las llamadas, con los que el suscriptor juzga la calidad de la red, son los primeros en degradarse, y al operador le resulta difícil redistribuir rápidamente el ancho de banda entre servicios.
El problema no está en fallas del equipo ni en la configuración de una red en particular. El estándar 3GPP (3rd Generation Partnership Project) describe mecanismos para limitar el ancho de banda del suscriptor y de servicios individuales, pero no define qué servicio obtiene el ancho de banda primero cuando no alcanza para todos. En este artículo veremos dónde está ese vacío del estándar y cómo lo resuelve el PCEF de VAS Experts.
Hay un techo, pero no hay reglas
Para entender de dónde surge este vacío, hay que adentrarse en la especificación 3GPP TS 23.203 «Policy and charging control architecture» (arquitectura de control de políticas y tarificación).
La arquitectura de QoS en 3GPP se basa en portadores: bearers en LTE y QoS Flows en 5G. Un portador es un canal lógico entre el dispositivo del suscriptor y el gateway de paquetes, con su propio conjunto de parámetros de calidad.
Dedicated Bearer
Si un flujo de datos necesita determinados parámetros de servicio (velocidad garantizada, latencia admisible y tasa de pérdida de paquetes) o cierta prioridad, se crea para él un portador independiente (Dedicated Bearer) con su propio perfil de QoS (QCI/5QI, ARP).
Según el estándar, también se puede definir la prioridad mediante ARP (Allocation and Retention Priority), pero se trata de la prioridad del portador, no de un servicio individual. Mediante SDF (service definition function), los servicios se distribuyen entre portadores con QCI y ARP definidos. Cuando faltan recursos de radio, un portador con ARP bajo no se crea, y uno existente puede eliminarse por completo. Es decir, la prioridad la tiene el portador, pero solo afecta a la creación o eliminación del portador completo con todos los servicios que contiene, y no permite distribuir de forma flexible el ancho de banda entre servicios.
Default Bearer
Todo el tráfico de los servicios para los que no se creó un canal dedicado (web, mensajería, YouTube, torrents, actualizaciones en segundo plano) pasa por el canal base, o portador predeterminado (Default Bearer). Siempre es un portador non-GBR (Non-Guaranteed Bit Rate) y normalmente se le asigna la clase de baja prioridad QCI 9. El tráfico de esta clase se procesa según la capacidad disponible (best effort) y su entrega no está garantizada. Para todo el tráfico non-GBR, el estándar prevé un parámetro común: APN-AMBR.
Según la especificación 3GPP, la función del PCEF (Policy and Charging Enforcement Function) es controlar que la velocidad total de todos los flujos de datos de servicio (SDF) non-GBR dentro de un punto de acceso a la red (APN) no supere ese techo. El estándar no describe cómo distribuir el ancho de banda entre flujos que compiten cuando su demanda total supera el techo. Por eso, en las interfaces mediante las cuales el servidor de políticas (PCRF) envía reglas al PCEF (por ejemplo, Gx sobre el protocolo Diameter), no existen atributos (AVP) que permitan transmitir esa distribución.
Imaginemos que el plan del suscriptor es de 50 Mbps, mientras que un torrent o la actualización de un juego pueden ocupar hasta 100 Mbps, de modo que el canal se satura por completo. Los paquetes de la app de mensajería pasan por el mismo policer que el torrent. No hay reglas de balanceo, así que el policer recorta el tráfico sin distinguir entre servicios. Así, casi todo el ancho de banda se lo lleva quien genera más tráfico; en nuestro caso, el torrent.
El estándar 3GPP regula estrictamente las interfaces entre nodos, pero deja intencionalmente a criterio de los fabricantes la lógica de planificación (scheduling) y la competencia del tráfico dentro de un mismo APN. Como resultado, el estándar no tiene ningún mecanismo para distribuir el ancho de banda entre servicios según su prioridad.
QoS jerárquico en el PCEF de VAS Experts
En VAS Experts, esta tarea se resuelve con QoS jerárquico (HQoS) en el PCEF con perfiles locales. El ancho de banda del suscriptor no se amplía, sino que se distribuye entre los servicios según su prioridad. Los tipos de tráfico prioritarios, como la voz y la web, lo reciben primero, y el P2P y las descargas en segundo plano usan el resto.
Dos niveles de policing
El nivel superior de la jerarquía es la clase raíz HTB (root), es decir, el ancho de banda total del suscriptor. Se define en el perfil de policing (plan tarifario). Aquí se asigna el valor de APN-AMBR (o la velocidad del plan de internet residencial), por ejemplo, 50 Mbps. En total, el suscriptor no podrá superar este techo.
En el segundo nivel (leaf classes) hay ocho clases, de class0 a class7. Por defecto, class0 tiene la prioridad más alta y class7, la más baja. El motor DPI basado en firmas reconoce el protocolo o el destino del tráfico (YouTube, BitTorrent, Telegram) y asigna el flujo a la clase correspondiente. La distribución por clases se define mediante un marcado global por protocolos y destinos, o mediante un marcado individual por protocolos para un suscriptor concreto. Las clases se vinculan con los grupos de tarificación (rating groups) mediante una tabla de correspondencia.
Figura 1 – Niveles de vigilancia policial
Cómo se reparte el ancho de banda entre las clases
El administrador puede elegir entre dos mecanismos de policing.
El mecanismo principal es HTB (Hierarchical Token Bucket), que implementa el QoS jerárquico. Cuando llega un nuevo valor de APN-AMBR desde el PCRF, el sistema lo traslada dinámicamente a la clase raíz y distribuye ese ancho de banda entre las clases. Para cada una de las ocho clases se definen una velocidad garantizada (rate) y una máxima (ceil).
Qué aporta: el servicio prioritario obtiene su ancho de banda en cuanto aparece su tráfico, y el de baja prioridad usa todo lo que queda libre. Cuando no hay tráfico de alta prioridad, el de baja prioridad puede usar toda la velocidad disponible.
Ejemplo de distribución del ancho de banda por clases para un plan de 50 Mbps: # Tráfico entrante (hacia el suscriptor), plan de 50 Mbps htb_inbound_root=rate 50mbit # class0 — llamadas: 5 Mbps garantizados htb_inbound_class0=rate 5mbit ceil 50mbit # class1 — video: 20 Mbps garantizados htb_inbound_class1=rate 20mbit ceil 50mbit htb_inbound_class2=rate 8bit ceil 50mbit htb_inbound_class3=rate 8bit ceil 50mbit htb_inbound_class4=rate 8bit ceil 50mbit htb_inbound_class5=rate 8bit ceil 50mbit htb_inbound_class6=rate 8bit ceil 50mbit # class7 — torrents: 1 Mbps garantizado, pero puede ocupar todo el canal cuando está libre htb_inbound_class7=rate 1mbit ceil 50mbit
El segundo es TBF (Token Bucket Filter), un policer sin jerarquía. Limita cada clase de forma independiente: a la clase se le asigna un techo fijo (rate) y no lo supera aunque el resto del ancho de banda esté libre. Las clases sin un límite definido no se restringen. TBF no tiene un techo general.
Qué aporta: una limitación estricta y predecible, o el bloqueo de una clase de tráfico específica.
Ejemplo de limitación estricta de torrents a 3 Mbps:
tbf_inbound_class7=rate 3mbit tbf_class7=rate 3mbit
Qué ganan los suscriptores y los operadores
Ahora el suscriptor puede hablar tranquilamente por la app de mensajería mientras descarga un archivo grande, porque el torrent va en class7, con la prioridad más baja, y usa los 50 Mbps completos mientras otros servicios no necesitan el canal. En cuanto el suscriptor inicia una llamada o abre YouTube, ese tráfico entra en class0 o class1, y el planificador HTB le quita de inmediato ancho de banda al torrent en favor del servicio prioritario. La llamada ya no se corta, el video se reproduce sin pausas y el torrent sigue descargando, solo que más lento.
La velocidad del plan no cambió. Solo cambió su distribución entre los servicios.
Además, el operador obtiene la máxima calidad de los recursos que ya tiene. Incluso si, ante una congestión, el núcleo reduce el APN-AMBR a 7–10 Mbps, las prioridades dentro del límite se mantienen. El ancho de banda reducido se destina ante todo al video y a las llamadas, por lo que el video se reproduce sin rebuffering y las llamadas en el mensajero MAX se mantienen en Full HD.
Menos trabajo manual para el operador
Sin prioridades, los rating groups deben equilibrarse manualmente: ampliar uno para que no se ahogue otro y tener en cuenta el volumen total de tráfico para que todo funcione en conjunto.
Con HQoS, el operador asigna una sola vez una clase de prioridad a cada servicio. El operador define las clases y su orden según su modelo de negocio y según qué servicios influyen más en la experiencia del usuario. El perfil de policing se crea una sola vez y se asigna a los suscriptores. A partir de ahí, el ancho de banda se distribuye automáticamente en cada sesión de suscriptor, sin importar cómo cambien la carga de la red y el ancho de banda asignado al suscriptor. Las clases no utilizadas pueden activarse más adelante: basta con cambiar el marcado en el DPI, sin necesidad de modificar el perfil.
Si en su red los suscriptores se quejan de llamadas que se cortan y video que se traba aunque el canal de radio funciona correctamente, y ante la congestión tiene que restringir el ancho de banda a todos por igual, vale la pena ver cómo funciona HQoS en Stingray PCEF con su tráfico. Los especialistas de VAS Experts le ayudarán a distribuir los servicios en clases de prioridad según su modelo de negocio y sus planes tarifarios. Escríbanos y conversemos por dónde empezar.
