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

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:

¿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. OperateDownload()Se invoca sobre una instancia de FirmwareImage no activa, con el checksum de la imagen.
2. AgenteValidarEl Agente revisa la imagen y su checksum. El resultado llega como una notificación OperationComplete.
3. OperateCambiar de imagen
   • Activate() sobre la instancia
   • o BootFirmwareImage más Reboot()
4. NotifyConfirmar el arranque
   • Boot! con FirmwareUpdated
   • ValueChange en SoftwareVersion

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.

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

¿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ó.

¿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).

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