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)).

[helsing]

Hi Tomas,

Sorry this is taking long, I am just letting you know I am still working on this. Could you please add a little more context?

Could you please add some more context to what you would like to achieve?

Best regards,

Håkon

[optical]

Human LTE connectivity indication. Our application is sending every 3s a message, which ensures that the data plane CSCON should be active all the time. There should not be any power saving or other disconnects from the network. We have mobile usecase of the nrf9160 modem. It switches BTS stations very often. We would like to indicate to the user that this is happening. The connection loss is often lengthy process.

The following log shows scenario when connection to the next cell took "only" 20s in worse signal condition this mas can take much more time.

[15:08:50.733,000] <dbg> dt_coap_client: Data recieved # <- Reponse from Server

[15:08:50.733,000] <dbg> dt_coap_client: Recieved coap id: 7894, token_len: 2, type: 01

[15:08:51.692,000] <inf> dt_modem: Notif: %XSNRSQ: 23,1,132,0

[15:08:53.464,000] <dbg> dt_coap_client: Non Con send Id: 14438

[15:08:53.464,000] <dbg> dt_socket_manager: Send handler: 1

[15:08:53.900,000] <inf> dt_modem: Notif: %CESQ: 10,0,0,0

[15:08:54.102,000] <inf> dt_modem: Notif: %CESQ: 4,0,0,0

[15:08:54.708,000] <inf> dt_modem: Notif: %XSNRSQ: 17,1,132,0

[15:08:56.463,000] <dbg> dt_coap_client: Non Con send Id: 14439

[15:08:56.463,000] <dbg> dt_socket_manager: Send handler: 1

[15:08:59.078,000] <inf> dt_modem: Notif: +CSCON: 0

[15:08:59.261,000] <inf> dt_modem: Notif: %CESQ: 255,0,255,0

[15:08:59.262,000] <inf> dt_modem: Notif: +CEREG: 2

[15:08:59.268,000] <wrn> main: Pausing Socket Manager

[15:08:59.268,000] <wrn> dt_app_flight: Stoping sending task due to network disconnect

[15:09:04.278,000] <inf> dt_modem: Notif: %CESQ: 18,0,4,0

[15:09:04.279,000] <inf> dt_modem: Notif: +CEREG: 5,"5A18","0092A521",7,,,"11100000","11100000"

[15:09:04.285,000] <inf> main: Resuming Socket Manager

[15:09:04.285,000] <inf> dt_app_flight: Resuming network task due to network connect event

[15:09:04.289,000] <dbg> dt_coap_client: Non Con send Id: 14440

[15:09:04.289,000] <dbg> dt_socket_manager: Send handler: 1

[15:09:04.485,000] <inf> dt_modem: Notif: +CSCON: 1

[15:09:04.679,000] <inf> dt_modem: Notif: %CESQ: 21,1,11,1

[15:09:05.481,000] <inf> dt_modem: Notif: %CESQ: 15,0,6,0

[15:09:06.466,000] <dbg> dt_coap_client: Non Con send Id: 14441

[15:09:06.466,000] <dbg> dt_socket_manager: Send handler: 1

[15:09:06.684,000] <inf> dt_modem: Notif: %CESQ: 13,0,0,0

[15:09:06.684,000] <inf> dt_modem: Notif: %XSNRSQ: 22,1,133,0

[15:09:06.828,000] <dbg> dt_coap_client: Data recieved # <- Reponse from Server

The modem between 15:08:50 -> 15:08:59 losses connection. This is time we would like to already indicate the use that the modem is not connected to the network. How to achieve this. The modem must know whether the packets are transmitted. The packets  Id: 14438 and  Id: 14439 are probably transmitted after new connection 15:09:04.279. Which is after 10s and we would like to show the user in meantime that we are waiting for network connection. We are currently using the CEREG notification, which tells only part of the story in this case 5s of downtime instead of 20s. In worse signal condition the discrepancy is much greater. CSCON would signal 10s of downtime,which is still only a half of the time.

Second use case is similar. During the downtime we would like to eliminate CoaP retransmisions because it does not make sense to send(enqueue) them into modem. They will be transmitted together defeating their purpose and they only consume more data, which raises the cost of the device operation.

You can see in the log that we are pausing sending to the socket when CEREG notification arrives and resuming it when CEREG 5 roaming arrives. We would like to use approach using the CSCON. However, the logic cannot solely depend on the CSCON notification because. The modeme will only make CSCON connection, when data has been enqueued into it. This meas when we would connect the CSCON logic to the pausing and resuming logic it would end up in logical loop. We want to send something -> CSCON=0 -> The CSCON will never be established because we have not enqueued anything.

Without any additional monitoring AT command we cannot determine whether the modem will establish CSCON(has enqueued packets)

[helsing]

Thank you for the explanation and sorry for the delay. I am discussing your situation with our team and will get back to you.

[helsing]

Thank you for the update. So, one of your big challenges here is that your signal is very poor. What is the overall goal here, and what is the application?

[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.