Effect of attributes on different assignment levels

[kFYatek]

This is an issue that generated disagreement during the 2019 TestFest in Korea. I believe it applies to both the 1.0 and 1.1 specifications.

Consider the following situation:

1. The DM server executes a Write-Attributes operation on a Resource Path (e.g. /19/0/0), setting the pmin and pmax attributes.
2. The DM server initiates an Observation on the whole Object Instance (e.g. /19/0).
3. Let's assume that the contents of the observed Instance does not change through any other means than the same server actually writing the values.

Should any notifications actually be sent in this case? I.e., should the pmax attribute set on the Resource be respected when the observation is issued on the whole Object Instance? How would that change if pmin and pmax attributes would also be set on the Object Instance level, as well as on the Resource level?

[asoloway64]

The simple answer to this question "Should any notifications actually be sent in this case?" is no. Reporting criteria can be attached to a resource when that reporting criteria is assigned to the object instance. Reporting criteria assigned to a resource cannot be attached to an object instance. Only those reporting criteria assigned to the observation level will be evaluated when determining whether to generate a notification report.

[asoloway64]

For your follow-on conditions of setting the pmin and pmax on the object instance level, yes, a notification would be generated. That is completely independent of the attributes set at the resource level.

[kFYatek]

The test case during which this issue has been discovered: LightweightM2M-1.0-int-1900 and LightweightM2M-1.1-int-1900
Some of the server teams issued the Observe command on the whole Object Instance (/19/0), so just lowering pmin and pmax attributes was not enough to trigger the notification, the value had to actually change.

[hannestschofenig]

Can you send me an updated, corrected version of the test case description?

[sbernard31]

We get a pretty much similar question on Wakaama project : eclipse-wakaama/wakaama#636.

And so I fall on this old issue.

I must confess that I'm confused by the answer.

The simple answer to this question "Should any notifications actually be sent in this case?" is no. Reporting criteria can be attached to a resource when that reporting criteria is assigned to the object instance. Reporting criteria assigned to a resource cannot be attached to an object instance. Only those reporting criteria assigned to the observation level will be evaluated when determining whether to generate a notification report.

When a Observation relation is established at object instance, if 1 of its resources changes then a notification is send.

resource changed --> object instance changed --> object instance notification sent.

With reporting criteria this could looks like :

resource changed --> apply reporting criteria at resource level --> object instance changed --> object instance notification sent.

