Overview of OMA DM

"SyncML" is the old, collective term for the OMA (DM and DS) protocol and elements. The usage of "SyncML" in this documentation set is equivalent to referring to the current OMA standard.

OMA device management (OMA DM) is a standard developed by the Open Mobile Alliance (OMA), which allows remote configuration of mobile devices. Remote configuration includes setting of device parameters, obtaining troubleshooting information, installing or upgrading software, etc. OMA DM consists of three parts:

  • Protocol - The network protocol used between a management server and a mobile device. The OMA DM protocol is based on messages in XML format, exchanged between the devices and the server over different network transports. The protocol is designed to be network transport-independent – OMA defines standard bindings over several transports, but additional protocols can be also integrated in a proprietary way.

    The OMA DM message format and protocol are specified in the OMA Device Management Protocol version 1.2, OMA Representation Protocol version 1.2,OMA Device Management Representation Protocol version 1.2., and binding of the SyncML over HTTP transport is specified in the SyncML HTTP Binding specification version 1.2.

  • Data model - The data available for remote manipulation of the device configuration. OMA DM represents all available management objects of a single device as a hierarchical tree structure where all nodes can be uniquely addressed with URIs. This structure is called Device Management Tree (DMT). The management server is able to obtain current device configuration by inspecting the tree structure and values associated with the tree nodes of the DMT. The server is also able to change the configuration of the device by manipulating these structure and/or node values, using a small fixed set of commands.

    The structure of the DMT and available set of commands for its manipulation depends of the concrete device model. That's why OMA DM also defines a mechanism for describing the DMT structure supported by the devices of particular type. This mechanism is called Device Description Framework (DDF) and is based on one or more XML-formatted files, which describe the whole management tree or separate management objects (DMT sub-trees) supported by the device.

  • Policy - The policy decides who can manipulate a particular parameter, or update a particular object in the device.

Mobile Device Management Architecture

The Mobile Device Management building components are shown below:

Mobile Device Manager

The Mobile Device Manager is responsible for representing the OMA DM devices in a way compliant with the RM Generic Device Management (GDM) system, so that such devices can be controlled from RM through its unified management mechanism. To do this, the Mobile Device Manager represents OMA DM enabled devices as hierarchical sets of control unit (CU) objects.

RM Mobile Device Manager can be configured to operate with arbitrary OMA DM devices using appropriate "Control Unit to DMT Mapping" (CU-DMTM) files. CU-DMTM files are in XML format, and are intended to instruct the device manager about the DMT structure and the way this DMT structure and DMT node values are mapped to CU instances, CU state variables and CU actions. For more information about CU-DMTM files, refer to Developer Guide.

In addition to the CU-DMTM files, some CU state variables and actions may be implemented in Java and deployed on RM as State Variable Plugins and Action Plugins. Such components may be needed when the means delivered by the declarative CU-DMTM files are not sufficient to express the logic of a state variable or the activities of an action. For more info refer to the Developing CU State Variable and Action Plugins guide.

RM Mobile Device Manager component exports two types of interfaces:

  • Control Unit Providers - Acts as a device adapter between the RM core GDM system and the Mobile DM system, e.g. through these adapters mobile devices are represented in the generic management model of RM, and hence can be manipulated through the built-in RM device management mechanisms. In this way, a mobile can also be accessed by the user through the Management Console and by custom applications through the front-end GDM APIs in the same way as the other device types supported in RM and without the need of developing any specific software for adaptation';

  • Low-level DMT API – Enables at a low level to communicate with OMA DM devices by using directly the target OMA DM element – getting the DMT structure and DMT node values and sending OMA DM commands. This API is useful to custom application modules requiring more direct control over the mobile device, i.e. not abstracted via RM Generic Device Management. Refer to the Managing a Device's DMT document for more information about using it.

OMA DM Server

The OMA DM Server implements the server side of the OMA DM protocol, including device identification and session management. Refer to the OMA DM Server API documentation for more details on using the server for management with OMA DM devices.

Custom Alert Handlers

The format and semantics of the possible alert messages that an OMA DM client can send to the management server is not covered by the OMA specifications. That's why the system provides a mechanism for installing special plugins, called Alert Handlers, which will be called to interpret a certain type of alert messages coming from devices. For more information, see the Handling Device Alerts document.

OMA Download Server

The OMA Download Server provides mobile devices with ability to download client bundles stored in the RM Software Repository over the OMA Download protocol. For this purpose the OMA Download Server generates at runtime the proper download descriptors upon a request from the device.