# ¿Cómo funcionan las notificaciones y suscripciones USP en TR-369? Equipo de ingeniería de Dodderware · Publicado 2026-10-28 · https://blog.dodderware.com/es/notificaciones-usp/ [Read in English](https://blog.dodderware.com/usp-notifications-subscriptions/) > **Respuesta corta:** USP (TR-369) no tiene un mensaje Subscribe. Un Controlador se suscribe con un Add que crea una fila en la tabla Device.LocalAgent.Subscription. del Agente. Cuando ocurre el evento, el Agente envía un Notify con una notificación ValueChange, ObjectCreation, ObjectDeletion, OperationComplete o Event, como Boot!. Si NotifRetry está activo, el Agente pide respuesta y reintenta hasta recibirla o hasta que la notificación venza. Una plataforma de gestión de equipos está tan al día como lo último que le contó cada equipo. En USP (TR-369), qué reporta un Agente, a qué Controlador y con cuánta insistencia lo definen las suscripciones, y el reporte viaja en un mensaje Notify. Esta guía recorre el mecanismo tal como lo define la especificación. ## ¿Cómo se suscribe un Controlador a las notificaciones? Una **suscripción** (Subscription) es la lógica que le indica a un Agente qué Notifications enviarle a un Controlador en particular (§1.4). USP no tiene un mensaje Subscribe entre sus once tipos de request (§7.3.3.2). Las suscripciones viven en el modelo de datos, como instancias del Multi-Instance Object `Device.LocalAgent.Subscription.{i}.`, y sus reglas normativas están en la descripción de ese Object en el Device:2 Data Model (§7.6.1, R-NOT.0). El Controlador crea una con un mensaje Add común y corriente (§7.6.1.1). Los Parameters de una suscripción responden cuatro preguntas: - **Qué vigilar.** `ReferenceList` contiene los Path Names o Search Paths a los que aplica (§7.6.1.1). Para enterarse de cuándo una estación se une a la red Wi-Fi, el Controlador se suscribe a ObjectCreation sobre `Device.WiFi.AccessPoint.1.AssociatedDevice.`. Para saber cuándo alguien más cambia el SSID, se suscribe a ValueChange sobre `Device.WiFi.SSID.1.SSID` (§7.6.1.1). - **Qué hacer.** `TriggerAction` hace que el Agente envíe un Notify, la opción por defecto, que actualice su propia configuración, o ambas cosas (§7.6.1.2). - **Cuánto insistir.** `NotifRetry` y `NotifExpiration` deciden si se confirma la entrega y cuándo se dejan de hacer reintentos (§7.6.2). - **Para quién es.** Cada suscripción tiene un `ID` y un `Recipient`, una entrada de la tabla de Controladores del Agente, como en la expresión de búsqueda de un ejemplo de la especificación, `[ID=="boot-1"&&Recipient=="Device.LocalAgent.Controller.1"]` (§7.5.1.1). El Controlador también necesita permiso. Los permisos de un Role se escriben con cuatro caracteres, `rwxn`, donde `n` es Notify (§8.9.2.1). Cuando ocurre un evento, la implementación debería cambiar su estado e iniciar la Notification en una ventana de no más de 10 segundos (R-NOT.0a). 1. **El Controlador se suscribe** (Add): Una fila nueva en Device.LocalAgent.Subscription. indica las rutas, el tipo de notificación y el Recipient. 2. **Se cumple la condición** (Evento): Cambia un Parameter, se agrega o elimina una instancia, termina una operación o se dispara un Event (por ejemplo, Boot!). 3. **El Agente reporta** (Notify): El Notify lleva el subscription_id y, si NotifRetry es true, send_resp en true. 4. **El Controlador confirma** (NotifyResp): Devuelve el mismo subscription_id. Si no hay respuesta, el Agente reintenta hasta NotifExpiration. *La vida de una suscripción USP, desde el Add que la crea hasta la respuesta al Notify. Diagrama de Dodderware, basado en TR-369 §7.6.1, §7.6.2 y §7.6.4.* > **¿Sabías que…?** > > Una suscripción no tiene por qué enviar nada. Con `TriggerAction`, puede hacer que el Agente cambie su propia > configuración en lugar de notificar, o que haga ambas cosas. En el ejemplo de la especificación, un evento > `Device.LocalAgent.Threshold.{i}.Triggered!` hace que el Agente envíe un Notify y active un perfil de Bulk Data > (§7.6.1.2). ## ¿Qué tipos de notificación define USP? Un Notify lleva exactamente uno de seis tipos de notificación (§7.6.4.2): | Tipo | Se envía cuando | Qué lleva | | ----------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | ValueChange | Un Parameter suscrito cambia de valor, aunque el cambio lo haya hecho el Controlador suscrito (§7.6.3.1) | `param_path`, `param_value` | | ObjectCreation | Se agrega una instancia a un Multi-Instance Object suscrito (§7.6.3.2) | `obj_path` y las `unique_keys` de la instancia | | ObjectDeletion | Se elimina una instancia de un Multi-Instance Object suscrito (§7.6.3.2) | `obj_path` | | OperationComplete | Termina una operación asíncrona, con éxito o no (§7.6.3.3) | `command_name`, `obj_path`, `command_key`, argumentos de salida o `cmd_failure` | | OnBoardRequest | El Agente le pide el onboarding a un Controlador, probablemente por primera vez (§7.6.3.4) | `oui`, `product_class`, `serial_number`, versiones de USP soportadas | | Event | Se dispara un evento definido en el modelo de datos, como Boot! (§7.6.3.5) | `obj_path`, `event_name` y los parámetros del evento | Todo Notify lleva además el `subscription_id` que el Controlador definió al crear la suscripción. En un OnBoardRequest, que no tiene suscripción, ese campo va vacío (R-NOT.7). ## ¿Cómo se ven Boot! y los demás eventos? Los eventos se definen en el modelo de datos, ligados a Objects, y su nombre termina en signo de exclamación, como `Device.Boot!` (§2.6.3). Boot! es además el ejemplo de notificación Event que da la especificación: su Notify indica `Device.` como objeto y `Boot!` como evento, con parámetros como `Cause`, `CommandKey`, `ParameterMap` y `FirmwareUpdated` (§7.6.4.1). Los eventos y OperationComplete suelen trabajar juntos. Cuando un Controlador ejecuta un Command asíncrono con Operate, el Agente crea un Request Object, lo elimina cuando termina la operación y envía el resultado en una notificación OperationComplete, con el `command_key` que eligió el Controlador, a todos los Controladores suscritos (§7.7.2). Para un cambio de firmware, la especificación recomienda suscribirse a un ValueChange de `DeviceInfo.SoftwareVersion` o al evento Boot!: si la versión no cambió, o si `FirmwareUpdated` viene en false, puede que el equipo haya tenido problemas para arrancar la imagen nueva (Apéndice II.2.1). El proceso completo está en [actualizaciones de firmware con USP](https://blog.dodderware.com/es/actualizacion-firmware-usp/). > **Dónde encaja DWS Support** > > DWS Support mantiene al día el estado de cada equipo USP con las notificaciones que envía su Agente: los eventos Boot! y > Periodic!, ValueChange y OperationComplete. Crea automáticamente las suscripciones que necesita al conectarse a un > Agente. > > [Conoce DWS Support](https://dodderware.com/es/productos/dws-support/) ## ¿Qué pasa si el Controlador no responde? La entrega solo se confirma si la suscripción lo pide. Cada Notify tiene un indicador `send_resp`. Si el Parameter `NotifRetry` de la suscripción es true, el Agente pone `send_resp` en true y solo da la notificación por entregada cuando el Controlador responde. Si es false, el Agente debería ignorar el estado de la entrega (§7.6.2). Cuando `send_resp` es false, el Controlador no debería responder (R-NOT.8), y cuando responde, debe devolver el mismo `subscription_id` (R-NOT.10). Si no hay respuesta, el Agente reintenta con un algoritmo fijo (R-NOT.1). Dos Parameters de cada entrada de la tabla de Controladores del Agente marcan el ritmo: `USPNotifRetryMinimumWaitInterval`, 5 segundos por defecto, y `USPNotifRetryIntervalMultiplier`, 2000 por defecto, que la fórmula divide entre 1000, así que cada rango se duplica: | Reintento | Rango de espera por defecto | | -------------- | ----------------------------------------------- | | 1 | De 5 a 10 segundos | | 2 | De 10 a 20 segundos | | 3 | De 20 a 40 segundos | | 4 a 9 | Se duplica, hasta llegar a 1280 a 2560 segundos | | 10 en adelante | De 2560 a 5120 segundos | Desde el décimo reintento, el rango queda fijo (R-NOT.2), y el Agente sigue intentando hasta que la notificación se entrega o se alcanza el `NotifExpiration` de la suscripción (§7.6.2). El conteo de reintentos vuelve a cero después de cada entrega exitosa y después de un reinicio (R-NOT.3, R-NOT.4). Un Controlador con los permisos adecuados puede cambiar ambos Parameters en cualquier momento (R-NOT.1). OnBoardRequest es la única notificación que nunca se rinde. Debe enviarse con `send_resp` en true y reintentarse hasta que el Controlador la confirme con un Notify Response (R-NOT.6, R-NOT.6a), como si perteneciera a una suscripción con `NotifExpiration` en 0, es decir, sin vencimiento (§7.6.3.4). ## ¿En qué se diferencia de TR-069? La mayor diferencia es a quién se le avisa. La especificación incluye una nota para quienes vienen de TR-069: en CWMP, al ACS no se le notifican los cambios de valor que provocó el propio ACS, porque con un solo ACS no hace falta. En USP, el Agente sigue cada suscripción sin importar quién la creó (§7.6.1), y un ValueChange se envía aunque el cambio lo haya hecho el mismo Controlador que se suscribió (§7.6.3.1). Con varios Controladores en un mismo Agente, cada uno recibe las notificaciones de sus propias suscripciones, sin importar quién hizo el cambio. Hay un matiz. Algunos eventos se definen por Controlador, como los de `Device.BulkData.` o `Device.LocalAgent.Threshold.`, y solo van al Controlador que configuró su origen, aunque otro Controlador tenga una suscripción (§4.1.3.1, R-MTP.4e). Para la comparación completa entre ambos protocolos, lee [TR-069 vs TR-369](https://blog.dodderware.com/es/tr-069-vs-tr-369/), y para el resto de USP, empieza por [qué es TR-369](https://blog.dodderware.com/es/que-es-tr-369/). ## ¿Sabías que…? - USP no tiene un mensaje Subscribe. Un Controlador se suscribe creando una instancia del Subscription Object en el modelo de datos del Agente con un Add común y corriente. (TR-369 §7.3.3.2, §7.6.1.1) - Una implementación debería cambiar su estado e iniciar la Notification en una ventana de no más de 10 segundos. (TR-369 §7.6.1 (R-NOT.0a)) - Un ValueChange se envía aunque el cambio lo haya hecho el mismo Controlador suscrito. En TR-069, al ACS no se le notifican los cambios que él mismo provocó. (TR-369 §7.6.1, §7.6.3.1) - Con los valores por defecto, los reintentos de una notificación empiezan con una espera de 5 a 10 segundos y se duplican hasta llegar a un rango fijo de 2560 a 5120 segundos. (TR-369 §7.6.2 (R-NOT.1, R-NOT.2)) - OnBoardRequest nunca es objeto de una suscripción, y debe reintentarse hasta que el Controlador lo confirme. No vence. (TR-369 §7.6.3.4 (R-NOT.6, R-NOT.6a)) ## Preguntas frecuentes ### ¿Cómo se suscribe un Controlador a las notificaciones en USP? Envía un mensaje Add que crea una instancia de Device.LocalAgent.Subscription.{i}. en el Agente, con las rutas que le interesan en el Parameter ReferenceList y el tipo de notificación que quiere. No existe un mensaje Subscribe aparte. ### ¿Qué es una notificación ValueChange en TR-369? Una notificación que envía el Agente cuando un Parameter suscrito cambia de valor. Lleva la ruta del Parameter y su nuevo valor, y se envía aunque el cambio lo haya hecho el mismo Controlador suscrito. ### ¿Qué tipos de notificación soporta USP? ValueChange, ObjectCreation, ObjectDeletion, OperationComplete, OnBoardRequest y Event. Event lleva eventos definidos en el modelo de datos, como Boot!. OnBoardRequest es el único que no es objeto de una suscripción. ### ¿Qué significa send_resp en un Notify de USP? Le indica al Controlador si el Agente espera una respuesta. Cuando el Parameter NotifRetry de la suscripción es true, el Agente pone send_resp en true y solo da la notificación por entregada cuando el Controlador responde. Si no hay respuesta, reintenta. ### ¿Cada cuánto reintenta un Agente USP una notificación? Con los valores por defecto, el primer reintento espera de 5 a 10 segundos y cada rango siguiente se duplica, hasta 2560 a 5120 segundos desde el décimo reintento. El Agente se detiene cuando la notificación se entrega o cuando se alcanza el NotifExpiration de la suscripción. ### ¿Un Agente USP le notifica a un Controlador los cambios que hizo ese mismo Controlador? Sí. La especificación aclara que en TR-069 al ACS no se le notifican los cambios de valor que él provocó, porque hay un solo ACS, mientras que un Agente USP sigue cada suscripción sin importar quién la creó. ## Fuentes - Broadband Forum, TR-369 – The User Services Platform, Issue 1 Amendment 5 (USP 1.5), enero de 2026. - Dodderware, documentación de producto e ingeniería de DWS Support. - §1.4, §2.6.3: Definiciones (Event, Notification, Subscription) y Event Path Names - §4.1.3.1: Eventos que solo van al Controlador que configuró su origen (destination_id) - §7.3.3.2, §7.5.1.1: Tipos de request, y el ejemplo de Get sobre la tabla de suscripciones - §7.6, §7.6.1, §7.6.1.1, §7.6.1.2: Mecanismo de suscripciones (R-NOT.0, R-NOT.0a), ReferenceList y TriggerAction - §7.6.2: send_resp, NotifRetry y el algoritmo de reintentos (R-NOT.1 a R-NOT.4) - §7.6.3, §7.6.4: Tipos de notificación, el mensaje Notify, sus ejemplos y sus campos (R-NOT.5 a R-NOT.10) - §7.7.2: Operaciones asíncronas y OperationComplete - §8.9.2.1: El permiso n (Notify) en los Roles de los Controladores - Apéndice II.2.1: Seguir un cambio de firmware con ValueChange o Boot! [Leer la especificación TR-369](https://usp.technology/specification/index.htm) TR-369 © The Broadband Forum. Todos los derechos reservados. Citado brevemente y parafraseado con fines explicativos; los diagramas son de Dodderware. --- **Gestiona equipos TR-069 y TR-369 desde una sola consola.** DWS Support reúne cada ONT y router del hogar en una consola web, hable el protocolo que hable: TR-069 por GenieACS o un ACS integrado, TR-369 por un controlador USP nativo. Se instala en tu propia infraestructura. [Solicita una demo](https://dodderware.com/es/productos/dws-support/#get-started)