Registration lifetime, update and send operations

[davidahoward]

Does the client need to do a registration update operation if a send operation occurs at an interval less than the registration lifetime?

Does the lifetime counter get reset because of a send operation?

For example, if the registration lifetime is set to 3600 seconds, and the client does a send operation every 300 seconds, would the client ever need to do a registration update operation? Why?

OMA-TS-LightweightM2M_Core-V1_1_1-20190617-A.pdf
OMA-TS-LightweightM2M_Transport-V1_1_1-20190617-A.pdf

[giuseppe-melis]

Hi David,
I'm pretty sure that I understand your question but let me point the use cases, because I managed the same doubt in the past.
I work mainly on LwM2M 1.0.2

the client registers to the server with lifetime 3600
...
the client sends reg update near 3500
...
after 1000, the server sends a READ/WRITE/EXEC/... to the client
the client doesn't receive the message due to offline (usually NAT block) and the undelivered message is stored in the queue of the server
...
at lifetime time, the client sends reg update (can be seen as "come back online")
the server detects the reg update and sends the messages from the queue (with a delay at application level...for some application is acceptable, for others not)
the max delay is the lifetime
[this is the normal behaviour, lets continue on the flow]
...
after 1000, the server sends a READ/WRITE/EXEC/... to the client
the client doesn't receive the message due to offline (usually NAT block) and the undelivered message is stored in the queue of the server
...
after 200 the client sends a notify to the server.
Can this notify be considered as "come back online"?

For what we understood in the past from the specs, the only way to detect the "online" status is the reg update.
if anyone can review my thoughts and give me a feedback, it would be great.

Sincerely, if also the notify would trigger the sending of the queue, I would be happy because I would reduce the max delay to the distance between the notifies
Since usually the applications send notifies more often than reg updates, this would help to reduce the delay between the sending of the message and its apply

does this use case match your question?

[sbernard31]

@giuseppe-melis I think @davidahoward talk about the new Send Operation from LWM2M v1.1 and you are talking about Observe/notify not exactly the same.

But more generally, I see 2 questions here :

1. Is Registration Update the only way to refresh registration ?
2. Using Queue mode, Is Registration Update the only way to trigger server to send "queued" requests ?

My understanding is :

1. Yes. LWM2M-v1.1.1@core§6-2 Client-Registration-Interface
2. Yes and more than that each "wake-up" should start by a Registration Update. (So you should not just send a notify without update before) LWM2M-v1.1.1@transport§Figure-6.5-2-Example-of-an-Information-Reporting-exchange-for-Queue-Mode

Why ?

1. I don't know ? Maybe because initially LWM2M Registation Interface is largely inspired by a draft of RFC9176 - CoRE Resource Directory ? (which will be a not so good reason as feature are really different)
   OR we can also consider that this brings better separation of concerns. All registration process is handled by Client Registration Interface. So maybe this simple/clearer design justifies the cost of sending an update request from time to time. Knowing that you can have very large Registration lifetime and Update Request is very small, I guess you will not optimize so much by avoiding it.

2. Pretty much same answer as for 1)... except that maybe there is most to save if your client wake-up very often to send notification (but if this is a very verbose client, saving an update is maybe not so important ?)
   In case of Queue Mode, if you're behind a NAT this also means that each time the device wake-up, it could have a new socket address and if server uses notify as event to send "queued" requests, it should update the registration to change the client socket address too (See Update registration on observe notification #391)

So at the end :

• EITHER, we have a simple way to manage registration like define in current specification.
• OR we could have a more "optimized" way which should be something like : "any data send by a client should refresh registration and eventually update its address if it changes" and is also a sign that client is awake. This will be at cost of more complexity and probably more WRITE access to Registration Store used at server side to persist registration. (as you will update registration much more)

(Note that for coap+tcp brings even more question around all of this : https://github.com/eclipse/leshan/wiki/CoAP-over-TCP)

[giuseppe-melis]

Thanks Simon,
very brilliant explanation and sorry for my misunderstanding

[sbernard31]

(Note that I'm not part of specification authors, so I maybe missed something)

sorry for my misunderstanding

No problem, I think your answer/question is totally complementary with the original one.

[davidahoward]

I'm not sure I understand 2.

2. Pretty much same answer as for 1)... except that maybe there is most to save if your client wake-up very often to send notification (but if this is a very verbose client, saving an update is maybe not so important ?)
   In case of Queue Mode, if you're behind a NAT this also means that each time the device wake-up, it could have a new socket address and if server uses notify as event to send "queued" requests, it should update the registration to change the client socket address too (See Update registration on observe notification #391)

Are you saying that the client waking up and sending NOTIFY/SEND to server won't work behind a NAT because the server doesn't get the socket address from the received packet?

[sbernard31]

Are you saying that the client waking up and sending NOTIFY/SEND to server won't work behind a NAT because the server doesn't get the socket address from the received packet?

This is not what I'm saying. I try to rephrase.

I understand the specification :

• as each wake-up should start by a "Registration Update",
• and requests are "dequeued" on "Registration Update".

I guess that :

• almost all server store client socket address in "registration",
• "Registration update" will update this client socket address in "registration",
• when you send request to a client you use "client socket address" store in "registration".

So if you dequeue on "Registration Update" all works as excepted.

Now, if you use "notify" as event "wake-up" event when you're behind a NAT , I just say that you should not forget that you should also probably update "client socket address" in "registration".

I don't say it's impossible technically, but at least for now I understand this is out of the spec : #391.

I imagine you can use "client socket address" from NOTIFY/SEND packet as destination for "queued request" without updating "client socket address" in "registration" but honestly that smell not so good design to me.

[sbernard31]

@davidahoward did you succeed to get more clarification about all of this maybe via other channel ?