In the past ten years, mobile devices such as mobile phones have evolved considerably. The change has been more of a revolution than an evolution. The nature of mobile phones has strongly moved from voice-centric to data-centric. As a result, most new applications and services developed for new mobile phones utilize the data connection capabilities of these devices. In addition to this data-centric movement, mobile applications and services of new types are now more frequently introduced, and end-users are expected to exploit them.
As the nature of mobile devices changes and more new applications are constantly introduced, end-users contend with more feature-rich, complex devices in the mass market. These devices are unavoidably more challenging for users to use and manage, although device manufacturers are putting substantial effort into the design of the usability aspects. Increasing device complexity can lead to end-user frustration with these new features and applications. This in turn can hinder the adoption of these new applications and services.
The possibility that end-users may not adopt and cannot use new mobile applications has caused great concern among various parties, including service providers, operators, device manufacturers, enterprises, and software vendors. All of them see that there is a compelling need to create functionality to help the end-users get familiar with these new applications. DM is a necessary component toward that goal. This need for DM is analogous to what has happened with personal computers. PC end-users are nowadays mostly persons without a technical background. This has commonly led to external parties configuring or maintaining the computers on behalf of the end-users.
Wireless operators especially have a strong interest in DM. This is quite natural, as there are often millions of subscribers in their networks. In this kind of environment, wireless remote DM can substantially decrease the number of customer care calls and increase the usage of data services provided by an operator. Remote DM can be done very efficiently as mobile phones are wirelessly connected to a network infrastructure.
Remote DM over a wireless network (e.g., GPRS [General Packet Radio Service]) is not the only way to manage. DM can also take place over local connectivity mechanisms such as BluetoothTM or USBTM (Universal Serial Bus). Figure 9-1 depicts different usage environments for DM.
Figure 9-1. DM usage environments
High-level DM functions are very similar to the functions that exist in the traditional desktop system management domain:
Parameter configuration is intended to manage configurations and settings in devices. For instance, managed settings may enable an application to connect to a service in a network. The diagnostics function enables troubleshooting and performance monitoring of services. Software management is needed for software related operations, such as application installation or upgrade.
DM technology can be thought of as a functionality that offers services to other applications (e.g. provides them with configuration to be fully operational). Thus, DM cannot be regarded as a standalone application, but as a very important and vital enabler for mobile devices with a large set of mobile applications.
An important characteristic related to the nature of DM is the differentiation of the paying party. Some management operations, such as the update of a service configuration, are typically initiated and desired by the service provider and should not be billed to the end-user. Other operations are triggered by the end-users and should logically be charged to them. For instance, end-users may want to install new applications, for which they will then be billed.
Until the end of 2001, there were no standardized mobile DM technologies that could be used for all the functions listed above. Standards organizations such as the WAP Forum and CDG (CDMA Development Group) had developed specifications for specific usages but they were not generic enough. This has naturally led to the development of proprietary technologies introduced for specific DM functions. Nevertheless, with device management, a standard generic solution is the only acceptable alternative for the long term. Operators, service providers, and enterprises will not be able to efficiently manage very high numbers of devices in their domain if different types of devices and applications require separate management technologies. The SyncML Initiative recognized this deficiency and started to specify a standard, generic DM solution in 2001. As a result, the SyncML Initiative released version 1.1 of the SyncML DM Specification [SDM02] in February 2002.
The SyncML Initiative has specified the management functionality in the mobile domain, but similar work has earlier been carried out in the information technology (IT) domain. For network and desktop system management, organizations such as the IETF (Internet Engineering Task Force) and the DMTF (Desktop Management Task Force) have worked for years on IT systems management. For example, the IETF has released the SNMP (Simple Network Management Protocol) [RFC1157] for managing the diverse computing and communications elements of the modern, distributed environment. Also, the IETF has expanded the capabilities of the SNMP to cover additional MIBs (Management Information Bases). Gradually, this led to the use of the SNMP for the management of far more than just network elements. On the other hand, the DMTF has worked around the technology for building a new generation of managed PC systems and products. The SyncML Initiative has leveraged the work done by these organizations. It has been inspired by the above specifications, but adjusted them to the domain of wireless and embedded devices.
Benefits to Interest Groups
Device management is a very exciting technology that brings clear benefits to most of the parties associated with mobile devices and mobile services. These parties include the following:
The end-users group consists of the individuals who actually use wireless devices. They may be customers owning their devices or corporate employees using devices provided by enterprises. For end-users, DM itself should be invisible, although it provides direct benefits. For instance, the out-of-box experience can be improved dramatically if a device can be configured automatically on behalf of an end-user. Another good example is remote troubleshooting. With remote troubleshooting ability, an end-user does not need to come back to a retailer or a corporate IT person to fix a possible problem in a device or a service.
Wireless operators and enterprises commonly want to perform the maintenance for their devices. Enterprises do not usually have a large wireless infrastructure but they may own a large number of devices used in various networks. For operators, the situation is quite the opposite. They offer the wireless infrastructure for wireless devices owned by end-users, enterprises, and wireless operators themselves. Despite this difference, wireless operators and enterprises face the same challenge, maintaining all the devices. Naturally, the number of devices is typically lower in the enterprise domain than in the operator domain. Complex devices used in their domains should be used efficiently and smoothly, without problems. Thus, a DM solution to the forthcoming device challenges (complexity, remote diagnostics, error correction, etc.) needs to be available to reduce the costs associated with customer support.
Consumers of the operators and employees of the enterprises commonly use devices of different models and manufacturers. Having a cost-effective way to manage all these devices not only requires DM functionality, but also a DM standard. Having a DM standard such as SyncML DM will make it possible to provide one solution capable of managing the entire pool of devices, regardless of their origin and characteristics.
Service providers, including ISPs (Internet Service Providers), ASPs (Application Service Providers), wireless operators, and enterprises, want their services and applications to be used easily, robustly, and frequently. As a consequence, devices always need to have the right configurations and software to use these services. DM is the technology that will guarantee this.
Device manufacturers mostly gain indirect benefits from DM. DM capability on devices results in good user experiences that users associate with the device brand. In such a situation, end-users will feel that a manufacturer's device is easy to use and that help for using it is always available. In addition to these indirect benefits, a DM standard allows manufacturers to implement only one DM protocol in a device. Hence the overall code size (i.e. footprint) requirement for a device is reduced.
Providing an end-to-end DM solution requires the existence of a counterpart on the service or network side, the DM server software. Software vendors are the companies to provide this type of software. In other words, the demand for DM has created a business potential for these software vendors. The existence of a DM standard is also beneficial to software vendors. A DM standard enables them to focus on value-added features and differentiation rather than being hindered by the need to support multiple protocols.
The SyncML Initiative has identified a set of practical usage models to form the basis for its DM specification. Table 9-1 lists the most common usage models for DM functions. It is worth noting that the list below is not exhaustive. Other usage models can also be supported by the DM functionality.
Table 9-1. DM Usage Models
Provisioning a new device
A brand new device is configured according to the customer's preferences.
Remote service management
After the activation of a service, the configuration for the service is added to a device.
A user runs a DM application in a desktop PC. This application enables the management of settings in a device communicating with the PC through local connectivity, such as Bluetooth.
A help desk person remotely verifies the operating parameters. If necessary, the help desk person can change the parameters remotely.
Back up and restore
The content of a device is periodically stored on a local PC or a back-up server in the network. Later, this content can be restored on the device.
An operator changes a configuration in all the devices in its networks. For instance, this configuration could be the settings of a GPRS (General Packet Radio Service) access point.
Automatic status reporting
A DM server automatically requests status information from a device, which can be manned (e.g., a mobile phone) or unmanned (e.g., an alarm system in a remote location).
A new software module is installed, or an installed software module is replaced or deleted on a device.
To see how the usage models can be realized in practice, two common usage models, provisioning a new device and troubleshooting, are introduced with example use cases.
Provisioning a New Device An end-user buys a new mobile device in a retail store. Store personnel use a device management system to configure the mobile device according to the end-user's preferences. The configuration contains the basic initial activation and connection to a wireless network. In addition, the configuration of premium add-on services, such as browser and email, is performed. The new mobile device and all desired services are fully operational when the end-user leaves the store. Service enrollment takes place immediately at purchase. In addition, similar functionality can be utilized at any time after the purchase.
Troubleshooting A service provider offers email, WAP, and PIM synchronization services to customers. These services require specific settings in customers' devices. With a DM system, the service provider's helpdesk can check whether all these services are operational in the customer's devices or whether errors have occurred when using them. If errors have happened, the DM system can be utilized to determine and correct the possible problem.