Appendix I - Firmware Management of Devices with USP Agents

  1. Getting the firmware image onto the device
  2. Using multiple firmware images
    1. Switching firmware images
    2. Performing a delayed firmware upgrade
    3. Recovering from a failed upgrade

Many manufacturers build and deploy devices that are able to support multiple firmware images (i.e. multiple firmware images can be installed on an Agent at the same time). There are at least a couple of advantages to this strategy:

  1. Having multiple firmware images installed improves the robustness and stability of the device because, in all likelihood, one of the installed images will be stable and bootable. Should a device not be able to boot a newly installed firmware image, it could have the ability to attempt to boot from a different firmware image, thus allowing the device to come back online.

  2. Support for multiple firmware images offers the ability for the service provider to have a new firmware downloaded (but not activated) to the device at any point during the day, then perhaps requiring only a Set message and an Operate message to invoke the Reboot command at some later time (perhaps during a short maintenance window or when the device is idle) to cause the device to switch over to the new firmware. Along with reducing the impact on the subscriber, the ability to spread the download portion a firmware upgrade over a longer period of time (eg, the entire day or over several days) can help minimize the impact of the upgrade on the provider’s network.

This Appendix discusses how to utilize the firmware image table on a device to support firmware upgrades whether the device supports multiple instances or just a single instance.

Getting the firmware image onto the device

A Controller can download a firmware image to an Agent by invoking the Download() command (via the Operate message) found within an instance of the Device.FirmwareImage.{i}. data model table. The Download() command will cause the referenced file to be downloaded into the firmware image instance being operated on, and it will cause that file to be validated by the Agent (the validation process would include any normal system validate of a firmware image as well as the check sum validation provided in the Download() command).

If an Agent only supports a single firmware image instance then a Controller would invoke the Download() command on that active firmware image instance using the AutoActivate argument to immediately activate the new firmware after it has been downloaded. Neither the Device.DeviceInfo.BootFirmwareImage parameter nor the Device.DeviceInfo.FirmwareImage.{i}.Activate() command would typically be implemented by a device that only supports a single firmware image instance.

If an Agent supports more than a single firmware image instance then a Controller would typically invoke the Download() command on a non-active firmware image instance in an effort of preserving the current firmware image in case of an error while upgrading the firmware. A firmware image instance is considered active if it is the currently running firmware image.

Using multiple firmware images

This section discusses the added functionality available when a device supports two or more instances in the Device.FirmwareImage.{i}. data model table.

Switching firmware images

Once a device has multiple firmware images downloaded, validated, and available, a Controller can use the data model to query what images are on the device, which image is active, and configure which image to activate.

A Controller can activate a new firmware image by following one of two different procedures: (A) the Controller can modify the Device.DeviceInfo.BootFirmwareImage parameter to point to the Device.DeviceInfo.FirmwareImage.{i}. object instance that contains the desired firmware image and then reboot the device by invoking an Operate message with a Reboot() command or (B) the Controller can invoke an Operate message with an Activate() command against the desired FirmwareImage instance.

When attempting to get a device to switch to a different firmware image, it is recommended that the Controller either subscribe to a ValueChange notification on the DeviceInfo.SoftwareVersion parameter or subscribe to the Boot! Event notification. If the Software Version value has not changed or the Boot! Event’s FirmwareUpdated argument is false, it could be an indication that the device had problems booting the target firmware image.

Performing a delayed firmware upgrade

One of the benefits to having support for multiple firmware images on a device is that it provides an opportunity to push a firmware image to a device and then have the device switch to that image at a later time. This functionally allows a service provider to push a firmware image to a set of devices at any point during the day and then use a maintenance window to switch all of the target devices to the target firmware.

This ability is of value because normally the download of the firmware and the switch to the new image would both have to take place during the maintenance window. Bandwidth limitations may have an impact on the number of devices that can be performing the download at the same time. If this is the case, the number of devices that can be upgrading at the same time may be lower than desired, requiring multiple maintenance windows to complete the upgrade. However, support for multiple firmware images allows for the service provider to push firmware images over a longer period of time and then use a smaller maintenance window to tell the device to switch firmware images. This can result is shorter system-wide firmware upgrades.

Recovering from a failed upgrade

Another benefit of having multiple firmware images on a device is that if a device cannot boot into a target firmware image because of some problem with the image, the device could then try to boot one of the other firmware images.

When there are two images, the device would simply try booting the alternate image (which, ideally, holds the previous version of the firmware). If there are more than two images, the device could try booting from any of the other available images. Ideally, the device would keep track of and try to boot from the previously known working firmware (assuming that firmware is still installed on the device).

Should the device boot a firmware image other than that specified via the Device.DeviceInfo.BootFirmwareImage parameter, it is important that the device not change the value of the Device.DeviceInfo.BootFirmwareImage parameter to point to the currently-running firmware image object. If the device was to change this parameter value, it could make troubleshooting problems with a firmware image switch more difficult.

It was recommended above that the Controller keep track of the value of Device.DeviceInfo.SoftwareVersion parameter or the FirmwareActivation enumerated value in the Boot! Event’s Cause argument. If the version changes unexpectedly or a FirmwareActivation cause is detected, it could be an indication that the device had problems booting a particular firmware image.