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 and the client. OMA DM is designed to support and utilize any number of data transports such as:
physically over both wireline and wireless media
transport layers implemented over any of WSP, 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. 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.
