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.