What is Mobile Device Management?

Mobile Device Management (MDM) provides the ability to improve mobile device functionality by updating firmware, changing configurations and managing software over the air (OTA). It may also provide the ability to retrieve information from a device for troubleshooting or later reporting and trend analysis. MDM optimizes mobile device functionality, ensures better interoperation with the operators network and decreases time to market while reducing operating expenses and increasing customer satisfaction.

For Network Operatorsr:

Mobile Device Management saves money by making mobile devices easier to manage. Operational costs are reduced by remotely updating and troubleshooting devices. Customer care representatives can solve problems faster and more efficiently. The costs of returns, recalls and configuration changes are all significantly reduced. Learn more about Customer Care and Mobile Device Management.

For Device Manufacturers:

Mobile Device Management improves time to market and reduces costs. Modern mobile devices have more complex functionality impacting both test times and return rates. MDM allows device manufacturers to meet market timing requirements without compromising functionality and testing. Once devices are launched, MDM can be used to improve device functionality and perform remote trouble-shooting thereby reducing return rates. Learn more about Mobile Device Management for Device Makers.

For Enterprises:

Mobile Device Management gives IT administrators the ability to manage mobile devices in the enterprise, similar to the way laptops are managed. IT can ensure employees have the right applications, that their devices are secure and working as expected. And from an administrator perspective, using an operator-hosted mobile device management system provides all the benefits, without the cost of maintaining a DM server in house. Learn more about Mobile Device Management for Enterprises.

For Subscribers:

Mobile Device Management enhances the subscriber quality of experience across the board. Subscribers avoid the inconvenience of recalls or the need to return to the point of sale to reflash a handset to fix bugs. New services and applications are more likely to work, but if they don't calls to customer care are shorter, more effective and require less active participation from the subscriber. Updated handsets provide enhanced functionality.

How does Mobile Device Management work?

A typical mobile device management solution requires two components: a server, and a client. The server is the mastermind of the system, sending management commands to mobile devices such as mobile phones and laptop wireless data cards. The server is typically deployed and maintained by the network operator who uses it to update, configure and trouble-shoot devices. The client runs on the handset; it receives, and implements the management commands from the server.

A standards-based approach to device management ensures maximum interoperability between servers and clients from multiple vendors. However, for additional functionality it is recommended that the client and server be sourced from the same vendor.

Mobile Network Operators install a server in their network, and ensuring mobile phones are deployed with a device management client. Updates, configuration changes and corrections can be made by operator staff and can optionally be made available to end-users through a web-based interface.

Mobile Network operators may also provide hosted device management to IT administrators who wish to manage mobile devices in the enterprise. This provides IT administrators with the same control as the network operators, without the need to maintain a separate DM server.

A MDM solution may also be offered on a smaller scale as part of an enterprise IT infrastructure, separate from that of a mobile operator. While this does provide greater control over the system, it requires additional IT resources in order to implement, administer and manage.

Updates can be initiated from either the server or the device.

If a server initiates the update (to change firmware, configuration or any other action), the following series of actions are performed.

• The server contacts the client device using a unique identifier, i.e. a mobile phone number.
• Once the device is contacted, the end-user may be asked to accept or reject the request.
• If the user rejects, the update process is terminated. If desired, the network operator can re-send the update request at a later date and time.
• If the user accepts, a trusted connection between the client and the server is established. (This is over a data connection)
• Through this trusted connection, the client executes the requested actions. Possible actions could include:
  • Firmware update of the device. Benefit: Newly purchased devices, as well as deployed devices can be remotely updated Over-The-Air to the latest firmware level.
  • Configuration change. Benefit: As network changes are being made, configuration settings can be modified without requiring users to take manual action.
  • Corrective action. Benefit: A customer who discovers a service is unavailable (i.e web browsing) can contact customer care representative who remotely views the device settings to see what is wrong and remotely correct them.
• Once the update action is completed, the device confirms the changes with the server.
• The device then returns to normal operation, without any further manual intervention. (Even for firmware updates, the device may automatically reboot itself before returning to normal operation)

If a device initiates the update (to change firmware, configuration or anything other action), the same steps 4 through 7 occur.

Who determines Mobile Device Management standards?

Mobile Device Management standards are defined by the Open Mobile Alliance, which has a specialized working group focused on Device Management (OMA-DM). This group specifies the protocols and mechanisms that achieve management of devices. As defined by the standards body, device management includes setting initial configuration information in devices, subsequent installation and updates of persistent information in devices, retrieval of management information from devices, and processing events and alarms generated by devices. Also defined by the standards body, managed information includes (but is not limited to): configuration settings, operating parameters, software installation and parameters, software and firmware updates, frameworks for management objects, application settings and user preferences.

