Disable queue mode by sending Update Operation

[ezhaboy]

• Name, version and date of the document:

  • OMA-TS-LightweightM2M_Core-V1_1_1-20190617-A
  • OMA-TS-LightweightM2M_Transport-V1_1_1-20190617-A

• Section of the document:

  • OMA-TS-LightweightM2M_Core-V1_1_1-20190617-A: 6.2.2. Update Operation
  • OMA-TS-LightweightM2M_Transport-V1_1_1-20190617-A: 6.4.3. Registration Interface

6.2.2. Update Operation When any of the parameters listed in Table: 6.2.2.-1 Update Parameters changes, the LwM2M Client MUST send an "Update" operation to the LwM2M Server. Parameters include Lifetime, Binding Mode, SMS Number, Objects and Object Instances.

6.4.3. Registration Interface Table: 6.4.3.-1 Operation to Method and URI Mapping (Registration Interface) /{location}?lt={Lifetime}&b={binding}&Q&sms={MSISDN}

Question:

• Is it allowed that LwM2M Client sends update operation to change its queue mode behavior?
• If yes, can LwM2M Client do like this:
  • /rd?ep=ep0&lt=3600&lwm2m=1.1&b=U&Q
  • /{location}?Q=false

[sbernard31]

I didn't know the LWM2M 1.1 so much but I have a good knowledge of the v1.0.x Reading the LWM2M 1.1 specification, I didn't understand that Q=false is allowed.

I'm really surprised by the change about binding between v1.0 and v1.1 :thinking:

In v1.0, that is easy.

The binding values are : U, UQ, S, SQ, US or UQS. This value should be used for register request : /rd?ep={Endpoint Client Name}&lt={Lifetime}&sms={MSISDN}&lwm2m={version}&b={binding} and for update request: /{location}?lt={Lifetime}&sms={MSISDN}&b={binding} and for resource Binding (7) of object Server(1) : This Resource defines the transport binding configured for the LwM2MClient.

If you change the binding removing Queue (eg. change from UQ to U), you just send an update request with the new binding value U.

In v1.1, it seems impossible...

...because Q mode is a separated parameter in register and update request. It seems to me this breaks compatibility with the v1.0 for not so much benefits ? :thinking: I'm not sure but it seems to me that in the resource /1/0/7 Q is considered as a possible part of the binding value (e.g. UQ or UTQ, or USQ ...) meaning there is a kind of inconsistency between this resource and the binding parameter of register and update request.

So my guess :

• either the &Q is a typo or mistake and should be fixed in the specification and there is no issue. (That I really hope :crossed_fingers:)
• or you can just not be aware about adding or removing Q mode, you have a kind of inconsistency between request and /1/0/7 resources and compatibility if broken between v1.0 and v1.1.
• (or I missed something :sweat_smile:)

[erimancer]

son: U, UQ, S, SQ, US o UQS. Este valor debe utilizarse para la solicitud de registro : /rd?ep={Endpoint Client Name}&lt={Lifetime}&sms={MSISDN}&lwm2m={version}&b={binding} y para la solicitud de actualización : /{location}?lt={Lifetime}&sms={MSISDN}&b={binding} y para el enlace de recursos (7) del servidor de objetos (1) : este recurso define el enlace de transporte configurado para el LwM2MClient.

Si cambia la cola de eliminación

[sbernard31]

@erimancer, :uk: version ?

[erimancer]

registro) / {location}? Lt = {Lifetime} & b = {vinculante} & Q & sms = {MSISDN}

[erimancer]

• [ ]

registro) / {ubicación}? Lt = {Lifetime} & b = {vinculante} & Q & sms =

• [x] {MSISDN}

[dnav]

We discussed this issue in the OMA DMSE group.

In LwM2M 1.1, the Q mode was made independant of the Binding Mode. As the LwM2M version is part of the registration payload, there are no compatibility issues.

It is indeed true that a LwM2M Client which declared to be in Q mode during its registration, can not indicate to the LwM2M Server that it is no longer in Q mode. We did not have an usecase for this.

Regarding the Binding Mode Resource of the Server Object (/1/n/7), the description states:

The possible values are those listed in the LwM2M Core Specification.

In LwM2M 1.1, the possible values are the one from the Table: 6.2.1.2.-1 Behaviour with Current Transport Bindings: U, T, S, or N.

Q is not a possible part of the binding value.

[sbernard31]

In LwM2M 1.1, the Q mode was made independant of the Binding Mode. As the LwM2M version is part of the registration payload, there are no compatibility issues.

It sounds that with this rule everything can change and this is consider as compatible as long as the device tell the version at register time. :thinking:

By the way,

1. at bootstrap time the device doesn't give the lwm2mversion in bootstrap request (out of topic but I still don't get why bootstrap request does not looks more like register request)
2. binding resource(/1/?/7) is mandatory.

So if you want to support both device (LWM2M 1.0 and 1.1), to be able to write a server object using queue mode, bootstrap server MUST do a discover before, right ?

So "compatible", but complicated :confused:

It is indeed true that a LwM2M Client which declared to be in Q mode during its registration, can not indicate to the LwM2M Server that it is no longer in Q mode. We did not have an usecase for this.

~Is there a use case for the opposite ? I mean why update request contain Q parameter ?~

In LwM2M 1.1, the possible values are the one from the Table: 6.2.1.2.-1 Behaviour with Current Transport Bindings: U, T, S, or N. Q is not a possible part of the binding value.

