LWM2M Client - XRAI

RE: LWM2M Client - XRAI

Michal — Mon, 16 Jan 2023 15:50:51 GMT

Thank you for the information and feel free to contact us if there's anything more.

Best regards,

Michal

RE: LWM2M Client - XRAI

Hkhan7861 — Fri, 13 Jan 2023 06:40:53 GMT

Hi Michal

I have furthered by questions toward my provider and i'm hoping to hear back soon. Thank you !

Hassan

RE: LWM2M Client - XRAI

Hkhan7861 — Fri, 13 Jan 2023 06:39:12 GMT

Hi Achim

I tried all that you suggested thank you very much! unfortunately, still no luck. I am attempting to contact my provider to find out whether the "AT%RAI" command will be able any time.

KInd regards,

Hassan

RE: LWM2M Client - XRAI

Michal — Wed, 11 Jan 2023 16:31:24 GMT

Hello Hassan,

Also thank you for the help Achim.

Should I still look into it, or have you gotten the answer you were looking for?

Best regards,

Michal

RE: LWM2M Client - XRAI

Achim Kraus — Mon, 09 Jan 2023 09:10:19 GMT

Let me add: using DTLS 1.2 then raise the question, if you need frequently DTLS handshakes. If so, you need also to consider that with "AT%XRAI=0" during the handshake.

RE: LWM2M Client - XRAI

Achim Kraus — Mon, 09 Jan 2023 08:48:47 GMT

Not sure, what you exactly do. There are two variants of RAI, using "AT%XRAI" is one, and it enables that feature for all future traffic. You may use it for an message exchange (request/response) or "one way message" (request with "no response option" or "non response/notify"). Once a mode is enabled, the future traffic will use that function. So while you device sends NON notifications, you may start that period with "AT%XRAI=4" (no response) and when the device checks the interest with a CON notification, you may switch to "AT%XRAI=3" (one response).

if you sent a "registration update", you usually get at least one response, so that should also be "AT%XRAI=3" (one response). If you expect the LwM2M server to send further request to the device, you may even switch to "AT%XRAI=0" (disable RAI). I'm not that common with eDRX, so it may be also possible, that "AT%XRAI=3" is used and rare additional server request are then handled on the next eDRX receive/wakeup.

According some other issues here in the forum, there seems to be no "hard relation", when a changed RAI mode is applied. So this changes may result in unexpected behavior, just test it "good enough".

(There is also an alternative RAI mode, which requires support by the network operator, "AT%RAI". with that, the RAI mode is controlled by socket options. Maybe that relates such mode-switching more reliable with the messages.)