Firmware Update and management in oneM2M

Question

OneM2M divides device management into two different methods.

1- Device management over the service layer

2- Device management using external management technologies

I want to understand how to do a firmware update by using each of the methods. However I only find very basic examples like getting a memory resource object as an example for device management. But what is a use case for using <mgmtCmd> and <execInstance>. Is there any concrete example which you can share?

I understand that a Node is the actual hardware device and Management Objects are resources that represens the management functions and entities. But I dont understand the correlation between <mgmtCmd> and <mgmtObj>'s.

Lets assume I have a device (AE & Node). It has a firmware information that I keep as a <mgmtObj> on the Node itself. It has also <mgmtCmd> that updates the firmware. (I assume that MgmtCmd is created by the AE. I am also not sure who should create the <mgmtCmd>? The related AE I guess.)

How should I run the <mgmtCmd> by choosing each methods that I describe above? Should I use an external management service like TR-069 or OMA-DM or LWM2M DM ? Or is the device management over the oneM2M service layer enough to do that ?

What OneM2M says that an <execInstance> resource is an instance of <mgmtCmd>. If I update <gmtCmd>'s execEnable attribute then related to that <mgmtCmd> should create an <execInstance> as a child resource. Then operation should be followed on that <execInstance. I have also some confusion for that part. What is the meaning of updating <mgmtCmd>'s <execInstance> attribute ? How I am supposed to do that ? If I update it once, how do I update same attribute with the same value if I run same command multiple times.

As you see, I am really confused a lot. Can you explain briefly and give an obvious example how to do device management (ex. Firmware Update) on OneM2M ?

Answer 1

I agree, the management abstraction part of oneM2M can be hard to understand. I guess the most important points can be seen in TS-0001's figure "6.2.4.1.1-1: Device Management Architecture" and the accompanying text in that chapter:

• The device to be managed is a node (either an ASN, ADN, or MN).
• The device management functionality is implemented in the CSE's.
• The "business" part of device management (e.g. what devices should get an update) is an AE that triggers, for example, an update. This AE may also has the role of a Device Management System and therefore may also, during the onboarding phase of a device, create all the necessary <node>, <mgmtObj> specialisations etc. resources for that device.
• The Device Management functionality can be implemented by either oneM2M means, or utilise an underlying management protocol, such as TR-0069, OMA DM, etc. The bindings and mappings to those protocols are defined in separate specifications (e.g. TS-0005 or TS-0006).
• It is also possible to manage non-oneM2M devices, but for this a management proxy is needed on the connecting node that is acting as a management proxy to perform the (local) management as well as mapping those devices to oneM2M <node>'s.

For the second part (how does an AE execute a management command): as stated before, the <node> resource and all available management capabilities (as <mgmtObj> specialisations) are created during the on-boarding phase of the device discovery phase by the managing AE.

To trigger a management command (e.g. initiating a firmware update) the following applies:

• The AE UPDATES the according <mgmtCmd>, but only the execEnable attribute.
• The CSE then internally CREATES a new <execInstance> resource for that <mgmtCmd> and returns it instead(!) of the updated <mgmtCmd>. In reality, the execEnable attribute is not really changed in the resource, it only triggers the creation of the <execInstance>.
• The returned <execInstance> contains all necessary information about the management resource and acts as a "proxy" for the actual management by the AE.

Why is this so complicated? Remote management is not an immediate process. The device might be busy or even switched off, the operation might take some time etc. In order to move the (perhaps time and resource consuming) responsibility and work from the CSE to the AE, the <execInstance> resource helps to decouple this process from the actual management part of the CSE. One can see a lot of procedural status information, capabilities and constraints in the <execInstance> resource. Another advantage is that multiple AE's can access the same <mgmtCmd> in a managed and controlled way.

I hope this answers your questions.