OMA DM Q&A

OMA DM Q&A

The following document was created by the OMA DM working group to supplement industry knowledge of the Open Mobile Alliance Device Management Enabler (OMA DM).   This document is publicly available.

Q: What is Device Management:

A: Device Management is the generic term used for technology that allows Management Authorities to carry out the difficult procedures of configuring mobile devices on behalf of the end user (customer). Management Authorities would typically be wireless operators, service providers or corporate information management departments. Through Device Management, a Management Authority can remotely set parameters, conduct troubleshooting servicing of terminals, install or upgrade software, perform monitoring and diagnostics. In broad terms, device management consists of three parts:

  • Protocol and mechanism: The protocol used between the Device Management Server and the Device Management Client onboard a device
  • Data model: The data made available for remote manipulation, for example APN and mail settings
  • Policy: The policy decides who can manipulate a particular parameter, or update a particular object in the device

See also OMA Dictionary, http://www.openmobilealliance.org/

Q: What is OMA DM?

A: The OMA Device Management (OMA DM) Enabler is a set of specifications designed for the management of mobile devices such as mobile phones, PDAs, tablet computers and, more recently, M2M devices. The OMA DM Enabler is intended to support multiple uses including Provisioning, Device Configuration, Software Upgrades and Fault Management.

OMA DM is a specification suite of OMA Enablers. It consists of core protocols and application data models.

OMA DM Version 1.2 Enabler defines interfaces (= a core protocol and data model skeleton) between a DM Client and a DM Server. The protocol is designed as a representation of SyncML, which is robust over band-constrained, packet-lossy wireless networks. A series of Management Object (ConnMO, SCOMO, …) works on top of DM 1.2 to provide a standard interface for a specific DM application (Connectivity Management, Software Component Management, …).

The architecture of the Device Management enabler anticipates the needs of the market actors to differentiate their products through vendor-specific extensions while providing a core parameter set that can be relied upon in all terminals exposing this standardized interface.

OMA DM Version 1.3 reused the architecture from OMA DM Version 1.2. It does introduce new notifications, transport protocols and a new DM Server to DM Server interface for delegation.

OMA DM Version 2.0 reuses the Management Objects, which are designed for DM Version 1.3 or earlier DM Protocols. OMA DM Version 2.0 introduces new Client-Server DM protocol. OMA DM Version 2.0 also introduces new user interaction method on Device Management using Web Browser Component.

Q: Is OMA DM widely deployed?

A: Yes, it is currently estimated that globally, OMA DM based device management solutions are currently deployed in nearly 3 billion mobile devices.

Q: Where can the latest versions of OMA DM be found?

A: All OMA Enablers are publically available on the OMA website at: http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases

Q: Where can I find more information about the OMA DM Working Group?

A: Information on the Device Management Working Group can be found on the OMA website at: http://openmobilealliance.org/about-oma/work-program/device-management/

Q: What is the process by which the OMA DM Enabler is defined?

A: OMA DM, like all OMA technical work, is member driven. The OMA member companies bring requirements to the OMA Working Groups to be discussed and possibly included in the OMA Enabler Releases.

Please see the OMA Work Program and Release Planning Process to learn more about the OMA process.

Q: Can new features to OMA DM be proposed?

A: Yes, any OMA member company can propose new features or updates to OMA Enablers.

Q: Can other organizations propose changes or features to OMA Enablers?

A: Yes, OMA has active liaison relationships with GSMA, 3GPP, Small Cell Forum, oneM2M and many other organizations. Through the liaison process, OMA often accepts new requirements in the form of Work Items. However, only OMA Sponsor, Full and Associate members have voting rights where Enablers are concerned.

Q: What security features are included in OMA DM?

A: For authentication, OMA DM provides its own (application-level) mechanism as well as transport-layer authentication. For confidentiality and integrity, it depends on transport layer mechanisms, e.g. SSL/TLS in HTTP binding.

OMA DM does include security requirements including:

  • Credentials
  • Initial Provisioning of Credentials
  • Authentication
  • Integrity
  • Confidentiality
  • Notification of initiated session
  • Bootstrap

 

Q: How does the OMA DM Enabler allow for vendor differentiation?

A: The architecture of the Device Management enabler anticipates the needs of the market actors to differentiate their products through vendor-specific extensions while providing a core parameter set that can be relied upon in all terminals exposing this standardized interface.

