Sleep Mode MAX_TRANSMISS_WAIT

[Earthworn]

Version(s)

v2.0.0-M10

Which components

server

Tested With

anjay zephyr client

What happened

Hi,

I m Using the Anjay Zephyr Client on nrf9160DK.
If i use Queue Mode and change the default coap MAX_TRANSMISS_WAIT (93 s) value to 21 s the Leshan Server still shows that the Client enters sleep mode after 93s. I can see on client side, that the client enters sleep Mode after 21s. Not sure if the client does not give the correct information to the leshan server or if the leshan server just always work with the default value. So i m not sure if this is an leshan or Anjay bug. The log does not give any information if the MAX_TRANSMISS_WAIT is transfered. If you need it i can send it to you

Best regards Levi

[jvermillard]

The CoAP MAX_TRANSMISS_WAIT and other low-level timing are not negotiated between the client and the server.
You need to configure both the client and the server, out of band, with the same parameters.

[Earthworn]

Okay thank you

[sbernard31]

(:warning: Long Answer :sweat_smile:)

About LWM2M specification :

AFIAK there is nothing in LWM2M specification which clearly defines when the server must consider a client off-line (sleeping).

The specifications says LWM2Mv1.1.1@transport§6.5. Queue Mode Operation for client :

The LwM2M Client lets the LwM2M Server know it is awake by sending a registration update message as a Confirmable message. Absent any application specific profiles, it is RECOMMENDED that the LwM2M Client waits at least MAX_TRANSMIT_WAIT seconds [CoAP] from the last CoAP message it sent to the LwM2M Server before intentionally going offline.

And for server :

If message delivery fails, for example, because the message got lost due to network connectivity issues or because the LMW2M Client was sleeping then CoAP re-transmission behaviour at the LwM2M Server will try to retransmit the message. The CoAP stack at the LwM2M Server will resend the message up to a certain number of attempts, as described in Section 4.2 of [CoAP]. If these retransmission attempts fail, the CoAP stack at the LwM2M Server will give up and inform the LwM2M layer. The LwM2M Server has to inform the application about this failed delivery but this API is outside the scope of the LwM2M specification.

Using MAX_TRANSMIT_WAIT is recommended for client but not mandatory.

Note It exists an LWM2M Object called CoAP Config (ID 500). If a client implements this object and use MAX_TRANSMIT_WAIT to go to sleep , we could imagine that server use it to calculate the MAX_TRANSMIT_WAIT. But this is not defined in specification.

There is also some discussion about a server could say to the device that there is nothing more to send, see OpenMobileAlliance/OMA_LwM2M_for_Developers#524

---

About Leshan behavior :

How it behaves at Leshan Server Side :

• Leshan Server will consider the client offline if a request failed to be send (e.g. timeout)
• But also when a device doesn't speak since a long time. By default this is 93s since last LWM2M response (meaning if there is communication on lower layer we don't use it to reset this 93s timeout). This default value is provided by StaticClientAwakeTimeProvider which implements ClientAwakeTimeProvider interface. So this is possible to implement a more dynamic version of ClientAwakeTimeProvider. See this is out of specification way.

---

To summarize ideas about how to manage this :

Do nothing as this is OK if client goes to sleep sooner.

OR If all clients use same time to sleep, just change the default static value.

OR If you only have ~2 or ~3 different time to sleep in your fleet :

• Not implemented but with new Transport Layer Abstraction (Add a way to add more transport Layer  #1025), you can create several server endpoint for same protocol. So you could imagine that you have 1 endpoint with MAX_TRANSMIT_WAIT at 93s and another at 21s. Client should connect to the right one. And Leshan server use a dynamic ClientAwakeTimeProvider based on this value. 🤔

OR If All clients have different timeout :

• you can use the out of spec way describe above.
• implement a way to get MAX_TRANSMIT_WAIT using CoAP Config (ID 500)

---

To finally answer to the question :

Not sure if the client does not give the correct information to the leshan server or if the leshan server just always work with the default value. So i m not sure if this is an leshan or Anjay bug. The log does not give any information if the MAX_TRANSMISS_WAIT is transfered.

FMPOV, there is no bug neither at Leshan nor Anjay side.
The specification is maybe not good enough on this point.
We could imagine some way to better support it but not sure at much it is in the scope of the project.
Maybe at least we could improve API to let user implement the strategy they prefer.

If you need it i can send it to you.

I'm not sure to get you, what do you propose ?
Are you an Anjay developer ? 🙂

[jvermillard]

without checking, I think your answer contains more words than the specification paragraph on queue mode 😂

[sbernard31]

Yep this is an answer for @Earthworn but also mainly a way to summarize all about what I found on this topic for my future self 😁

[Earthworn]

Thank you. I m not an anjay developer. I just evaluate the Anjay zephyr Client on nrf9160dk with the leshan server.

I proposed to send you the logging information of my application but this isn't neccessary because it is not an bug. And you explained the issue pretty well. Sorry for my bad English.

I have to agree with jvermillard. There are not many Information about the Queue Mode in the specification. In the beginning i thought i missed an paragraph.

[sbernard31]

You're welcome.

I understand you don't need a concrete solution for this. So we can re-close this. (Feel free to re-open or to comment more if needed)