What options are there for EDRx + SSL + MQTT for Low Power device?

Knowledge Base TCP/UDP
1

Hello guys. Thanks in advance for your pieces of advice.
Could you tell if there is a good practice for the next case?
If shortly, IoT device communicates with MS Azure via NB-IoT. It communicates within an encrypted connection. The device sleeps almost all the time, it just publishes once per e.g. 12 hrs a message. It has to work e.g. for 5 yrs from one battery cell.
In details, what techs I assume to use:

  • IoT device is controlled by one of: such MCU + BC66 as an NB-IoT module, or BC66 standalone
  • IoT device communicates with Azure IoT Hub (via MQTT)
  • The connection is secured (self-signed client certificates and Azure portal CA’s one are in test now)
  • EDRx is suggested to use
    The awaited problem is that sending of certificates takes much of time (due NB-IoT tech low kb/sec rate) and accordingly drains the battery much. How to keep TCP connection alive for e.g. 12 hrs while in EDRx? Or any other better solution to keep up the POC purpose?
2

Hi, Yevhen_EKTOS:
The following handbook should answer your questions
Quectel_BC66&BC66-NA_MQTT_Application_Note_V2.0.pdf (3.7 MB)

answer :How to keep TCP connection alive for e.g. 12 hrs while in EDRx ?

image
image814×349 53.6 KB

Hope this helps you with your problems,thank you!

3

Thank you Herbert for your attention to my question.

Quectel_BC66BC66-NA_MQTT_Application_Note_V2.0.pdf :

I’ve requested with the AT command:

AT+QMTCFG=?

+QMTCFG: "dataformat",(0-5),(0,1),(0,1)
+QMTCFG: "keepalive",(0-5),(0-3600)
+QMTCFG: "session",(0-5),(0,1)
+QMTCFG: "timeout",(0-5),(1-60),(1-10),(0,1)
+QMTCFG: "will",(0-5),(0,1),(0-2),(0,1),"will_topic","will_msg"
+QMTCFG: "version",(0-5),(3,4)
+QMTCFG: "aliauth",(0-5),"productkey","devicename","devicesecret"
+QMTCFG: "echomode",(0-5),(0,1)
+QMTCFG: "ssl",(0-5)[,(0,1)[,(1-3),(0-5)]]

It seems that the AT output and QMTCFG command description in the .pdf are about only MQTT settings.

<keep-alive_time>
Integer type. Keep-alive time. The range is 0-3600. The default value is 120. Unit:
second. It defines the maximum time interval between messages received from a
client. If the server does not receive a message from the client within 1.5 times of
the keep-alive time period, it disconnects the client as if the client has sent a
DISCONNECT message.

You can see here “messages” (MQTT entity) but not packets, that is related for TCP.

If the server does not receive a message from the client within 1.5 times of
the keep-alive time period

The 1.5 times condition behavior is MQTT related to.

I hope I could explain it clear. Unfortunately, QMTCFG can’t solve TCP keep-alive adjusting issue.
I’d be happy for any idea, even for other concept, that fits a brief description of the project purpose in my first message.
Thanks in advance.

4

Hi, Yevhen_EKTOS:
I understand what you mean, but if you are using 2G/3G/4G/5G products, once the module is connected to the radio network, establish PDP context, send and receive data or data interaction, the module will be in a high power consumption state and maintain a long connection with the network;Only when the module is idle (inactivate the PDP context) can the module enter low power mode (EDRX or PSM).
If you are using NB or CAT1/CAT.M products, this type of module in low power (DRX or PSM) or idle state by receiving and receiving data awakening module, T3324 and T3412 timer to monitor and control the state of the module.
Therefore, if you are using NB or CAT1/ CAT.m products, the module will enter low power mode regardless of the data transfer protocol you are using. Instead, you can use TCP/UDP or MQTT to enter low power mode after the module sends or receives data to core network or after the link keepalive timeout.

5

Hello Herbert.
I was trying to get what you had meant here but I couldn’t :slight_smile:

If you are using NB or CAT1/CAT.M products, this type of module in low power (DRX or PSM) or idle state by receiving and receiving data awakening module, T3324 and T3412 timer to monitor and control the state of the module.

and this:

Instead, you can use TCP/UDP or MQTT to enter low power mode after the module sends or receives data to core network or after the link keepalive timeout.

Please could you give some detailed explanation?

Thank you Herbert.

6

Hi Yevhen_EKTOS:
refering to 6.2. Example of MQTT Operation with SSL
Quectel_BG96_MQTT_Application_Note_V1.1.pdf (628.2 KB)
About NB(or NB-IOT) or CAT.1/CAT.M,I suggest you use Google search,That way you can get more details.

7

OK.
I’ve tested successfully BC66 MQTT + SSL both examples for AWS and for Azure already. But without eDRX or PSM.
I’m reading more about NB-IoT + eDRX / PSM.
Thank you.

8

Hi, Yevhen_EKTOS:
If you have the BC66 AT command manual, please refer to 8.4 and 8.5,thank you!

9

Hello Herbert.
Could you look into Quectel_BC66BC66-NA_MQTT_Application_Note_V2.0.pdf (page 9 \ Figure 1: MQTT Data Interaction Mechanism)?
Is Link layer diagram entity physically located at some NB-IoT provider service (behind Base Station)?
Thank you.

10

Hi, Yevhen_EKTOS:
Here, the concept of link layer is vague. It is neither the link layer in the OSI model nor the layer 2 on 3GPP. It can be understood as the link that adapt to all kinds of data transmission protocols in the upper layer.The link layer at the base station side or in 3GPP is also called Layer 2, which includes MAC layer, RLC layer and PDCP layer. Its main role is to schedule, encapsulate, encrypt, decrypt, compress and other functions of data.
You can also think of it as the logical layer between TCP/UDP (and other transport protocols) and the physical layer,and is the generic Internet Data Transfer Protocol layer.

11

Hi,
If you solved the issue then great.
We solved the issue by using keepalive on the TCP level; AT+QICFG=“tcp/keepalive”,1,2,30,3
The interval is two minutes as the TCP Idle time is 5minutes, if during past 5minutes there is no traffic in the socket then the connections shall be zombie/limbo, the Quectel modem shall not notice nothing.
The tcp/keepalive helped a lot !

12

Hello

It seems I’m facing exactly the same issue. Without eDRX, everything is working fine. Since I have activated eDRX, my MQTT connection seems to be zombie after a few minutes. I’m still seing myselft connected (+QMTCONN: 0,3) but i don’t receive anymore any notification.
I tried to set AT+QICFG=“tcp/keepalive”,1,2,30,3 but it seems to improve the behaviors but i’m still facing the issue.

When you tell :

is this idle time is a parameter configured on server side ?

Regards,

13

Hello,
5 minutes is the default setting of windows (I assume also for linux).
You can also try to add the below to the configuration
“AT+QMTCFG="keepalive",0,120\r” // keep-alive time 0, server is not required to disconnect the client on the grounds of inactivity
Regards

14

Hello
Thank you so much for the help.
I tried what you suggested but it didn’t work.
Actually, i’m using the BG77 in a specific mode : i’m activating eDRX, and then once i’m connected to the MQTT broker, i stop the UART and I set the DTR pin (in order to disable the UART on BG side) and save poer. I have configured the RI pin to wake me up with URC message
(AT+QCFG=“urc/ri/other”,“pulse”,120,1")
(AT+QMTCFG=“recv/mode”,0,1,0")
Maybe the issue comes from the RI pin.

Best regards,