¿Cómo funcionan las notificaciones y suscripciones USP en TR-369?

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. AddEl Controlador se suscribeUna fila nueva en Device.LocalAgent.Subscription. indica las rutas, el tipo de notificación y el Recipient.
2. EventoSe cumple la condiciónCambia un Parameter, se agrega o elimina una instancia, termina una operación o se dispara un Event (por ejemplo, Boot!).
3. NotifyEl Agente reportaEl Notify lleva el subscription_id y, si NotifRetry es true, send_resp en true.
4. NotifyRespEl Controlador confirmaDevuelve el mismo subscription_id. Si no hay respuesta, el Agente reintenta hasta NotifExpiration.

¿Qué tipos de notificación define USP?

Un Notify lleva exactamente uno de seis tipos de notificación (§7.6.4.2):

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.

¿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:

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, y para el resto de USP, empieza por qué es TR-369.