InnoPath has been an active member of the OMA-DM working group since 2002; and has provided leadership in the areas of FUMO, SCOMO, DiagMON and LAWMO .

More information is available here: http://www.openmobilealliance.org/Technical/DM.aspx

 

There are two major aspects of Mobile Device Management, the method by which MDM is achieved and the specific objects which are managed by the MDM system.

The method by which MDM is achieved must be standards-based. Standards based device management ensures interoperability between device management servers and clients, independent of vendor. Furthermore, an OMA-DM implementation is superior to OMA-CP implementations because it provides the ability to verify changes made to a device.

Given that a standards based system is in place, it can be used to transfer a standardized set of information between the client and the server. These are defined as management objects, which are part of a management tree.

SyncML is a standard for synchronizing data between different devices. Such data includes contacts, to-do lists, and schedules. Devices might be phones, handhelds, PCs, or even services, such as web sites. SyncML provides an XML-based standard format for this data, such that all SyncML-compatible devices can understand. It can work over various types of connections, including Wireless Internet, Bluetooth, and infrared.

The SyncML standard started as a non-profit corporation formed by a group of companies who co-operated to produce an open standard for data synchronization and device management. In 2002, it SyncML was consolidated into the Open Mobile Alliance (OMA) in 2002, contributing their technical work to the OMA technical Working Groups: Device Management Working Group and Data Synchronization Working Group. Therefore, the OMA-DM inherited many works from SyncML. Today, the Data Synchronization Working Group continues the work originated in the former SyncML Initiative.

For more information, go here: http://www.openmobilealliance.org/Technical/DS.aspx

Yes, The InnoPath solution has been designed to be standard on both the client and server products. This approach is one factor in why InnoPath has so many different customers for both the iMDM client, and iMDM server. However, there are advantages in going beyond the standards for time-to-market requirements. Combining the best of standards-based and proprietary implementations, we call this Standards+, summarized here. In support of OMA-DM standards, InnoPath offers the Port to Production program which is designed to help network operators and device manufacturers deploy new devices faster and more efficiently with full testing and interoperability with different combinations of client and server vendor products.

Additionally, InnoPath has products such as the Server Simulator, which help network operators and handset makers test interoperability with a fully OMA-DM compliant server test bed optimized for automation and unusual test cases.

OMA-DM is the current standard for mobile device management. OMA-CP was the first device management protocol standardized by the Open Mobile Alliance (in 2005). OMA-CP is now being superseded by OMA-DM.

The key functional difference between OMA-DM (Open Mobile Alliance – Device Management) and OMA-CP (Open Mobile Alliance – Client Provisioning) is that OMA-CP is an open loop system. The server can send management commands to the client, but there is no feedback mechanism to ensure that the client has received and acted upon the commands. OMA-DM provides a closed loop system where the server can not only set a parameter, but can also request that the client verify that the operation was successful. InnoPath’s Device Pulse feature reads basic device parameters and configuration using OMA-DM. Click here to learn about InnoPath Configuration Verification.

What’s the difference between DM and DL?

DM is a protocol that defines different aspects of Device Management operation. It controls the actions and processes by which downloadable data from the DL Server is manipulated for the purposes of updating a device. Some device management operations are "Bootstrapping", "Configuration Settings", "Configuration Query", and etc.. According to OMA DM protocol standards, there are two protocol versions DM 1.1 and DM 1.1.2. There are two architectural entities in the DM protocol; they are DM Server (Device Management Server), and DM Client or DMA (Device Management Agent).

DL is a protocol that defines how content is downloaded from the download server (also called content server). There are two architectural entities that involved in this protocol, DL Server (Download Server), and DLA (Download Agent) which is implemented on the device. There are two kinds of download operations specified by the DL protocol. They are In-band and Out-of-Band. With In-band Download operation, the download server is the DM server itself and the download operation is in the same DM session (Device Management Session). In Out-of-Band operation, there is a separate content server; there are two sessions involved in this operation a DM Session and a DL Session. According to OMA DL protocol there are two versions of protocol specifications DL 1.0 and DL 2.0. DL functionality is separate from device management capability, in that it only refers to the ability to store and retrieve a specific data file, i.e content. The specific data file may be one of, but not necessarily limited to, a complete firmware update, a Diff file, an update package, one or more management objects, or client extension definitions, even a downloadable client such as InnoPath's OpenOS client.

