RRC inactivity timer duration for NB-IoT and LTE-M
-
Hello everyone,
Is there any precise information about the RRC inactivity timer duration at least for NB-IoT and LTE-M by Telekom in Germany?
I am currently measuring power consumption using LwM2M and MQTT over cIoT. Analyzing the results I found out the existence of the RRC inactivation timer that keeps the connected mode for various seconds even after the last packet is sent/received. I have therefore the following additional questions:
- Is the RRC inactivation time always constant for a specific carrier in a specific network?
- Is the RRC inactivation time generally different between NB-IoT and LTE-M?
- Is the RRC inactivation time normally variating choosing different eNodeBs?
- Is it generally possible to visualize the RRC inactivation timer duration from a modem (i.e. Quectel BG96)?
- Could the RRC inactivation be set by the device or is it just controllable by the operator of the eNodeB?
Thank you in advance.
-
@Alessandro-Parmigiani Hi Alessandro. I have experimented a lot with this on various networks/modules and in general my experience is that RRC inactivity cannot be controlled by the device. The only succesful way I have found to circumvent the RRC inactivity period is to use Release Assist.
However, release assist has some downsides. I have found that it only works on NB-IoT, I have not found any LTE-M modules/networks that support it. The implementation also highly depends on which module you are using. Release assist does lead to significant power saving, in some specific cases (like uplink only nodes) more than 90% of power can be saved.
In general it is very hard to visualize the RRC timer. The best method I found is to activate the +CSCON URC. This will tell you when the modem has left RRC connected state.
However, I do not know the specifics for the T-Mobile network. I am just a user
-
Hi @Alessandro-Parmigiani ,
The RRC inactivity timer is set by the network and cannot be modified by the device. Its value is usually consistent within one network (there are exceptions, though!) but it is not necessarily identical across all network technologies (e.g. NB-IoT and LTE-M).
Note that for NB-IoT, the RRC inactivity timer may also have different values depending on the CE-Level in which the module is (CE0, 1 or 2).In Germany, the timer is set to 10s for LTE-M and between 20s and 30s for NB-IoT depending on the area.
We are however reviewing those values at the moment and will most probably shorten the RRC inactivity timer for NB-IoT in the near future, especially for CE Level 0 and CE Level 1.
We will gladly inform you via this post whenever this change has been performed!If your application however does not expect downlink data after sending an uplink message, we strongly recommend using the Release Assistance Indication on NB-IoT to bypass this RRC Inactivity period and immediatly switch to Idle mode (as mentioned by Stefan de Lange above).
RAI is supported across all DT NB-IoT networks, with some regional limitations within our Polish network.
This feature unfortunately isn’t yet available for LTE-M, but has been standardized by 3GPP. It is therefore likely to be implemented in the future both by module vendors and network providers.Hope this can help!
Best regards,
Ronan
-
Hi @Stefan-de-Lange and @Ronan-Lacroix,
Thank you very much for your answers. I have been reading about the Release Assistance Indication (RAI) and it looked exactly like what I was looking for. Unfortunately, as you mentioned it just exists for NB-IoT and I am not sure it is supported on the BG 96. At the moment I’m testing LTE-M in Slovakia and I have some questions for you both:
The spikes on the left are a data transfer. At the very right end the two major peaks relates to the RRC idle mode trigger I guess. In the middle an approximately 5s long RRC inactive period.-
From your experience, is the RRC inactivation time related to the number of LTE frames, in this case 5 s ~ 5.12 s, therefore 512 frames or can it also be uncorrelated?
-
Is the RRC inactivation time ending where the spikes on the right begin? Or is the transition to idle mode also included?
Thank you in advance
-
-
@Alessandro-Parmigiani said in RRC inactivity timer duration for NB-IoT and LTE-M:
- From your experience, is the RRC inactivation time related to the number of LTE frames, in this case 5 s ~ 5.12 s, therefore 512 frames or can it also be uncorrelated?
I do not know. The module normally does not expose such details. You would need to have a network simulator or a module which supports extensive tracing on L1/L2/L3 (like the Sequans for example).
- Is the RRC inactivation time ending where the spikes on the right begin? Or is the transition to idle mode also included?
I believe the large spikes on the right signal RRC release. The very low power level afterwards suggests PSM mode. Your module also seems to be skipping the C-DRX phase, according to power consumption it is continuously in receive mode… I wonder why that is?
-
Is the inactivity timer always containing C-DRX cycles like in the picture?
Below you can find a wider view of a very similar scenario within my power analysis:
From here you can see the DRX cycles after the connection mode. This is why I’m thinking that the inactivity timer is contained between the actual data transmission (spikes on the right) and the beginning of the DRX cycles
Thank you in advance.
-
@Alessandro-Parmigiani Do you have the same picture including time/current scale? It would be very helpful to figure out what is going on
-
-
Is the inactivity timer always containing C-DRX cycles like in the picture?
It should. Unless C-DRX is disabled by the network, which appears to be the case. This is strange because it saves power. Have you tried to activate PSM and CSCON URC’s? That would help you in debugging.
From here you can see the DRX cycles after the connection mode. This is why I’m thinking that the inactivity timer is contained between the actual data transmission (spikes on the right) and the beginning of the DRX cycles
Yes I think so as well. You can get a lot more info if you enable aforementioned URC’s and hook up the serial debug port to the otii serial input.
-
@Stefan-de-Lange In your replies above you stated that you managed to get release assistance working on NBIoT. Can you kindly advise which module or chipset you used for this. The only one I am aware of having this supported is the Sara N3. I am currently testing a Sercom module based on the ALT1250 chipset and could not find any support for using it with UDP/TCP. I was able to get it working with the control plane traffic AT+CSODCP=1,1,“AA”,1,0 does work and the RRC is released immediately but this is of no use for me because I cannot access the control plane traffic. I could not replicate this behavior on UDP or TCP or HTTP. Any help would be greatly appreciated. On the Sara N3 there is a special command NSOSTF (https://www.u-blox.com/sites/default/files/SARA-N2-Application-Development_AppNote_%28UBX-16017368%29.pdf) but could not find any other module that supports this type of command. The Sara N3 is not ideal for me as I need an LTE-M and NBIoT module.
Thanks again for your help
-
@David-Micallef Hi David, I have tested several modules including SARA N2/N3. I would recommend testing the Nordic nRF9160 as it showed superior power consumption for all usecases. It also fully supports RAI for NB-IoT. I have tested RAI for UDP, LWM2M and confirmed/non-confirmed CoAP on nRF9160. It works in all cases. See also section 8.13 in the nRF91 AT command manual: https://infocenter.nordicsemi.com/pdf/nrf91_at_commands_v1.6.pdf
-
@Stefan-de-Lange Thanks for your reply, this helps a lot. I had briefly evaluated the 9160 (not for RAI). I also did some more research and it seems that even in the 9160, RAI is not supported in LTE-M. Its a pity because without it, a device in eDRX or PSM that needs to send data regularly will have a big battery impact because of the RRC being in connected state. Disabling the radio (CFUN…) is also not ideal because the attaching process is still costly from a battery perspective.
Thanks again for your help.
-
@David-Micallef Yes, you are right, RAI is not supported for LTE-M. Even if you find a module that supports it for LTE-M you will be out of luck because as far as I am aware there are currently no networks that support it either. This leads to some significant powerconsumption in the PSM case for LTE-M. The nRF9160 however, has extremely low idle/active currents. During C-DRX the module may go as low as 70 uA. Thus the effect of the C-DRX phase on energy consumption is limited, compared to some other modules.
Disabling the radio (CFUN…) is also not ideal because the attaching process is still costly from a battery perspective.
Also true. But it is a gray area and depends on several parameters. For example, the nRF9160 can attach/detach very quickly. Thus you may find that if you do uplink once an hour turning off/on the radio can still save you some energy. Operators may not like it if you detach/attach frequently, but that’s the world they have created as it stands today
-
@Stefan-de-Lange 100% agreed. Its just a case of probably 1 to 2 years and I believe we will see a lot of changes and adoptions of RAI even in LTE-M. This https://www.gsma.com/iot/wp-content/uploads/2019/08/201906-GSMA-LTE-M-Deployment-Guide-v3.pdf document from GSMA outlines RAI so its just a case of time until the networks starts to flood with IoT devices and engineers start to push this requirement. Thanks again for your help.
-
@David-Micallef I hope so. If you need professional help in developing/testing I can give you the contact info of my (ex) colleague. He is a real expert on this topic, together we tested many many modules/usecases. It’s how I aquired most of my knowledge on this topic. Just send me a private message if you are interested
-
@Stefan-de-Lange Thanks for your help. I will keep you colleague in mind.
-
@Stefan-de-Lange Sorry for the late answer. I have been trying with the URC logs and they confirm my suspects. Data are sent just at the beginning of the connected mode. Then a RRC inactivity timer of about 5 seconds follows. Do you know why providers are choosing in favor of longer or shorter DRX inactivity timer as well as an inactivity timer with DRX cycles?
-
@david-micallef said in RRC inactivity timer duration for NB-IoT and LTE-M:
On the Sara N3 there is a special command NSOSTF (https://www.u-blox.com/sites/default/files/SARA-N2-Application-Development_AppNote_%28UBX-16017368%29.pdf) but could not find any other module that supports this type of command.
@Stefan-de-Lange ,@David-Micallef Quectel BC95-G also has the NSOSTF command, see AT commands manual. And I’m assuming that their other modules (some of which are NB + LTE-M) will have that command too.
