Does ["notification Storing" when Server is Disabled] really works ?

[sbernard31]

Reading LWM2M-v1.2.1@core§Table: E.2-2 LwM2M Object: LwM2M Server Resource definitions

ID	Name	Operations	Description
4	Disable	E	If this Resource is executed, this LwM2M Server Object is disabled for a certain period defined in the Disabled Timeout Resource. After receiving "Execute" operation, LwM2M Client MUST send response of the operation and perform de-registration process, and underlying network connection between the Client and Server MUST be disconnected to disable the LwM2M Server account. After the above process, the LwM2M Client MUST NOT send any message to the Server and ignore all the messages from the LwM2M Server for the period.
5	Disable Timeout	RW	A period to disable the Server. After this period, the LwM2M Client MUST perform registration process to the Server. If this Resource is not set, a default timeout value is 86400 (1 day).
6	Notification Storing When Disabled or Offline	RW	If true, the LwM2M Client stores "Notify" operations to the LwM2M Server while the LwM2M Server account is disabled or the LwM2M Client is offline. After the LwM2M Server account is enabled or the LwM2M Client is online, the LwM2M Client reports the stored "Notify" operations to the Server. If false, the LwM2M Client discards all the "Notify" operations or temporarily disables the Observe function while the LwM2M Server is disabled or the LwM2M Client is offline. The default value is true. The maximum number of storing Notifications per Server is up to the implementation.

So I understand that "notification storing" with server disabled works like :

1. Server send an Observe Request.
2. Client answers with 2.05 Content response => observe relation is established for registration before disabling.
3. Server send Execute Request on /1/x/4.
4. (Client answers 2.04 Changed response.)
5. Client send De-registration request.
6. (Server answers with 2.02 Deleted response)
7. Client is off line for "Disable Timeout" seconds
8. Client store the notifications
9. Client send Register request.
10. Server answers with 2.01 created
11. Client send Notify 2.05 Content with timestamped value.

But reading the specification I understand that an observe relation is tied to 1 registration. so on de-Registration observation relation must be deleted and so last notify will just be ignored by the server. (This makes sense to not keep state for a deregistered client)

See LWM2M-v1.2.1@core§6.2. Client Registration Interface :

If the lifetime of a registration expires without receiving an update from the LwM2M Client, the LwM2M Server will consider it a de-registration:

• The LwM2M Server MUST remove the registration of that LwM2M Client and existing observations. ...

And LWM2M-v1.2.1@core§6.4.1. Observe Operation:

Until the LwM2M Client sends a new registration, the LwM2M Server expects the LwM2M Client to remember the observation requests. ...
...
...
Note: When a LwM2M Client deregisters, the LwM2M Server should assume past states are nullified including the previous observations.

[JaroslawLegierski]

From what I see, we can't use NOTIFY because device has deregistered, but maybe it could work with a direct SEND OPERATION when device is back online ?

[sbernard31]

From what I see, we can't use NOTIFY because device has deregistered, but maybe it could work with a direct SEND OPERATION when device is back online ?

As I understand the specification, a device can use SEND Operation on its own initiative.
"The "Send" operation is used by the LwM2M Client to send data to the LwM2M Server without explicit request by that Server."
(source : LWM2M-v1.2.1@core§6.4.6. Send Operation)

So nothing in the specification prevent a client to send a SEND request just after the REGISTER request and this SEND request can contains anything (which is accessible by the server).

So you could image that on disable, if Notification Storing When Disabled or Offline is true, your client should :

1. Deregister, (behavior defined by the specification : all device should behave like this)
2. Remove all observe relations, (behavior defined by the specification : all device should behave like this)
3. Transform those observe relations in something which will store data somewhere following same observation rules, (behavior does not violate the specification but will be specific to your client)
4. Wait during Disable Timeout seconds (behavior defined by the specification : all device should behave like this)
5. Register (behavior defined by the specification : all device should behave like this)
6. Send all stored data. (behavior does not violate the specification but will be specific to your client)

