# ¿Cómo se actualiza el firmware de un equipo USP (TR-369)?

Equipo de ingeniería de Dodderware · Publicado 2026-10-28 · https://blog.dodderware.com/es/actualizacion-firmware-usp/

[Read in English](https://blog.dodderware.com/usp-firmware-upgrade/)

> **Respuesta corta:** En TR-369, el Controlador actualiza el firmware invocando Download(), mediante un mensaje Operate, sobre una instancia de la tabla Device.DeviceInfo.FirmwareImage. El Agente descarga el archivo en esa instancia y lo valida, checksum incluido. Un equipo de una sola imagen la activa de inmediato con AutoActivate. Uno con dos o más imágenes descarga en una instancia no activa y luego cambia con Activate() o con un reinicio.

Si planificas actualizaciones de firmware en CPE, enviar el archivo es lo fácil. Las preguntas difíciles vienen después:
¿la imagen pasó la validación?, ¿el equipo arrancó con ella? y ¿qué le pasa al suscriptor si no? TR-369 las responde en
su teoría de operación del firmware, el Apéndice II, construida alrededor de una tabla del modelo de datos y dos
comandos, `Download()` y `Activate()`. Esta guía la recorre con lo que dice la especificación y nada más.

## ¿Dónde guarda USP el firmware de un equipo?

La gestión del ciclo de vida del firmware es una de las extensiones que TR-369 incluye en su alcance (§1.2.2), y va por
separado del resto del software del equipo. La gestión de módulos de software de USP considera módulo a todo el software
del equipo, salvo el firmware primario (Apéndice I.2). Ese firmware se gestiona con los objetos Firmware Image del
modelo de datos.

Esos objetos forman la tabla `Device.DeviceInfo.FirmwareImage.{i}.`, donde cada instancia guarda una imagen, y una
instancia está activa si contiene el firmware que está corriendo en ese momento (Apéndice II.1). El apéndice trabaja con
cuatro elementos:

| Elemento del modelo de datos                         | Para qué sirve                                                                |
| ---------------------------------------------------- | ----------------------------------------------------------------------------- |
| `Device.DeviceInfo.FirmwareImage.{i}.Download()`     | Descarga un archivo en esa instancia de imagen y hace que el Agente lo valide |
| `Device.DeviceInfo.FirmwareImage.{i}.Activate()`     | Cambia el equipo a la imagen guardada en esa instancia                        |
| `Device.DeviceInfo.BootFirmwareImage`                | Apunta a la instancia de imagen con la que debe arrancar el equipo            |
| `Device.DeviceInfo.FirmwareImage.{i}.BootFailureLog` | Registra qué salió mal cuando esa imagen falló                                |

## ¿Cómo llega una imagen nueva al equipo?

El Controlador invoca `Download()`, mediante un mensaje Operate, sobre una instancia de la tabla de imágenes. El comando
descarga el archivo indicado en esa instancia y hace que el Agente lo valide: la validación normal de cualquier imagen
de firmware en el sistema, más la suma de verificación (checksum) que el Controlador incluyó en el comando `Download()`
(Apéndice II.1).

La instancia de destino depende del equipo (Apéndice II.1):

- **Una sola imagen.** El Controlador invoca `Download()` sobre la instancia activa con el argumento `AutoActivate`,
  así el firmware nuevo se activa apenas termina la descarga. Un equipo así por lo general no implementa
  `BootFirmwareImage` ni `Activate()`.
- **Dos o más imágenes.** El Controlador suele invocar `Download()` sobre una instancia no activa, para conservar la
  imagen actual por si algo falla durante la actualización.

1. **Download()** (Operate): Se invoca sobre una instancia de FirmwareImage no activa, con el checksum de la imagen.
2. **Validar** (Agente): El Agente revisa la imagen y su checksum. El resultado llega como una notificación OperationComplete.
3. **Cambiar de imagen** (Operate)
   - Activate() sobre la instancia
   - o BootFirmwareImage más Reboot()
4. **Confirmar el arranque** (Notify)
   - Boot! con FirmwareUpdated
   - ValueChange en SoftwareVersion

*Actualización de firmware en un equipo con dos o más imágenes, de la descarga al arranque confirmado. Diagrama de Dodderware, basado en TR-369 Apéndice II.1, II.2.1 y §7.6.3.3.*

Cuando el equipo ya tiene varias imágenes descargadas, validadas y disponibles, el Controlador puede consultar cuáles
hay, cuál está activa y configurar cuál activar. Para hacer el cambio tiene dos caminos (Apéndice II.2.1): apuntar
`Device.DeviceInfo.BootFirmwareImage` a la instancia con la imagen deseada y reiniciar el equipo con un comando
`Reboot()`, o invocar `Activate()` sobre esa instancia.

## ¿Cómo sabe el Controlador que terminó la descarga?

`Download()` informa su resultado con la notificación OperationComplete. La especificación lo usa justamente como
ejemplo del comando que origina esa notificación (§7.6.4.2.5), y OperationComplete existe para avisar que una operación
asíncrona terminó, con éxito o sin él (§7.6.3.3).

Las operaciones asíncronas siguen un patrón fijo (§7.7.2):

1. El Agente crea una instancia en su tabla Request y devuelve una referencia a ella en la respuesta a Operate. La
   elimina cuando la operación termina, haya salido bien o mal.
2. El Controlador que quiere conocer el resultado crea una suscripción con `NotificationType` en OperationComplete y un
   `ReferenceList` que incluye la ruta del comando.
3. Cuando la operación termina, el Agente envía un Notify con el `command_key` que el Controlador eligió en su solicitud
   Operate. La notificación trae los argumentos de salida o un `CommandFailure` con un código y un mensaje de error
   (§7.6.4.2.5).

El Controlador también puede cancelar una solicitud que siga en la tabla con `Device.LocalAgent.Request.{i}.Cancel()`
(§7.7.2). Un detalle importa para el firmware: no se espera que las operaciones asíncronas sobrevivan a un reinicio del
Agente, y un comando que seguía en proceso cuando el Agente reinició se considera fallido, salvo que la descripción del
comando diga que se conserva (§7.7.2.1). Las suscripciones y Notify se explican en
[notificaciones y suscripciones USP](https://blog.dodderware.com/es/notificaciones-usp/).

## ¿Cómo confirmas que el equipo arrancó con la imagen nueva?

Que la descarga salga bien no prueba que el equipo esté corriendo el firmware nuevo. Al cambiar de imagen, la
especificación recomienda que el Controlador se suscriba a un ValueChange de `DeviceInfo.SoftwareVersion` o al evento
`Boot!`. Si la versión de software no cambió, o si el argumento `FirmwareUpdated` de `Boot!` es false, el equipo pudo
tener problemas para arrancar con la imagen de destino (Apéndice II.2.1). En el ejemplo de la propia especificación, una
notificación `Boot!` trae `Cause`, `CommandKey`, `ParameterMap` y `FirmwareUpdated` (§7.6.4.1).

Las mismas señales sirven al revés. Si la versión cambia sin que nadie lo esperara, o si `FirmwareUpdated` es true sin
que hubiera un cambio planeado, el equipo pudo tener problemas para arrancar con alguna imagen (Apéndice II.2.3).

Cuando el equipo vuelva, revisa el servicio además de la versión. En una ONT de fibra, el primer número que conviene
leer es la potencia óptica: mira [qué potencia RX es normal en una ONT GPON](https://blog.dodderware.com/es/potencia-optica-ont-gpon/).

## ¿Qué pasa cuando falla una actualización?

Aquí es donde una segunda imagen se gana su lugar. Si el equipo no logra arrancar con la imagen de destino, puede probar
con otra (Apéndice II.2.3):

- Con dos imágenes, simplemente prueba con la alternativa, que idealmente guarda la versión anterior del firmware.
- Con más de dos, puede probar con cualquiera de las otras disponibles, idealmente con el último firmware que funcionó.

El equipo también tiene que dejar rastro. Si arranca con una imagen distinta a la que indica `BootFirmwareImage`, no
debe cambiar ese parámetro para que apunte a la imagen en uso, porque eso complicaría diagnosticar el problema del
cambio (Apéndice II.2.3). Así el Controlador sigue viendo qué imagen pidió.

> **¿Sabías que…?**
>
> USP trata la pérdida del Controlador como una actualización fallida. Si al activar una imagen el Agente ya no logra
> enviarle mensajes a su Controlador, o le envía mensajes que el Controlador no entiende, se espera que el equipo vuelva a
> la imagen activada antes y deje información en el `BootFailureLog` de la imagen que falló (Apéndice II.2.3).

## ¿Cómo actualizas toda la flota en una ventana corta?

Normalmente, la descarga y el cambio tienen que caber dentro de la ventana de mantenimiento. El ancho de banda puede
limitar cuántos equipos descargan al mismo tiempo, y entonces la actualización puede necesitar varias ventanas
(Apéndice II.2.2).

Los equipos con más de una imagen cambian eso. El proveedor puede enviar la imagen a un grupo de equipos a cualquier
hora del día y luego usar una ventana de mantenimiento más corta para cambiarlos a todos, lo que según la
especificación puede acortar las actualizaciones de toda la red (Apéndice II.2.2). Cambiar más tarde también reduce el
impacto para el suscriptor, y repartir la descarga a lo largo del día, o de varios días, puede ayudar a reducir el
impacto en la red del proveedor (Apéndice II).

> **Dónde encaja DWS Support**
>
> El controlador USP de DWS Support envía las descargas de firmware a los Agentes como comandos Operate de USP y actualiza
> el estado de cada equipo con sus notificaciones OperationComplete. Las actualizaciones de flota corren como campañas que
> necesitan aprobación antes de arrancar: primero un grupo canary, luego una rampa y al final disponibilidad general (GA),
> dentro de una ventana de mantenimiento y con un límite de tasa, y cualquier campaña se puede pausar o abortar. Las
> imágenes deben publicarse antes de usarse y llegan a los equipos por URLs con token de corta duración, y los operadores
> pueden marcar versiones de firmware con problemas conocidos para que aparezca una advertencia en las páginas de firmware
> y de equipo.
>
> [Conoce DWS Support](https://dodderware.com/es/productos/dws-support/)

## ¿El firmware sigue importando si el software se vuelve modular?

Sí, aunque la especificación espera que cambie con menos frecuencia. Operadores y fabricantes se están alejando de las
imágenes de firmware monolíticas hacia un software modular, que permite acortar los plazos de versionado del firmware,
normalmente de 12 a 18 meses, y actualizar servicios individuales sin tocar el firmware completo, incluidos parches
rápidos para problemas de seguridad (Apéndice VI.1).

El firmware primario queda fuera de ese modelo y se gestiona con sus propios objetos Firmware Image (Apéndice I.2). La
imagen base del equipo sigue pasando por `Download()` y `Activate()`. Para ver el panorama completo de lo que cubre
TR-369, lee [qué es TR-369](https://blog.dodderware.com/es/que-es-tr-369/).

## ¿Sabías que…?

- El Controlador inicia una actualización de firmware invocando el comando Download(), mediante un mensaje Operate, sobre una instancia de la tabla Device.DeviceInfo.FirmwareImage. (TR-369 Apéndice II.1)
- El Agente valida cada imagen descargada, incluida la suma de verificación (checksum) que el Controlador indicó en el comando Download(). (TR-369 Apéndice II.1)
- En un equipo con dos o más imágenes, la nueva suele ir a una instancia no activa, para que el firmware en uso sobreviva a una actualización fallida. (TR-369 Apéndice II.1)
- Si al activar una imagen el Agente pierde la conexión con su Controlador, se espera que el equipo vuelva a la imagen activada antes y registre la falla en BootFailureLog. (TR-369 Apéndice II.2.3)
- Los operadores adoptan software modular en parte para acortar los plazos de versionado del firmware, que normalmente son de 12 a 18 meses. (TR-369 Apéndice VI.1)

## Preguntas frecuentes

### ¿Qué diferencia hay entre Download() y Activate() en USP?

Download() trae un archivo de firmware a una instancia de Device.DeviceInfo.FirmwareImage y hace que el Agente lo valide. Activate() cambia el equipo a una imagen que ya tiene. Los equipos de una sola imagen usan en su lugar Download() con el argumento AutoActivate y por lo general no implementan Activate().

### ¿Cómo sabe el Controlador que terminó la descarga del firmware?

El Controlador se suscribe a la notificación OperationComplete del comando. Cuando la operación termina, el Agente envía un Notify con la clave de comando que eligió el Controlador, con los argumentos de salida o con un CommandFailure y su código de error.

### ¿Cómo confirmo que el equipo arrancó con el nuevo firmware?

La especificación recomienda suscribirse a un ValueChange de DeviceInfo.SoftwareVersion o al evento Boot!. Si la versión no cambió, o si el argumento FirmwareUpdated de Boot! es false, el equipo pudo tener problemas para arrancar con la imagen de destino.

### ¿Qué pasa si falla una actualización de firmware con USP?

Un equipo con varias imágenes puede arrancar con otra, idealmente la última que funcionó. Si la imagen nueva corta la conexión del Agente con su Controlador, se espera que el equipo vuelva a la imagen activada antes y registre la falla en el BootFailureLog de esa imagen.

### ¿Se puede descargar el firmware de día y cambiarlo de noche?

Sí, en equipos con más de una imagen. La especificación describe enviar la imagen a cualquier hora del día y cambiar todos los equipos de destino dentro de una ventana de mantenimiento más corta, lo que puede acortar las actualizaciones de toda la red.

### ¿USP gestiona el firmware igual que los demás módulos de software?

No. La gestión de módulos de software de USP cubre todo el software del equipo excepto el firmware primario, que se gestiona con los objetos Firmware Image del modelo de datos.

## 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.2.2: Alcance, incluida la gestión del ciclo de vida del firmware
- Apéndice II, II.1: Gestión de firmware en equipos con Agentes USP y carga de la imagen en el equipo
- Apéndice II.2.1, II.2.2, II.2.3: Cambio de imagen, actualizaciones diferidas y recuperación de una actualización fallida
- §7.6.3.3, §7.6.4.1, §7.6.4.2.5: La notificación OperationComplete, el ejemplo del evento Boot! y los campos de OperationComplete
- §7.7.2, §7.7.2.1: Operaciones asíncronas, la tabla Request y su persistencia tras un reinicio
- Apéndice I.2: Módulos de software y firmware primario
- Apéndice VI.1: Modularización del software y plazos de versionado del firmware
- DWS · Brief de producto: Campañas de firmware, entrega de imágenes y avisos de problemas conocidos en DWS Support

[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)