• State Verified Answer
  • Replies 4 replies
  • Subscribers 75 subscribers
  • Views 778 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 310056
Options

High Latency in NB-IoT communication using Telefonica DE

lobaro-theo

Hello,

in Germany, O2/Telefonica (MCC+MNC: 26203) recently launched its NB-IoT network on a larger scale. Unfortunately, we see very high latencies (20-30s) in UDP communication with the nRF9160 compared to the other available networks (Vodafone-26202 and Deutsche Telekom-26201). In addition, we see that packets are processed in bursts, if at all, and an unusual pattern of power consumption. We cannot explain these, also due to the very good network coverage. Therefore, I would like to ask here for an analysis by suitable person at Nordic.

Here are the facts first:

- nRF9160 SiP (Rev 2)
- MFW 1.3.4
- Modem Lib 2.4.0

The symptoms are detectable on the nRF9160 DK and own hardware. Also tried firmware based on freeRTOS and Zephyr which are completely different, the result of high latency is the same. Different SIM cards were also tried. However, the problem occurs only with NB-IoT, with LTE-M everything works very well regardless of the chosen provider.

To get closer to the matter I have recorded some logs:

- Modem Traces
- Wireshark traces
- Screenshot from the Power Profiler
- The signal quality (CINR) is very good
- Telekom: '+CEINFO: 1,1,C,8,1,-87,6' -> DL-R:8x,UL-R:1x,rsrp:-85 dBm, cinr:8 dB
- Telefonica: '+CEINFO: 1,1,C,8,1,-74,15' -> DL-R:8x,UL-R:1x,rsrp:-74 dBm, cinr:15 dB

Once each for the problematic network of Telefonica and Deutsche Telekom. Both show a completely different behavior. Whereas the modem at Telefonica permanently needs 25mA+peaks, this is not the case at all at Telekom. See also these two pictures for comparison:

Telefoncia Power Consumption (high latencies) Telekom Power Consumption (low latencies)

I hereby ask someone at Nordic to look at the attached traces in comparison to each other and to assess what the problems at Telefonica could be and whether a malfunction of the modem can be ruled out. The communication is deliberately kept simple and unencrypted so as not to distract from the real problem. But I can say that the normally used DTLS secured communication with such high latencies and the current implementation in nrf-modem does not work or only very unreliable.

Thank you in advance!

Download Traces:

1513.Traces.zip

Parents
  • 0

    Hi, I'll give the traces to the modem team so they can analyse them.

    In the mean time, could you check if you see the same behaviour happens with modem FW v1.3.5?

    I expect it to be something caused by the network, and not the modem FW, but it would be nice to have it confirmed.

    Best regards,

    Didrik

  • 0 in reply to Didrik Rokhaug

    Yes it has been tested 1.3.5 also with same behavior, since the trace collector v2 (preview) app does not have support for it (yet) we used the 1.3.4.

  • +1 in reply to lobaro-theo

    Hi, and sorry for the delay.

    Due to summer vacations, it is harder than usual to find someone who can study the traces.

    However, I got an answer in the end.

    In NB-IoT, the network can automatically allocate uplink (UL) resources for a device (UE, short for User Equipment, in LTE-spec-speach) to send data or UE can request UL resources with RACH procedure. logicalChannelSR-ProhibitTimer (~16 s) is started when data becomes available and timer expiry will trigger RACH procedure if NW has not allocated UL resources before that. After each UL allocation retxBSR-Timer is started (~16s) and timer expiry will also trigger RACH procedure if there is data waiting for transmission.

    In this case, one UL allocation is received after successful PDN activation. There is no data available for transmission yet and padding is sent instead, and the retxBSR timer is started. After that socket is opened and data is sent, but the network does not send new UL allocations, so no data is sent before the retxBSR timer expires and the UE requests UL resources.

    The modem team means that the device works as expected. To reach fluent data flow with this NW configuration NW should allocate UL resources more frequently. After a successful PDN activation only one UL allocation is received.

Reply
  • +1 in reply to lobaro-theo

    Hi, and sorry for the delay.

    Due to summer vacations, it is harder than usual to find someone who can study the traces.

    However, I got an answer in the end.

    In NB-IoT, the network can automatically allocate uplink (UL) resources for a device (UE, short for User Equipment, in LTE-spec-speach) to send data or UE can request UL resources with RACH procedure. logicalChannelSR-ProhibitTimer (~16 s) is started when data becomes available and timer expiry will trigger RACH procedure if NW has not allocated UL resources before that. After each UL allocation retxBSR-Timer is started (~16s) and timer expiry will also trigger RACH procedure if there is data waiting for transmission.

    In this case, one UL allocation is received after successful PDN activation. There is no data available for transmission yet and padding is sent instead, and the retxBSR timer is started. After that socket is opened and data is sent, but the network does not send new UL allocations, so no data is sent before the retxBSR timer expires and the UE requests UL resources.

    The modem team means that the device works as expected. To reach fluent data flow with this NW configuration NW should allocate UL resources more frequently. After a successful PDN activation only one UL allocation is received.

Children
Related
Terms of service