|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
This topic describes the overall architecture of OTA Firmware Update.
|This architecture applies to Windows Mobile 6.1 and later.|
For a broad overview, see Understanding OTA Firmware Update.
- The OEM has created update packages for various versions using
- The update packages are signed.
- The update packages are stored in the OMA DM server or in a
The OTA firmware update process can be automated. Your OMA DM server initiates this process, which involves interaction among the DM server, the OMA DM client, the Download Agent, and the image update installer on the client device.
The following illustration shows the architecture for OTA firmware update.
The following numbered steps correspond with the numbers in the illustration:
- The OMA DM server sends a notification SMS trigger to the
The SMS message includes server identification (server ID) and tells the client device to initiate a session with the OMA DM server. The client device uses the server ID to verify that the server is authorized to communicate with it.
- The client device sends a message over an IP connection to
initiate a session. The message includes device information, such
as information from the DevInfo Configuration Service Provider.
- Microsoft strongly recommends that the OMA DM server send a
ROMPackage object query to the client device to get the ROM
versions of the device.
Note: The ROM on a Windows Mobile device is segmented into packages. Each ROM package has its own version, and each package can be updated independently.
Packages are identified by package identification (package ID).
- Based on the ROM versions, the OMA DM server determines which
update package should be implemented and then sends the package
information (such as the URL indicating the location of the
package) to the firmware update managed object.
The OMA DM server then performs an Exec command.
For more information, see FwUpdate Configuration Service Provider. For an example of the XML for OTA firmware Update, see OTA Firmware Update Example.
- The FwUpdate Configuration Service Provider accepts the request
and then passes the package download URL to the Download Agent.
- The Download Agent notifies the user of the update for
informational purposes, and then downloads the package from the
Note: Microsoft recommends that the server use HTTP and support byte range headers. In case of interruption, the use of byte range headers enables a download to resume from the point of interruption; otherwise, the download restarts. Note: The user can monitor the download status by looking at a progress bar in the Download Agent UI.
- If the download succeeds, the Download Agent device calls the
device Image Update installer to install the update. The Update
Agent (UpdateBin.exe) initiates the update process.
If the installation succeeds, the device is rebooted, and a UI prompt informs the user that the installation succeeded.
If the installation fails, the Download Agent maps the failure code to a Firmware Update Managed Object (FUMO) result code, and then collects the necessary information from the FwUpdate Configuration Service Provider.
- The State node in the FwUpdate Configuration Service Provider
is updated with failure or success.
- The final status (success or failure) is sent to the OMA DM
server over a new DM session by using the OMA DM generic alert
1226. The correlator that was set during the Exec command of the
FwUpdate Configuration Service Provider is also passed. For
information about FUMO result codes that Windows Mobile supports,
Update Result Codes.
- The OMA DM server can query the ROMPackage object to verify
that the version node contains the updated version information.