TR-069 frente a TR-369 (USP) en 2026: una guía práctica para operadores FTTH
CWMP ha llevado nuestras redes CPE durante quince años. USP es el sucesor moderno. Aquí te contamos qué cambia, qué no, y cómo plantear la migración hoy.
Para la mayoría de operadores que leen esto, TR-069 no es un tema apasionante. Es el protocolo que, en silencio, mantiene configurados, con firmware al día y autenticados a varios millones de ONT. Luego algo falla a escala —un envío de firmware de un proveedor sale mal, un bloqueo en la base de datos del ACS deja caído el aprovisionamiento durante una hora— y de pronto el protocolo se vuelve muy interesante. Este artículo es para ese momento.
Una breve historia
TR-069 —formalmente "CWMP" o CPE WAN Management Protocol— fue publicado por primera vez por el Broadband Forum en 2004 y ha sido el protocolo dominante para gestionar CPE residencial desde entonces. Sobrevivió porque resolvía un problema real (configuración remota de millones de dispositivos detrás de NAT) y porque la alternativa —enviar ingenieros a los hogares— era impensable a escala.
TR-369, con el nombre comercial "USP" (User Services Platform), fue publicado en 2018 y ha ido madurando de manera constante. No es una pequeña revisión de TR-069. Es una re-arquitectura para una era en la que el hogar está lleno de cosas conectadas, múltiples controladores quieren gestionar el mismo gateway y esperamos control en tiempo real en lugar de sondeo periódico.
Qué es realmente diferente
| Transporte | TR-069: petición-respuesta HTTP(S), inicio por ACS poco frecuente. USP: HTTPS, WebSockets, MQTT, STOMP — múltiples transportes, bidireccional. |
| Iniciador | TR-069: el dispositivo informa al ACS, el ACS responde. USP: los controladores pueden enviar en cualquier momento sin esperar un connect-request. |
| Controladores por agente | TR-069: en la práctica un solo ACS. USP: múltiples controladores —p. ej. ISP, hogar inteligente, empresa— pueden coexistir en un agente. |
| Modelo de datos | Ambos se apoyan en el modelo de datos TR-181, así que la mayoría de parámetros se conservan. |
| Seguridad | TR-069: TLS + autenticación de ACS. USP: TLS, certificados, integridad a nivel de mensaje y un modelo de rol/identidad más fuerte. |
| Descubrimiento | TR-069: opciones DHCP 43/125 o URL de ACS cableada. USP: lo mismo más mDNS, DNS-SD para controladores locales. |
Resumen en lenguaje llano
TR-069 es un patrón periódico liderado por el ACS. USP es dirigido por eventos y multi-controlador. Si solo envías configuración una vez por hora y disparas acciones ad-hoc de vez en cuando, apenas notas la diferencia. Si quieres tiempos de reacción por debajo del segundo, control multi-inquilino, o publicar telemetría de CPE en una tubería de streaming, USP lo hace fácil y TR-069 lo hace doloroso.
Qué NO cambia
El modelo de datos de dispositivo TR-181 —el árbol de parámetros que tu ONT y gateway ya hablan— se traslada a USP. Esto importa más que cualquier otro hecho. La inversión que tienes en conocimiento de parámetros, perfiles, scripts y pruebas se preserva. No tiras tu vocabulario operativo; solo aprendes un verbo más rápido para enviarlo.
La cuestión de la migración
La pregunta más común que recibimos es: ¿necesitamos migrar, y cuándo? La respuesta honesta es "no urgente para lo que haces hoy, pero probablemente sí en 3 años". Aquí va un enfoque pragmático:
- 1Si tu parque de CPE instalado es 100 % TR-069 y no planeas casos de uso multi-controlador, ejecuta TR-069 durante los próximos 18–24 meses mientras haces la debida diligencia.
- 2Si compras CPE nuevo este año, especifica soporte USP como requisito duro en el RFP. La mayoría de los proveedores de silicio modernos (Realtek, Broadcom, MediaTek) envían agentes compatibles con USP.
- 3Elige un ACS que hable ambos protocolos (TR-069 y TR-369) sobre un único modelo de datos, para que la migración sea un cambio de bandera por dispositivo, no una re-plataforma.
- 4Trata al primer 5–10 % de tu parque como piloto. La mayor parte del aprendizaje operativo ocurre a pequeña escala y te ahorra un cambio radical más adelante.
Modos de fallo comunes y lo que enseñan
Una forma útil de evaluar cualquier ACS —el tuyo, el nuestro o el de cualquier proveedor— es preguntar cómo maneja los modos de fallo que seguimos viendo en producción. Ninguno es teórico; hemos topado con cada uno en campo.
- Tormentas de connect-request tras un corte regional, cuando 200.000 ONT vuelven al mismo tiempo.
- Envío de firmware de un proveedor que deja inservible al 0,3 % de un lote, y necesitas hacer rollback rápido.
- Deriva del árbol de parámetros entre versiones de firmware del proveedor: misma ruta TR-181, comportamiento por defecto distinto.
- Mal comportamiento de NAT bloqueando connect-requests iniciados por el ACS, que exige rutas de disparo alternativas.
- Conflictos de precedencia de perfiles: dos perfiles apuntan al mismo parámetro con valores distintos.
Somete la tormenta a estrés
Antes de confiar en un ACS en producción, simula un flap del 5 % del parque y obsérvalo. Hemos visto despliegues de ACS de nivel producción caer con 30.000 informs concurrentes porque la BD se bloqueó. El ACS de Netxol apunta específicamente a un presupuesto de 200.000 informs concurrentes; la mayoría de nuestros clientes nunca necesitarán ese margen, pero la arquitectura obliga a las decisiones de diseño correctas en todos los demás sitios.
La IA cambia el modelo operativo, no el protocolo
TR-069 y USP son mecanismos. Por sí mismos no deciden qué enviar, cuándo ni a quién. Antes ese era el trabajo de un operador humano con una hoja de cálculo de planes de actualización masiva. Cada vez más, es el trabajo de un plano de control de IA que observa la red, razona sobre la acción correcta y la autoriza bajo política.
En la práctica, esto significa que un ACS TR-069 en 2026 no debería ser solo un panel de control remoto. Debería ser un ejecutor para un cerebro de IA que conoce la topología, el estado del abonado y el comportamiento histórico, y puede emitir un cambio de parámetro con la confianza de que no empeorará las cosas. El ACS de Netxol es el lado ejecutor de ese bucle en nuestra plataforma; el AI Brain es el controlador.
Lecturas adicionales
Referencias canónicas
- Broadband Forum — TR-069 (CWMP)La especificación original de CWMP, aún la referencia canónica.
- Broadband Forum — TR-369 (USP)Familia de especificaciones USP.
- Broadband Forum — Modelo de datos de dispositivo TR-181Modelo de datos de dispositivo navegable, invaluable en operaciones.
- Implementación de referencia USP (OB-USP-Agent)Agente USP de código abierto, útil para trabajo de laboratorio.