The design of the architecture follows the OMA architecture principle [ARCH-PRINC] of Network Technology Independence by separating the bearer-neutral requirements from bearer-specific bindings. The described architecture also anticipates additional bearer and proxy types, as any are identified, without requiring a re-specification of previously released documents. This preserves vendor and customer investment while supporting the scaling required by future innovations.

Q: What is the performance comparison between DM 1.x and DM 2.0?

A:  The following table shows a comparison in performance between OMA DM 1.X and DM 2.0 based on some experimental test (source http://openmobilealliance.org/about-oma/work-program/device-management/)

Q: What are the technical advances from DM 1,X to DM 2.0?

A: DM 2.0 is backward compatible with Management Objects defined on top of DM 1.X, but introduces a significant improvement in terms of complexity, interoperability and cost efficiency to meet the expected market needs. This is achieved by an innovative new protocol, which adopts a number of technologies borrowed from Web Environment (HTTP RESTful methods, JSON serialization and Web Browser Components, for example) plus a simplification in DM Tree access and organization and DM Session transactions.

Q: What are the main differences between DM 2.0 and LWM2M?

A: DM 2.0 is a RESTful http-based protocol which re-uses the existing OMA DM data model (Management Objects). DM 2.0 is primarily aimed at cellular smart phones, however, could also be used for M2M-devices.

LWM2M is a RESTful IETF CoAP-based protocol with a new data model consisting of simple LWM2M Objects. LWM2M is primarily aimed at resource constrained M2M devices.

Q: Why can a single protocol not replace the OMA DM protocol today? Can we list key abilities / feature set of the OMA DM protocol?

A: OMA DM is supported across 3+ billion devices. The support for OMA DM is proliferating into surrounding devices such as connected vehicles, cellular hotspots, laptops with WWAN etc., OMA DM is utilized for multiple purposes including firmware upgrades, basic mobile network setup & basic IMS setup in the devices. A wide range of features defined in 3GPP like IMS, ANDSF, Communication Continuity, IMS service level tracing, SDoUE have defined management objects for to be used along with OMA DM. The OMA DM has also been adopted in other contexts such as Wi-Fi alliance HS2.0. OMA DM is also available in supporting diagnostics features today on VoLTE (OMA DiagVoLTE). Broad categories OMA DM covering today:

  • Configuration settings
  • Operating parameters
  • Software installation and parameters
  • Software and firmware Updates
  • Application settings and interfaces
  • User preferences
  • Service metrics

Because of the wide spread availability and deployment of Management Objects already defined across multiple SDOs using OMA DM protocol, it would be difficult to replace OMA DM protocol in its entirety.

Q: Why should other organization adopt OMA DM instead of specifying proprietary solution?

A: Introducing proprietary solutions creates interoperability issues, which are clearly address by OMA DM.

Other organizations should adopt OMA DM because:

  1. It is a widely deployed standard across many devices
  2. It is managed by Mobile Operators through Device Management Servers
  3. It has proven interoperability among different servers and devices vendors
  4. It has been adopted by other SDOs such as 3GPP, oneM2M, Wi-Fi Alliance, GSMA and so on.

Q: Are OMA DM 1.x-based enablers (e.g. FUMO, SCOMO, DiagMon) compatible with DM 2.0?

A: Yes, OMA DM 2.0 has been design in order to guarantee the backward compatibility of Management Object specified for OMA DM 1.X: in other words, every OMA DM 1.X compliant Management Object can be reused with OMA DM 2.0

Q: What is the recommended migration path from DM 1.x to DM 2.0?

A: DM 1.x and DM 2.0 support compatible Management Objects, there is no direct migration path from DM 1.x to DM 2.0 protocol. Any recommendation from OMA in this aspect is out of scope of the specifications, however specific migration procedures are welcome to be implemented.

Q: Which type of devices that can be managed with OMA DM?

A: OMA DM can manage multi-mode devices on any network, including devices that do not have a SIM card: mobile devices, mobile terminals, connected vehicles, gateways, medical equipment etc.,

Q: Can a downloaded client into a device be provisioned via OMA DM if it has no access to the device credentials (IMSI, IMEI, MSISDN)?

A: Yes, a device can be provisioned with OMA DM even if it has no access to the device details and information like IMSI, IMEI and MSISDN

Q: Which type of transport can be used to manage a device with OMA DM? E.g. can OMA DM be used over Wi-Fi?

A: OMA DM is transport agnostic. OMA DM supports and utilizes 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