![](https://csdnimg.cn/release/download_crawler_static/8256391/bg5.jpg)
OMA DM-BASED REMOTE SOFTWARE FAULT MANAGEMENT 495
Copyright © 2009 John Wiley & Sons, Ltd. Int. J. Network Mgmt 2009; 19: 491–511
DOI: 10.1002/nem
referred to as a notifi cation, or an alert message. Once communication is established between the server
and client, a sequence of messages might be exchanged to complete a given device management task
using several OMA DM commands as follows [29]:
• Add (adding an MO or MO content) – Server creates a new node and returns error if there is an exist-
ing node; is not allowed to create a node at the Add target URI, or if the specifi ed URI cannot be
resolved.
• Alert (management session start) – This conveys notifi cations, such as device management session
requests, to the client.
• Atomic (processing commands atomically) – Set of commands inside Atomic must be processed in the
same way as commands inside Sequence, with all subordinate commands to be executed as a set or
not at all.
• Copy (copy MO content) – This command treats the data of the copy and the data of the original
independently after the copy is complete.
• Delete (removing MO(s)) – One or more MOs are removed from a management tree.
• Exec (executing a process) – New process is invoked and returns a status code or result.
• Get (reading MO content or an MO list) – Server retrieves the content from the DM Client or the list
of MOs residing in a management tree.
• Replace (updating MO content) – Existing content of an MO is replaced with new content.
• Results (return MO or MO contents) – Client returns the MO or MO contents requested by the
server.
• Sequence (processing commands sequentially) – One or more of Add, Replace, Delete, Copy, Get, Exec
or Alert element types must be specifi ed, and these element types must be processed in the specifi ed
sequence.
• Status (return the status of processing) – Client and the server return the status code after processing
requested commands.
The server sends all commands except Status to the client. Status command is sent by both of them. We
can design the data collection process for a mobile device by using a combination of these commands.
OMA DM WG has introduced device diagnostics and monitoring functionality to remotely solve some
problems of mobile devices using the OMA DiagMon [39]. The overall goal of OMA DM DiagMon is to
enable management authorities to proactively detect and repair problems even before they impact on
users, or to determine actual or potential problems with a device as necessary. The management author-
ity is an entity that has the rights to perform a specifi c DM function on a device, or manipulate a given
data element or parameter. For example, the management authority can be the network operator, handset
manufacturer, enterprise, or device owner. OMA DM DiagMon includes the following management
areas: diagnostics policy management, fault reporting, performance monitoring, device interrogation,
remote diagnostics procedure invocation and remote device repairing [40]. OMA DM WG publishes the
standard documents in the following sequence: Work Item Document (WID), Requirement Document
(RD), Architecture Document (AD), Technical Specifi cation (TS), and Enablers Package (EP). The OMA
DM DiagMon WG is currently working on TS. This only defi nes MOs for common cases of diagnostics
and monitoring. We have now expanded MOs, however, to perform remote software debugging based
on MOs defi ned by the OMA DM DiagMon WG. This paper therefore contributes a useful case study to
demonstrate this capability.
3. RELATED WORK
In this section, we describe some previous research related to device management and general software
debugging methods for mobile platforms.
Currently, several management frameworks for device management have been proposed.
Simple Network Management Protocol (SNMP) [30,31] is the most widely used method for network