Registration validity timespan after Lifetime replacement.

[krwc]

The following content is referring to the OMA-TS-LightweightM2M-V1_0-20170113.

During registration, LwM2M Client informs the LwM2M Server about its
Lifetime, and before "Lifetime" seconds expires, the registration is valid.

Specification however, does not discuss how setting Lifetime at arbitrary point in time
affects the timespan of LwM2M Client's registration validity. Namely, it is not clear
when exactly the LwM2M Server should consider Client's registration as expired.

For example:

1. LwM2M Server registration Lifetime is 86400 (and it is send during Register by the Client).
2. LwM2M Server at some point in time (timestamp), say t, performs Write on its Instance,
   setting lifetime to 1.

Below an image to make this crystal clear:

            t (replacement of Lifetime)
            |
-+----------+-+------------------------------------------+----------------->
 |            |                                          |
Update       t+1                              At this point old registration (with
                                              Lifetime 86400) would be expired.

Now, we have to determine at which point the registration in fact expires:
a) Would it expire after t + 1, if the Client haven't send the Update?
b) Would it expire after old expiration deadline?
c) Something else happens?

[fdur]

From my point of view: response a

[boaks]

May understanding of the lifetime is, that the client informs the server of his lifetime.
If the server writes an new lifetime, then the client has not only to response to that write,
it MUST also explizitly agree on that new value by sending a "5.3.2 Update" with the new lifetime.
So I would prefer b).

[krwc]

Thanks @fdur and @boaks for your input. However, since you both seem to have different views on the subject I'd still like to wait for the official committee answer. :-)

[jpradocueva]

DM WG to provide a clarification.

[boaks]

For the case, when more LWM2M servers are considered, the lifetime may be written by an other LWM2M server. Therefore I think, the client MUST sent his update registration to the server and therefore this establishes the new lifetime at the server. Wire this to a special resource in the data mangement interface will make it more complex.

[jpradocueva]

Section 5.3 clearly describes , the following

Feedback provided by Device Management Working Group.
"If the LwM2M Server or the LeM2M Client set a value to the Lifetime Resource of the server object instance, this value becomes the new lifetime of the Registration Session"

In the example provided as soon as "t" is set by LwM2M server then client should use this as its new set limit for lifetime timer..

Further sequences use "t" for any actions

TICKET TO BE CLOSED

[boaks]

I still belief, that a server will adjust his "session lifetime" only by messages from the registration interface. Anything else (wiring registration interface with device management messages) will make implementations complex!

And I don't know, how the message flow should look like, when two LWM2M servers are connected to the same device and one LWM2M Server update the lifetime of the other.

[dnav]

Note that if the lifetime resource value is modified, the Client must send a Registration Update message to the Server as per section 5.3.2:

When any of the parameters listed in Table 9 changes, the LwM2M Client MUST send an “Update” operation to the LwM2M Server.

Table 9:

Parameter	Required
Lifetime	No
Binding Mode	No
SMS Number	No
Objects and Object Instances	No

[boaks]

Hi David,

Note that if the lifetime resource value is modified, the Client must send a Registration Update message to the Server as per section 5.3.2:

your absolutely right! I wrote this also above. And therefore I think, the server should use that "register update" to update the used lifetime and not "couple/wire up" the data management interface with the registration interface.

[dnav]

Sorry, I don't get your point.
Server wants the Client lifetime to be modified.
1/ Server sends a Write /1/x/1 [new value]
2/ Client acks the Write
3/ Client sends a Registration Update to /{location}?lt=[new value]
4/ Server and Client update their internal expiration date for the session to now + [new value]

[boaks]

As far as I understand the above clarification:

1/ Server sends a Write /1/x/1 [new value]
2/ Client acks the Write
3/ Server and Client update their internal expiration date for the session to now + [new value]
4/ Client sends a Registration Update to /{location}?lt=[new value]

[boaks]

Sorry, I don't get your point.

My point was, that the original question above, explicitly states:

a) Would it expire after t + 1, if the Client haven't send the Update?
b) Would it expire after old expiration deadline?

This would therefore either be

a)
3/ Server and Client update their internal expiration date for the session to now + [new value]
4/ Client sends a Registration Update to /{location}?lt=[new value]

or

b)
3/ Client sends a Registration Update to /{location}?lt=[new value]
4/ Server and Client update their internal expiration date for the session to now + [new value]

So, if the TS says:

"If the LwM2M Server or the LeM2M Client set a value to the Lifetime Resource of the server object instance, this value becomes the new lifetime of the Registration Session"

Then a) is chosen and therefore the sequence from @dnav (that I also agree, to be the right one) is changed to the sequence I specified above (step 3 and 4 exchanged).

with a), I don't understand, how multiple LWM2M server should implement that, if one server writes to the lifetime of the other.

[dnav]

The TS states that:

• The lifetime of a LwM2M session is the value of the lt parameter of the Registration message. It can be modified by a Registration Update message.
• The Client gets the value of lt from the lifetime resource of the Server Object instance.

Any other point is implementation dependant.