Reduce RRC connected duration with MQTT

[Jakub Nagy]

Hi,

I'm developing a system which needs to have near real time control (downlinks) and uplinks. I've into these 2 issues. Please note that I'm still a beginner with LTE hence these questions, although I haven't been able to find a solution on this forum.

1. Setting the network connection periodicity

The device is running the MQTT control sample. It checks the network each 2.56 seconds. I'm not sure where is this setting coming from, since neither eDRX or PSM are enabled. The MQTT keepalive interval is 60 seconds, where the device connects for an extended period of time. What is this connection interval called, how can I change it through the SDK?

2. Reducing time in the RRC connected state

When I sent data to/from the MQTT server, the device processes it in around 1-2 seconds. Then it stays in the RRC connected state for an extra 10 seconds, consuming unwanted power:

By enabling CONFIG_LTE_LC_RAI_MODULE and CONFIG_LTE_RAI_REQ and setting the socket RAI flag to RAI_LAST together with MQTT_QOS_0_AT_MOST_ONCE I've been able to reduce the time in the RRC connected state to around 1.2s, reducing power consumption 5x. But this is only for transmissions/uplinks.

Is there something similar I can do for downlinks/reception? I know that RAI is intended more for UDP/CoAP but right now developing the application around that seems more complex, especially because of the downlink requirements.

Note that I need low latency, so I cannot use eDRX or PSM, but I still think it should be possible to shorten the time the device is in RRC connected state.

Thank you!

[Achim Kraus]

A bit long, but I hope it helps.

If you enable the modem trace and have a look at wireshark window, you will see:

Using TCP (MQTT), results in a couple of packets (e.g. TCP-ACK), more than just the ones for the application data.

You may think of it as each of those packets goes into a "radio-message".

RAI mainly means, you inform the modem to release the connection, because no "radio-messages" are expected to be exchanged in the next time. But with TCP it will not be too easy to see, when really the last packet is exchanged. At least not on the application layer.

For UDP that works, because there the mapping into "radio-messages" is 1-to-1. Knowing the application protocol (CoAP) on the top of UDP then enables to use RAI at the right points in time. 

> downlink requirements

That's more an issue of the "internet breakout/NAT" of your mobile network provider, and maybe your network configuration on the server/cloud side. E.g. using a VPN (if offered by the MNO/MVNO) helps there. 

The question is then frequently, if a "low power" consumption is required or a "fast reactive downlink". Both at the same time is in conflict. To save energy, the device will need to be kept sleeping as long as possible, to be reactive on the downlink needs to wakeup very frequently.

Therefore, if "low power" has precedence, it helps quite a lot to use REST with "health messages": means send a message every hour or 30 minutes to report the device is "healthy", even if nothing else has changed. As response you will then be able to send data downlink to the device, but only when the device initiates the communication with that health message. "Client initiated communication" is generally still the very most used pattern in the internet. That works in the most cases out of the box. For UDP and DTLS since the invention of DTLS 1.2 Connection ID, it works pretty efficient.

If "reactive downlink" has precedence, then that "internet breakout" may use larger timeouts for TCP than for UDP, which looks like using TCP is easier for that. Until you detect, that this is more an assumption than an grant. And that unexpected messages and sleeping device (even short sleeping, say 80s) don't fit and may break the TCP connection more often than wanted. If you need "grants" for those NAT, then a VPN does a well job. With that, the larger timeout for TCP isn't longer relevant and using UDP works perfect again. But you will still need to take care about the transport layer. If you use eDRX with 80s, then a downlink message requires also a timeout of 80s. With such a VPN you still need to care about the network configuration on your own server. In some cases it's then easier to use the "downlink" just as wakeup and then do the standard "client initiated communication" from the device, send the real "application downlink message" as response. Some MNO/MVNO even offer such a wakeup API (see Waking and Interacting with an IoT Device in eDRX Mode On Demand ).

 

 

[Jakub Nagy]

Hi Achim,

thank you very much for your detailed response!

Let me elaborate a bit on the use-case: I'm building a self-sevice pickup point lock box. It the future, it could use BLE scan responses to communicate with a phone but currently, it needs to be connected via a LPWAN technology. I have much more experience with LoRAWAN but since lower latency and higher reliability is needed, I opted for NB-IoT. So the user needs to click a button in an app and the locker needs to unlock, so the paging time needs to be less than 5 seconds for sure. Additionally we want to sent a status update (battery, RSRP, tamper detection) each every 2 minutes or so.

From what I understand the VPN removes the need for keepalive messages for TCP because the VPN server handles the communication. But if I'm sending the status updates every 2 minutes, they can also act as the keepalives so this might not be needed. Or are there other benefits for using a VPN?

The wakeup during eDRX seems like an interesting option. So I imagine I could use a eDRX cycle of 2 minutes (for the status updates) and a PTW of 1.28/2.56s during which the device could receive the wakeup message. How would I go about sending such a wakeup message? I'm using 1NCE and their roaming partners, but I haven't found a mention of such capability on their website.

I've actually been able to solve my original issue shortly after posting the original post. As I mentioned in the first post, I've been able to reduce the uplink/publish message duration by using RAI from 12s to 2s. But I found out that if I send an uplink right after I receive a downlink from the network, this RAI request also applies on the connection of the downlink, shortening the RRC connected time. This fits right into the communication scheme where I send a command to open a lock and then I need a response from the lock sensor to confirm if it was actually opened. By doing this the total time the system is on is around 5s and this reduces the total unlock event energy from 3.6J to 1.4J (including the energy consumed by the solenoid) which is quite significant. I guess this could partially or fully diminish the redundancy/acking capability of the TCP protocol but so far it works well in good signal conditions.

I've also checked your CoAP client and I would like to migrate the app to that eventually but I'm worried it will take a bit more time to setup simply because the codebase is much larger. But it's great that you're active in these forums so you might be of help.

[Achim Kraus]

Congratulation, that you already solved it.

> But if I'm sending the status updates every 2 minutes, they can also act as the keepalives so this might not be needed.

Yes, if you send something every 2 minutes, you don't need something else, no VPN nor heartbeats.

> How would I go about sending such a wakeup message?

I only found this at that provider of the link. For 1NCE setting up the VPN is quite easy.

I have to confess, that if I read 2 minutes send interval and 5s reaction time, I wonder, what the resulting energy and data consumption will be. I guess, you will find it out when the test runs for a couple of weeks.

[Jakub Nagy]

Achim Kraus said:

Congratulation, that you already solved it.

Thank you! I'm still new to both Zephyr, NB-IoT and NRF SDK, I've previously used mainly STM with their HAL so there are some differences but I'm getting used to it.

Achim Kraus said:

Yes, if you send something every 2 minutes, you don't need something else, no VPN nor heartbeats.

Okay great.

Achim Kraus said:

I only found this at that provider of the link. For 1NCE setting up the VPN is quite easy.

Okay I'll try to do more research.

Achim Kraus said:

I have to confess, that if I read 2 minutes send interval and 5s reaction time, I wonder, what the resulting energy and data consumption will be. I guess, you will find it out when the test runs for a couple of weeks.

The idea is not to run only on a battery, for that I would need <1mW and a large battery >15Ah to run for more than 5 years. The system will include a small solar panel and MPPT charger. But if I can reduce the power consumption from 60mW to 15mW, which so far I did in lab conditions I can afford to use a much smaller panel in the 1-3W range instead of 10W as intended firstly. I'm counting with a lot of reserve as you ca see.

Also I will close this issue and put my previous reply as the answer.