NRF9161 - modem stacks outgoing messages and then flushes it: can this be handled?

[marsal]

Hi,

we are still struggling with nrf9161 behavior and trying to mitigate data sending dropouts (NRF9161 signal strength measurment seems to break TCP/IP connection - any solution/suggestion? and  NRF9161 based LTE-M tracker data drops while moving – can it be optimized? ).

Here is one partial issue: we are currently using UDP and flushing data to an application server. It seems that the modem behaves as follows: the UDP stack/modem seems to stack incoming messages but when the modem has an connection dropout, it does not send them. When the connection comes back, the modem flushes "old" messages. For our business case, they are not useful and we would like to discard these "old" messages when the modem reconnects. Is such behavior possible to achieve? Or I need to rely on some UDP level only?

Thank you

Martin

[Håkon Alseth]

Hi,

 

Here is one partial issue: we are currently using UDP and flushing data to an application server. It seems that the modem behaves as follows: the UDP stack/modem seems to stack incoming messages but when the modem has an connection dropout, it does not send them. When the connection comes back, the modem flushes "old" messages. For our business case, they are not useful and we would like to discard these "old" messages when the modem reconnects. Is such behavior possible to achieve? Or I need to rely on some UDP level only?

The issue is when there is a handover from one cell tower to another, and LTE based re-transmissions occur, effectively sending older UDP based payloads.

In your application, this is not wanted, and you want to flush those buffers.

Is this correct?

 

If I have understood the scenario correct (please correct me if I am mistaken); then you can close and re-open the UDP based socket. This will flush it.

Another option is to check the current network conditions by running AT%CONEVAL command:

https://docs.nordicsemi.com/bundle/ref_at_commands_nrf91x1/page/REF/at_commands/mob_termination_ctrl_status/coneval_set.html

 

Kind regards,

Håkon

[marsal]

Thanks a lot, Hakon! The scenario is correct. If I understand well, you suggest to run AT%CONEVAL? How long it takes and does it interfere with the data being sent/received? If you would look at (already mentioned)NRF9161 signal strength measurment seems to break TCP/IP connection - any solution/suggestion?  , we suspect that the process of signal measurement can co-cause the data transfer drops.

[Håkon Alseth]

Hi,

 

There is no explicit flush command.

The simplest form of a "flush" in this scenario is to close the socket. CONEVAL can be run prior to the send() operation to ensure that your network conditions are optimal or per your required level (see "energy_estimate" field).

marsal said:

If you would look at (already mentioned)NRF9161 signal strength measurment seems to break TCP/IP connection - any solution/suggestion?  , we suspect that the process of signal measurement can co-cause the data transfer drops.

Your RSRP is returned as 27 (-140 + 27 = -113 dBm) which is below the receiver sensitivity limit for CatM1:

https://docs.nordicsemi.com/bundle/ps_nrf9151/page/_tmp/alta.nRF9151/autodita/APPLICATION.RADIOLTE/parameters.rf_spec_rx_m1.html

The linked case highlights your signal strength as a problem, thus the required keepalive (as given by the whole network chain, routing/server/etc) is not maintained, and the TCP connection drops.

  

Kind regards,

Håkon