InnoPath ’s products are standards based and support OMA-DM and OMA-CP. InnoPath is an active member of the OMA-DM working group, and thus ensures product developments are in alignment with standards decisions. Learn more about InnoPath and the OMA-DM working group.

A management object (MO) is the hook used by the server to manage a particular setting on a client. In other words, an MO is a logical element that can contain and manage configurable information within a device. Management Objects define what information is available, and how it is stored and retrieved.

A device management platform makes device management applications such as FOTA, DIAGMON, SCOMO work by providing the supporting layer between those applications and the wireless network transport protocol (SMS, WAP, HTTP etc).

Learn more about the InnoPath Device Management Server.

All the management objects for a device are organized by and accessible through a management tree. The “map” of the management tree is provided in a device description framework (DDF), an XML based representation of data which is supplied by the device manufacturer. The DDF describes the device in such a way that the management system can understand how to manage it. Management trees are typically unique to a particular device.

In the wider computer industry, bootstrapping, or booting, refers to the process of a simple program (BIOS) loading and executing a larger, more complex program, usually the Operating System, or OS. In common usage this is often shortened to “boot”.

In a mobile device management context, bootstrap is a process that provisions a device such that it can be managed by a device management server. This can be done in three ways, either at the factory before phones are shipped, Over-The-Air, or by inserting a smart card into the device.

What is an OMA Enabler?

An OMA Enabler is a management object designated for a particular purpose (ie. DM application). It is defined in a specification and is published by the Open Mobile Alliance as a set of requirements documents, architecture documents, technical specifications and test specifications. Examples of enablers would be: a download enabler, a browsing enabler, a messaging enabler, a location enabler, etc. If multiple specifications are required to support an enabler, the grouping of specifications is referred to as an enabler release. Examples of enabler releases are: FUMO, SCoMO, LAWMO and DIAGMON.

However, because an enabler is only a generic framework, a complete solution requires additional components. For example, InnoPath ’s firmware management solution leverages FUMO at its core, but adds a complete end to end management infrastructure that includes the Update Agent and Delta Manager. Learn more about the Update Agent and Delta Manager.

What are the most important OMA Enablers?

The most important OMA Enablers, at least for InnoPath and mobile device management, are FUMO, LAWMO, SCoMO and DIAGMON.

FUMO
FUMO stands for Firmware Update Management Object and allows mobile device firmware to be updated over the air. FUMO provides an interface between the client and server and enables mobile operators and device manufacturers to develop and deploy interoperable firmware update solutions. FUMO updates the device firmware and thus can be used to manipulate anything implemented in firmware including the device operating system, security, display and so on.

LAWMO
LAWMO stands for Lock And Wipe Management Object. It provides the ability to lock and unlock a device, wipe a device’s data and factory reset operations. Its purpose is to protect the device from un-authorized use should it ever be lost or stolen. It also provides the ability to ensure privacy of data on a lost or stolen device, by remotely deleting all data on the device and/or returning it to its factory settings. The LAWMO enabler defines a standard method for all operators and device manufacturers to implement lock and wipe. Learn more about Lock and Wipe.

SCoMO
SCoMO: This enabler stands for Software Component Management Object and it is designed to be a standardized solution for managing Software Components and its requirements. SCoMO provides the ability to Download, Install, Update, Remove, Activate and Deactivate software as well as query for an inventory of software on the device.

Whereas the idea of the FUMO enabler is to manage the firmware of the device, the Software Component Management Object is intended to manage software assets other than firmware. Examples include applications, executables, libraries, UI-elements, certificates, licenses etc.

DIAGMON
DIAGMON stands for Diagnostics and Monitoring. DIAGMON is designed to enable management authorities such as network operators to proactively detect and repair troubles even before the users are impacted. In order to achieve this, 6 key areas are addressed:

1. Diagnostics Policy Management: Setting and enforcing policies for diagnostics features and data.
2. Fault Reporting: Reporting faults to the network as trouble is detected at the device.
3. Performance Monitoring: Measuring, collecting and reporting key performance indicators (KPIs) data as seen by the device (may be on a periodic basis.)
4. Device Interrogation: Enabling the DM Server to query the device for additional diagnostics data in response to a fault
5. Remote Diagnostics Procedure Invocation: Enables a DM Server to run diagnostics procedures embedded in the device to perform maintenance and diagnostics.
6. Remote Device Repairing: Enables a DM Server to run repair procedures based on diagnostic test results. Learn more about Configuration Verification.

Glossary

Learn more about Mobile Device Management Standards:

The Critical Role of Interoperability Standards for Mobile Device Management