Technical Report Document Number


Introduction to OMA Device Management 2.0



Download 309.51 Kb.
Page5/11
Date31.01.2017
Size309.51 Kb.
#13095
1   2   3   4   5   6   7   8   9   10   11

5.4 Introduction to OMA Device Management 2.0

5.4.1 Description


OMA Device Management 2.0 is the new evolution of the OMA Device Management 1.x Protocols, and defines the interface between the DM Server and the DM Client to manage devices. Compared to OMA DM 1.x Protocols, the unique features of OMA DM 2.0 are as follows:

  • Protocol Simplification and Optimization: Transaction model, DM Packages, addressing schemes and security model are simplified and optimized as well for the fast market penetrations. Simplifications and optimization is the fundamental spirits that goes throughout OMA DM 2.0.

  • Extended DM Command Set: OMA DM 2.0 supports 10 DM commands, that is much extended compared to OMA DM 1.x. For example, the HGET/HPUT/HPOST commands are specified to utilize the RESTful interface, and the SHOW command is specified for the web-based user interaction.

  • Management Data Delivery using HTTP (RESTful interface): The DM Client can retrieve or send the management data from or to the Data Repository using the HTTP protocol. This enables the effective management data delivery.

  • Web-based User Interaction: The DM Server can utilize web pages to interact with the user. The Web Browser Component and the Web Server Component are newly introduced, and these two components can perform the user interaction session, which is independent with the DM session. This feature brings the rich user interactions to OMA DM 2.0.

  • JSON Representation for DM Packages: In OMA DM 2.0, JSON replaces XML. The new JSON format for DM Packages lightens the parsing overheads and shortens the DM Package length keeping the same degree of the extensibility.

  • New Addressing Scheme: OMA DM 2.0 introduces the new addressing scheme that uniquely addresses each node based on the Management Object Instance. In OMA DM 2.0, Management Objects do not need to be organized as a tree, and the DM Server does not need to have the knowledge of the DM Tree that can be different for each type of devices.

OMA DM 2.0 is not backward compatible with OMA DM 1.x. This is because OMA DM 2.0 uses the completely different representation based on JSON, and eliminates complex functionalities that are not required by the market. Although OMA DM 2.0 is not backward compatible with OMA DM 1.x, Management Objects (e.g., FUMO, SCOMO, DiagMon, LAWMO) designed for OMA DM 1.x can be still used for OMA DM 2.0. This is possible since OMA DM 2.0 uses the same Management Object definition and provides the necessary functionalities such as Generic Alerts. The complete separation between Management Objects and the OMA DM Protocol is one of the success factors as well.

5.4.2 Architecture


The following figure shows the OMA DM 2.0 Architecture and the related components and the interfaces:



Figure 5.4.1: OMA DM 2.0 Architecture

The Web Server Component and the Web Browser Component can be utilized for the user interactions. For the user interaction, OMA DM 2.0 specifies that the DM Server can send the SHOW command; therefore, the DM Client initiates the Web Browser Component with the specified web page. The actual user interaction can be performed using the HTTP/HTML, which is out-of-scope of the OMA DM 2.0. Please note that how to initiate the Web Browser Component, and how the transfer the user interaction results are out-of-scope of OMA DM 2.0 as well.



Using the Data Repository, the DM Client can retrieve and upload the management data from or to the Data Repository using the HTTP protocol. The DM Server can send the HPUT/HPOST and HGET command for those purposes.

5.4.3 Reference Points

5.4.3.1 Functional Components

5.4.3.1.1 DM Client

The DM Client is the logical software component that conforms to the requirements for DM Clients specified in OMA DM 2.0.
5.4.3.1.2 DM Server

The DM Server is the logical software component that conforms to the requirements for DM Servers specified in OMA DM 2.0. The DM Server is also responsible for providing the Bootstrap Message using the DM-3 Interface.
5.4.3.1.3 Web Server Component

Web Server Component is the logical software component responsible to host web pages for the Web Browser Component in the device. The web pages are used for the user interactions.
5.4.3.1.4 Web Browser Component

Web Browser Component is the logical software component responsible for retrieving web pages from the Web Server Component and presenting them to the user.
5.4.3.1.5 Data Repository

Data Repository is the logical software component that the DM Client can retrieve or send management data to or from this component by using HTTP.

