Device Management for none-oneM2M Devices?

Question

I already discussed how to manage devices in OneM2M on this topic but I noticed that I have still some misunderstanding.

1. Relation between MgmtObj and MgmtCmd. What is the exact correlation between them ? It seems MgmtObj keeps the status like the current software or firmware in it, the battery, device info etc. ObjectIds and ObjectPaths are used for mapping these information to a device management standard like LWM2M, TR-0069. Is it correct ?

2. I dont understand why Node has multiple reboot objects in it?

3. Lets assume we have multiple different firmwares on a node. Each firmware controls different part of the hardware. Then I guess I should create a MgmtCmd for each firmware but how a MgmtCmd knows which firmware (MgmtObj) its related for ? There is no link between them when we look at the resource definition in OneM2M. Actually this points to my first question that the relationship between MgmtObj and MgmtCmd because somehow when the MgmtCmd runs and finished its job then the related firmware should be updated in related Node.

4. Lets assume that I am not going to implement any device management standard like TR-0069, LWM2M etc. We are using nonOneM2M devices which has its own proprietary way of device management. Then whats the simplest way to do that ?

What we thought is, we should put some device management logic to the IPE(Inter proxy entity) which can subscribe to all the events that occurs in any related MgmtCmds for devices like update of its ExecEnabled status and creation of ExecInstance. Then we should notify the IPE with that ExecInstance then IPE manages all the procedure. Is it suitable to use Subscription/Notification mechanism for device management ?

The mgmtCmd resource represents a method to execute management procedures or to model commands and remote procedure calls (RPC) required by existing management protocols (e.g. BBF TR-069 [i.4]), and enables AEs to request management procedures to be executed on a remote entity. It also enables cancellation of cancellable and initiated but unfinished management procedures or commands.

The mgmtObj resource contains management data which enables individual M2M management functions. It provides a general structure to map to external management technology e.g. OMA DM [i.5], BBF TR-069 [i.4] and LWM2M [i.6] data models. Each instance of mgmtObj resource shall be mapped to single external management technology.

-------------------------------- CLARIFICATION --------------------------------

When we look at the xsd of node, it contains child resources like

• List of firmwares
• List of softwares
• List of reboots
• etc...

Actually I just made up an example, its not a real world scenario. Also I try to understand why node has multiple of those resources like reboot, software, even if deviceinfo seems weird. What they refers ?

<xs:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.onem2m.org/xml/protocols"
    xmlns:m2m="http://www.onem2m.org/xml/protocols" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    elementFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:include schemaLocation="CDT-commonTypes-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-memory-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-battery-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-areaNwkInfo-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-areaNwkDeviceInfo-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-firmware-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-software-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-deviceInfo-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-deviceCapability-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-reboot-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-eventLog-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-cmdhPolicy-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-activeCmdhPolicy-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-subscription-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-semanticDescriptor-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-transaction-v3_9_0.xsd"/>
    <xs:include schemaLocation="CDT-schedule-v3_9_0.xsd"/>

    <xs:element name="node" substitutionGroup="m2m:sg_announceableResource">
        <xs:complexType>
            <xs:complexContent>
                <!-- Inherit common attributes for announceable Resources -->
                <xs:extension base="m2m:announceableResource">
                    <!-- Resource Specific Attributes -->
                    <xs:sequence>
                        <xs:element name="nodeID" type="m2m:nodeID" />
                        <xs:element name="hostedCSELink" type="m2m:ID" minOccurs="0" />
                        <xs:element name="hostedAELinks" type="m2m:listOfM2MID" minOccurs="0" />
                        <xs:element name="hostedServiceLinks" type="m2m:listOfM2MID" minOccurs="0" />
                        <xs:element name="mgmtClientAddress" type="xs:string" minOccurs="0" />              
                        <xs:element name="roamingStatus" type="xs:boolean" minOccurs="0" />
                        <xs:element name="networkID" type="xs:string" minOccurs="0" />

                        <!-- Child Resources -->
                        <xs:choice minOccurs="0" maxOccurs="1">
                            <xs:element name="childResource" type="m2m:childResourceRef" minOccurs="1" maxOccurs="unbounded" />
                            <xs:choice minOccurs="1" maxOccurs="unbounded">
                                <xs:element ref="m2m:memory" />
                                <xs:element ref="m2m:battery" />
                                <xs:element ref="m2m:areaNwkInfo" />
                                <xs:element ref="m2m:areaNwkDeviceInfo" />
                                <xs:element ref="m2m:firmware" />
                                <xs:element ref="m2m:software" />
                                <xs:element ref="m2m:deviceInfo" />
                                <xs:element ref="m2m:deviceCapability" />
                                <xs:element ref="m2m:reboot" />
                                <xs:element ref="m2m:eventLog" />
                                <xs:element ref="m2m:cmdhPolicy" />
                                <xs:element ref="m2m:activeCmdhPolicy" />
                                <xs:element ref="m2m:subscription" />
                                <xs:element ref="m2m:semanticDescriptor" />
                                <xs:element ref="m2m:transaction" />
                                <xs:element ref="m2m:schedule" />
                            </xs:choice>
                        </xs:choice>
                    </xs:sequence>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
    </xs:element>

----------------------- MORE CLARIFICATION -----------------------------

By the way, there is already a discussion about deviceinfo. Then I think they chose the way of multiple deviceInfo per Node because the current version of OneM2M supports multiple deviceInfo per Node. I also curious about whats meaning of multiple reboot or firmware per Node ?

Answer 1

To answer your questions one by one:

1. A specialisation of a <mgmtObj> holds the actual management information or represents an aspect of a device or node to be managed. Some of those specialisations can define "trigger" attributes that can execute a local action on a node. If one updates such an attribute then the action will be executed on the associated device.
   A <mgmtCmd> represents a method to execute a remote command or action on a node or device. It offers a way to implement management functionalities that are not provided by <mgmtObj> specialisations. It can also be used for tunnelling management functionality through oneM2M rather then abstracting it.

2. According to TS-0001, Table 9.6.18-1 "Child resources of <node> resource", the <node> resource shall only have 0 or 1 child resource of the reboot specialization.
   Actually it seems that the XSD, which you also quote in your question, is not correct because it does not reflect the written spec (also for some other attributes).

3. The assumption here is that a firmware is the basic and non-modular software stack or operating system of a device. You can use the [software] specialization to support modular OS architectures where you install "drivers" or packages for various apsects on the device. Each of those software packages can be managed independly from the firmware. TR-0069, for example, supports this kind of management.
   The reason why a node may support multiple firmwares is that a device can store multiple firmware versions or generations, and you want to support this feature. Of course, only one firmware is active at a time.

4. In general, what you want to do is to define and implement a management adapter for your proprietary protocol. This would be an IPE that implements the logic to map between the oneM2M management resources and the proprietary aspects as well as to implement the local protocol to communicate with the proprietary devices.

For the question regarding to use subscription and notifications: this depends on your concrete deployment architecture, but sure, using subscriptions/notification would be an efficient way to implement this. The other method would be that the management IPE polls for changes of the relevant resources, which in general is more resource intensive.