Store and forward of Notify messages for Client with UQ binding

[valensd-etc]

Hi,

I'm not sure if this should be posted in leshan or in the OMA LWM2M developers group. Please let me know and I will move it.

I have a Wakaama client connecting with UQ binding (to a Leshan server) because the cellular connection is turned off to save power. We want our client to implement a store and forward of notification messages when the network connection is turned off. Are there any recommendations on implementing this? Does the Leshan client have any implementation?

Will the server respond correctly (to the stored notification messages) when the client does its registration update and then starts sending the stored notification messages? As long as every notification message is sent with a sequential message ID my thought is the server should not have any problems?

Thanks,
Valens

[sbernard31]

I'm not sure if this should be posted in leshan or in the OMA LWM2M developers group

I will turn myself in captain obvious but the part strictly about the spec could have been posted on OMA LWM2M developers group. The part about Leshan is well placed here.

Anyway, I will try to answer to the OMA LWM2M spec question too.

We want our client to implement a store and forward of notification messages when the network connection is turned off. Are there any recommendations on implementing this?

The LWM2M specification define a way to store notifications when device is off line.

In the Server object (Id 1), there is a resource "Notification RW Storing When Disabled or Offline" (id 6) which is described as (§E.2):
"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."

To report those stored notifications, you can use JSON format (application/vnd.oma.lwm2m+json)
The specification say (§4.4) :
"Historical version of notifications are typically generated when “Notification Storing When Disabled or Offline” resource of LwM2M Server Object is set to true (see Appendix D.2) and when the Device comes on line after having been disabled for a period of time."

Here is an JSON example of the specificaiton (§4.4) :

{
   “bn”:“/72/“,
    “e”:[
         {"n":"1/2","v":22.4,"t":-5},
         {"n":"1/2","v":22.9,"t":-30},
         {"n":"1/2","v":24.1,"t":-50}
    ],
    "bt":25462634
}

At Leshan Server side you can get it, using ObserveResponse.getTimestampedLwM2mNode()
I have no idea if Wakaama support this.

Does the Leshan client have any implementation?

Leshan client does not support stored notification for now : #596.

Will the server respond correctly (to the stored notification messages) when the client does its registration update and then starts sending the stored notification messages?

You must know the protocol constraints :

1. UDP packet can be lost. (you could use CON message type to resolve this)
2. UDP does not ensure packet order.
3. Coap Observe can drop out-to-date notification.

See for more details : https://github.com/eclipse/leshan/wiki/F.A.Q.#all-questions-relative-to-lwm2m-observe

So, if you are using the stored notifications like defined above, this should be OK. If you store n values for the same resource and you send n notifications pretty much at the same time, you should be aware that some values could be dropped.

As long as every notification message is sent with a sequential message ID my thought is the server should not have any problems?

Leshan should behave as explained above.

[sbernard31]

Could we close this issue ?

[valensd-etc]

Yes I think for now it can be closed. Thanks Simon!