5.4.3.2 Interfaces


The brief explanations for the defined interfaces are as follows:

  • DM-1 Notification: the interface over which the DM Server sends DM Notification to the DM Client to initiate the DM session.

  • DM-2 Device Management: the interface over which the DM Server sends device management commands to the DM Client and the DM Client returns status code, results and Alerts.

  • DM-3/4 Bootstrap: the interface over the Bootstrap Message is delivered. OMA DM 2.0 supports factory bootstrap, client-initiated bootstrap, server-initiated bootstrap and SmartCard bootstrap.

5.4.4 Protocol

5.4.4.1 DM Packages


The below figure describes the DM Package exchanges between the DM Client and the DM Server defined in OMA DM 2.0:



Figure 5.4.2: OMA DM 2.0 Package Flow

  • Step 0 (DM Notification): The DM Server requests the DM session by sending the DM notification to the DM Client.

  • Step 1 (DM Session Initiation): This DM package initiates the DM session and might contain information for the supported Management Object and Generic Alerts generated by the DM Client.

  • Step 2 (Request): The DM Server sends the DM commands to the DM Client.

  • Step 3 (Command Processing): The DM Client processes the DM commands received. To process the DM command, the DM Client might interact with components such as the Web Browser Component, the Data Repository.

  • Step 4 (Response): Unless the END command is received, the DM Client responses to the DM Server. It contains the results for the DM command and Generic Alerts generated by the DM Client.

5.4.4.2 DM Commands


The below table shows the DM commands specified in the OMA DM 2.0:

Logical Op.

Name

Description

DM 1.x Relation

Read

GET

To retrieve data from the device. The data is included in Package#3.

Get

HPUT

To request the device to send data to the Data Repository using HTTP PUT.

MO individually implements this

HPOST

To request the device to send data to the Data Repository using HTTP POST.

Write

DELETE

To delete data in the device.

Delete

HGET

To requests the DM Client to retrieve data from the Data Repository using HTTP GET, and add or replace the received data into the device.

Add, Replace

Exec

EXEC

To execute an executable node.

Exec

Not related to MO

SHOW

To initiate a UI session between the Web Browser Component and the Web Server Component.

Alert for UI. Only 5 UI types exist

CONT

To continue the DM session with the specified DM Server URI.

element

END

To terminate the DM session.

element

DEFAULT

To use a specific address to capture configuration if that is missing in the device for a specific MOID.

None

Table 5.4.1: OMA DM 2.0 Commands

5.4.5 Functions

5.4.5.1 Introduction


Each device that deploys OMA DM 2.0 supports Management Objects. Management Object is the set of related nodes for a specific function, and OMA DM 2.0 achieves management functions by using the Management Objects. The type of the Management Object is defined by the MOID.

For example, for the firmware management functions, the Firmware Update Management Object as specified in [i.4] can be used as shown below:





Figure 5.4.3: Firmware Update Management Object

OMA DM 2.0 does not require that Management Objects in the device are organized as a hierarchical tree structure since the nodes are addressed based on the Management Object instance. In the device, Management Object is realized as a Management Object instance. Once the Management Object instance is created in the device, the DM Client assigns the MO Instance Identifier (MIID) to it, and the DM Server can use the ClientURI to uniquely identify each node in the Management Object Instance. Note that ClientURI is built based on the MOID and MIID.



Suppose that the above FUMO is realized as an instance in the device. Then the DM Server can use below Client URIs:

  • urn:oma:mo:oma-fumo:1.0/fumo1/PkgName – to identify the /PkgName node

  • urn:oma:mo:oma-fumo:1.0/fumo1/DownloadAndUpdate/PkgURL – to identify the /DownloadAndUpdate/PkgURL node

The “fumo1” in the above ClientURI is the MIID assigned to the FUMO instance, and can be omitted if the MOID is enough to uniquely identify a Management Object Instance (i.e., there is only one Management Object Instance for the MOID). Hence, the ClientURI can be simplified further to “urn:oma:mo:oma-fumo:1.0/ /PkgName” if MIID is not needed.

5.4.5.2 Management Objects supported by OMA DM 2.0


