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 🙂


  • Deutsche Telekom IoT

    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:

    62d3d146-e85e-41d9-bd62-6136de7e288c-image.png
    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

    @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?

    0c77efce-658f-4484-8a97-e50911f4a22f-image.png



  • 3d4488f6-8790-494e-a791-e778a85a77af-image.png

    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:

    7b2bbabf-adaa-49b1-8a97-35ab86e407f1-image.png

    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 🙂