NRF9161 based LTE-M tracker data drops while moving – can it be optimized?

[marsal]

Hi everyone,

I’m using a custom board (a tracker) that can travel at speeds up to 65 km/h and transmits data regularly every 200 ms. I expect, therefore, that the inactivity timer should not be activated. While the device is in motion, I’m seeing intermittent data gaps ranging up to several seconds, which is unacceptable for our application.

Could this be caused by non-optimal cell-handover settings? I’ve attached a few logs below for reference.

Any suggestions would be greatly appreciated.

Thanks,
Martin

 

Three log fragments examples, related to data send drops:

 

17:31:57.179 +CSCON: 0

17:31:57.230 <inf> main: RRC mode: Idle

17:31:57.276 +CEREG: 1,"04D3","0DBC2351",7,,,"11100000","11100000"

17:31:57.298 <inf> main: Cell update, cell tac: 1235, cell id: 230433617

17:31:57.371 +CSCON: 1

17:31:57.429 <inf> main: RRC mode: Connected

17:31:57.539 +CSCON: 0

17:31:57.568 <inf> main: RRC mode: Idle

17:31:57.907 +CSCON: 1

17:31:57.926 <inf> main: RRC mode: Connected

***

17:37:54.095 +CEREG: 1,"04D3","0DC18750",7,,,"11100000","11100000"

17:37:54.154 [00:54:10.770,263] <inf> main: Cell update, cell tac: 1235, cell id: 230786896

***

17:38:05.373 +CEREG: 1,"04D3","0DDD4350",7,,,"11100000","11100000"

17:38:05.434 <inf> main: Cell update, cell tac: 1235, cell id: 232604496

***

 

Modem firmware: mfw_nrf91x1_2.0.2

 

Current 9161 modem initiation sequence is:

 

AT+CFUN=0

AT%XSYSTEMMODE=1,0,0,0

AT+CPSMS=0

AT+CEDRXS=0

AT%RAI=0

AT+CSCON=1

AT+CEREG=5

AT+CFUN=1

[Achim Kraus]

marsal said:

I’m seeing intermittent data gaps ranging up to several seconds, which is unacceptable for our application.

marsal said:

5 Hz to an MQTT broker

You chose MQTT. That usually queues the messages and transmit them, when transmission is possible. So, there may be a short gap in the time-stream, but not the data-stream, that's just delayed. If you add the "sensor-time" to the data, you will also be able to have the time-stream available with delays.

I guess, you need to adapt your application to that common practice.

[marsal]

Thanks, well, my interval_between_two_subsequent_successful_mqtt_sends is between 210ms and 300ms in case that there are no cell updates, which is OK for me. When cell update comes, it raises to e.g. 1.5 sec. So the cell update seems really be the case.

Er, I am struggling just now to catch the modem trace... Not sure if UART or RTT approach is better for me. 2.6.3.

[marsal]

Thanks, dejans, a lot!

Well, the best case could be that the descibed changes could have improved the behavior described in the very first email.

I have made the changes described in the previous email with trace link and only then I was recording the trace. Before the change, at the same path, I had observed number of cell switch changes with 1-2 secs data transfer breaks. In general, my question would be if the described settings are OK and/or what could be done more. Big thanks again.

[dejans]

Hi Martin,

marsal said:

In general, my question would be if the described settings are OK and/or what could be done more.

Connection re-establishment is triggered due to sync loss to serving cell (T310 expiry). This is normal operation for moving UE. Data paths are suspended for time of connection re-establishment. Parameters which control re-establishment are given by the network. There is nothing which could be done from UE side to avoid this interruption. You could contact the carrier regarding network support for LTE-M handover.

Best regards,
Dejan

[marsal]

Thx, dejans!

[marsal]

Let me still ask: does this meant the the network doesn't work in "Connected" mode for LTE-M (Rev14)? Or should I somehow set nrf9161 to allow this? Thanks again!

[dejans]

Hi Martin,

There is nothing on UE side which could be done to improve your use case. Everything is up to network configuration.

Network works in connected mode, but it could maintain connection better if it would support handover. You should contact the carrier and ask whether they support handover for LTE-M. Overall handover is controlled by the network and UE cannot do anything to trigger it.

UE can only try connection re-establishment for recovering connection problems which might cause too long delay for data transmission with regard to your requirements.

Best regards,
Dejan

[marsal]

Thanks a lot, indeed, dejans!

[dejans]

Hi,

It is great to hear that you found answers beneficial.

Best regards,
Dejan

[marsal]

Indeed, we are already in communication with our cell provider and they are promising to optimize the network for us :-). Possibly another option is to try DECT NR+ instead of LTE-M + and a gateway having also an LTE modem!?

[dejans]

Hi,

marsal said:

Possibly another option is to try DECT NR+ instead of LTE-M + and a gateway having also an LTE modem!?

Can you provide details how you intend to use this setup?

Best regards,
Dejan

[marsal]

Thanks, here is the idea - this means a rework of the current setup, of course:

10 to 20 trackers in one race  + 1 gateway. Distance between trackers and gateway can be up to 1km, direct line of sight. If not enough for the data transfer, an "intermediate" node is expected to be positioned somewhere in the middle between the gateway and the more distant place of the race.

Trackers (using our current hardware, btw ;-),  ):
a) Sending to the gateway each 200ms data about position/speed/direction (approx 100 bytes each)
b) Receiving from gateway each 1 second GNSS correction RTK data (up to 1KB each second, same for each tracker)
Idea: trackers typically communicate with gateway, if the gateway is not reachable for a tracker and vice versa, they send/receive via another tracker (mesh).

Gateway (our current hardware + LTE modem rework):
a) receiving position/speed/direction data from trackers, sending it to an MQTT server via LTE (I guess not via LTE-M for this case)
b) receiving RTK corrective data from another server and sending them to trackers via DECT NR+
c) Some other communication (AGNSS, some controls)

So, any hints and DECT NR+ firmware to test this warmly welcomed.

Thank you!

Martin