OMA DM 2.0 shares the same Management Object definitions, which allows that Management Objects designed for OMA DM 1.x can be reused for OMA DM 2.0. Hence, every MO identified in the section 5.1.5.2.2 that is considered as relevant to the management of M2M Device/Gateway are supported by the OMA DM 2.0 (e.g., FUMO, SCOMO, Gateway MO, etc.). In addition, OMA DM 2.0 supports below standard MOs:

Standard MO

Description

DevInfo MO V1.2

  • This MO provides the basic device information such as the device identifier, manufactures, etc.

DM Account MO V2.0

  • This MO provides the account information for the DM Servers.

Delegation Access Control MO V1.0

  • This MO provides the information for the access control.

Session Info MO V1.0

  • This MO provides the information for the DM session.

Table 5.4.2: Standard Management Object for OMA DM 2.0

5.4.5.3 Detailed Comparisons with OMA DM 1.x


Below table explains the differences between OMA DM 2.0 and OMA DM 1.x from the overall perspective:

Label

DM 2.0

DM 1.x

Package Representation

  • JSON

  • XML

DM Command

  • 6 DM commands.

  • Random, Sequential, Atomic processing

MO Addressing

  • ClientURI

  • Absolute, Relative, Virtual

User Interaction

  • Web-based User Interaction using SHOW command

  • User Interaction Alert supports 5 types (Display, Confirmation, User Input, Single Choice, Multi Choice)

Security

  • Authorization – ACL for MO instance granularity (can be extended to node granularity)

  • Confidentiality/Authentication – transport layer security only

  • Authorization – ACL for node granularity

  • Confidentiality/Authentication – DM Protocol security or transport layer security

DM Notification

  • TLV (2 Headers, 5 Options)

  • Transport: SMS, Google Cloud Messaging

  • TLV (6 Headers, 8 Options, Digest) + Binary Format (backward compatible with DM 1.2)

  • Transport: SMS, OBEX, SIP, HTTP, Cell Broadcast.

Table 5.4.3: Comparison between OMA DM 2.0 and OMA DM 1.x

5.4.5.4 Protocol Examples


In this section, an example is presented in which the DM Server updates the firmware of the device. The Package#1 (DM session initialization) sent from the DM Client to the DM Server is as follows:

POST /dmclient/dm20 HTTP/1.1

Content-Type: application/vnd.oma.dm.initiation+json

Accept: application/vnd.oma.dm.request+json

OMADM-DevID: IMEI:493005100592800

Host: www.dms.com


{

"MOS": [


{

"DDF": "http://www.vendor.com/DDF/devinfo1.0.ddf",

"MOID": "urn:oma:mo:oma-dm-devinfo:1.0",

"MIID": ["miid1"]

},

{

"DDF": "http://www.vendor.com/DDF/oma-fumo1.0.ddf",



"MOID": "urn:oma:mo:oma-fumo:1.0",

"MIID": ["miid1"]

},

{

"DDF": "http://www.vendor.com/DDF/oma-dm-dmacc2.0.ddf",



"MOID": "urn:oma:mo:oma-dm-dmacc:2.0",

"MIID": ["miid1"]

}

]

}



In the above Package#1, the JSON object “MOS” carries the Management Object information that is supported by the device. According to the “MOS”, the DM Server can know that the DM Client supports DevInfo MO, FUMO, DM Account MO.

After receiving the Package#1, the DM Server sends the Package#2 to update the firmware of the device. The Package#2 is as follows:

HTTP/1.1 200 OK

Content-Type: application/vnd.oma.dm.request+json


{

"CMD": [


["EXEC", "oma:mo:oma-fumo:1.0//Update"]

]

}



After completing the firmware updating, the DM Client sends the Package#3 for the response as follows:

POST /dmserver/dm20 HTTP/1.1

Content-Type: application/vnd.oma.dm.response+json

Accept: application/vnd.oma.dm.request+json

OMADM-DevID: IMEI:493005100592800

Host: www.dms.com


{

"Status": [

{"sc": 200}

]

}



After receiving the Packge#3 from the DM Client, the DM Server terminates the DM session by sending the END command. The Package#2 for this is as follows:

HTTP/1.1 200 OK

Content-Type: application/vnd.oma.dm.request+json
{

"CMD": [


["END"]

]

}



On receiving the Package#2, the DM Client does not send the Package#3. The DM session is terminated.




Download 309.51 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9   10   11




The database is protected by copyright ©ru.originaldll.com 2024
send message

    Main page