You often need to evolve devices to another stage so they can function either correctly or better. For example, say a device resets accidentally and the user has no idea how to reconfigure it. If your device management server contains the required information and can reset the device for the user, it saves both time and cost. Another example is when a user needs a device firmware update. He may not have sufficient equipment and knowledge to perform the update actions, but he also doesn't want to take his device to a maintenance center. By having a device initiate its own management session, servers can perform the procedure for the user. In the end, device management aims to achieve these important function requirements:
- Bootstrap provisioning, remote maintenance, and reporting of configuration data to a device
- Device diagnostics and fault management
- Application and non-application software installation, update, and management
Despite the fact that thousands of different devices are designed to fulfill these needs, this ideal is difficult to achieve. While individuals have plenty of device options, device management is still a big challenge. Device management is originally based on several proprietary protocols, each of which serves a small set of devices. This complicates the tasks of users, wireless operators, service providers, and corporate information management departments who have to purchase, learn, and manage several device management systems for different types of proprietary device management protocols. Therefore, instead of performing tasks through sets of systems running various kinds of protocols, there needs to be a common interface that allows device management authorities to complete all the tasks remotely.
This is exactly why OMA Device Management exists.
The Open Mobile Alliance (OMA) was formed in June 2002 by nearly 200 companies that play important roles in the mobile industry's value chain. The alliance focuses on developing interoperable mobile service enablers, and becomes the focal point in device management by consolidating several organizations into OMA, including SyncML Initiatives and WAP Forum. SyncML DM, which was one of SyncML's main specifications, has evolved into OMA DM. OMA's Device Management Working Group is in charge of the revision and publication of OMA Device Management.
OMA DM has the approved enabler, version 1.1.2, and is currently working on the candidate enabler, version 1.2. OMA DM 1.2 contains the Enabler Release Definition for OMA DM, along with eight technical specifications and two supporting files. Enabler Release Definition mainly defines the scope of OMA DM, and the server and client requirements to conform to OMA DM. Technical specifications consist of three parts: data models, protocol and mechanism, and policy. In the following section, we discuss in detail data models, protocols, and mechanisms intermixing with version 1.2 policy concepts.
Each device that supports OMA DM contains a management tree. The management tree (see Figure 1) contains and organizes all the available management objects so that you can access every node directly through a unique URI. For example, to access the "xyzInc" node, the correct URI is ./DMAcc/xyzInc.
Figure 1. Example management tree (Source: OMA DM Tree and Description)
Nodes are entities that you can manipulate through the OMA DM protocol. An interior node can have an unlimited number of child nodes, while a leaf node must contain a value, including null. Each node has a set of run-time properties associated with it. All properties are only valid for the associated node, except the Access Control List (ACL). A node's ACL represents which server can manipulate that node. The manipulation includes adding a child node, getting the node's properties, replacing this node, or deleting this node. Table 1 lists other run-time properties.
Table 1. Run-time property list
| Property | Applicable commands | Comments |
|---|---|---|
| ACL | Get, Replace | Get and Replace are the only valid commands for ACL manipulation. Note that Replace always replaces the complete ACL. |
| Format | Get | Automatically updated by Add and Replace commands on the associated node. |
| Name | Get, Replace | Replace is equivalent to renaming the node. |
| Size | Get | Automatically updated by the device |
| Title | Get, Replace | Only updated by server actions or software version changes. |
| TStamp | Get | Automatically updated by Add and Replace commands on the associated leaf node. |
| VerNo | Get | Automatically updated by the device. |
However, it would be insufficient for servers and clients to perform device management tasks if no common objects exist in OMA DM conformance devices. Therefore, OMA DM requires clients and servers to implement three mandatory management objects and one optional object for clients and servers (see Table 2). These objects are defined in the device description framework (DDF). The DDF provides servers with necessary information in order to manage client devices. Device manufacturers can publish their description of their devices so that organizations operating device management servers can update the new description into those servers. The servers can then utilize the new description and manage new functions of their devices, or even manage new devices. Physically, you can use XML and WBXML to transfer management information back and forth. Thus, OMA DM also provides a way to transform management trees to and from XML and WBXML files.
Table 2. Standardized management objects
| Management object | Description |
|---|---|
| DMAcc | Settings for the DM client in a managed device. |
| DevInfo | Device information for the OMA DM server. Sent from the client to the server in the beginning of every session. |
| DevDetail | General device information that benefits from standardization. |
| Inbox | Reserved URI where the device should use the management object identifier to identify the absolute URI. (Optional) |
OMA DM's protocol defines its device management usage based on SyncML Representation Protocol and SyncML Synchronization Protocol. This protocol includes packet elements that construct the device management messages, message transfer mechanism, and treatments that servers and clients should perform. Among all the packet elements, it is worthwhile to know command elements in more detail.
Table 3. Protocol command elements
| Command | Who sends the command | Description |
|---|---|---|
| Add | Server | Creates a node |
| Atomic | Server | Specify that the subordinate commands are processed as a set |
| Copy | Server | Duplicate or move the data on the client |
| Delete | Server | Delete a node and its entire subtree, if the permission is right |
| Exec | Server | Execute the value of the target node |
| Get | Server | Return value of the target node |
| Replace | Server | Overwrite a value of an existing node |
| Sequence | Server | Specify the order of processing a set of commands |
| Alert | Client | Convey notification |
| Results | Client | Specify the command for this response and return the result |
Table 3 lists all the commands that OMA DM supports. The commands are executed according to what the ACL and the target node's accessType specify. Meanwhile, a corresponding status code is associated with every command to facilitate the other party to figure out the processing results.
To perform a complete device management task, servers and clients go through two phases: the setup phase and the management phase (see Figure 2). During the setup phase, servers and clients authenticate each other and exchange device information. Packet 0 is an option for servers to notify clients to initiate the management session. After the client successfully sends the authentication and its device information (packet 1), the server sends its credential and information, along with the management operations or user interaction commands to the client (packet 2).
Then begins the management phase, which could have several iterations until the management task is completed. During this phase, the client sends its response to the server. The response only allows the Replace command containing DevInfo, the Results command, and the Alerts command to be sent to the server. The server can then send out another operation to the client.
Figure 2. Phases of Device Management Protocol (Source: OMA Device Management Protocol)
As for mechanisms, OMA DM specifies bootstrap and notification initiated session. Bootstrap is a process that provisions a device from a clean state to a state that can initiate device management sessions. You can further bootstrap a bootstrapped client to initiate a session to a new device management server. You can bootstrap the client through the server-initiated process, from smart cards, or even through customized bootstraps, which may perform during the device manufacturing time. Meanwhile, two profiles are specified in the bootstrap mechanism. The first one is the OMA Client Provisioning Profile. This profile's message content is based on the OMA Client Provisioning Content Specification; it provides a way to map client-provisioning information to the device management tree. The second profile is OMA Device Management Profile, which uses the standard device management information encoded into WBXML.
The second mechanism actually specifies the details of packet 0 in the Device Management Protocol's setup phase. Normally, clients do not have the resources or are not willing to consistently listen to servers' notification because of security reasons. Therefore, this mechanism provides a way for servers to notify clients to initiate a management session. Occasions might include when device management administrators trigger requests on servers to perform device management tasks through the user interface, or faults are generated that require clients to go online.
As always, security is a concern in device management. Servers and clients should use TLS 1.0 or SSL 3.0 as their protocols. HMAC-MD5 ensures integrity of device management messages. In addition, you should send credentials of servers and clients for authentication.
Mapping technical concepts to specifications
Because many specifications are contained in OMA DM, which can be confusing, we'll briefly introduce each specification by mapping it back to the concept and terminologies mentioned earlier.
DM Tree and Description, DM Standardized Objects, and DM Tree and Description Serialization define the data model part:
- DM Tree and Description define the formation of the management tree, including nodes, properties, and DDF.
- DM Standardized Objects define DM Account, DevInfo, DevDetail, and inbox management objects.
- To facilitate the exchange of management tree values, DM Tree and Description Serialization defines the way to convert a run-time management tree or subtree into an XML or WBXML structure.
As for protocol, DM Protocol and DM Representation Protocol play the main roles. As we mentioned in the previous section, SyncML Representation Protocol and SyncML Synchronization Protocol is the base. On top of this, DM Representation Protocol defines the usage of the markup language in device management. In addition, DM Protocol defines protocol packages shown in Figure 2, accompanying other necessary points for setting up a management session.
Two mechanisms are also defined to complete OMA DM: DM Bootstrap and DM Notification Initiated Session. Bootstrap, or client provisioning, is the first step for preparing a managed device. DM Notification Initiated Session, on the other hand, allows management servers to notify the client to initiate a session back.
Finally, DM Security, along with some DM tree properties, constitutes the specification's policy part. Besides the principles of confidentiality, integrity, authentication, and so on, ACL is one example of policies that control whether you can manipulate the node.
OMA DM devices with WebSphere Everyplace Device Manager
WebSphere Everyplace Device Manager (Device Manager) provides a flexible solution for managing various mobile devices. In V6.0, it supports Palm, Symbian, Windows® Mobile 2003, Windows PocketPC, OSGi, and of course, OMA DM 1.1.2 and 1.2 devices. In this section, we will use Device Manager's functions for managing OMA DM devices as an example of putting theory into practice.
Table 4. Jobs and tasks Device Manager supports for OMA DM devices
| Jobs |
|---|
| Bootstrap |
| Command Script |
| Custom Command |
| Device Configuration |
| Inventory Collection |
| Node Discovery |
| Notification |
| OMA Client Provisioning |
| OMA DM Firmware Update |
| Text SMS |
Device Manager uses the word "job" to describe any specialized processing, performed on a device or group of devices, through device manager user interfaces or its APIs. Table 4 lists all supported jobs.
Although in theory the first step is bootstrapping, in the world of Device Manager, everything starts from enrollment. An administrator could pre-enroll a device, and determine whether he or she will use a bootstrap job to initially provision the client device; or if the device and server do not use any OMA DM security, the client can automatically enroll when the device first connects to the server. After enrolling, the server will have an entry containing the device type, name/serial number, the device username and password. Then, the inventory collection job is performed by default.
The inventory collection job uses the Get command to return the value of the designated standard objects (discussed in the data model section) and stores them in the device management database as "inventory." Succeeding jobs like the device configuration job, besides being able to set the initial configuration of newly enrolled devices, changes the inventory data if needed. Meanwhile, if administrators need a value besides standard objects, they can supply the designated node's URI and use the node discovery job to walk through the specified node's subtree and return the value.
For bootstrapping, you can choose either the bootstrap job or OMA client provisioning based on the client-supported profile. With the former, you can use DM 1.1.2 Plain Profile and DM 1.2 Profile. The bootstrap job also supports the WAP Profile, which uses OMA Client Provisioning 1.1. For the latter, you must build an OMA Client Provisioning XML file before using the job. However, no matter which profile you choose, the server must send out a notification so the client will initiate the session back. The notification job can achieve this. In addition, the text SMS job can send notification from the server to the client.
Administrators can create both the custom command job and command script job to perform operations on devices or return device information using OMA DM's server-to-client commands. The difference between the custom command job and the command script job is all about scripts. While administrators can specify the custom command job using the device management console or Administration API, administrators can also build a command script and create a command script job by specifying the script location if the custom command job is not flexible enough. When the job runs, the command script is parsed and interpreted to build the list of BaseOMA DM commands to be sent to the device.
There is only one job left that we did not mention: OMA DM firmware update . Ideally, updating firmware happens remotely; however, OMA DM never specifically defines how to do this. A new specification, Firmware Update Management Object (FUMO), does instead. FUMO takes the advantages of OMA DM by using its predefined command to fulfill the lack of an interoperable firmware update solution for mobile devices. Device Manager, therefore, follows FUMO V1.0 to implement this firmware update job. For more information on firmware updates, see Resources for FUMO.
OMA DM is an interoperable device management specification. By conforming to OMA DM, users, wireless operators, service providers, and corporate information management departments can eliminate the complication of various proprietary protocols. Also, OMA DM is one building block to conforming to OMA SyncML Common 1.2. In this article, we have illustrated the motivation behind OMA DM, its background, technical concepts, as well as details of each specification. Hopefully, through industry endeavors, we can have a better device management experience in the future.
- OMA: OMA is the leading industry forum for developing market-driven, interoperable mobile service enablers.
- OMA DM v1.2 Candidate Enabler: After reading this article, visit the OMA DM v1.2 Candidate Enabler site for more details.
- OMA SyncML Common Specification: To know more about the base of an OMA DM protocol, find the SyncML Representation Protocol at this site.
- OMA Client Provisioning: This is a specification defining client provisioning in general usage. OMA DM supports this in the bootstrap specification as one provisioning profile.
- Firmware Update Management Object V1.0 Candidate Enabler: Interested in the interoperable firmware update specification? Take a look at this Web site.
- WebSphere Everyplace Device Manager: This is the official Web site containing a brief introduction to Device Manager.
- WebSphere Everyplace Device Manager 6.0 Information Center: Learn more about the technical side of Device Manager from this site.
Stephanie Lin has been a developer with the IBM China Software Development Lab in Taipei since 2005, and currently is a project member of the WebSphere Everyplace Subscription Manager team. Her interests are server-side technologies and solutions in the telecommunications industry. Contact Stephanie at phlin@tw.ibm.com.
Steven Jiang is a Project Manager on the PvC Enterprise/SPO development team at the IBM China Software Development Lab. His current project is the WebSphere Everyplace Subscription Manager (WESM), with a focus on service engagement and product solution architecture.
Hicks Lin is a developer with the IBM China Software Development Lab in Taipei where he is a technical leader for WebSphere Everyplace Subscription Manager. He is interested in J2EE and other server-side technologies.
Jeffrey Liu received a Masters degree from National Taiwan University, Information Management department, and joined the IBM China Software Development Lab in 2005. He is a member of WebSphere Everyplace Subscription Manager product development team and currently focuses on the development of WESM Radius server.
