DOC

OMA-ERELD-DM-V1_2_0-20050421-D

By Robert Ferguson,2014-06-22 10:15
8 views 0
oma dm

    Enabler Release Definition for OMA Device

    Management

    Draft Version 1.2 – 2131 AprJan 2005

    Open Mobile Alliance

    OMA-ERELD-DM-V1_2_0-200504210131-D

    ; 2005 Open Mobile Alliance Ltd. All Rights Reserved.

    Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document.[OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 2 V(14)

    Use of this document is subject to all of the terms and conditions of the Use Agreement located at http://www.openmobilealliance.org/UseAgreement.html.

    Unless this document is clearly designated as an approved specification, this document is a work in process, is not an approved Open Mobile Alliance? specification, and is subject to revision or removal without notice.You may use this document or any part of the document for internal or educational purposes only, provided you do not modify, edit or take out of context the information in this document in any manner. Information contained in this document may be used, at your sole risk, for any purposes. You may not use this document in any other manner without the prior written permission of the Open Mobile Alliance. The Open Mobile Alliance authorizes you to copy this document, provided that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials and that you comply strictly with these terms. This copyright permission does not constitute an endorsement of the products or services. The Open Mobile Alliance assumes no responsibility for errors or omissions in this document.Each Open Mobile Alliance member has agreed to use reasonable endeavors to inform the Open Mobile Alliance in a timely manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification. However, the members do not have an obligation to conduct IPR searches. The declared Essential IPR is publicly available to members and non-members of the Open Mobile Alliance and may be found on the “OMA IPR Declarations” list at http://www.openmobilealliance.org/ipr.html. The Open Mobile Alliance has not conducted an independent IPR review of

    this document and the information contained herein, and makes no representations or warranties regarding third party IPR, including without limitation patents, copyrights or trade secret rights. This document may contain inventions for which you must obtain licenses from third parties before making, using or selling the inventions. Defined terms above are set forth in the schedule to the Open Mobile Alliance Application Form.

    NO REPRESENTATIONS OR WARRANTIES (WHETHER EXPRESS OR IMPLIED) ARE MADE BY THE OPEN

    MOBILE ALLIANCE OR ANY OPEN MOBILE ALLIANCE MEMBER OR ITS AFFILIATES REGARDING ANY OF

    THE IPR’S REPRESENTED ON THE “OMA IPR DECLARATIONS” LIST, INCLUDING, BUT NOT LIMITED TO THE

    ACCURACY, COMPLETENESS, VALIDITY OR RELEVANCE OF THE INFORMATION OR WHETHER OR NOT

    SUCH RIGHTS ARE ESSENTIAL OR NON-ESSENTIAL.

    THE OPEN MOBILE ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT, INDIRECT,

    PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR IN

    CONNECTION WITH THE USE OF DOCUMENTS AND THE INFORMATION CONTAINED IN THE DOCUMENTS.

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.

    Used with the permission of the Open Mobile Alliance Ltd. under the terms set forth above.

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 3 V(14)

    Contents

    1. SCOPE.....................................................................................................................................................................................42. REFERENCES.......................................................................................................................................................................62.1 NORMATIVE REFERENCES.......................................................................................................................................................6

    2.2 INFORMATIVE REFERENCES....................................................................................................................................................6

    3. TERMINOLOGY AND CONVENTIONS..........................................................................................................................7

    3.1 CONVENTIONS.......................................................................................................................................................................7

    3.2 DEFINITIONS..........................................................................................................................................................................7

    3.3 ABBREVIATIONS.....................................................................................................................................................................7

    4. INTRODUCTION .................................................................................................................................................................85. ENABLER RELEASE SPECIFICATION BASELINE.....................................................................................................9

    6. MINIMUM FUNCTIONALITY DESCRIPTION FOR DEVICE MANAGEMENT (INFORMATIVE)..................107. CONFORMANCE REQUIREMENTS NOTATION DETAILS....................................................................................11

    8. ERDEF FOR DEVICE MANAGEMENT - CLIENT REQUIREMENTS.....................................................................129. ERDEF FOR DEVICE MANAGEMENT - SERVER REQUIREMENTS....................................................................13APPENDIX A. CHANGE HISTORY (INFORMATIVE)....................................................................................................14

    A.1 APPROVED VERSION HISTORY.............................................................................................................................................14

    A.2 DRAFT/CANDIDATE VERSION 1.2 HISTORY...........................................................................................................................14

    Figures

    FIGURE 1: OMA DS AND DM SPECIFICATION STRUCTURE AND RELATIONSHIP.............................................4Tables

    TABLE 1 ERDEF FOR DEVICE MANAGEMENT CLIENT-SIDE REQUIREMENTS................................................12TABLE 2 ERDEF FOR DEVICE MANAGEMENT SERVER-SIDE REQUIREMENTS...............................................13? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 4 V(14)

    1.Scope

    The scope of this document is limited to the Enabler Release Definition of Device Management according to OMA Release process and the Enabler Release specification baseline listed in section 5. The OMA DM v1.2 specifications are based on the OMA Device Management (DM) v1.1.2 specifications and make use of the OMA SyncML Common v1.2 specifications as specified in the OMA SyncML Common specifications Enabler Release Definition [ERELDSC].

    The SyncML Initiative, Ltd. was a not-for-profit corporation formed by a group of companies who co-operated to produce an open specification for data synchronization and device management. Prior to SyncML, data synchronization and device management had been based on a set of different, proprietary protocols, each functioning only with a very limited number of devices, systems and data types. These non-interoperable technologies have complicated the tasks of users, manufacturers, service providers, and developers. Further, a proliferation of different, proprietary data synchronization and device management protocols has placed barriers to the extended use of mobile devices, has restricted data access and delivery and limited the mobility of the users.

    The SyncML Initiative merged with the Open Mobile Alliance in November 2002. The SyncML legacy specifications were converted to the OMA format with the 1.1.2 versions of OMA SyncML Common, OMA Data Synchronization and OMA Device Management in May 2002. The relationship between these documents which had been created during the SyncML Initiative has been preserved and is depicted in Figure 1: OMA DS and DM Specification Structure and Relationship.

    Figure 1: OMA DS and DM Specification Structure and Relationship

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 5 V(14)

    Although the SyncML Common specification defines transport bindings that specify how to use a particular transport to exchange messages and responses, the SyncML Common representation, synchronization and device management protocols are transport-independent. Each package in these protocols is completely self-contained, and could in principle be carried by any transport. The initial bindings specified are HTTP, WSP and OBEX, but there is no reason why SyncML Common could not be implemented using email or message queues, to list only two alternatives. Because the SyncML Common messages are self-contained, multiple transports may be used without either the server or client devices having to be aware of the network topology. Thus, a short-range OBEX connection could be used for local connectivity, with the messages being passed on via HTTP to an Internet-hosted synchronization server.

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

    OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 6 V(14)2.References

    2.1Normative References

    “OMA Device Management Bootstrap, Version 1.2”. Open Mobile Alliance?. [DMBOOT]

    OMA-TS-DM-Bootstrap-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA DM Device Description Framework, Version 1.2”. Open Mobile Alliance?. [DMDDFDTD]

    OMA-TS-DM-DDF-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA Device Management Notification Initiated Session, Version 1.2”. Open Mobile [DMNOTI]

    Alliance?. OMA-DM-Notification-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA Device Management Protocol, Version 1.2”. Open Mobile Alliance?. [DMPRO]

    OMA-TS-DM-Protocol-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA Device Management Requirements Document, Version 1.2”. Open Mobile Alliance?. [DMRD]

    OMA-RD-DM-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA Device Management Representation Protocol, Version 1.2”. [DMREPU]

    Open Mobile Alliance?. OMA-TS-DM-RepPro-V1_2_0.

    URL:http://www.openmobilealliance.org

    “OMA Device Management Security, Version 1.2”. Open Mobile Alliance?. [DMSEC]

    OMA-TS-DM-Security-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA Device Management Standardized Objects, Version 1.2”. Open Mobile Alliance?. [DMSTDOBJ]

    OMA-TS-DM-StdObj-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA Device Management Tree and Description, Version 1.2”. Open Mobile Alliance?. [DMTND]

    OMA-TS-DM-TND-V1_2_0. URL:http://www.openmobilealliance.org

    “OMA Device Management Tree and Description Serialization, Version 1.2”. Open Mobile [DMTNDS]

    Alliance?. OMA-TS-DM-TNDS-V1_2_0. URL:http://www.openmobilealliance.org

    “Enabler Release Definition for SyncML Common Specifications, version 1.2”. Open Mobile [ERELDSC]

    Alliance?. OMA-ERELD-SyncML-Common-V1_2_0.

    URL:http://www.openmobilealliance.org

    “OMA Interoperability Policy and Process”, Version 1.1, Open Mobile Alliance?, OMA-IOP-[IOPPROC]

    Process-V1_1, URL:http://www.openmobilealliance.org

    “Key words for use in RFCs to Indicate Requirement Levels”, S. Bradner, March 1997, [RFC2119]

    URL:http://www.ietf.org/rfc/rfc2119.txt2.2Informative References

    None.

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 7 V(14)

    3.Terminology and Conventions

    3.1Conventions

    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].All sections and appendixes, except “Scope” and “Introduction”, are normative, unless they are explicitly indicated to be informative.

    The formal notation convention used in sections 8 and 9 to formally express the structure and internal dependencies between specifications in the Enabler Release specification baseline is detailed in [IOPPROC].3.2Definitions

    Enabler ReleaseCollection of specifications that combined together form an enabler for a service area, e.g. a download

    enabler, a browsing enabler, a messaging enabler, a location enabler, etc. The specifications that are

    forming an enabler should combined fulfil a number of related market requirements.

    Management of the Device configuration and other managed objects of Devices from the point of view of Device Managementthe various Management Authorities. Device Management includes, but is not restricted to setting initial

    configuration information in Devices, subsequent updates of persistent information in Devices, retrieval of

    management information from Devices and processing events and alarms generated by Devices.Minimum Functionality Description of the guaranteed features and functionality that will be enabled by implementing the Descriptionminimum mandatory part of the Enabler Release.

    3.3Abbreviations

    DMDevice Management

    DTDDocument Type Definition

    ERDEFEnabler Requirement Definition

    ERELDEnabler Release Definition

    HTTPHypertext Transfer Protocol

    MIMEMultipurpose Internet Mail Extension

    OBEXObject Exchange protocol

    OMAOpen Mobile Alliance

    RDRequirements Document

    SCRStatic Conformance Requirements

    SyncMLSynchronization Mark-up Language

    WAPWireless Application Protocol

    WSPWireless Session Protocol

    XMLExtensible Mark-up Language

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 8 V(14)

    4.Introduction

    This document outlines the Enabler Release Definition for DM and the respective conformance requirements for client and server implementations claiming compliance to the Open Mobile Alliance DM v1.2 specifications.

    It should be understood that the OMA SyncML Common v1.2 specifications must be used in conjunction with the OMA Device Management Enabler Release, version 1.2. Fully conformant DM client and DM server implementations can only be achieved through combining the conformance requirements outlined within this enabler release definition with those outlined within the SyncML Common Specifications [ERELDSC] enabler release definition.

    Device management is the generic term used for technology that allows third parties to carry out the difficult procedures of configuring mobile devices on behalf of the end user (customer). Third parties would typically be wireless operators, service providers or corporate information management departments.

    Through device management, an external party can remotely set parameters, conduct troubleshooting servicing of terminals, install or upgrade software. In broad terms, device management consists of three parts:

    Protocol and mechanism: The protocol used between a management server and a mobile device

    Data model: The data made available for remote manipulation, for example browser and mail settings

    Policy: The policy decides who can manipulate a particular parameter, or update a particular object in the deviceIn a wireless environment, the crucial element for device management protocol is the need to efficiently and effectively address the characteristics of mobile devices including low bandwidth and high latency.

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 9 V(14)

    5.Enabler Release Specification Baseline

    This section is normative.

    The following section comprises the OMA DM v1.2 enabler release.

    DocumentReference

    OMA Device Management Bootstrap, Version 1.2. [DMBOOT]URL:http://www.openmobilealliance.orgOMA DM Device Description Framework DTD, Version 1.2.[DMDDFDTD]URL:http://www.openmobilealliance.orgOMA Device Management Notification Initiated Session, Version 1.2.[DMNOTI]URL:http://www.openmobilealliance.orgOMA Device Management Protocol, Version 1.2. [DMPRO] URL:http://www.openmobilealliance.org

    OMA Device Management Requirements Document, Version 1.2. [DMRD]URL:http://www.openmobilealliance.orgOMA Device Management Representation Protocol, Version 1.2. [DMREPU]URL:http://www.openmobilealliance.orgOMA Device Management Security, Version 1.2. [DMSEC] URL:http://www.openmobilealliance.org

    OMA Device Management Standardized Objects, Version 1.2.[DMSTDOBJ]URL:http://www.openmobilealliance.orgOMA Device Management Tree and Description, Version 1.2.[DMTND]URL:http://www.openmobilealliance.org

    OMA Device Management Tree and Description Serialization, Version 1.2.[DMTNDS]URL:http://www.openmobilealliance.org? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

OMA-ERELD-DM-V1_2_0-20050421-DOMA-ERELD-DM-V1_2_0-20050131-DPage 10 V(14)

    6.Minimum Functionality Description for Device

    Management(Informative)

    This section is informative. It describes the functionality that is delivered with the OMA Device Management specifications and their internal mandatory requirements.

    The OMA DM specifications define the protocols and mechanisms for how configuration parameters can be delivered to an OMA client from a OMA DM server that is part of the overall architecture. The mandatory functionality defines a set of commands used in the DM protocol for various management procedures as well as needed security level for management session. Mandatory management tree is used as server interface to the device, which includes several mandatory management objects that are providing basic device management functionality.

    The optional functionality covers several additional commands in DM protocol. Also, support for notification initiated session and bootstrapping is recommended, but optional functionality.

    ? 2005 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ERELD-20040205]

Report this document

For any questions or suggestions please email
cust-service@docsford.com