OMA DM协议：设备管理规范V1.2.1

需积分: 9 101 浏览量更新于2024-07-24 收藏 467KB PDF 举报

"OMA-TS-DM_Protocol-V1_2_1-20080617-A是Open Mobile Alliance (OMA)发布的一个设备管理协议规范，该协议基于SyncML Representation Protocol，用于实现对各种管理操作的标准化。此文档详细描述了OMA DM Protocol的版本1.2.1，它是一个在2008年6月17日批准的版本。" OMA（开放移动联盟）DM协议是无线通信领域中的一个关键标准，它定义了一种使用SyncML表示协议的管理协议。SyncML，即同步标记语言，是一种数据同步和设备管理协议，旨在促进不同设备和系统之间的数据交换和管理。OMA DM协议是建立在这个基础上，用于管理和配置移动设备，如智能手机、PDA等，以及与这些设备相关的服务。在OMA DM协议中，主要涵盖了以下几个关键知识点： 1. **协议结构**：OMA DM协议基于HTTP或WAP作为传输层，使用XML来编码管理消息。这允许它在多种网络环境下工作，并且能够处理异构设备间的通信。 2. **管理操作**：协议支持多种管理操作，包括设备初始化、软件更新、故障诊断、数据备份与恢复、配置设置的推送和接收等。这些操作通过一系列的DM消息来完成，如DM请求、响应和确认。 3. **模型和数据结构**：OMA DM定义了一个设备管理模型，该模型由设备信息模型（Device Information Model, DIM）组成，描述了设备上的可管理对象及其属性。DIM有助于抽象设备的复杂性，使得管理操作能够对设备进行统一的处理。 4. **安全性**：协议考虑了安全性方面的需求，包括认证、授权和加密，以确保数据的安全传输和设备的保护。这通常涉及使用HTTPS或WTLS来提供安全通道，以及使用预共享密钥或证书进行身份验证。 5. **事件通知**：OMA DM协议还支持事件通知功能，允许服务器端订阅设备的特定状态变化，当这些变化发生时，设备会自动发送通知，提高了远程管理的实时性。 6. **版本兼容性**：随着技术的发展，OMA DM协议不断更新以适应新需求。版本1.2.1是一个更新的版本，可能包含对之前版本的改进和错误修复，以提升协议的稳定性和效率。 7. **实施与互操作性**：由于OMA DM是公开的标准，不同制造商和开发者可以遵循这个规范来开发他们的设备和服务，从而保证了跨平台的互操作性。 OMA-TS-DM_Protocol-V1_2_1-20080617-A文档详细阐述了OMA DM协议的各个方面，对于理解如何通过标准化方式管理移动设备及其服务至关重要。这个协议对于设备制造商、应用开发者以及网络运营商来说，都是一个重要的参考指南，帮助他们在全球范围内实现设备的高效、安全和一致的管理。

OMA-TS-DM_Protocol-V1_2_1-20080617-A Page 9 (53)

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

5. Node addressing

Each node MUST be addressed by a unique full device URI. URIs MUST follow requirements specified in Uniform

Resource Identifiers (URI) [RFC2396] with the restrictions as specified in OMA Device Management Tree and Descriptions

[DMTND]. Node addressing is defined in [DMTND].

Each node has a type that determines what kind of management content can be set/read on that object. Operations on a certain

node require a predefined type of value to be sent and when the object is read, a value of that type is returned. For example a

certain node can have a simple text type (text/plain) so simple text values can be set while another node stores complex types

like the WAP Provisioning document type and require that value set in that node come with the WAP Provisioning document

MIME type. Examples for other objects with complex values can be WAP settings or installed software.

In OMA DM Protocol, the target and source of a command are identified by the Target and Source elements respectively.

Target refers to the recipient, and Source refers to the originator. Exceptions to this approach are mentioned in management

commands requiring exception.

OMA-TS-DM_Protocol-V1_2_1-20080617-A Page 10 (53)

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

6. Multiple Messages In Package

6.1 Description

The OMA Device Management protocol provides the functionality to transfer one SyncML package using multiple SyncML

messages. This is necessary when one SyncML package is too large to be transferred in one SyncML message. For example,

this limitation may be caused by the transport protocol or by the limitations of a small footprint device.

In OMA Device Management, the role of the package as a logical grouping of items is very limited. Most restrictions occur

on messages, not on packages. For example, a command must fit entirely into one message. This includes the Sequence

and Atomic commands, each of which must fit entirely into one message.