This could work but the 3. step sounds a bit strange.

Another solution could be to create a new Send Controller object (and eventually register it to LWM2M registry) where a LWM2M sever could define/set Send behavior but this begins to be a bit out of topic.

[mkgillmore]

"Notification Storing" applies to the SEND operation initiated from the CLIENT. Likely a configuration design decision by implementers. @lodup29 Please comment further

[lodup29]

My understanding is that stored notifications are indeed tied to an active registration and apply when the client is offline or the LwM2M Server account is disabled though access control. Stored notifications should not apply after a de-registration.

As for storing pending SEND OPERATION, I believe that the first step would be to statute on #567 as stored SEND should be timestamped. If this is allowed, given the nature of a SEND, I believe it would make sense to leave the behaviour to the implementation, and not tie stored send behaviour to the value of resource 6.

[sbernard31]

@lodup29

Note this issue is about :

• "notification Storing" when Server is disabled (I think this one doesn't work as currently described in specification)
• NOT "notification Storing" when Server is offline (I think this one works)

Stored notifications should not apply after a de-registration.

I agree.

So the problem is that resource 1/x/4 says "LwM2M Client MUST send response of the operation and perform de-registration process", and what is describe for resource 1/x/6 can not works :

f true, the LwM2M Client stores "Notify" operations to the LwM2M Server while the LwM2M Server account is disabled or the LwM2M Client is offline. After the LwM2M Server account is enabled or the LwM2M Client is online, the LwM2M Client reports the stored "Notify" operations to the Server. If false, the LwM2M Client discards all the "Notify" operations or temporarily disables the Observe function while the LwM2M Server is disabled or the LwM2M Client is offline. The default value is true. The maximum number of storing Notifications per Server is up to the implementation.

[sbernard31]

As for storing pending SEND OPERATION, I believe that the first step would be to statute on #567 as stored SEND should be timestamped.

This #538 (comment) seems to say this is allowed but official answer from OMA would be appreciated.

(Note that currently on Leshan, we support timestamp value in SEND response, because we get that answer ☝️ + community ask for it)

If this is allowed, given the nature of a SEND, I believe it would make sense to leave the behaviour to the implementation, and not tie stored send behaviour to the value of resource 6.

I agree.
But maybe we could have an optional dedicated object to control/configure SEND operation.
(This is a bit out of topic so if idea makes sense, probably better to create a new issue)

[svdwalt007]

Analysis: Normative Contradiction — Requires Distinguishing Protocol vs Application Observations

This is a genuine normative contradiction. The resolution requires distinguishing two concepts:

1. Protocol-level observation (CoAP Observe token + message exchange): Destroyed on de-registration, as stated in the spec. These are tied to the CoAP layer and the registration's communication context.

2. Application-level observation configuration (Write-Attributes pmin/pmax/gt/lt/st values): These represent the server's intent to observe resources and should persist across registration cycles in the client's persistent state.

When Notification Storing (/1/x/6) is true and the server is disabled:

• The client de-registers (protocol-level observations are cancelled)
• The client retains the Write-Attributes configuration in persistent storage
• The client continues evaluating notification conditions internally and buffers matching values
• On re-registration, the server re-establishes protocol-level observations, and the client delivers buffered notifications

The key spec text that needs amendment: "When a LwM2M Client deregisters...past states are nullified including previous observations." This statement in the de-registration section needs a carve-out: "...except when Notification Storing When Disabled/Offline (/1/x/6) is true, in which case the client retains Write-Attributes configurations and buffers notifications for delivery upon re-registration."

This distinction between protocol-level and application-level observation state is critical for v1.3 clarification. Without it, Notification Storing is unimplementable as designed.

---

This comment was automated using the new Best-LwM2M-Agentic-Skills that Sean van der Walt has developed (available for your use). Feedback on these skills' use would be highly appreciated.