Different LTE-M current consumption behaviors and RAI inactivity handling on nRF9151

[Hassan0]

Hello,

We are currently performing power consumption measurements on the Nordic nRF9151 using the PPK2 in LTE-M with an Objenious SIM card.

During our tests, we observed two different network behaviors leading to significantly different current consumption profiles, even when running exactly the same test scenario.

1. Different network attach behaviors and current consumption

The attached screenshots correspond to:

• Same firmware
• Same LTE-M configuration
• Same SIM card
• Same location and radio conditions
• Same test procedure

The test simply consists of:

1. Setting CFUN=1
2. Waiting for network registration
3. Repeating the same attach sequence again a few seconds later without changing any parameter

Despite this, we observe two different attach behaviors with very different energy consumption, in some cases almost double.

Logs: 

[2026-05-26 09:56:37.039] at+cfun=1
[2026-05-26 09:56:37.897]
[2026-05-26 09:56:37.898] OK
[2026-05-26 09:56:38.982]
[2026-05-26 09:56:38.982] +CEREG: 2,"E485","093F9E11",7
[2026-05-26 09:56:40.786]
[2026-05-26 09:56:40.786] +CEREG: 1,"E485","093F9E11",7,,,"11100000","11100000"
[2026-05-26 09:56:47.918] at+cfun=0
[2026-05-26 09:56:49.870] +CEREG: 1,"E485","093F9E10",7,,,"11100000","11100000"
[2026-05-26 09:56:54.306]
[2026-05-26 09:56:54.788]
[2026-05-26 09:56:54.788] OK
[2026-05-26 09:56:54.788]
[2026-05-26 09:56:54.788] +CEREG: 0
[2026-05-26 09:56:57.621] at+cereg=5
[2026-05-26 09:56:58.961]
[2026-05-26 09:56:58.962] OK
[2026-05-26 09:57:02.461] at+cfun=1
[2026-05-26 09:57:03.198]
[2026-05-26 09:57:03.198] OK
[2026-05-26 09:57:04.593]
[2026-05-26 09:57:04.593] +CEREG: 2,"E485","093F9E10",7
[2026-05-26 09:57:05.015]
[2026-05-26 09:57:05.015] +CEREG: 1,"E485","093F9E10",7,,,"11100000","11100000"
[2026-05-26 09:57:15.791] at+cfun=0
[2026-05-26 09:57:22.234]
[2026-05-26 09:57:22.234] OK
[2026-05-26 09:57:22.236]
[2026-05-26 09:57:22.236] +CEREG: 0
[2026-05-26 09:57:26.291] at+cereg=5
[2026-05-26 09:57:27.091]
[2026-05-26 09:57:27.091] OK
[2026-05-26 09:57:29.946] at+cfun=1
[2026-05-26 09:57:30.901]
[2026-05-26 09:57:30.901] OK
[2026-05-26 09:57:32.098]
[2026-05-26 09:57:32.098] +CEREG: 2,"E485","093F9E10",7
[2026-05-26 09:57:32.508]
[2026-05-26 09:57:32.508] +CEREG: 1,"E485","093F9E10",7,,,"11100000","11100000"
[2026-05-26 09:57:41.527] at+cops?*
[2026-05-26 09:57:46.284]
[2026-05-26 09:57:46.284] +COPS: 0,2,"20820",7
[2026-05-26 09:57:46.286]
[2026-05-26 09:57:46.288] OK
[2026-05-26 09:58:36.929] AT%XSYSTEMMODE?
[2026-05-26 09:58:38.099]
[2026-05-26 09:58:38.099] %XSYSTEMMODE: 1,0,0,0
[2026-05-26 09:58:38.105]
[2026-05-26 09:58:38.105] OK

We also observe similar behavior differences during:

• UDP transmissions
• DTLS handshake procedures

However, with other operators (for example Orange), we do not observe these differences, which makes us think this could be related to operator-side LTE-M configuration or network behavior.

Could you please help us understand:

• What LTE-M signaling or network procedures could explain these differences?

2. RAI behavior and inactivity timer reduction in NB-IoT protocol

We are also testing RAI behavior on the nRF9151 in order to reduce the inactivity time after UDP transmissions.

We enabled RAI using:

AT%RAI=2

Relevant logs:

AT%RAI=2
OK

AT+CFUN=1
OK

+CEREG: 2,"C3D1","093F9ED8",9

%RAI: "093F9ED8","20820",0,1

+CEREG: 1,"C3D1","093F9ED8",9,,,"11100000","11100000"

From the %RAI notification, it seems that:

• AS-RAI is disabled by the network
• CP-RAI is enabled

Based on our understanding, CP-RAI should reduce the inactivity time after uplink UDP transmissions in NB-IoT protocol.

We verified this behavior with another modem platform, where enabling CP-RAI effectively reduces the inactivity duration.

However, on the nRF9151, enabling:

AT%RAI=2

does not seem to change the inactivity duration or current consumption behavior after UDP transmissions.

Could you please confirm:

1. Is AT%RAI=2 the correct command to enable CP-RAI on nRF9151 for UDP traffic?
2. Is there a modem trace or debug method allowing us to verify whether the RAI indication is actually transmitted and accepted by the network?

Thank you.

[Syed Maysum Abbas Zaidi]

Hi,

Thanks for your response. First, could you run AT#XSMVER (or AT#XSLMVER on older SLM) to confirm the nRF Connect SDK version? Based on the commands you are using (AT#XSSOCKET, AT#XCONNECT, AT#XSEND), it looks like you are running the Serial Modem (or SLM) application from our SDK. If confirmed, RAI is supported via AT#XSOCKETOPT. The consolidated AT_SO_RAI option uses name 61 and accepts the following values (mentioned here):

1 = RAI_NO_DATA
2 = RAI_LAST
3 = RAI_ONE_RESP
4 = RAI_ONGOING
5 = RAI_WAIT_MORE

Just to add on that the old individual RAI options (like AT_SO_RAI_LAST, AT_SO_RAI_NO_DATA and others with value 50-54) were removed in nRF Connect SDK v2.8.0, so we need to know the correct version first. Newer versions have AT_SO_RAI option (name 61) with the corresponding values as mentioned above.

I don't think custom NCS app would be required, please try using AT#XSOCKETOPT first and let us know if it works. Thanks.

Best Regards,
Syed Maysum

[Hassan0]

Hi,

I also tried to test SMS functionality on the same setup, but I am facing issues.

My network attachment is successful:

+CEREG: 0,1,"E485","093F9E10",7

However, SMS commands do not seem to work.

When using SLM SMS command:

AT#XSMS=1
ERROR

When using standard AT SMS commands:

AT+CMGF=1
+CMS ERROR: 302

Could you please confirm whether SMS functionality is supported in SLM v2.6.0 (nRF Connect SDK 2.6.1)?

Or is SMS support disabled by default in this firmware configuration?

Thank you.