Clarification on Less Than and Greater Than attributes

[kFYatek]

In the current (OMA-TS-LightweightM2M-V1_0-20170126-D) revision of the 1.0 TS, the "Greater Than" attribute is defined (in section 1.2, Table 4) as follows:

This “Greater Than” Attribute defines a threshold high value. When this Attributes is present, the LwM2M Client MUST notify the Server each time the Observed Resource value crosses the “Greater Than” Attribute value with respect to pmin parameter.

The use of the word "crosses" is somewhat ambiguous and hard to understand. Different existing implementations implement semantics of this Attribute in different ways:

• Wakaama sends a notification only if the current value is "on the other side" of the threshold than the previously sent one. If both Greater Than and Less Than Attributes are set, the value needs to cross either of them for the notification to be sent.
• AwaLWM2M, similarly sends a notification only if the current value is "on the other side" of the threshold than the previously sent one, but the value needs to cross both Greater Than and Less Than thresholds for the notification to be sent if both are set.
• mbed Client treats those Attributes as "filters" - the server is notified of all changes if the value to be sent is greater than gt or less than lt.

mbed Client's behaviour is consistent with wording used in very old revisions of the spec, such as OMA-TS-LightweightM2M-V1_0-20141126-C ("When present, the LWM2M Client SHOULD notify its value when the value is above the value specified in parameter").

The Attributes in LwM2M seem to be related to the mechanism introduced in draft-ietf-core-interfaces and currently maintained in draft-ietf-core-dynlink. Both of these documents are referenced in the LwM2M 1.0 TS draft.

draft-ietf-core-interfaces-01, an old revision back from 2013, defines the gt and lt attributes in a way consistent with the wording used in he aforementioned 20141126-C revision and with the behaviour of mbed Client. It is listed as a normative reference [CoRE_Interface] and briefly mentioned in section 4.4 (Write Attributes):

Note: How to indicate the Attributes in the message payload is specified in [CoRE_Interface].

draft-ietf-core-dynlink-01, the current draft revision, is listed as an informative reference [DYNAMIC LINK], but never otherwise mentioned in the TS. It describes the gt and lt attributes in a way mostly consistent with Wakaama's interpretation, but seems to suggest that a notification will only be sent when the value changes from something below gt to something above gt, not the other way round.

I focused on the gt Attribute, because its symmetry with lt is well understood.

Which of these interpretations is correct for LwM2M? I believe it should be described in a more detailed and unambiguous way in the TS.

Here I am leaving some of my thoughts about each of the interpretations for consideration:

• AwaLWM2M's implementation makes very little sense and seems broken. EDIT: Although, on a second thought, the behaviour when both lt and gt are set seems consistent with draft-ietf-core-dynlink-01.
• Wakaama's implementation makes lt and gt not only symmetrical, but essentially identical - there is no practical difference between setting lt ONLY or gt ONLY, they both have exactly the same semantics in such case. Thus, it doesn't intuitively seem correct.
• Adhering to draft-ietf-core-dynlink-01 would be consistent, but since Notify messages are allowed to be Non-Confirmable, it is actually pretty likely that a probably important message such as crossing the threshold will not be delivered. RFC 7641 allow a great degree of freedom for implementations to choose when to deliver notifications as confirmable or non-confirmable messages. Some workaround would be to include a requirement in the LwM2M spec such as "when Greater Than or Less Than Attribute is set, notifications sent over UDP transport MUST be sent as confirmable messages".
• The old wording from the 2014 revision is also consistent and makes it reasonably safe to send notifications as non-confirmable messages at all times. However, it introduces a possibly unwanted effect that when the threshold is crossed, the Server will be stormed with notifications until the value drops below that threshold.

Also, this requirement mentioned just under Table 4 in section 1.2:

Note: the following rules MUST be respected (“lt” value + 2*“st” values <“gt” value)

does not seem to make much sense for some of the interpretations.

[ThGarnier]

Hello, many thanks for your deep analysis.
I will try to provide a "short" :-) clarification on this topic :

1. "The use of the word "crosses" is somewhat ambiguous and hard to understand. " ; not really ambiguous in fact : common sense crossing means it is in both sense right ? otherwise it should be specified, in which sense is the limitation. So definitively (maybe wrongly, it's another story) it is the intention in LwM2M specification. Regarding that point (lt, gt, stp), there is a "famous" :-) debate during the Dusseldorf LwM2M Plug Test on Jan 2015 (that's why the wording of your 2014 reference is different) and it is the agreed consensus which is present in the spec.
2. Yes, some notifications could be not delivered (according to lt,gt,st ..parameters) if some oscillations take place; the formula is here for avoiding to storm the Server.

