Overview
The device manager of RM's OMA device management system offers means for control of OMA DM devices through the RM generic model for management of arbitrary device types. The model is based on Control Unit abstraction, and allows representing miscellaneous devices and their resources as hierarchies of control unit objects sharing a common interface for control.
The RM obtains a device's configuration by inspecting the control unit structure and querying the values of the exported state variables and is able to change the device configuration by invoking the corresponding actions.
The Mobile Device Manager provides a generic representation of OMA DM enabled devices as control units by implementing Control Unit Providers responsible for the following features:
Communication with devices over the OMA DM protocol - The system uses RM's implementation of the server-side part of the OMA DM Protocol (including SyncML Representation Protocol) and several network transport bindings.
Representing OMA DM enabled devices as hierarchical sets of control unit objects - This imposes the need of creating a flexible way for mapping between the data models supported by OMA DM and by RM – DMT and control unit models, respectively. Such a mapping mechanism is achieved by means of control unit to DMT Mapping (CU-DMTM) files - you can define such a file by using a dedicated XML format for describing the DMT structure of a particular class of devices or their specific management objects as a set of control units.
Mobile Device Types
As the other device classes supported by RM, OMA DM devices are also identified by their type and unique ID. The unique ID usually corresponds to the IMEI of the device and is provided by the device during the initialization of the OMA DM management session. The ID is retrieved from the DevInfo management object (./DevInfo/DevId).
The RM assigns type mprm.generic.oma-dm.device (Generic Mobile Device) to each device, which is not recognized as a more concrete custom or built-in RM mobile type (such as Mobile OSGi Device).
Basic Mobile Device Properties
For an OMA DM device, in general RM provides the information from the ./DevInfo standard management object as well as properties related to HTTP communication with the device (user agent, last session, etc). You can explicitly register or remove a device, and synchronize its state onto the backend.
Specifically, for the device DMT, RM delivers basic node and leaf information following the semantics of the OMA DM standard. Additionally, RM offers representation for the ./DevInfo, ./DevDetail and ./DMAcc management objects.
Standard OMA DM Objects
There are some differences in the structure of the OMA DM standard objects between version 1.1. and version 1.2 of the OMA DM protocol. RM automatically handles the differences and provides adequate representation of the standard management objects.
Accessing Device DMT Structure
Most conveniently, the DMT of a device can be accessed by using the Generic DMT Browser, which represents the DMT as a collection of component control units so that the DMT becomes available in the RM device management tree. For more information about using the Generic DMT Browser in the Management Console, refer to User's Guide. You can also use the RM DMT API to explore the structure and content of DMTs - see Managing a Device's DMT.
Extending Mobile Device Management Schema
Custom Defined Device Types
The type of the device is determined by a set of rules defined in OMD DM device definition files in XML format. Basically, these files contain conditions which a device's DMT should satisfy in order to be classified as of a particular OMA DM device type. For more information about the semantics of the device definition files, refer to Developer's Guide.
DMT to Control Unit Mapping
Representation and manipulation of the devices and their manageable resources in RM is achieved through the control unit abstraction as described in the Goals of the Control Unit Abstraction from Generic Device Management documentation. In order to be manageable by the RM, a device has to be represented as a set of control unit objects, which can be organized in a hierarchical structure.
The RM is able to obtain current device configuration by inspecting the control unit structure and querying values of the state variable supported by the device control units and to change the configuration of the device by invoking the corresponding control unit actions.
You can extend RM device management with any OMA DM devices types by following the control unit model. As previously mentioned, to simplify the way of representing an OMA DM device as a set of control units, RM Mobile DM package introduces special mapping files - CU-DMTM XML files.
For more information about the semantics of the CU-DMT mapping mechanism, refer to Developer's Guide.
Download and Deployment Management
Regarding mobile devices, RM supports general maintenance and deployment of components through its Software Repository and OMA Download Server.
Deployment is achieved by means of download descriptors, published by Software Repository for a specific component. Both, descriptor and component (i.e. media object) are downloaded by the OMA DM device from RM's download server.
Download descriptors of components published in the Software Repository is available under the following URLs:
http://<ms_host>[:<http_port>]/syncml-dl/<unique_bundle_ID>, where
<ms_host> is the address of the management server (MS) connected to the device,
<http_port> is the MS port allocated for connection over HTTP (default is 80),
<unique_bundle_ID> is the unique component ID internally assigned by the repository.
Media objects (i.e. components) published in the Software Repository are available under the following URLs:
http://<ms_host>[:<http_port>]/syncml-dl/content/<unique_bundle_ID>
Besides its generic deployment capabilities, the Mobile Device Management Package also provides support for a concrete content type - MIDlet Suites. These are traditional MIDlet Suite JAR files, holding one or more conventional MIDlets which are compliant with the J2ME MIDP specification.