[BC66] QLWNOTIFY failed after PSM

I’m not able to send NOTIFY to Leshan LwM2M server after waking up from PSM. Can anyone help see what i’m doing wrong?

I successfully registered and responded to OBSERVE as well as able to NOTIFY before PSM:

11:03:28: +QLWREG: 0
11:03:31: +QLWURC: “observe”,44607,0,10376,0,6
11:03:31: AT+QLWOBSRSP=44607,1,10376,0,6,2,1,00,0
11:03:31: OK
11:03:32: +QLWOBSRSP: 0
11:03:33: AT+QLWNOTIFY=10376,0,6,2,12,83001A6164D0B4FA00000000,0,1,1
11:03:33: OK
11:03:34: +QLWURC: “report”,11056
11:03:34: +QLWNOTIFY: 0
11:03:34: +CSCON: 0
11:03:36: +CSCON: 1
11:03:36: +QLWURC: “report_ack”,0,11056
11:03:57: +CSCON: 0

After Entering and Waking up from PSM, I get this ‘report_ack’ error 9, what is this ‘lw_event’ means? No documentation on this.

11:06:34: AT
11:06:34: +CEREG: 1,“7469”,“03F91A7A”,9,0,0,“00100010”,“00111001”
11:06:34: +CPIN: READY
11:06:34: OK
11:06:39: +QLWURC: “recovered”,0
11:06:39: AT+QLWNOTIFY=10376,0,6,2,216,83011A6164D0BEFA0000000083021A6164D0C8FA0000000083031A6164D0D2FA0000000083041A6164D0DCFA0000000083051A6164D0E6FA0000000083061A6164D0F0FA0000000083071A6164D0FAFA0000000083081A6164D104FA0000000083091A6164D10EFA00000000830A1A6164D118FA00000000830B1A6164D122FA00000000830C1A6164D12CFA00000000830D1A6164D136FA00000000830E1A6164D140FA00000000830F1A6164D14AFA0000000083101A6164D154FA0000000083111A6164D15EFA0000000083121A6164D168FA00000000,0,1,1
11:06:39: OK
11:06:40: +QLWURC: “report”,34886
11:06:40: +QLWNOTIFY: 0
11:06:47: +CEREG: 1,“7469”,“03F91A7D”,9,0,0,“00100010”,“00111001”
11:06:50: +CSCON: 1
11:06:52: +CSCON: 0
11:06:55: +CSCON: 1
11:06:56: +QLWURC: “report_ack”,9,34886
11:06:56: +QLWURC: “lw_event”,0,9,34886
11:06:57: +QLWURC: “lw_event”,0,9,34886
11:07:21: +CSCON: 0

hi, Muhammad_Bin_Ahmad
How did you wake up the modules?
I suggest you try sending it multiple times after waking up.

Hi Herbert,|

I wake up the module by using the PSM_EINT pin, and “AT” command/response.
This method works and I’m able to wake up from PSM/ deep sleep.

Nevertheless, this NOTIFY is giving me error, I already tried multiple time, even some delay after waking up. All not working.

Do you have any info on what do “report_ack”,9,34886 and “lw_event”,0,9,34886 mean? From the datasheet, ‘9’ means reset but what exactly does it mean? What am I suppose to do?

Please refer to this documentation and I will test validation locally to provide you with the correct method.

Hi Herbert,
I tried adding Update command after waking up as per your documentation, still error.

10:08:03: AT
10:08:03: +CEREG: 1,“7469”,“03F91A7AT
A”,910:08:03: ,0,0,“00100010”,“00111001”
10:08:03: +CPIN: READY
10:08:03: OK
10:08:03: +QLWURC: “recovered”,0
10:08:04: AT+QLWUPDATE=1,0
10:08:04: OK
10:08:04: AT+QLWNOTIFY=10376,0,6,2,24,83021A6164D12CFA0000000083031A6164D1E0FA00000000,0,1,2
10:08:04: OK
10:08:05: +CSCON: 1
10:08:05: +QLWUPDATE: 0,17394
10:08:05: +QLWURC: “report”,17395
10:08:05: +QLWNOTIFY: 0
10:08:05: +CSCON: 0
10:08:05: +QLWURC: “report_ack”,9,17395
10:08:05: +QLWURC: “lw_event”,0,9,17395