So according to your analysis and thanks for this, it seems current implementations you mentionned are not in line with the (2015/2016) spec.
Thierry

[kFYatek]

Hi, and thanks for your response.

So according to your analysis and thanks for this, it seems current implementations you mentionned are not in line with the (2015/2016) spec.

So what is the expected behaviour? Should it be as described in draft-ietf-core-dynlink-01?

[jpradocueva]

DM WG to review this Issue based on Pittsburgh feedback.

[jpradocueva]

Feedback provided by DM Working Group.
Section 5.1.2 clearly states this in a table

For gt

"Notes : This "Greater Than" Attribute defines a threshold high value. When this Attributes is present, the LwM2M client MUST notify the server each time the Observed Resource value crosses the "Greater Than" Attribute value with respect to pmin parameter"

NOTE THE WORD EACH TIME

[kFYatek]

Please excuse me, but this does not seem to resolve anything for me. "Each time" was never a problem, the word "crosses" was. Specifically, whether there is some directionality to it.

Please explicitly clarify the following - should a notification be sent for each of the following cases?

1. the only set attribute is lt=10, the previous value was 4, the new value is 18
2. the only set attribute is gt=10, the previous value was 4, the new value is 18
3. the only set attribute is lt=10, the previous value was 18, the new value is 4
4. the only set attribute is gt=10, the previous value was 18, the new value is 4

If the answer is "all of them (1, 2, 3, 4)", then what's the point of calling the attributes "less than" and "greater than" as there is essentially no semantic difference between the two?

The other plausible answer is "2 and 3", which would be consistent with the current drafts of draft-ietf-core-dynlink.

Which answer is right in the end?

[yonpak]

I think it would be beneficial to add examples for better clarity.

My answer would be 2 and 3 based on my understanding of the 5.1.2 statement above.

What is not very clear to me is if LWM2M "gt" is actaully aligned with "gth" in draft-ietf-core-dynlink.
How I interpret the 5.1.2 statement is that every time new value is set is greater than the "gt" value, client will notify to the server respecting the pmin parameter.
However, my interpretation does not seem to align with some description of "gth" description in draft-ietf-core-dynlink.
"If the value continues to rise, no new state synchronizations are generated as a result of gth."

[kFYatek]

The common definition of the word "crosses" is "To go from one side of (something) to the other" (via Wiktionary), which strongly suggests behaviour as described for "gth" in draft-ietf-core-dynlink.

But to be honest, I'm still not sure what is the official understanding of the DM WG even though this ticket is closed.

[jpradocueva]

DM has provided the following comment after the need for further clarification after closing the issue.

lt and gt must be considered as thresholds. If the value goes from one side to the other side of gt or lt, a notification should be sent.

ex 1
lt = 2 , gt = 9, stp = 2
old value = 4 , new value = 7, send notification (due to step)
old value = 9, new value = 10, send notification (due to gt)
old value = 10, new value = 8, send notification (due to gt and by step)
old value = 7, new value = 4, send notification ( due to cross in step)

ex 2
lt = 2 or gt=2, stp = 4
old value = 4, new value = 9, send notification (due to step cross)
old value = 3, new value = 1, send notification (due to lt or gt value crosses)
old value = 1, new value = 3, send notification (due to lt or gt value crosses)

The Note just above table 4 title is only applicable when both lt & gt are defined
"Note: the following rules MUST be respected (“lt” value + 2*“st” values <“gt” value)
Table 4: class Attributes"

We agree the names are confusing. Note that draft-ietf-core-dynlink should not be considered: it is not a reference document for LwM2M TS. Moreover, this is still a draft and was started long after LwM2M TS.

[kFYatek]

So, to sum things up:

• Putting the '“lt” value + 2*“st” values <“gt” value' requirement aside, the lt and gt attributes are completely equivalent and there is no semantic difference whatsoever between the two.
• Considering only the lt/gt/st Attributes, the condition for sending a notification is "lt triggered OR gt triggered OR st triggered".

Is the above correct?

[kFYatek]

Also, this example of yours:

old value = 10, new value = 8, send notification (due to gt and not by step as step is 2 and not crossed)

seems to be in direct contradiction to what is explicitly stated in the specification. To quote Table 4:

This “Step” Attribute defines a minimum change value between two notifications. When this Attribute is present, the change value condition will occur when the value variation since the last notification of the Observed Resource, is greater or equal to the “Step” Attribute value.

so it seems obvious that the difference of 2 when the Step attribute is set to 2 shall trigger notification.

[jpradocueva]

Based on the above reply, DM indicates:

• Yes, to your first response.
• To you second response. Good catch and we have updated the example accordingly.

[kFYatek]

OK, thank you very much for your clarification. Now everything is clear to me.