Guía de Operaciones de OmniUPF
Tabla de Contenidos
- Descripción General
- Comprendiendo la Arquitectura del Plano de Usuario 5G
- Componentes del UPF
- Protocolo PFCP e Integración SMF
- Operaciones Comunes
- Resolución de Problemas
- Documentación Adicional
- Glosario
Descripción General
OmniUPF (Función de Plano de Usuario basada en eBPF) es una Función de Plano de Usuario 5G/LTE de alto rendimiento que proporciona reenvío de paquetes de grado de operador, aplicación de QoS y gestión de tráfico para redes móviles. Construido sobre la tecnología eBPF de Linux (Filtro de Paquetes de Berkeley extendido) y mejorado con capacidades de gestión integrales, OmniUPF ofrece la infraestructura central de procesamiento de paquetes requerida para redes 5G SA, 5G NSA y LTE.
¿Qué es una Función de Plano de Usuario?
La Función de Plano de Usuario (UPF) es el elemento de red estandarizado por 3GPP responsable del procesamiento y reenvío de paquetes en redes 5G y LTE. Proporciona:
- Reenvío de paquetes de alta velocidad entre dispositivos móviles y redes de datos
- Aplicación de Calidad de Servicio (QoS) para diferentes tipos de tráfico
- Detección y enrutamiento de tráfico basado en filtros y reglas de paquetes
- Informe de uso para facturación y análisis
- Buffering de paquetes para escenarios de gestión de movilidad y sesiones
- Soporte para intercepción legal para cumplimiento normativo
OmniUPF implementa la funcionalidad completa de UPF definida en 3GPP TS 23.501 (5G) y TS 23.401 (LTE), proporcionando una solución de plano de usuario completa y lista para producción utilizando la tecnología eBPF del núcleo de Linux para un rendimiento máximo.
Capacidades Clave de OmniUPF
Procesamiento de Paquetes:
- Procesamiento de paquetes de plano de usuario totalmente compatible con 3GPP
- Ruta de datos basada en eBPF para un rendimiento a nivel de núcleo
- Encapsulación y desencapsulación de GTP-U (Protocolo de Túnel GPRS)
- Soporte para IPv4 e IPv6 tanto para redes de acceso como de datos
- XDP (Ruta de Datos eXpress) para procesamiento de latencia ultra baja
- Procesamiento de paquetes multihilo
QoS y Gestión de Tráfico:
- Reglas de Aplicación de QoS (QER) para gestión de ancho de banda
- Reglas de Detección de Paquetes (PDR) para clasificación de tráfico
- Reglas de Acción de Reenvío (FAR) para decisiones de enrutamiento
- Filtrado de Flujo de Datos de Servicio (SDF) para enrutamiento específico de aplicaciones
- Reglas de Informe de Uso (URR) para seguimiento de volumen y facturación
Control y Gestión:
- Interfaz PFCP (Protocolo de Control de Reenvío de Paquetes) a SMF/PGW-C
- API RESTful para monitoreo y diagnóstico
- Estadísticas y métricas en tiempo real
- Monitoreo de capacidad de mapas eBPF
- Panel de control basado en web
Características de Rendimiento:
- Procesamiento de paquetes sin copia a través de eBPF
- Reenvío de paquetes a nivel de núcleo (sin sobrecarga de espacio de usuario)
- Escalabilidad multinúcleo
- Capaz de descarga para aceleración de hardware
- Optimizado para implementaciones nativas de la nube
Para un uso detallado del panel de control, consulte Operaciones de la Interfaz Web.
Comprendiendo la Arquitectura del Plano de Usuario
OmniUPF es una solución de plano de usuario unificada que proporciona reenvío de paquetes de grado de operador para redes 5G Autónomas (SA), 5G NSA y 4G LTE/EPC. OmniUPF es un solo producto que puede funcionar simultáneamente como:
- UPF (Función de Plano de Usuario) - plano de usuario 5G/NSA (controlado por OmniSMF a través de N4/PFCP)
- PGW-U (Puerta de Enlace de Datos del PDN) - puerta de enlace EPC 4G a redes externas (controlado por OmniPGW-C a través de Sxc/PFCP)
- SGW-U (Puerta de Enlace de Servicio del Plano de Usuario) - puerta de enlace de servicio EPC 4G (controlado por OmniSGW-C a través de Sxb/PFCP)
OmniUPF puede operar en cualquier combinación de estos modos:
- Solo UPF: Despliegue puro de 5G
- PGW-U + SGW-U: Puerta de enlace 4G combinada (despliegue típico de EPC)
- UPF + PGW-U + SGW-U: Soporte simultáneo para 4G y 5G (escenario de migración)
Todos los modos utilizan el mismo motor de procesamiento de paquetes basado en eBPF y el protocolo PFCP, proporcionando un alto rendimiento consistente, ya sea operando como UPF, PGW-U, SGW-U, o los tres simultáneamente.
Arquitectura de Red 5G (Modo SA)
La solución OmniUPF se sitúa en el plano de datos de las redes 5G, proporcionando la capa de reenvío de paquetes de alta velocidad que conecta dispositivos móviles a redes y servicios de datos.
Arquitectura de Red 4G LTE/EPC
OmniUPF también soporta implementaciones de 4G LTE y EPC (Núcleo de Paquetes Evolucionado), funcionando como OmniPGW-U o OmniSGW-U dependiendo de la arquitectura de la red.
Modo Combinado PGW-U/SGW-U (Despliegue Típico de 4G)
En este modo, OmniUPF actúa como SGW-U y PGW-U, controlado por funciones de plano de control separadas.
Modo Separado SGW-U y PGW-U (Roaming/Múltiples Sitios)
En implementaciones de roaming o múltiples sitios, se pueden desplegar dos instancias separadas de OmniUPF: una como SGW-U y otra como PGW-U.
Modo de Bucle N9 (Instancia Única SGWU+PGWU)
Para implementaciones simplificadas, OmniUPF puede ejecutar tanto los roles SGWU como PGWU en una sola instancia con procesamiento de bucle N9 completamente en eBPF.
Características Clave:
- ✅ Latencia N9 sub-microsegundo - Procesado completamente en eBPF, nunca toca la red
- ✅ Reducción de CPU del 40-50% - Un solo paso de XDP frente a dos instancias separadas
- ✅ Implementación simplificada - Una instancia, un archivo de configuración
- ✅ Detección automática - Cuando
n3_address=n9_address, el bucle se habilita - ✅ Cumplimiento completo de 3GPP - Protocolos PFCP y GTP-U estándar
Configuración:
# OmniUPF config.yml
interface_name: [eth0]
n3_address: "10.0.1.10" # IP de la interfaz S1-U
n9_address: "10.0.1.10" # La misma IP habilita el bucle N9
pfcp_address: ":8805" # Tanto SGWU-C como PGWU-C se conectan aquí
Cuándo usar:
- Implementaciones de computación en el borde (minimizar latencia)
- Entornos con restricciones de costos (servidor único)
- Laboratorio/pruebas (configuración simplificada)
- Implementaciones pequeñas a medianas (< 100K suscriptores)
Cuándo NO usar:
- Redundancia geográfica requerida (SGWU y PGWU en diferentes ubicaciones)
- Mandatos regulatorios para puertas de enlace separadas
- Escala masiva (> 1M suscriptores)
Para detalles completos, ejemplos de configuración, resolución de problemas y métricas de rendimiento, consulte Guía de Operaciones de Bucle N9.
Cómo Funcionan las Funciones de Plano de Usuario en la Red
La función de plano de usuario (OmniUPF, OmniPGW-U o OmniSGW-U) opera como el plano de reenvío controlado por el respectivo plano de control:
-
Establecimiento de Sesión
- 5G: OmniSMF establece la asociación PFCP a través de la interfaz N4 con OmniUPF
- 4G: OmniPGW-C o OmniSGW-C establece la asociación PFCP a través de Sxb/Sxc con OmniPGW-U/OmniSGW-U
- El plano de control crea sesiones PFCP para cada sesión PDU de UE (5G) o contexto PDP (4G)
- El plano de usuario recibe reglas PDR, FAR, QER y URR a través de PFCP
- Los mapas eBPF se poblan con reglas de reenvío
-
Procesamiento de Paquetes de Subida (UE → Red de Datos)
- 5G: Los paquetes llegan a la interfaz N3 desde gNB con encapsulación GTP-U
- 4G: Los paquetes llegan a la interfaz S1-U (SGW-U) o a la interfaz S5/S8 (PGW-U) desde eNodeB con encapsulación GTP-U
- El plano de usuario compara los paquetes con los PDR de subida basándose en TEID
- El programa eBPF aplica QER (limitación de tasa, marcado)
- FAR determina la acción de reenvío (reenviar, descartar, almacenar en búfer, duplicar)
- Se elimina el túnel GTP-U, los paquetes se reenvían a la interfaz N6 (5G) o SGi (4G)
- URR rastrea el conteo de paquetes y bytes para la facturación
-
Procesamiento de Paquetes de Bajada (Red de Datos → UE)
- 5G: Los paquetes llegan a la interfaz N6 como IP nativa
- 4G: Los paquetes llegan a la interfaz SGi como IP nativa
- El plano de usuario compara los paquetes con los PDR de bajada basándose en la dirección IP de UE
- Los filtros SDF pueden clasificar aún más el tráfico por puerto, protocolo o aplicación
- FAR determina el túnel GTP-U y los parámetros de reenvío
- Se agrega la encapsulación GTP-U con el TEID apropiado
- 5G: Los paquetes se reenvían a la interfaz N3 hacia gNB
- 4G: Los paquetes se reenvían a S1-U (SGW-U) o S5/S8 (PGW-U) hacia eNodeB
-
Movilidad y Transferencia
- 5G: OmniSMF actualiza las reglas PDR/FAR durante escenarios de transferencia
- 4G: OmniSGW-C/OmniPGW-C actualiza las reglas durante la transferencia inter-eNodeB o TAU (Actualización de Área de Seguimiento)
- El plano de usuario puede almacenar paquetes durante el cambio de ruta
- Transición sin problemas entre estaciones base sin pérdida de paquetes
Integración con el Plano de Control (4G y 5G)
OmniUPF se integra con ambas funciones de plano de control 5G y 4G a través de interfaces estándar 3GPP:
Interfaces 5G
| Interfaz | De → A | Propósito | Especificación 3GPP |
|---|---|---|---|
| N4 | OmniSMF ↔ OmniUPF | Establecimiento, modificación, eliminación de sesiones PFCP | TS 29.244 |
| N3 | gNB → OmniUPF | Tráfico de plano de usuario desde RAN (GTP-U) | TS 29.281 |
| N6 | OmniUPF → Red de Datos | Tráfico de plano de usuario hacia DN (IP nativa) | TS 23.501 |
| N9 | OmniUPF ↔ OmniUPF | Comunicación entre UPF para roaming/borde | TS 23.501 |
Interfaces 4G/EPC
| Interfaz | De → A | Propósito | Especificación 3GPP |
|---|---|---|---|
| Sxb | OmniSGW-C ↔ OmniUPF (modo SGW-U) | Control de sesión PFCP para puerta de enlace de servicio | TS 29.244 |
| Sxc | OmniPGW-C ↔ OmniUPF (modo PGW-U) | Control de sesión PFCP para puerta de enlace del PDN | TS 29.244 |
| S1-U | eNodeB → OmniUPF (modo SGW-U) | Tráfico de plano de usuario desde RAN (GTP-U) | TS 29.281 |
| S5/S8 | OmniUPF (SGW-U) ↔ OmniUPF (PGW-U) | Plano de usuario interpuerta (GTP-U) | TS 29.281 |
| SGi | OmniUPF (modo PGW-U) → PDN | Tráfico de plano de usuario hacia la red de datos (IP nativa) | TS 23.401 |
Nota: Todas las interfaces PFCP (N4, Sxb, Sxc) utilizan el mismo protocolo PFCP definido en TS 29.244. Los nombres de las interfaces difieren, pero el protocolo y los formatos de mensaje son idénticos.
Componentes del UPF
Ruta de Datos eBPF
La ruta de datos eBPF es el motor central de procesamiento de paquetes que se ejecuta en el núcleo de Linux para un rendimiento máximo.
Funciones Centrales:
- Procesamiento de GTP-U: Encapsulación y desencapsulación de túneles GTP-U
- Clasificación de Paquetes: Comparación de paquetes con reglas PDR utilizando TEID, IP de UE o filtros SDF
- Aplicación de QoS: Aplicar limitación de tasa y marcado de paquetes según reglas QER
- Decisiones de Reenvío: Ejecutar acciones FAR (reenviar, descartar, almacenar en búfer, duplicar, notificar)
- Seguimiento de Uso: Incrementar contadores URR para facturación basada en volumen
Mapas eBPF: La ruta de datos utiliza mapas eBPF (tablas hash en memoria del núcleo) para el almacenamiento de reglas:
| Nombre del Mapa | Propósito | Clave | Valor |
|---|---|---|---|
uplink_pdr_map | PDRs de subida | TEID (32 bits) | Información PDR (ID FAR, ID QER, IDs URR) |
downlink_pdr_map | PDRs de bajada (IPv4) | Dirección IP de UE | Información PDR |
downlink_pdr_map_ip6 | PDRs de bajada (IPv6) | Dirección IPv6 de UE | Información PDR |
far_map | Reglas de reenvío | ID FAR | Parámetros de reenvío (acción, información de túnel) |
qer_map | Reglas de QoS | ID QER | Parámetros de QoS (MBR, GBR, marcado) |
urr_map | Seguimiento de uso | ID URR | Contadores de volumen (subida, bajada, total) |
sdf_filter_map | Filtros SDF | ID PDR | Filtros de aplicación (puertos, protocolos) |
Características de Rendimiento:
- Sin copia: Paquetes procesados completamente en espacio de núcleo
- Soporte XDP: Adjuntar a nivel de controlador de red para latencia sub-microsegundo
- Multinúcleo: Escala a través de núcleos de CPU con soporte de mapa por CPU
- Capacidad: Millones de PDRs/FARs en mapas eBPF (limitado por memoria del núcleo)
Para monitoreo de capacidad, consulte Gestión de Capacidad.
Manejador de Interfaz PFCP
La interfaz PFCP implementa 3GPP TS 29.244 para la comunicación con SMF o PGW-C.
Funciones Centrales:
- Gestión de Asociación: Latido PFCP y configuración/liberación de asociación
- Ciclo de Vida de Sesión: Crear, modificar y eliminar sesiones PFCP
- Instalación de Reglas: Traducir IEs PFCP en entradas de mapa eBPF
- Informe de Eventos: Notificar a SMF sobre umbrales de uso, errores o eventos de sesión
Soporte de Mensajes PFCP:
| Tipo de Mensaje | Dirección | Propósito |
|---|---|---|
| Configuración de Asociación | SMF → UPF | Establecer asociación de control PFCP |
| Liberación de Asociación | SMF → UPF | Desmantelar asociación PFCP |
| Latido | Bidireccional | Mantener viva la asociación |
| Establecimiento de Sesión | SMF → UPF | Crear nueva sesión PDU con PDR/FAR/QER/URR |
| Modificación de Sesión | SMF → UPF | Actualizar reglas para movilidad, cambios de QoS |
| Eliminación de Sesión | SMF → UPF | Eliminar sesión y todas las reglas asociadas |
| Informe de Sesión | UPF → SMF | Informar uso, errores o eventos |
Elementos de Información (IE) Soportados:
- Crear PDR, FAR, QER, URR
- Actualizar PDR, FAR, QER, URR
- Eliminar PDR, FAR, QER, URR
- Información de Detección de Paquetes (IP de UE, F-TEID, filtro SDF)
- Parámetros de Reenvío (instancia de red, creación de encabezado externo)
- Parámetros de QoS (MBR, GBR, QFI)
- Disparadores de Informe de Uso (umbral de volumen, umbral de tiempo)
Servidor API REST
La API REST proporciona acceso programático al estado y las operaciones de UPF.
Funciones Centrales:
- Monitoreo de Sesiones: Consultar sesiones PFCP activas y asociaciones
- Inspección de Reglas: Ver configuraciones de PDR, FAR, QER, URR
- Estadísticas: Recuperar contadores de paquetes, estadísticas de rutas, estadísticas de XDP
- Gestión de Buffers: Ver y controlar buffers de paquetes
- Información de Mapas: Monitorear uso y capacidad de mapas eBPF
Puntos de Acceso API: (34 puntos de acceso en total)
| Categoría | Puntos de Acceso | Descripción |
|---|---|---|
| Salud | /health | Verificación de salud y estado |
| Configuración | /config | Configuración de UPF |
| Sesiones | /pfcp_sessions, /pfcp_associations | Datos de sesión/asociación PFCP |
| PDRs | /uplink_pdr_map, /downlink_pdr_map, /downlink_pdr_map_ip6, /uplink_pdr_map_ip6 | Reglas de detección de paquetes |
| FARs | /far_map | Reglas de acción de reenvío |
| QERs | /qer_map | Reglas de aplicación de QoS |
| URRs | /urr_map | Reglas de informe de uso |
| Buffers | /buffer | Estado y control del buffer de paquetes |
| Estadísticas | /packet_stats, /route_stats, /xdp_stats, /n3n6_stats | Métricas de rendimiento |
| Capacidad | /map_info | Capacidad y uso de mapas eBPF |
| Dataplane | /dataplane_config | Direcciones de interfaz N3/N9 |
Para detalles y uso de la API, consulte Guía de Monitoreo.
Panel de Control Web
El Panel de Control Web proporciona un tablero en tiempo real para el monitoreo y gestión de UPF.
Características:
- Vista de Sesiones: Navegar por sesiones PFCP activas con IP de UE, TEID y conteos de reglas
- Gestión de Reglas: Ver y gestionar PDRs, FARs, QERs y URRs en todas las sesiones
- Monitoreo de Buffers: Rastrear paquetes almacenados en búfer y controlar el almacenamiento por FAR
- Tablero de Estadísticas: Estadísticas en tiempo real de paquetes, rutas, XDP y estadísticas de interfaces N3/N6
- Monitoreo de Capacidad: Uso de mapas eBPF con indicadores de capacidad codificados por colores
- Vista de Configuración: Mostrar configuración de UPF y direcciones de dataplane
- Visor de Registros: Transmisión de registros en vivo para resolución de problemas
Para operaciones detalladas de la interfaz de usuario, consulte Guía de Operaciones de la Interfaz Web.
Protocolo PFCP e Integración SMF
Asociación PFCP
Antes de que se puedan crear sesiones, el SMF debe establecer una asociación PFCP con el UPF.
Ciclo de Vida de la Asociación:
Puntos Clave:
- Cada SMF establece una asociación con el UPF
- UPF rastrea la asociación por ID de Nodo (FQDN o dirección IP)
- Los mensajes de latido mantienen la vitalidad de la asociación
- Todas las sesiones bajo una asociación se eliminan si se libera la asociación
Para ver asociaciones, consulte Vista de Sesiones.
Detección de Reinicio de SMF y Limpieza de Sesiones Huérfanas
OmniUPF detecta automáticamente cuando un SMF se reinicia y limpia sesiones huérfanas según las especificaciones de 3GPP TS 29.244.
Cómo Funciona:
Cuando un SMF establece una asociación PFCP, proporciona un Timestamp de Recuperación que indica cuándo se inició. OmniUPF almacena este timestamp para cada asociación. Si el SMF se reinicia:
- El SMF pierde todo el estado de sesión en memoria
- El SMF restablece la asociación PFCP con el UPF
- El SMF envía un nuevo Timestamp de Recuperación (diferente al anterior)
- UPF detecta el cambio de timestamp = SMF reiniciado
- UPF elimina automáticamente todas las sesiones huérfanas de la antigua instancia de SMF
- El SMF crea sesiones nuevas para suscriptores activos
Flujo de Detección de Reinicio:
Ejemplo de Registro:
Cuando un SMF se reinicia, verá:
WARN: La asociación con NodeID: smf-1 y dirección: 192.168.1.10 ya existe
WARN: El Timestamp de Recuperación del SMF cambió (antiguo: 2025-01-15T10:00:00Z, nuevo: 2025-01-15T10:30:15Z) - SMF reiniciado, eliminando 245 sesiones huérfanas
INFO: Eliminando sesión huérfana 2 (LocalSEID) debido al reinicio del SMF
INFO: Eliminando sesión huérfana 3 (LocalSEID) debido al reinicio del SMF
...
INFO: Eliminando sesión huérfana 246 (LocalSEID) debido al reinicio del SMF
Notas Importantes:
-
Aislamiento: Solo se eliminan las sesiones del SMF reiniciado. Otras asociaciones de SMF y sus sesiones no se ven afectadas.
-
Comparación de Timestamps: Si el Timestamp de Recuperación es idéntico, las sesiones se conservan (SMF se reconectó sin reiniciarse).
-
Cumplimiento 3GPP: Este comportamiento está mandado por la Sección 5.22.2 de 3GPP TS 29.244:
"Si el Timestamp de Recuperación de la función CP ha cambiado desde la última Configuración de Asociación, la función UP deberá considerar que la función CP se ha reiniciado y deberá eliminar todas las sesiones PFCP asociadas con esa función CP."
Para resolver problemas de sesiones huérfanas, consulte Detección de Sesiones Huérfanas.
Manejo de Indicación de Error GTP-U
OmniUPF maneja mensajes de Indicación de Error GTP-U de pares descendentes (PGW-U, SGW-U, eNodeB, gNodeB) según las especificaciones de 3GPP TS 29.281.
¿Qué son las Indicaciones de Error?:
Cuando OmniUPF reenvía un paquete GTP-U a un par remoto (por ejemplo, PGW-U en despliegue SGW-U), el par puede enviar de vuelta una Indicación de Error si no reconoce el TEID (Identificador de Punto de Túnel). Esto indica:
- El par remoto se ha reiniciado y ha perdido el estado del túnel
- El túnel nunca se creó en el lado remoto (desajuste de configuración)
- El túnel ya se eliminó en el lado remoto
Cómo Funciona:
- UPF reenvía el paquete → Envía un paquete GTP-U con TEID X al par remoto (puerto 2152)
- El par remoto no reconoce el TEID X → Busca el TEID en su tabla de túneles, no encontrado
- El par remoto envía Indicación de Error → Mensaje GTP-U tipo 26 con IE que contiene el TEID erróneo
- UPF recibe la Indicación de Error → Analiza el mensaje para extraer el TEID X
- UPF encuentra sesiones afectadas → Busca todas las sesiones para FARs que reenvían al TEID X
- UPF elimina sesiones → Elimina sesiones de los mapas eBPF y del estado PFCP
- UPF actualiza métricas → Incrementa contadores de Prometheus para monitoreo
Flujo de Indicación de Error:
Formato del Paquete (Sección 7.3.1 de 3GPP TS 29.281):
Indicación de Error GTP-U:
┌─────────────────────────────────────────┐
│ Encabezado GTP-U (12 bytes) │
├─────────────────────────────────────────┤
│ Versión, PT, Banderas │ 0x32 │
│ Tipo de Mensaje │ 26 (0x1A) │
│ Longitud �� 9 bytes │
│ TEID │ 0 (siempre)│
│ Número de Secuencia │ varía │
│ Número de N-PDU │ 0 │
│ Siguiente Encabezado de Extensión │ 0 │
├─────────────────────────────────────────┤
│ IE: Datos de TEID I (5 bytes) │
├─────────────────────────────────────────┤
│ Tipo │ 16 (0x10) │
│ TEID erróneo │ 4 bytes │
└─────────────────────────────────────────┘
Cuándo Esto Importa:
Escenario 1: Reinicio de PGW-U en Arquitectura GTP S5/S8
- SGW-U (OmniUPF) reenvía tráfico S5/S8 a PGW-U
- PGW-U se reinicia y pierde todo el estado del túnel S5/S8
- SGW-U continúa reenviando a TEIDs antiguos
- PGW-U envía Indicaciones de Error
- SGW-U detiene automáticamente el uso de túneles muertos
Escenario 2: Reinicio de UPF Par en Arquitectura N9
- UPF-1 (OmniUPF) reenvía tráfico N9 a UPF-2
- UPF-2 se reinicia
- UPF-1 recibe Indicaciones de Error
- UPF-1 limpia sesiones
Ejemplo de Registro:
Al recibir una Indicación de Error:
WARN: Recibida Indicación de Error GTP-U de 192.168.50.10:2152 para TEID 0x12345678 - el par remoto no reconoce este TEID
WARN: Se encontró sesión LocalSEID=42 con FAR GlobalId=1 reenviando al TEID erróneo 0x12345678 del par 192.168.50.10
INFO: Eliminando sesión LocalSEID=42 debido a Indicación de Error GTP-U para TEID 0x12345678 de 192.168.50.10
WARN: Eliminadas 1 sesión(es) debido a Indicación de Error GTP-U para TEID 0x12345678 del par 192.168.50.10
Métricas de Prometheus:
Monitoree la actividad de Indicación de Error con granularidad por par y por nodo:
# Total de Indicaciones de Error recibidas de pares
upf_buffer_listener_error_indications_received_total{node_id="pgw-u-1",peer_address="192.168.50.10"}
# Sesiones eliminadas debido a Indicaciones de Error
upf_buffer_listener_error_indication_sessions_deleted_total{node_id="pgw-u-1",peer_address="192.168.50.10"}
# Indicaciones de Error enviadas (para TEIDs entrantes desconocidos)
upf_buffer_listener_error_indications_sent_total{node_id="enodeb-1",peer_address="10.60.0.1"}
Etiquetas de Métrica:
node_id: ID de Nodo PFCP de la asociación (o "desconocido" si no existe asociación)peer_address: Dirección IP del par remoto
Estas métricas ayudan a identificar pares problemáticos y rastrear patrones de Indicación de Error por nodo de plano de control.
Notas Importantes:
-
Limpieza Automática: No se necesita intervención del operador - las sesiones se eliminan automáticamente
-
Coincidencia de TEID: Solo se eliminan las sesiones con FARs que reenvían al TEID erróneo exacto
-
Aislamiento por Par: Las Indicaciones de Error de un par solo afectan las sesiones que reenvían a ese par
-
Múltiples Sesiones: Si múltiples sesiones reenvían al mismo TEID muerto, todas se eliminan
-
Complementario al Timestamp de Recuperación:
- Detección de Timestamp de Recuperación = proactivo (detecta reinicio durante la configuración de asociación)
- Manejo de Indicación de Error = reactivo (detecta túneles muertos cuando fluyen datos)
-
Manejo de Paquetes Malformados: Las Indicaciones de Error inválidas se registran e ignoran (no se eliminan sesiones)
Para resolver problemas de Indicaciones de Error, consulte Depuración de Indicaciones de Error GTP-U.
Creación de Sesiones PFCP
Cuando un UE establece una sesión PDU (5G) o contexto PDP (LTE), el SMF crea una sesión PFCP en el UPF.
Flujo de Establecimiento de Sesión:
Contenidos Típicos de la Sesión:
- PDR de Subida: Coincidir en TEID N3, reenviar a través de FAR a N6
- PDR de Bajada: Coincidir en dirección IP de UE, reenviar a través de FAR a N3 con encapsulación GTP-U
- FAR: Parámetros de reenvío (creación de encabezado externo, instancia de red)
- QER: Límites de QoS (MBR, GBR) y marcado de paquetes (QFI)
- URR: Informe de volumen para facturación (opcional)
Modificación de Sesiones PFCP
El SMF puede modificar sesiones para eventos de movilidad (transferencia), cambios de QoS o actualizaciones de servicio.
Escenarios Comunes de Modificación:
-
Transferencia (basada en N2)
- Actualizar FAR de subida con nuevo punto de túnel gNB (F-TEID)
- Opcionalmente almacenar paquetes durante el cambio de ruta
- Vaciar el búfer a la nueva ruta cuando esté listo
-
Cambio de QoS
- Actualizar QER con nuevos valores de MBR/GBR
- Puede agregar/eliminar filtros SDF en PDR para QoS específico de aplicación
-
Actualización de Servicio
- Agregar nuevos PDRs para flujos de tráfico adicionales
- Modificar FARs para cambios de enrutamiento
Flujo de Modificación de Sesión:
Para la gestión de reglas, consulte Guía de Gestión de Reglas.
Eliminación de Sesiones PFCP
Cuando se libera una sesión PDU, el SMF elimina la sesión PFCP en el UPF.
Flujo de Eliminación de Sesión:
Limpieza Realizada:
- Se eliminan todos los PDRs (subida y bajada)
- Se eliminan todos los FARs, QERs, URRs
- Se limpian los búferes de paquetes
- Se envía un informe final de uso al SMF para facturación
Operaciones Comunes
OmniUPF proporciona capacidades operativas completas a través de su panel de control basado en web y API REST. Esta sección cubre tareas operativas comunes y su significado.
Monitoreo de Sesiones
Comprendiendo las Sesiones PFCP:
Las sesiones PFCP representan sesiones PDU activas de UE (5G) o contextos PDP (LTE). Cada sesión contiene:
- SEIDs locales y remotos (Identificadores de Punto de Sesión)
- PDRs para clasificación de paquetes
- FARs para decisiones de reenvío
- QERs para aplicación de QoS (opcional)
- URRs para seguimiento de uso (opcional)
Operaciones Clave de Sesión:
- Ver todas las sesiones con direcciones IP de UE, TEIDs y conteos de reglas
- Filtrar sesiones por dirección IP o TEID
- Inspeccionar detalles de la sesión incluyendo configuraciones completas de PDR/FAR/QER/URR
- Monitorear conteos de sesiones por asociación PFCP
Para procedimientos detallados de sesión, consulte Vista de Sesiones.
Gestión de Reglas
Reglas de Detección de Paquetes (PDR):
Los PDR determinan qué paquetes coinciden con flujos de tráfico específicos. Los operadores pueden:
- Ver PDRs de subida indexados por TEID de la interfaz N3
- Ver PDRs de bajada indexados por dirección IP de UE (IPv4 e IPv6)
- Inspeccionar filtros SDF para clasificación específica de aplicaciones
- Monitorear conteos de PDR y uso de capacidad
Reglas de Acción de Reenvío (FAR):
Los FAR definen qué hacer con los paquetes coincidentes. Los operadores pueden:
- Ver acciones FAR (REENVIAR, DESCARTAR, ALMACENAR EN BÚFER, DUPLICAR, NOTIFICAR)
- Inspeccionar parámetros de reenvío (creación de encabezado externo, destino)
- Monitorear estado de almacenamiento por FAR
- Alternar almacenamiento para FAR específicas durante la resolución de problemas
Reglas de Aplicación de QoS (QER):
Los QER aplican límites de ancho de banda y marcado de paquetes. Los operadores pueden:
- Ver parámetros de QoS (MBR, GBR, marcado de paquetes)
- Monitorear QERs activas por sesión
- Inspeccionar marcas QFI para flujos de QoS 5G
Reglas de Informe de Uso (URR):
Los URR rastrean volúmenes de datos para facturación. Los operadores pueden:
- Ver contadores de volumen (subida, bajada, total de bytes)
- Monitorear umbrales de uso y disparadores de informes
- Inspeccionar URRs activas en todas las sesiones
Para operaciones de reglas, consulte Guía de Gestión de Reglas.
Almacenamiento en Búfer de Paquetes
Por Qué el Almacenamiento en Búfer es Crítico para UPF
El almacenamiento en búfer de paquetes es una de las funciones más importantes de un UPF porque previene la pérdida de paquetes durante eventos de movilidad y reconfiguraciones de sesión. Sin almacenamiento en búfer, los usuarios móviles experimentarían desconexiones, interrupciones en descargas y fallos en comunicaciones en tiempo real cada vez que se mueven entre torres celulares o cuando cambian las condiciones de la red.
El Problema: Pérdida de Paquetes Durante la Movilidad
En redes móviles, los usuarios están en constante movimiento. Cuando un dispositivo se mueve de una torre celular a otra (transferencia), o cuando la red necesita reconfigurar la ruta de datos, hay una ventana crítica donde los paquetes están en vuelo pero la nueva ruta aún no está lista:
Sin almacenamiento en búfer: Los paquetes que llegan durante esta ventana crítica serían descartados, causando:
- Conexiones TCP que se estancan o se reinician (navegación web, descargas interrumpidas)
- Llamadas de video que se congelan o se caen (Zoom, Teams, llamadas de WhatsApp fallan)
- Sesiones de juego que se desconectan (juegos en línea, aplicaciones en tiempo real fallan)
- Llamadas VoIP que tienen interrupciones o se caen por completo (llamadas telefónicas interrumpidas)
- Descargas que fallan y necesitan reiniciarse
Con almacenamiento en búfer: OmniUPF retiene temporalmente los paquetes hasta que la nueva ruta se establece, luego los reenvía sin problemas. El usuario experimenta cero interrupciones.
Cuándo Ocurre el Almacenamiento en Búfer
OmniUPF almacena paquetes en estos escenarios críticos:
1. Transferencia Basada en N2 (5G) / Transferencia Basada en X2 (4G)
Cuando un UE se mueve entre torres celulares:
Línea de Tiempo:
- T+0ms: Ruta antigua aún activa
- T+10ms: SMF le dice a UPF que almacene (ruta antigua cerrándose, nueva ruta no lista)
- T+10-50ms: Ventana crítica de almacenamiento - los paquetes llegan pero no se pueden reenviar
- T+50ms: Nueva ruta lista, SMF le dice a UPF que reenvíe
- T+50ms+: UPF vacía los paquetes almacenados en búfer a la nueva ruta, luego reenvía nuevos paquetes normalmente
Sin almacenamiento en búfer: ~40ms de paquetes (potencialmente miles) serían perdidos. Con almacenamiento en búfer: Cero pérdida de paquetes, transferencia sin problemas.
2. Modificación de Sesión (Cambio de QoS, Actualización de Ruta)
Cuando la red necesita cambiar parámetros de sesión:
- Actualización/disminución de QoS: El usuario se mueve de cobertura 4G a 5G (modo NSA)
- Cambio de política: El usuario empresarial entra en el campus corporativo (cambios en la dirección del tráfico)
- Optimización de red: La red central redirige el tráfico a un UPF más cercano (actualización de ULCL)
Durante la modificación, el plano de control puede necesitar actualizar múltiples reglas de manera atómica. El almacenamiento en búfer asegura que los paquetes no se reenvíen con conjuntos de reglas parciales/inconsistentes.
3. Notificación de Datos de Bajada (Recuperación en Modo Inactivo)
Cuando un UE está en modo inactivo (pantalla apagada, ahorro de batería) y llegan datos de bajada:
Sin almacenamiento en búfer: El paquete inicial que activó la notificación sería perdido, requiriendo que el remitente retransmita (agrega latencia). Con almacenamiento en búfer: El paquete que despertó al UE se entrega inmediatamente cuando el UE se reconecta.
4. Transferencia Inter-RAT (4G ↔ 5G)
Cuando un UE se mueve entre cobertura 4G y 5G:
- Cambios de arquitectura (eNodeB ↔ gNB)
- Cambian los puntos de túnel (nueva asignación de TEID)
- El almacenamiento en búfer asegura una transición suave entre tipos de RAT
Cómo Funciona el Almacenamiento en Búfer en OmniUPF
Mecanismo Técnico:
OmniUPF utiliza una arquitectura de almacenamiento en búfer de dos etapas:
- Etapa eBPF (Núcleo): Detecta paquetes que requieren almacenamiento en búfer según las banderas de acción FAR
- Etapa de Espacio de Usuario: Almacena y gestiona paquetes almacenados en memoria
Proceso de Almacenamiento en Búfer:
Detalles Clave:
- Puerto de Búfer: Puerto UDP 22152 (paquetes enviados desde eBPF a espacio de usuario)
- Encapsulación: Paquetes envueltos en GTP-U con ID FAR como TEID
- Almacenamiento: Búferes en memoria por FAR con metadatos (timestamp, dirección, tamaño del paquete)
- Límites:
- Límite por FAR: 10,000 paquetes (por defecto)
- Límite global: 100,000 paquetes en todos los FARs
- TTL: 30 segundos (por defecto) - los paquetes más antiguos que el TTL se descartan
- Limpieza: Proceso en segundo plano elimina paquetes expirados cada 60 segundos
Ciclo de Vida del Búfer:
- Almacenamiento en Búfer Activado: SMF establece acción FAR BUFF=1 (bit 2) a través de Modificación de Sesión PFCP
- Paquetes Almacenados: eBPF detecta la bandera BUFF, encapsula paquetes, envía al puerto 22152
- Almacenamiento en Espacio de Usuario: El gestor de búfer almacena paquetes con ID FAR, timestamp, dirección
- Almacenamiento en Búfer Desactivado: SMF establece acción FAR FORW=1, BUFF=0 con nuevos parámetros de reenvío
- Vaciar Búfer: El espacio de usuario reproduce paquetes almacenados utilizando nuevas reglas FAR (nuevo punto de túnel)
- Reanudar Normalidad: Nuevos paquetes reenviados inmediatamente a través de la nueva ruta
Por Qué Esto Importa para la Experiencia del Usuario
Impacto en el Mundo Real:
| Escenario | Sin Almacenamiento en Búfer | Con Almacenamiento en Búfer |
|---|---|---|
| Llamada de Video Durante la Transferencia | La llamada se congela durante 1-2 segundos, puede caerse | Sin interrupciones, sin problemas |
| Descarga de Archivo en el Límite de la Celda | La descarga falla, debe reiniciarse | La descarga continúa sin interrupciones |
| Juego en Línea Mientras se Mueve | La conexión se cae, se expulsa del juego | Juego fluido, sin desconexiones |
| Llamada VoIP en el Auto | La llamada se cae en cada transferencia | Cristalina, sin caídas |
| Video en Streaming en un Tren | El video se almacena en búfer, la calidad disminuye | Reproducción fluida |
| Hotspot Móvil para Laptop | La sesión SSH se cae, la llamada de video falla | Todas las conexiones mantenidas |
Beneficios para el Operador de Red:
- Reducción de la Tasa de Caídas de Llamadas (CDR): KPI crítico para la calidad de la red
- Mayor Satisfacción del Cliente: Los usuarios no notan las transferencias
- Menores Costos de Soporte: Menos quejas sobre conexiones caídas
- Ventaja Competitiva: Marketing de "mejor red para cobertura"
Operaciones de Gestión de Búfer
Los operadores pueden monitorear y controlar el almacenamiento en búfer a través de la interfaz web y la API:
Monitoreo:
- Ver paquetes almacenados en búfer por ID FAR (conteo, bytes, edad)
- Rastrear uso de búfer contra límites (por FAR, global)
- Alertar sobre desbordamiento de búfer o duración excesiva de almacenamiento en búfer
- Identificar búferes atascados (paquetes almacenados en búfer > umbral TTL)
Operaciones de Control:
- Vaciar búferes: Activar manualmente la reproducción de búfer (resolución de problemas)
- Limpiar búferes: Descartar paquetes almacenados en búfer (limpiar búferes atascados)
- Ajustar TTL: Cambiar el tiempo de expiración de paquetes
- Modificar límites: Aumentar la capacidad del búfer por FAR o global
Resolución de Problemas:
- Búfer no vaciándose: Verifique si SMF envió la actualización de FAR para desactivar el almacenamiento en búfer
- Desbordamiento de búfer: Aumente los límites o investigue por qué la duración del almacenamiento en búfer es excesiva
- Paquetes antiguos en el búfer: TTL puede ser demasiado alto, o la actualización de FAR retrasada
- Almacenamiento en búfer excesivo: Puede indicar problemas de movilidad o problemas con SMF
Para operaciones detalladas de búfer, consulte Guía de Gestión de Búfer.
Configuración del Búfer
Configure el comportamiento del almacenamiento en búfer en config.yml:
# Configuración del búfer
buffer_port: 22152 # Puerto UDP para paquetes almacenados en búfer (por defecto)
buffer_max_packets: 10000 # Máximo de paquetes por FAR (evitar agotamiento de memoria)
buffer_max_total: 100000 # Máximo total de paquetes en todos los FARs
buffer_packet_ttl: 30 # TTL en segundos (descartar paquetes antiguos)
buffer_cleanup_interval: 60 # Intervalo de limpieza en segundos
Recomendaciones:
- Redes de alta movilidad (autopistas, trenes): Aumente
buffer_max_packetsa 20,000+ - Áreas urbanas densas (transferencias frecuentes): Disminuya
buffer_packet_ttla 15s - Aplicaciones de baja latencia: Establezca
buffer_packet_ttla 10s para evitar datos obsoletos - Redes IoT: Disminuya los límites (los dispositivos IoT generan menos tráfico durante la transferencia)
Para opciones completas de configuración, consulte Guía de Configuración.
Estadísticas y Monitoreo
Estadísticas de Paquetes:
Métricas de procesamiento de paquetes en tiempo real que incluyen:
- Paquetes RX: Total recibido de todas las interfaces
- Paquetes TX: Total transmitido a todas las interfaces
- Paquetes descartados: Paquetes descartados debido a errores o políticas
- Paquetes GTP-U: Conteos de paquetes tunelados
Estadísticas de Rutas:
Métricas de reenvío por ruta:
- Acercamientos de ruta: Paquetes coincidentes por cada ruta
- Conteos de reenvío: Éxito/fallo por destino
- Contadores de error: TEIDs inválidos, IPs de UE desconocidas
Estadísticas XDP:
Métricas de rendimiento del eXpress Data Path:
- XDP procesados: Paquetes manejados en la capa XDP
- XDP pasados: Paquetes enviados a la pila de red
- XDP descartados: Paquetes descartados en la capa XDP
- XDP abortados: Errores de procesamiento
Estadísticas de Interfaces N3/N6:
Contadores de tráfico por interfaz:
- N3 RX/TX: Tráfico hacia/desde RAN (gNB/eNodeB)
- N6 RX/TX: Tráfico hacia/desde la red de datos
- Conteos totales de paquetes: Estadísticas agregadas de interfaz
Para detalles de monitoreo, consulte Guía de Monitoreo.
Gestión de Capacidad
Monitoreo de Capacidad de Mapas eBPF:
El rendimiento de UPF depende de la capacidad de los mapas eBPF. Los operadores pueden:
- Monitorear uso de mapas con indicadores de porcentaje en tiempo real
- Ver límites de capacidad para cada mapa eBPF
- Alertas codificadas por colores:
- Verde (<50%): Normal
- Amarillo (50-70%): Precaución
- Ámbar (70-90%): Advertencia
- Rojo (>90%): Crítico
Mapas Críticos a Monitorear:
uplink_pdr_map: Clasificación de tráfico de subidadownlink_pdr_map: Clasificación de tráfico de bajada IPv4far_map: Reglas de reenvíoqer_map: Reglas de QoSurr_map: Seguimiento de uso
Planificación de Capacidad:
- Cada PDR consume una entrada de mapa (tamaño de clave + tamaño de valor)
- La capacidad del mapa se configura al inicio de UPF (límite de memoria del núcleo)
- Superar la capacidad causa fallos en el establecimiento de sesiones
Para monitoreo de capacidad, consulte Gestión de Capacidad.
Gestión de Configuración
Configuración de UPF:
Verifique y verifique los parámetros operativos de UPF:
- Interfaz N3: Dirección IP para conectividad RAN (GTP-U)
- Interfaz N6: Dirección IP para conectividad de red de datos
- Interfaz N9: Dirección IP para comunicación inter-UPF (opcional)
- Interfaz PFCP: Dirección IP para conectividad SMF
- Puerto API: Puerto de escucha de API REST
- Punto de Métricas: Puerto de métricas de Prometheus
Configuración del Dataplane:
Parámetros activos de la ruta de datos eBPF:
- Dirección N3 activa: Enlace de interfaz N3 en tiempo de ejecución
- Dirección N9 activa: Enlace de interfaz N9 en tiempo de ejecución (si está habilitado)
Para ver la configuración, consulte Vista de Configuración.
Resolución de Problemas
Esta sección cubre problemas operativos comunes y sus estrategias de resolución.
Fallos en el Establecimiento de Sesiones
Síntomas: Las sesiones PFCP no se crean, el UE no puede establecer conectividad de datos
Causas Raíz Comunes:
-
Asociación PFCP No Establecida
- Verifique que el SMF pueda alcanzar la interfaz PFCP del UPF (puerto 8805)
- Verifique el estado de la asociación PFCP en la vista de Sesiones
- Verifique que la configuración del ID de Nodo coincida entre SMF y UPF
-
Agotamiento de Capacidad de Mapas eBPF
- Verifique la vista de Capacidad para el uso de mapas en rojo (>90%)
- Aumente los tamaños de los mapas eBPF en la configuración de UPF
- Elimine sesiones obsoletas si el mapa está lleno
-
Configuración Inválida de PDR/FAR
- Verifique que la dirección IP de UE sea única y válida
- Verifique que la asignación de TEID no tenga conflictos
- Asegúrese de que el FAR haga referencia a instancias de red válidas
-
Problemas de Configuración de Interfaz
- Verifique que la IP de la interfaz N3 sea accesible desde gNB
- Verifique las tablas de enrutamiento para la conectividad N6 a la red de datos
- Confirme que el tráfico GTP-U no esté bloqueado por un firewall
Para una resolución de problemas detallada, consulte Guía de Resolución de Problemas.
Pérdida de Paquetes o Problemas de Reenvío
Síntomas: El UE tiene conectividad pero experimenta pérdida de paquetes o no hay flujo de tráfico
Causas Raíz Comunes:
- Configuración Incorrecta de PDR
- Verifique que el PDR de subida TEID coincida con el TEID asignado por gNB
- Verifique que el