OMA Device Management

OMA DM specification is designed for management of mobile devices such as mobile phones, PDAs, and tablet computers.[5] Device management is intended to support the following uses:

• Provisioning – Configuration of the device (including first time use), enabling and disabling features
• Device Configuration – Allow changes to settings and parameters of the device
• Software Upgrades – Provide for new software and/or bug fixes to be loaded on the device, including applications and system software
• Fault Management – Report errors from the device, query about status of device

All of the above functions are supported by the OMA DM specification, and a device may optionally implement all or a subset of these features. Since OMA DM specification is aimed at mobile devices, it is designed with sensitivity to the following:

• small footprint devices, where memory and storage space may be limited
• constraint on bandwidth of communication, such as in wireless connectivity
• tight security, as the devices are vulnerable to software attacks; authentication and challenges are made part of the specifications

OMA DM was originally developed by The SyncML Initiative Ltd, an industry consortium formed by many mobile device manufacturers. The SyncML Initiative got consolidated into the OMA umbrella as the scope and use of the specification was expanded to include many more devices and support global operation.

Technically, the OMA DM protocol uses XML for data exchange, more specifically the sub-set defined by SyncML. The device management takes place by communication between a server (which is managing the device) and the client (the device being managed). OMA DM is designed to support and utilize any number of data transports such as:

• physically over both wireline (USB, RS-232) and wireless media (GSM, CDMA, IrDA, or Bluetooth)
• transport layers implemented over any of WSP (WAP), HTTP, or OBEX or similar transports

The communication protocol is a request-response protocol. Authentication and challenge of authentication are built-in to ensure the server and client are communicating only after proper validation. The server and client are both stateful, meaning a specific sequence of messages are to be exchanged only after authentication is completed to perform any task.

The communication is initiated by the OMA DM server, asynchronously, using any of the methods available such as a WAP Push or SMS. The initial message from server to client is said to be in the form of a notification, or alert message.

Once the communication is established between the server and client, a sequence of messages might be exchanged to complete a given device management task. OMA DM does provide for alerts, which are messages that can occur out of sequence, and can be initiated by either server or client. Such alerts are used to handle errors, abnormal terminations etc.

Several parameters relating to the communication such as the maximum message size can be negotiated between the server and client during the initiation of a session. In order to transfer large objects, the protocol does allow for sending them in smaller chunks.

Error recovery based on timeouts are not specified completely, hence, different implementations could possibly differ (protocol is not fully specified relating to these, and seem to leave them open intentionally).

The protocol specifies exchange of Packages during a session, each package consisting of several messages, and each message in turn consisting of one or more commands. The server initiates the commands and the client is expected to execute the commands and return the result via a reply message.

• JSR 233: J2EE Mobile Device Management and Monitoring Specification
• OMA Device Management Working Group
• Open Mobile Alliance - Device Management Overview
• Open Source OMA-DM simulator - Eclipse Koneki project