| The SyncML Initiative released the first version of the DM specification as a part of the SyncML 1.1 specification. This open technology ensures compatibility between a large number of devices and management servers. The use of SyncML DM has substantial advantages for relatively small and cost-effective devices. It is wireless-friendly and transport-independent. It also provides an extensible, mature, and flexible security model together with independence from a runtime environment. SyncML DM technology can be divided into the following three logical components: Bootstrapping is needed to configure the initial settings on a device. After the bootstrapping phase, only the SyncML DM Protocol is needed for communication between a mobile device and a DM Server. In general, bootstrapping is done over unsolicited message functionality such as WAP Push over SMS (Short Message Service) or OBEX. Bootstrapping includes a separate protocol and additional logic that ensures the necessary level of security for this type of functionality. The Bootstrap Agent (see Figure 9-2) handles this logic. Figure 9-2. SyncML DM architecture 
The SyncML DM Protocol allows management commands to be executed on management objects. It uses the SyncML Message format defined in the SyncML Representation Protocol. In addition, the SyncML DM protocol also reuses parts, such as the authentication procedure, of the functionality of the Synchronization Protocol. Within the DM Protocol, a management object can reflect a set of configuration parameters for a device. Actions upon this type of object might include reading and setting parameter keys and values. Another management object could be the runtime environment for software applications on a device. The SyncML Device Description Framework (DDF) specifies the addressing scheme and data structures used by the SyncML DM protocol. The DDF enables device manufacturers and application developers to include all manageable functions in devices in one consistent structure. The DDF actually provides the necessary information for DM Servers to manage the functions in devices of various types. The DDF functionality is quite similar to MIB (Management Information Base) [RFC1213], defined by IETF for the network management. The manageable applications are located on top of the description framework. A microbrowser, an email client, and a data synchronization application are examples of such manageable applications in a device. They include configuration parameters for the services. In addition, these applications may need to be diagnosed or they may need additional software to provide extra functionality. The characteristics of these applications indicate that external management operations can be beneficial. Figure 9-2 depicts the whole SyncML DM architecture for a SyncML DM device. In addition to the components described earlier, the transport protocols used in bootstrapping and by the DM Protocol are shown. The DM Agent application provides the necessary application logic and user interface functions. It is built upon the bootstrap components and the DM protocol. The DM configuration database (DM Conf.), shown between the bootstrap and SyncML components in Figure 9-2, includes all the necessary information for authenticating and communicating with a DM Server. The bootstrap components insert this information and the DM protocol uses the information. The information is needed regardless of the entity, the DM Server or the DM Client, initiating a management session. The bootstrapping phase and the usage of the DM protocol is illustrated in Figure 9-3. Bootstrapping is needed only once per server. The SyncML DM Protocol is used to run a SyncML DM session whenever needed. As Figure 9-2 implicitly shows, the DDF and the managed applications components are only used after bootstrapping. Those components are used within the SyncML DM Protocol and not during bootstrap. Figure 9-3. Phases of bootstrapping and DM sessions 
Comparison with SyncML Synchronization Framework The similarities of the SyncML DM architecture to the SyncML data synchronization architecture are associated with the usage of the Representation Protocol and with some adopted functions from the Synchronization Protocol. In addition, the DM Protocol uses the same transport bindings as the Synchronization Protocol. Nevertheless, there are some clear differences from the SyncML data synchronization architecture. The main differences are: A dedicated management protocol, SyncML DM Protocol, on top of the Representation Protocol Device information is represented and used differently Stronger security requirements Data objects are handled differently
The SyncML DM Protocol is quite different from the SyncML Data Synchronization Protocol, although some functions are reused. A fundamental difference is that the DM Protocol (version 1.1) allows only for the DM Server to send management operations toward the DM Client. The device information in the SyncML Data Synchronization Protocol is described in an XML document. This is not the case in SyncML DM. The representation of the device info for DM utilizes the SyncML DDF. Thus, all elements of the device info are transferred as individual data items within a SyncML Message. In addition, there are not as many mandated device information elements compared to the number of elements used in SyncML Data Synchronization. The security requirements within SyncML DM are slightly different and actually stronger. This is motivated by the fact that DM is quite invisible from the end-user point of view and most operations happen in the background. Thus, it is important to eliminate the possibility of denial of service (DoS) attacks or other security threats. Object handling in SyncML DM is not based on datastores or data items in those datastores. Instead, object handling uses a management tree structure utilizing the DDF that contains all manageable objects. Bootstrapping in SyncML Device Management Bootstrapping, also known as initial provisioning, is a prerequisite for starting any "real device management session." Bootstrapping is essentially about provisioning the DM Agent application in a device and possibly configuring some communications settings to enable a transport-level connection with a DM Server. After this operation, a DM session can be started and all other manageable applications can be configured properly. In addition to providing the necessary settings, bootstrapping can logically be regarded as the process that creates the trusted relationship between the DM Server and the DM Client. Bootstrapping can happen in a number of ways. One method is to use the SyncML DM Bootstrap Protocol to convey the necessary settings to a device. Commonly, this happens over unsolicited transports, such as the WAP Push or the OBEX protocol. The configuration parameters can also be offered within a smart card, such as a SIM (Subscriber Identity Module) card, which is then inserted into the device. A third possibility is to preprogram these settings during the manufacturing process. The last two ways appear to be the most convenient from the end-user perspective, because bootstrapping is already completed by the time a customer buys a device. They have the drawback, however, that if a new DM configuration needs to be added, the smart card or the device itself needs to be reprogrammed. Many different triggers can spontaneously initialize bootstrapping based on the SyncML DM Bootstrap Protocol. A DM Server can start bootstrapping a device if it detects a new un-bootstrapped device in a network. Alternatively, the DM Server can be ordered to send a bootstrap message to a device. A salesman can do the order at a point of sale where a sales system is connected to a management system. A customer can also do the same thing through a self-service Web site. Thirdly, bootstrapping might also be triggered directly from a terminal. For instance, an end-user sends a specific SMS or calls a specific number to trigger the DM Server. In all these triggering methods, the process and the phases are similar to the ones depicted in Figure 9-4. These triggering methods may utilize many technologies. The SyncML Initiative has not standardized them, as they are implementation-specific and dependent on the underlying technologies, which are not globally unified. The SyncML Bootstrapping specification includes the needed functionality after the DM Server has been triggered. Figure 9-4. Phases of bootstrapping 
When sending a SyncML Bootstrap Message, the server has the following two alternatives for formatting the message: The alternatives offer similar functionality and are defined by the SyncML Initiative in the SyncML Device Management Specification. As the name of the WAP provisioning bootstrap specification [WPR01] indicates, WAP Forum originally defined this mechanism. The SyncML Initiative simply reuses it. The WAP provisioning bootstrap offers a very complete set of documentation for bootstrapping and can actually be used to provision the WAP browser as such. This bootstrapping mechanism is well designed to work over low-bandwidth transports such as WAP Push over SMS. The SyncML Message format based bootstrapping utilizes the format defined by the SyncML Representation Protocol. Thus, it reuses existing technology. Implementations that use medium- or high-bandwidth transports might consider using this bootstrapping mechanism. It is worth noting that this mechanism is not very suitable over transports such as WAP Push over SMS, because the message length can be too large. Bootstrapping is needed to provide the necessary settings to enable communication between the DM Server and the DM Client. The settings include the following information: Server addresses, such as a server URL Authentication credentials, such as a server ID and a password Transport connection settings, such as network configuration for IP connections
An important aspect of bootstrapping is security and how to create a trusted relationship between a server and a device. In practice, this means that the device and the user are able to verify that a bootstrapping message comes from the trusted DM Server. Because of this requirement, the bootstrapping mechanism offers the functionality for authenticating the message itself and also for checking the integrity of the message. Basically, this procedure takes place when a device has received a message. The authentication and integrity check procedure is based on a shared secret, such as a password, which is used to generate an MD5-based digest. When receiving the digest and the bootstrapping message, the recipient can validate the sender and the integrity of the message. SyncML Device Management Protocol The SyncML Device Management Protocol is the equivalent of the SyncML Synchronization Protocol. Like the Synchronization Protocol, the DM Protocol can be used over various transport protocols and uses the same SyncML Representation Protocol, although it defines its own usage for the Representation Protocol [SDM02]. As the 'Device Management' term indicates, device management is primarily about managing devices. Thus, the DM Protocol (version 1.1) is designed to provide the DM Server with the functionality of sending commands to the DM Client. The DM Client is not allowed to send any management commands to the DM Server other than Status or Results commands. Note that this is asymmetric, unlike data synchronization. Within the management commands, the DM Protocol transfers management objects. The management objects are located in the management tree of a device, the structure of which is described by the DDF. The management tree organizes all available management objects in the device as a hierarchical tree structure, where all management objects can be uniquely addressed with a URI. Managing functionality The DM Server has two functional sets that are used. Due to this, the management functionality provided by the DM Protocol can be divided into the following two categories: Features belonging to the management object (MO) functionality are dedicated to management objects (MOs) within a device. An example of a MO is a configuration parameter of an email client. Table 9-2 describes the different features under the management object functionality. The table also defines the SyncML command used to realize each feature. Table 9-2. Features of Object Management FunctionalityFeature | Description | SyncML Command |
|---|
Reading MO content | The server retrieves the content (e.g. parameter value) from the DM Client. | Get | Reading a MO list | The list of MOs residing under a node in a management tree is read. | Get | Adding a MO or MO content | A new dynamic MO is inserted. | Add | Updating MO content | Existing content of an MO is replaced with new content. | Replace | Removing MO(s) | One or more MOs under a node are removed from a management tree. | Delete |
An example of updating MO content is given below. A DM Server sends the Replace command and the DM Client responds with the Status command. The example illustrates updating the anti-virus definition file in a device. <Replace> <CmdID>4</CmdID> <Meta> <Format xmlns="syncml:metinf">b64</Format> <Type xmlns="syncml:metinf"> application/antivirus-inc.virusdef </Type> </Meta> <Item> <!-- Anti-virus definition --> <Target> <LocURI>./anti-virus/definition</</LocURI> </Target> <Data> <!-- Base64-coded anti-virus file --> </Data> </Item> </Replace> The DM Client's response to the command would be the following: <Status> <CmdID>4</CmdID> <MsgRef>1</MsgRef> <CmdRef>4</CmdRef> <Cmd>Replace</Cmd> <TargetRef>./anti-virus/definition</TargetRef> <Data>200</Data> <!-- OK, definition updated --> </Status> The user interaction functionality of the DM Protocol enables communication with the user of a device. Information about management operations can be provided to the user, or a confirmation for a management operation can be requested from the user. Table 9-3 lists the main user interaction features defined in the SyncML DM Protocol specification. It is worth noting that all the user interaction features are based on the usage of the Alert command. These features can be attached to the features of the management object functionality by enveloping those with a Sequence or an Atomic command. With the Sequence command, the order of user interactions and management operations can be defined. The Atomic command helps to ensure that all commands are successfully processed. Table 9-3. Main User Interaction FeaturesFeature | Description |
|---|
Display | A notification or additional information about management can be shown to the user. | Confirmation | A confirmation question (yes or no) can be asked of the user. | User input | Input in a text form can be requested from the user. | User choice | One or more selections from a set of options can be requested from the user. |
SyncML DM recognizes the need for user interaction for certain management operations and hence provides the capabilities described above. The user interaction features should not be over used, since such overuse is counter to automatic and background device management, the fundamental goal of SyncML DM. Phases of DM Protocol A SyncML DM session can be initiated either from the DM Server or from the DM Client. Like the synchronization session, the DM session also has different phases, as depicted in Figure 9-5. The Notification phase is required if the DM Server initiates the session. The Notification phase is usually done over an unsolicited transport protocol, such as WAP Push over SMS. The Setup phase follows the Notification phase. The Setup phase is actually the first phase if the DM Client initiates the session. The last phase, the Management phase, includes an undetermined number of packages, because the DM Server may need to repeat Package #4 multiple times. In this case, Package #3 and Package #4 alternate. The Setup and Management phases may use different transport protocols than the Notification phase. They are usually run over transports such as WSP and HTTP. Figure 9-5. Phases of SyncML DM session 
The Notification phase contains only one Message from the DM Server to the DM Client. It is the management alert for requesting a DM Client to initiate a DM session with a specific DM Server. In addition to the information about the DM Server this Message contains information about the type of management session (e.g. background operation) and about the original entity requesting the management session. The latter can be used to notify the user that an operator has requested the management session. The Setup phase of a SyncML DM Session includes two SyncML packages, one from the DM Client (Package #1) and one from the DM Server (Package #2). Package #1 is dedicated to the following purposes: Sending the device information (manufacturer, model, etc.) to a DM Server Identifying the DM Client to the DM Server Informing the DM Server about the initiating entity (Client or Server) of the DM session
As a response to Package #1, Package #2 identifies the DM Server to the DM Client. In addition, Package #2 is the first package in which management commands are possibly included. Those commands can belong either to the management object functionality or to the user interaction functionality. After the Setup phase, the actual Management phase occurs. For the Management phase to occur, Package #2 must contain management commands that require one or more responses from the DM Client. The same condition exists for repeating Package #3 after Package #4. If Package #4 includes management commands that require a response from the DM Client, then Package #3 is repeated. Since the DM Client cannot send any management commands towards the DM Server, Package #3 cannot include any commands. If the DM Server has received Package #3 and it has no management commands to be sent to the DM Client, Package #4 is used for closing the DM session. In this case, the package is devoid of any management commands. Security features There are different security features associated with the DM Protocol, such as authentication, integrity check, and encryption. These features are slightly different for the Notification phase and the Setup and Management phases, as shown in Figure 9-6. The reason is that those phases may be run over different transport protocols. Figure 9-6. Security features associated with SyncML DM phases 
As depicted in Figure 9-6, only the DM Server is authenticated during the Notification phase. This authentication guides the DM Client when making a decision whether to start the Setup phase with the DM Server or not. The DM Server cannot authenticate the DM Client prior to the Setup phase. During the Setup and Management phases, DM commonly uses IP-based transport protocols. The underlying security protocol, such as SSL, TLS, or WTLS, offers the encrypted channel for confidentiality and integrity. Nevertheless, if those security protocols are not supported and the integrity check is needed, the SyncML Initiative has defined a check for this purpose. Integrity of SyncML DM Messages is achieved using an HMAC-MD5. This is a Hashed Message Authentication Code that can be used on every Message transferred between the DM Client and the DM Server if requested to do so by either entity. Device Description Framework Mobile devices are very different, both physically and functionally. Nevertheless, it is equally important to be able to manage these diverse devices. Thus, management systems need to be able to handle each individual device even if they have different internal structures and behaviors. To address this issue, the concept of a Device Description Framework (DDF) [STD02] has been introduced within SyncML DM technology. Briefly, this framework provides a way for device vendors to describe their devices so that a management system can understand how to manage them. The DDF document for a device is created based on the DDF functionality. Having the DDF document of the device enables the DM Server to correctly access the management tree of the device. The DDF document describes how the management tree in the device is constructed and how addressing happens within the device. The DDF document can vary from device to device. As a consequence, the structure of the management trees can also be different. For instance, Device A includes management objects of two types, browser bookmarks and a voice mail number. Device B only includes management object for a voice mail number. In this case, the management trees for the devices could look like they do in Figure 9-7. Figure 9-7. Example management trees 
The examples in the figure below clearly show that the device management trees for different devices can be different. Although there are some similar functions, they are not necessarily arranged in similar ways in different devices. An example of this type of function is the voice mail number. The DDF document of the device also describes how to address the management objects within the management tree. For instance, if a bookmark is added to the device management tree of Device A, it is added under the Browser node and the management command within a SyncML Message is the following: <Add> <CmdID>4</CmdID> <Meta> <Format xmlns="syncml:metinf">chr</Format> <Type xmlns="syncml:metinf">text/plain</Type> </Meta> <Item> <!-- Bookmark to SyncML web site --> <Target> <LocURI>./Browser/SyncML</LocURI> </Target> <Data>http://www.syncml.org</Data> </Item> </Add> Within the management tree, access rights for different DM Servers can vary. In other words, some DM Servers may not have the right to access all the management objects existing in the tree. To enable this functionality, the SyncML DDF includes an access control list (ACL) feature. For example, some Servers may only read the content of a MO whereas other Servers may read and even update the content of the MO. ACL values for a MO can be controlled and changed by a party that has the specific ACL right for the MO. After having those for a MO, the party's own and others' access rights can be managed. DM Client implementations can choose whether there are one or more parties who are able to modify the ACL values for a MO. | 