So this means that a server can not know anymore if a device is using or not queue mode by reading Server Object anymore ? (Not sure this was really useful) Or set/unset queue mode on the device just by writing an object resource. (This sounds more useful especially at bootstrap time ) Correct ?

[dnav]

My assumption is that the device controls the usage of queue mode, not the LwM2M Server nor the LwM2M Bootstrap Server.

If the device is not designed to support Queue mode, it won't be able to fulfill the LwM2M Server command anyway.

If the LwM2M Server needs a Queue mode able device to stay online, it can modify temporarily the lifetime value or send each operation in less than MAX_TRANSMIT_WAIT seconds.

[sbernard31]

My assumption is that the device controls the usage of queue mode, not the LwM2M Server nor the LwM2M Bootstrap Server.

I can image use cases where server will change network configuration (e.g. APN) and so maybe change devices IP environment from dynamic IP (e.g. IPv4 with Nat) to static IP (e.g. IPv6) in this case it could make sense to change the QueueMode setting too.

In a general way, expecting that a device management server is able to set how the device should behave sounds not so strange.

If the device is not designed to support Queue mode, it won't be able to fulfill the LwM2M Server command anyway.

Of course, but why talking about those devices ? Or you meant that there is no device which support both, I don't get what is your point here ?

If the LwM2M Server needs a Queue mode able device to stay online, it can modify temporarily the lifetime value or send each operation in less than MAX_TRANSMIT_WAIT seconds

As I said before, maybe we can imagine not so temporary usage. Reducing lifetime or sending request before MAX_TRANSMIT_WAIT will increase traffic drastically, this sounds not to be a good replacement for "stop to use QueueMode" at least for some use cases.

[sbernard31]

My feeling is that maybe this change was mainly driven by avoiding to increase too much "binding combinatory" and maybe some side effect was not seen.

Side effects :

1. Device is not able to say it pass from Q to not Q (and vice-versa) using an update request. (feature removed) ~(Strangely, the opposite is still possible :thinking: )~
2. Bootstrap server and server are not able to change Q mode anymore. (feature removed)
3. This makes bootstrap session more complicate because bootstrap server need to know LWM2M version(or object version) to write a very common object Server object. (to avoid to write incompatible value for /1/?/7, e.g. to not write UQ on 1.1 devices)

[dnav]

Maybe ;)

If memory serves, Q mode was designed for devices that may be disconnected for long period of time because of power cycles. This is why I wrote the usage of queue mode is determined by the device.

in your example, changing the network configuration and then the device IP address would require a new Registration anyway.

Note that passing from not Q to Q using an update request is not possible in 1.1 as the Queue mode is not in the list of Registration Update parameters.

[sbernard31]

Note that passing from not Q to Q using an update request is not possible in 1.1 as the Queue mode is not in the list of Registration Update parameters

Oops :sweat_smile:, you're right about update and Q mode, I was misled by my knowledge of LWM2M 1.0 and the question above :point_up:. Thanks to correct me :pray: (I updated https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/490#issuecomment-706995813)

in your example, changing the network configuration and then the device IP address would require a new Registration anyway.

This is new in LWM2M 1.1 :scream:. I will open an issue to discuss about this. In fact the specification says : "When a new security context is created (e.g. TLS/DTLS), the Client MUST register again to the LwM2M Server." So depending what means "security context" or at least with connectionID you can change IP without doing a new registration. I'm currently look at LWM2M 1.1 deeper as we begin to implement it, so I will probably be painful in following month :grin:.

If memory serves, Q mode was designed for devices that may be disconnected for long period of time because of power cycles. This is why I wrote the usage of queue mode is determined by the device.

In our experience at SierraWireless, the main usage is dynamic IP environment support. (e.g. NAT) That was also one use case defined in LWM2M 1.0 (§8.2.1Firewall/NAT) : "Any LwM2MClients behind a NAT can use Queued Mode. There are other mechanisms to transverse a NAT, however theyare out of scope for the LwM2MEnabler."

[sbernard31]

And thx :pray: to take time to reply !

[ezhaboy]

Thx @dnav and @sbernard31.

May I summarize my understanding:

• LwM2M Bootstrap Server should not write 'Q' to /1/x/7 during bootstrap, if version of LwM2M Client is 1.1.
• Server implementation of LwM2M 1.1 version may discard 'Q' from binding parameter.

[sbernard31]

LwM2M Bootstrap Server should not write 'Q' to /1/x/7 during bootstrap, if version of LwM2M Client is 1.1.

That's my understanding.

Server implementation of LwM2M 1.1 version may discard 'Q' from binding parameter.

If you are talking about binding parameter in REGISTER or UPDATE request. The specification says that a LWM2M 1.1 device should only send Q at all (at least in binding parameter as there is a dedicated parameter now). If it does (so does not respect the specification), this is not specify how the server should behave. I suppose it depends of implementation, server could be strict a reject the request or accept it ignore the Q and just raise a log :thinking:

[ezhaboy]

I suppose it depends of implementation, server could be strict a reject the request or accept it ignore the Q and just raise a log 🤔

/rd?ep=ep1&lt=60&lwm2m=1.1&b=UQ At least, in case of LwM2M Server receives above Register operation, it shouldn't consider queue mode of the LwM2M Client is enabled.

[sbernard31]

Here is a use case where not being able to set QueueMode by server instance is an issue.

[sbernard31]

here case where a user/manufacturer allow/want to change QueueMode at bootstrap time.

[hannestschofenig]

We removed the feature in v1.1. If there is still interest in this functionality we can re-consider adding it back to a future version of LwM2M.