In order to avoid overwhelming a client with limited resources, a server is not permitted to send new commands to a client

that has not yet returned a status to previous commands. In other words, most messages sent by the server to the client will

correspond to a (one message) package, except in the case where a server is sending a large object or asking for more

messages (using Alert 1222). A package containing a large object datum will span as many messages as necessary to

transmit the large object, as specified in Section 7.

Note that the server is always in one of the following states with respect to package boundaries:

1. The server has sent a complete package. In this state, the server is awaiting status from the client on the commands

sent in the package. Because the status and results may be large, such as the result of Get commands, the client may

send multiple messages back to the server before completing its response.

2. The server has received a complete package (of responses) from the client. In this state, the server may send new

commands to the client.

3. The server has sent one or more messages that are part of the same package, but has not yet sent the final message of

the current package. This state is only valid when the server is sending a large object, and the package will end when

the last chunk of the large object is sent.

Because the underlying transports for SyncML have a request/response form, either the client or the server may be required

to send a message that contains neither new commands nor a Final flag, in order to keep the request/response cycle going.

For example, when the server is in State 1 (above), it may receive many messages from the client containing Status and

Results. The server will respond to each such message sent by the client, but may not include new commands in those

responses. Messages sent by the server in this state will contain a Status to the SyncHdr sent by the client and also the

Alert 1222 (More Messages). Status MUST BE sent in response to Alert but MUST NOT be sent in response to

Results.

It is also possible for Alert 1222 to be replaced by Alert 1223 (Session Abort) if the server wishes to abort the session.

The following chart shows an example of how multiple messages can be used.

OMA-TS-DM_Protocol-V1_2_1-20080617-A Page 11 (53)

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

Pkg

#1: Alert 1201, Replace

(

DevInfo

), Final

Pkg

#2: Status on

SyncHdr

, Alert and Replace, Commands, Final

Pkg

#3 (1/2): Status on

SyncHdr

and commands, Results

Pkg #4 (1/3): Status on SyncHdr, Alert 1222

Pkg #3 (2/2): Status on SyncHdr and Alert, Results, Final

Pkg #4 (2/3): Status on SyncHdr , Command containing Large Object

Pkg #3 (1/2): Status on SyncHdr and commands, Alert 1222

Pkg #4 (3/3): Status on SyncHdr and Alert, rest of Large Object, Final

Pkg #3 (2/2): Status on SyncHdr and command, Results, Final

Pkg #4: Status on SyncHdr , Commands, Final

Pkg #3: Status on SyncHdr and commands, Results, Final

Pkg #4: Status on SyncHdr , Final

DM Server DM Client

6.2 Requirements

If a SyncML package is transferred in multiple SyncML messages, the last message in the package MUST include the

Final element [REPPRO]. Other messages belonging to the package MUST NOT include the Final element.

The Final element MUST NOT be supplied by the client to close its package until the server has sent its Final element to

close the previous package. For instance, the client MUST NOT supply the Final element to close package #2 or package

#4 until the server has supplied the Final element which closes the previous package (#1 or #3, respectively). This is

necessary because packages #2 and #4 constitute replies to the commands in packages #1 and #3.

The recipient of a SyncML package containing multiple messages MUST be able to ask for more messages. This is done by

sending an Alert command, with the alert code 1222, back to the sender. If there are SyncML commands to be sent as a

response to a preceding message, i.e. Results, the Alert command with the 1222 alert code MAY be omitted.

In the situation in which the server has sent the Final flag, and the client has not yet sent its Final flag, the server MUST

respond to the client with the following "Next Message" response:

The "Next Message" response contains Alert code 1222 (or 1223 to abort), status to the SyncHdr, no other commands,

and no Final flag.

剩余52页未读，继续阅读

辛巴_莎莎爸爸

粉丝: 0
资源: 2

OMA DM协议：设备管理规范V1.2.1

OMA-TS-DM_Protocol-V1_2_1-20080617-A.pdf

OMA-TS-DM_Security-V1_2-20070209-A

OMA-TS-DM_StdObj-V1_2-20070209-A

OMA-TS-DM_RepPro-V1_2-20070209-A

OMA-TS-DM_Bootstrap-V1_2-20070209-A[归纳].pdf

OMA-TS-DM-Protocol-V1_2-20060424-C

OMA-TS-DM_Notification

OMA-TS-PoC_System_Description-V2_1-20110802-A

OMA-TS-DM.rar_Java编程_Java_

OMA-TS-PoC_Control_Plane and user_plane

最新资源