nRF9151 LTE-M: MQTT downlink not always waking device from RRC Idle to RRC Connected when PSM/eDRX are disabled

[felan]

Hi There, 

I am currently developing an LTE-M application on nrf9151 using ncs v3.2.1, the device is a MQTT client that publishes telemetry periodically every 3 minutes, and it is meant to receive MQTT commands from the broker and act upon them within a few seconds i.e 5 to 10 seconds.  

modem FW : mfw_nrf91x1_2.0.4

Current software configuration: 

- MQTT QoS: QoS 1 for commands/status
- MQTT clean session: enabled
- PSM: disabled
- eDRX: disabled

CONFIG_LTE_LINK_CONTROL=y
CONFIG_LTE_LC_PSM_MODULE=n
CONFIG_LTE_LC_EDRX_MODULE=n
CONFIG_MQTT_CLEAN_SESSION=y
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_LTE_NETWORK_MODE_LTE_M_NBIOT=y

Observed behaviour: 

1. Device attaches to LTE-M and connect to MQTT properly. 
2. Device subcscribes to command topcis succesfully. 
3. While the device is in or near RRC Connected state, MQTT commands are received correctly.
4. After the network releases the device to RRC Idle, I publish a command from the broker.
5. Sometimes the modem transitions RRC Idle -> RRC Connected and the MQTT command is received.
6. Other times, no RRC transition is observed after the broker publish, and the command is not delivered to the application until a later uplink event (MQTT keepalive or telemetry publish).
7. I am not using PSM or eDRX, so my expectation was that the UE should remain reachable in RRC Idle via normal paging/DRX.

Power profiler observation:

I can see regular current peaks of approximately 80 mA every ~1.27 seconds while the device is in the idle state. I assume these are related to LTE-M paging/DRX activity, but I would like confirmation on how to interpret this. Despite these periodic peaks, downlink MQTT traffic does not always appear to page/wake the device into RRC Connected.

The issue is intermittent: sometimes downlink MQTT wakes the modem correctly, sometimes it does not appear to do so until uplink activity occurs.

1. With PSM and eDRX disabled on nRF9151 LTE-M, should downlink TCP/MQTT traffic reliably trigger network paging and cause the UE to transition from RRC Idle to RRC Connected?
2. If the device is in RRC Idle and an MQTT command is published from the broker, but no RRC Idle -> RRC Connected transition is observed, what are the most likely causes?
3. Are the periodic ~80 mA current peaks every ~1.27 seconds likely to be LTE-M idle-mode paging/DRX activity? If yes, does that confirm the modem is monitoring paging occasions correctly?
4.  Are there known issues or recommendations for MQTT over TLS on nRF9151 where downlink data is only received after the next uplink packet, such as an MQTT keepalive or telemetry publish?
5. Is there a recommended MQTT keepalive interval, socket configuration, or LTE configuration for low-latency downlink MQTT on nRF9151 while keeping data usage low?

Thanks for looking into this, your assistance is much appreciatted. 

Cheers, 

[Hakon]

Modem team;

Quite common DRX paging cycle is indeed 1.28 seconds which matches the peak seen in the PPK2 plot.

Very strange that MT paging wouldn’t work in normal DRX mode and especially MQTT+TCP based connection. Which carrier is used and is it an MVNO SIM? It’s quite common that with MVNO SIM the IP NAT route is kept open in the cellular IP network from the server towards the device only ~60 seconds at best, i.e. IPv4 based traffic towards the device doens’t have any route to the device anymore after this timeout.

Can you clarify whether the MQTT publish works for a period of time after last connection for some time, e.g. 60 seconds and then publish starts to fail?

MNO SIMs normally can maintain the IPv4 NAT routes much longer.

[felan]

Hi Hakon, 

Thanks for checking with the modem team.

I have done a few addition test and the behaviour still appears to be present even when I reduce the MQTT keepalive interval to 30-60 seconds. 

The main observation is that the device does not always receive the MQTT command when it is published from the broker while the device is in RRC Idle. Instead, the command appears to be received only when the device later sends its own uplink packet (MQTT keepalive / mqtt_live() or telemetry).

So the issue may not be that my previous keepalive interval was longer than an operator NAT timeout. Even with shorter keepalive intervals, the behaviour still looks uplink-triggered.

Current runtime PDN information: 

PDP type: IPv4

MTU: 1430

IMSI prefix: 90128

The device receives a private IPv4 address, and the IMSI prefix appears to be the Vodafone global IoT range. Therefore, I agree that operator-side NAT/firewall/IoT-core behaviour may be involved.

What I am trying to evaluate is whether MQTT over TLS on LTE-M can realistically support low-latency downlink commands, ideally in the 5–10 second range, while keeping monthly data consumption as low as possible.

Experimentally, using a very short MQTT keepalive (10-15 seconds) improves responsiveness, but the TLS/TCP overhead makes that approach unsuitable for the target data budget. With 30–60 second keepalive, the command latency still appears to be bounded by the next client-originated uplink rather than by immediate network paging, note this is an intermittent behaviour but easily reproducible. 

Could the modem team please clarify:

1. If PSM and eDRX are disabled, and the UE is in normal RRC Idle DRX, should mobile-terminated TCP data for an existing TLS socket reliably cause paging and RRC Idle -> Connected?
2. Is this behaviour something the nRF modem can influence, or is it mainly controlled by the operator APN / packet core / firewall / NAT configuration?

3. For a global LTE-M product needing 5–10 second command response with very low data usage i.e 2 MB per month , would Nordic recommend a different approach for the downlink behaviour (SMS will also be limited)? 

I have not yet had time to capture a modem trace, but I will provide one as soon as I can capture a clean reproduction.

Thanks for your assistance on this.

[Hakon]

Ok, I will ask the modem team to comment on this.