nRF9160 Network connection status NB-IoT. Handling

[optical]

Hello, 

i would like to ask you for advice how to correctly process the connection status information from the modem. Our application is sending telemetry data to the cloud and we would like to provide the user the most recent(real-time) information whether the data is being transmitted by the modem. 

Currently, we are using COAP protocol with NON message type, which does not have any response to determine, whether the data is being received by the server. For our use case the information that the data is being transmitted to the BTS is enough. We also would like to control the data flow to the modem by these notifications to prevent unnecessary re-transmission and reduce the data usage. There is no point sending message repeatedly when the modem did not event transmitted it.

The network we are using is NB-IoT, we do not have LTE-m active in our country so we cannot easily test it, however we are developing product for both.

Currently we are using for the flow control and user signaling only the +CEREG notification. Which has significant latency and it does not directly show whether the data is coming though. We would like to incorporate the +CSCON notification also into the flow, which should greatly improve the situation. The issue with CSCON is that when used for the flow control we are getting into a logical loop. When we are not sending data the CSCON will never activate(only on first BTS connection) and when CSCON is not active we would like to stop sending unnecessary data. Further more even the CSCON is not very accurate. In ideal situation the data is transmitted right after the BTS connection.

Ideal situation:

[11:34:30.731,000] <inf> dt_modem: Notif: +CEREG: 5,"BC48","000B0021",9,,,"11100000","00101000"

[11:34:30.747,000] <inf> main: Modem firmware version: nrf9160_1.3.1

[11:34:30.789,000] <inf> dt_app_flight: Processing Location Data: Takeoff: 139, Alt: 154, Rel: 14

[11:34:30.789,000] <inf> dt_app_flight: Time: 03.07.2022 09:34:27.000, timestamp: 1656840867000

[11:34:30.789,000] <inf> dt_app_flight: Sending 1 entrie to cloud

[11:34:30.789,000] <dbg> dt_coap_client: Non Con send Id: 41523

[11:34:30.790,000] <dbg> dt_socket_manager: Send handler: 1

[11:34:30.790,000] <dbg> dt_socket_manager: Msg fifo: 1

[11:34:30.790,000] <dbg> dt_socket_manager: Sending data: 53 # <------- Telemetry sent

[11:34:31.429,000] <inf> dt_modem: Notif: +CSCON: 1  # <------- The Flow control should sent it after the established connection is perfect world

[11:34:31.430,000] <inf> dt_modem: Notif: %CESQ: 86,4,26,3

[11:34:31.894,000] <dbg> dt_coap_client: Data recieved # <---- Recieved response from the server(only for testing)

However in connection to BTS with worse signal the data plane will signal CSCON=1 even thought it yet cannot transmit the data, afterwards it will try connection to another BTS.

What is your recommendation for processing the CEREG and CSCON notification, is there some additional notification, which can be used ? Maybe some interface for the packet sent confirmation ?

Do you have suggestion what additional information we should use to resolve the logical loop for flow control with use of CSCON ? Maybe some information whether the modem has enqueued a packet for transmission would resolve the loop. It may it self be used to determine the state of the connection. We are ending packets every 1-3s. That might be helpful to determine, whether the buffer is filling and waiting instead of sending.

The current notification capabilities are insufficient or interactive application, which used in mobile environment(lot of BTS changes (NB-IoT, the LTE-M should be significantly better)).

[optical]

The logs, which I sent were to reproduce issues when the device in the real world application(for us drone tracking) has poor signal. They were produce by using external antenna port without antenna. The device is able to connect to LTE network in our office even without the antenna. The issues are not severe when the device has good signal.

The signal quality does not address the issue of indicating the user that he is out of coverage or has poor signal or the redundant message sending. The device should be able to work in these conditions.

 

[helsing]

Hi Tomas,

Sorry you have not heard from me. We are still working on this and will get back to you with a comment.

[helsing]

Hi Tomas, sorry for the delay.

%CONEVAL will provide you with information about signal power. This could help predicting the conditions.

[optical]

Can Nordic provide an application note how to exactly use the %CONEVAL for our case ?

[Charlie]

Hi Tomas,

1) The drone tracking application sounds not quite fit the NB-IoT network. As drone normally has a fast speed and NB-IoT is mostly used by fixed IoT device and need a long time to search and attach to cell station due to its low bandwidth. You can read nWP044 - Best practices for cellular IoT development to learn more considerations you should take for your application development. For your application, if LTE-M is not an option and you do not have limitations on power consumption, 3G/4G/5G modules are better choices than NB-IoT since they are more robust with high speed. Another concern is that the base station antenna is targeting the ground, so your drone will have a worse signal than the ground in the same area.

2) If NB-IoT is your only choice, CEREG should be the correct indicator instead of CSCON as you have realized, but again it is too slow to detect environmental change due to the NB-IoT limitation. In your log file, you did not even get a chance to see +CEREG: 4( limited service due to out of E-UTRAN coverage) before getting +CEREG: 2. The Modem sleep notification %XMODEMSLEEP command may give some fast response when the device goes to sleep because of limited service. 

Building an application with the wrong technology will make you struggle a lot, hope you could figure out a proper solution for this application. We can have more discussion if you have other confusion.

Best regards,

Charlie