onem2m

Actuator Control in oneM2M

I read documentation for making two way communication in OneM2M. I understand that one way of doing that is using subscription and notification system. Lets assume we have an example like the figure below. IN-AE (Smartphone) wants to open the light of ADN-AE2. Assume that registration and resource creations are already done and also ADN-AE-2 is already subscribed to the container of a light in ADN-AE-2.

As a result, oneM2M covers the part of how IN-AE sends the light control request and how ADN-AE-2 or ADN-AE-1 took the request that comes from IN-AE and execute it. But what if ADN-AE-2 cannot control the light and fail while controlling it. What should be the scenario ? The contentinstance is already created with the request sent by IN-AE.

1- Should ADN-AE-2 create another contentinstance that is previous state of the container

2- Should ADN-AE-2 remove the contentinstance that is not executed (then what about other subscribers that take the notification and execute it successfuly)

What should be the recommended way if the actuator cannot do the action ?

enter image description here

http://www.onem2m.org/tr-0034/procedures/actuator-switch-control

Solution

  • This is a general problem in asynchronous communication. What happens when the receiver never receives a command, or is just not able to execute it (for whatever reasons, for example it is busy doing other things or the request is outside certain parameters)?

    Both your options are valid, but won't work when the ADN is offline, so that the ADN-AE2 cannot perform the procedures. Also, even when the ADN is always online, both procedures have problems when there are more than one other AE that wants to control the ADN-AE2, or when the IN-AE is impatiently setting the desired state again and again. This often might result in race conditions.

    I would suggest to re-think the communication scheme between the two AE's and split the original Container into two: one Container for the target state, and another Container for the status state. The target Container is used by AE's, other than the ADN-AE2, to set a desired state. The ADN-AE2 is notified of the creation of a new ContentInstance and acts accordingly. It then creates a new ContentInstance in the state container that reflects the new internal state, and this will notify the IN-AE to reflect the change.

    The following drawing reflects an example resource structure for this pattern:

    AE ─┬─ Container_target ─── ContentInstances*   ◀═══ Container for desired state, set by other AEs
    │                                      
    └─ Container_state ─── ContentInstances*    ◀═══ Container for actual state, set only by this AE

    This is a common pattern in asynchronous communication when the connectivity between nodes is not always reliable, or when the outcome of a state-change request is not always guaranteed. The responsibility for executing requests lies with the ADN-AE2, the policy for how often to retry or react on failure lies with the IN-AE.