*Android OMA-DM Standardization*
*OVERVIEW*
As per the current architecture of the Android Component of the WSO2 MDM
framework, Android mobile devices are managed using a custom built client
application installed on the device. Server to Client communication is done
over HTTP and the devices are provisioned periodically through a polling
mechanism. *OMA-DM* is a standard device management protocol which has been
adopted by several device manufacturers. This thread is a study on
standardization of the current Android MDM implementation using to use
OMA-DM Standards and Protocols.
*GOALS*
- Standardize current Android implementation using OMA-DM Specification.
*What is OMA-DM?*
- *Open Mobile Alliance* (OMA) is a non-profit organization.
- Delivers Open Specifications for creating interoperable services.
- The *Device Management (DM) Working Group (WG)* specifies protocols
and mechanisms to achieve the management of mobile devices, services access
and software on connected devices.
- Current stable version is *v1.3* [1].
*Why OMA-DM?*
- Managing devices with OMA DM version 1.2 allows two-way async
communication between the server and client.
- Ease of managing devices through *Management Objects*.
- Can easily manage converged and multi-mode devices on any network,
including devices that do not have a SIM card, as well as resource
constrained devices. This extensibility is one of the key benefits of OMA
DM, making it ideal for M2M communication scenarios.
*OMA-DM Device Management Technology*
- The OMA DM specifications [2] define the protocols and the mechanisms
allowing an OMA DM Server to deliver configuration parameters to an OMA DM
Client.
- This is done using a defined set of *“DM Commands”* for various
management scenarios.
- These are executed inside a well-defined and secure environment (the *“DM
Session”*).
- The *OMA DM Client* exposes the device internal data to the *OMA DM
Server* in the form of a hierarchic tree known as the *“DM Tree”*.
- A *Management Tree* is a mechanism by which the management client
interacts with the device, e.g. by storing and retrieving values from it
and by manipulating the properties of it, for example the access control
lists.
- It is made up of different building blocks (or sub-trees) called
*Management
Objects*.
- A *Management Object* is is a subtree of the Management Tree which is
intended to be a (possibly singleton) collection of *Nodes* which are
related in some way.
- Management Objects provide specific functionality in the management of
devices.
- The management of a device feature consists of the management of the
DM Tree, which virtualizes the device features and functionalities.
- The OMA DM Working Groups specified a number of Management Objects
implementing specific management functions.
- There are several Management Objects which have been specified to
support additional functionalities [3]:
- *Software Management *(OMA DM SCOMO) allowing not only the
installation and the removal of applications on the mobile, but also the
retrieval of the inventory of software components already
installed on the
device
- *Diagnostics and Monitoring *(OMA DM DiagMon MO), which enables
remote diagnostic, for example to query the device for memory and battery
status or to collect radio measures and QoS parameters, and remote
monitoring, by defining trap and reports
- *Connectivity* (OMA DM ConnMO), which allows the configuration of
bearers and proxies
- *Device Capabilities *(OMA DM DCMO), which allows a Management
Authority to remotely enable and disable device peripherals like cameras,
Bluetooth, USB, etc
- *Lock and Wipe *(OMA DM LAWMO), which allows to remotely lock
and/or wipe the device, for instance when the device is stolen
or sold, or
when personal or enterprise data are compromised
- *Browser* (OMA DM BMO), which allows remote management of browser
favorites and settings
- *Virtualization* (OMA DM VirMO), which enables remote management of
virtual machines running on the device (expected for 3Q 2013)
- *Management Policy *(OMA DM Management Policy MO), which allows the
deployment on the device of policies which the DM Client can execute and
enforce independently: if some events happen, then perform some
operations
(expected for 2Q 2014)
OMA DM WG also specified *Gateway* functionality (OMA DM GwMO v1.0), which
allows an OMA DM Server to manage devices that:
- are not directly accessible, for example, because they are deployed
behind a firewall
- can be clustered in a group, for instance when they are deployed in a
very large number (like sensors), using fan out mechanisms
- support other Management protocols than OMA DM
I will keep updating this mail thread as I move forward.
[1] -
http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/dm-v1-3
[2] -
http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases
[3] -
http://openmobilealliance.org/about-oma/work-program/device-management/
--
Dileesha Rajapakse
*Intern - Engineering*
Mobile : +94 (0) 772 555 933
Tel : +94 112 741 505
[email protected]
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