I put your question to the test,After exiting PSM, you need to click On Observe (OBS) on Leshan’s platform, then you need to use QLWUPDATE to get OBS, and then you can use QLWNOTIFY

Hi Herbert,

This is defeating the purpose of observe. You suggesting me to ‘Read’ rather than ‘Observe’.
I believe the issue is the modem didn’t retain the coap port when it try to Notify after PSM.

In fact, after the module woke up, I returned the correct URC using QLWNOTIFY, but the Leshan platform did not update the data I reported.
After exiting PSM, to click On Observe (OBS) on Leshan’s platform, then need to use QLWUPDATE to get OBS, and then you can use QLWNOTIFY.
Therefore, I think that the module lost OBS information after entering PSM, resulting in QLWNOTIFY not updating data

This workaround is not ideal for OBSERVE. Server should not keep sending observe multiple times. Multiple transactions will greatly reduce the device battery life.

Is Quectel going to fix this? As far as this issue is concern, I think Quectel module cannot work well with Leshan server, especially if PSM feature is used.

Yes, I need to communicate with the r&d team to verify and confirm the problem



[2022-01-24_19:20:38:893]+QLWREG: 0

[2022-01-24_19:20:42:839]+QLWADDOBJ: 0
[2022-01-24_19:20:52:263]+QLWURC: “observe”,37391,0,3304,0,5604

[2022-01-24_19:20:58:848]+QLWURC: “report”,4999

[2022-01-24_19:20:58:878]+QLWNOTIFY: 0
[2022-01-24_19:20:59:921]+QLWURC: “report_ack”,0,4999

[2022-01-24_19:23:26:752]+QLWURC: “report”,5000

[2022-01-24_19:23:26:752]+QLWNOTIFY: 0
[2022-01-24_19:23:27:821]+QLWURC: “report_ack”,9,5000

[2022-01-24_19:23:27:882]+QLWURC: “lw_event”,0,9,5000

Through the above test, I and THE R&D determined that the leshan platform could not keep the subscription for a long time, which was about 3 minutes. The platform cancelled the subscription, so the data could not be sent through QLWNOTIFY,but to be realized by updating OBS

Hi Herbert,

I also tried without PSM and I got the same result as you:.

09:09:19: AT+QLWREG
09:09:20: OK
09:09:20: +QLWREG: 0
09:09:22: +QLWURC: “observe”,47980,0,10376,0,6
09:09:22: AT+QLWOBSRSP=47980,1,10376,0,6,2,12,83001A6164D348FA40000000,0
09:09:23: OK
09:09:24: +QLWOBSRSP: 0
09:09:44: +CSCON: 0
09:13:15: AT
09:13:16: AT
09:13:16: OK
09:13:16: OK
09:13:18: +QLWURC: “report”,20136
09:13:18: +QLWNOTIFY: 0
09:13:18: +CSCON: 1
09:13:18: +QLWURC: “report_ack”,9,20136
09:13:18: +QLWURC: “lw_event”,0,9,20136
09:13:18: +CSCON: 0

However, looking at Wireshark network log, it seems like after few minutes, the module send NOTIFY with different port number. I think this is the cause of the issue and leshan server did not cancel the observation. Why the module didn’t retain it’s UDP port?

According to the investigation, the problem has nothing to do with the module. If you need to use leshan platform to implement your data service, I suggest deregister Leshan after sending data, and re-registering the platform after exiting PSM.
Yes, before I tested using QLWNOTIFY, using QLWUPDATE still didn’t work.

Hi Herbert,

May I know what lwm2m server that you guys use to test the module?

When I verified your question, I used the Leshan server.
You can also use Amazon IOT and Azure IOT.

Depending on your network, a NAT may change your mapping when wakeup after PSM.
And if that ip-address mapping changes, you violate RFC7641. The leshan project has written some information to understand and overcome that.

If you use DTLS (either with DTLS CID (upcoming RFC9146) or auto-handshakes) that may work, because leshan will then associate your notify by the principal and not the (changing) ip-address.

1 Like

Is that observation from the device or the server-side? If it’s the server side, then it’s caused by a NAT and obvious violation RFC7641. If it’s the device, then I wonder, how that can pass tests.

Is that intended, that the second message starts with the first?

Server side. IP remained the same but the module changed the port.

That’s just CBOR payload.