Partager via

OMA DM version 1.2 Architecture

  • Article

4/8/2010

Managing devices with OMA DM version 1.2 allows two-way communication between the server and client, which enables device manageability.

OMA DM version 1.2 allows end-to-end firmware deployment by notifying the server that an update was successful or that it failed. Firmware Update Managed Object (FUMO) uses the generic alert for this firmware update final notification.

OMA DM version 1.2 is compatible with both GSM and CDMA networks, and is backward compatible with the OMA DM version 1.1.2 server.

OEMs and mobile operators can configure the client to retry package delivery with an OMA DM version 1.1.2 package if OMA DM version 1.2 package delivery is unsuccessful. The number of times a retry is attempted, and the interval between retries is also configurable. **

Note

In some areas, Microsoft has extended the OMA standards. For more information, see OMA DM Standards and Extensions.

For best practices, see Best Practices in Managing Devices.

For security best practices, see Security and Managing Devices and OMA Device Management Security Best Practices.

Architecture

The following diagram illustrates the architecture for device management through over-the-air (OTA) device configuration using the OMA Device Management version 1.2 protocol.

Bb737599.19f009d0-f724-40ca-bf2a-57cad7b7995b(en-us,MSDN.10).gif

In the following scenario, the Windows Mobile device has already bootstrapped with the OMA DM server version 1.2 account information.

Note

Microsoft does not provide an OMA DM server. The OEM, mobile operator, or a third party must create their own server. For information about server requirements, see Server Requirements for OMA Device Management.

The mobile operator wants to configure the device OTA such that the device can synchronize emails, contacts, and calendar with Sync Server.

With OMA DM, communication occurs over an HTTPS channel.

The numbers in the picture correspond to the following steps:

  1. Using a WAP push, the mobile operator sends an OMA DM notification to the device.
  2. The device receives this message through Short Message Service (SMS). The message is then routed to the Push Router.
  3. The push router authenticates the message, and then sends the message to the OMA DM transport client to initiate a DM session.
  4. The DM transport client sets up the secure transport channel with the server, sends the package to the server.
  5. The server parses the package to identify the device type, creates the configuration data, packages it in a DM message, and then sends it back to the device
  6. The DM client receives the message, parses the SyncHdr element, and passes the SyncBody element to the OMA DM data process unit (DPU).
  7. The OMA DM DPU parses incoming SyncBody OMA DM XML, sends the DM request to the Configuration Manager2, and then creates a response SyncBody based on the result it receives from Configuration Manager2.
  8. Configuration Manager2 checks the access permit to find whether the action is permitted for designated objects by that particular server, and identifies which configuration service provider should be called.
  9. Configuration Manager2 routes the command to specific configuration service provider. The configuration service provider processes the command and sends processing result back to the Configuration Manager2.
  10. The Configuration Manager2 sends the result back to the DPU. The DPU then parses the result and creates the corresponding status OMA DM element.
  11. After all commands are processed, the DPU sends the response back to OMA DM transport client.
  12. The OMA DM transport client then creates the response OMA message and sends it back to the server.
  13. The server parses the package. When everything is configured correctly, it sends the last DM message to the device to close the session.

See Also

Reference

Provisioning OTA Through an OMA DM Server

Other Resources

OMA Device Management