(At least some have understood it like that : eclipse-wakaama/wakaama#636 (comment))

With your answer I understand the reporting criteria is only used when the attachment level matches observation level.
I mean if the reporting criteria is attached to resource level it is only applied to observation relation at resource level.
So this is more :

resource changed --> object instance changed --> apply criteria at object instance level --> object instance notification sent.

As all reporting criteria can only be attached to resource (See Table: 5.1.2.-2 class Attributes)

That means that attribute will only be used for Observation established at Resource level ?
So pmin/pmax/greater/ ... can not be used on object or object instance observe relation?

For your follow-on conditions of setting the pmin and pmax on the object instance level, yes, a notification would be generated. That is completely independent of the attributes set at the resource level.

This time I'm confused because it seems that you are using the assignation level as it was an attachment level (the level where the criteria is applied)

I probably totally missed something but could you clarify this ?

[dnav]

Disclaimer: This is my personal view, not an OMA one as the matter was not yet discussed in an OMA WG meeting.

So this is more :

resource changed --> object instance changed --> apply criteria at object instance level --> object instance notification sent.

We have the same understanding.

As all reporting criteria can only be attached to resource (See Table: 5.1.2.-2 class Attributes)

That means that attribute will only be used for Observation established at Resource level ?
So pmin/pmax/greater/ ... can not be used on object or object instance observe relation?

Actually, there are two "types" of attributes:

1. gt, lt, step, and egde which can be attached only at the Resource or Resource Instance level
2. pmin, pmax, epmin, epmax, con, and hqmax which can be attached at any level

You can use the second "type" of attributes for Observations at the Object or Object instance level. I think this is what you missed.

In the original question, you have:

19
 +- 0
     +- 0   pmin=10, pmax =60
     +- 1

An Observation on /19/0 does not have any attribute to consider.

In the follow-up question, you have:

19
 +- 0       pmin=30
     +- 0   pmin=10, pmax =60
     +- 1

An Observation on /19/0 must consider a 30 seconds minimum period.

Regards,

[sbernard31]

@dnav thx very much for the answer 🙏

Actually, there are two "types" of attributes:

gt, lt, step, and egde which can be attached only at the Resource or Resource Instance level
pmin, pmax, epmin, epmax, con, and hqmax which can be attached at any level

You can use the second "type" of attributes for Observations at the Object or Object instance level. I think this is what you missed.

I maybe missed that but I didn't find any version of the specification where pmin, pmax, epmin, epmax, con, and hqmax can be attached to any level :

• LWM2M-v1.2@core§Table: 5.1.2.-2 class Attributes
• LWM2M-v1.1.1@core§Table: 5.1.2.-2 class Attributes
• LWM2M-v.1.0.2§Table 4: class Attributes

Unless there is a confusion between assignability and attachment ?
For now, I understand that :

• observation level : is the level (object/object instance / ...) where the notification relationship is established.
• assignation level : is the level (object/object instance / ...) on which the write attribute is done.
• attachment level : is the level (object/object instance / ...) on which the attribute is really applied.

Do you understand it in a same way ?

[dnav]

I'm so used to these tables that I totally forgot about this "attachment" column. Now I understand your confusion. And I'm no longer sure of the correct intent.

Let's wait for the OMA WG clarification...

[sbernard31]

Not directly link but maybe it could help to think about that

In LWM2M-v1.1@core§6.4.4. Observe-Composite Operation, the description of Observe-Composite Operation says :

The Class Attributes for each resource that is observed through the "Observe-Composite" operation are individually configured by the LwM2M server using the "Write-Attribute". Each resource can have multiple observe conditions attached. If any of the conditions attached to one or more resources under observation meets the notification criteria a notify will be generated by the LwM2M client, which will include the value for each of the resources listed in the "Observe-Composite" operation. Hence, the resources that have not met the notify condition will still be included in the notification message.

So, here this is more :

resource changed --> apply reporting criteria at resource level --> "composite object" changed --> "composite object" notification sent. 

It looks like how @tuve understand Write Attribute with NONE composite observation. (See eclipse-wakaama/wakaama#636 (comment))
I resume it above like :

resource changed --> apply reporting criteria at resource level --> object instance changed --> object instance notification sent.

[sbernard31]

@hannestschofenig, I don't get why this is closed.

Could you clarify this point ? or give a link to this clarification ? 🙏

[kFYatek]

@sbernard31 The latest (1.2) spec says in section 6.4.2 that:

The "Notify" operation is sent from the LwM2M Client to the LwM2M Server during a valid observation on an Object, Object Instance or Resource. The "Notify" operation MUST be sent when all conditions (i.e. Minimum Period, Maximum Period, Greater Than, Less Than, Step) are met. Those conditions are either "Observation Attributes" sent as parameters or attributes attached at the level of the "Observe" operation.

This (but this is just my personal opinion, not approved by the working group at the moment) seems to strongly suggest that all the attributes below the level for which the Observe operation is issued shall be ignored.

[sbernard31]

Some news about how we decide to implement write attributes behavior on classic observe (ObserveComposite not yet implemented) in Leshan 2.x (LWM2M v1.1.x) :

We chose to implement :

resource changed --> object instance changed --> apply criteria at object instance level --> object instance notification sent.

Because :

• far most easier to implement
• match @asoloway64's comment : Effect of attributes on different assignment levels #478 (comment)
• match @dnav's comment: Effect of attributes on different assignment levels #478 (comment)
• match @kFYatek's comment : Effect of attributes on different assignment levels #478 (comment)

Confusion about :

That means that attribute will only be used for Observation established at Resource level ?
So pmin/pmax/greater/ ... can not be used on object or object instance observe relation?

For your follow-on conditions of setting the pmin and pmax on the object instance level, yes, a notification would be generated. That is completely independent of the attributes set at the resource level.

This time I'm confused because it seems that you are using the assignation level as it was an attachment level (the level where > the criteria is applied)

☝️ is solved by #539 (comment)