LTE connection timeout & retry policy

RE: LTE connection timeout & retry policy

Achim Kraus — Tue, 19 Sep 2023 13:49:34 GMT

Though this is now some time ago, what is your experience in the meantime with power saving and the network search, maybe with XDATAPRFL or PERIODICSEARCHCONF?

RE: LTE connection timeout & retry policy

barbiz — Sat, 07 Jan 2023 11:41:10 GMT

Thanks Oyvind,

we will try that soon and let you know!

Marco

RE: LTE connection timeout & retry policy

Øyvind — Thu, 05 Jan 2023 14:42:10 GMT

No, does not look like it is, only as an AT command.

-Øyvind

RE: LTE connection timeout & retry policy

barbiz — Thu, 05 Jan 2023 08:46:43 GMT

Thanks!

Is that function also available via lte link controller library?

Marco

RE: LTE connection timeout & retry policy

Øyvind — Thu, 05 Jan 2023 07:53:43 GMT

Hi Marco,

Yes, you can test this to verify your needs. It seems that you can also combine %XDATAPRFL and %PERIODICSEARCHCONF..

Kind regards,
Øyvind

RE: LTE connection timeout & retry policy

barbiz — Wed, 04 Jan 2023 17:24:07 GMT

Dear Oyvind,

thanks for your answer!

I also see that it is possible to change the %XDATAPRFL setting and that has impact in the periodic search conf.

Would you recommend to try the %XDATAPRFL which seems an easier approach first?

Marco

RE: LTE connection timeout & retry policy

Øyvind — Wed, 04 Jan 2023 07:53:54 GMT

Sorry for the slow response to this ticket.

The solution to this issue could be the use of Periodic cell search configuration %PERIODICSEARCHCONF, this is found in LTE Link Controller library under lte_lc_periodic_search.

For your application it may also be good to use Modem domain event notification %MDMEV and Search Status 1 which allows your application "a chance to stop the modem from using more power on searching networks from possibly weaker radio condition". The modem team also suggests the following:

Limit the used bands with band lock as much as possible, i.e. inform modem which bands can be skipped.
Resolve suitable relation between light searches and full searches for the use case. Let's say for example that application tries to send data once per hour. The relation of light and full search could be that only light search is done by default (modem deactivated after light search done), but if sending of data has failed 4 times in a row, then full search is allowed for the fifth attempt to send data. This way we make sure that all bands are fully scanned at least at some point (every fifth attempt).

Let me know how this works for you!

Kind regards,
Øyvind

RE: LTE connection timeout & retry policy

barbiz — Wed, 28 Dec 2022 11:48:46 GMT

Hello,

I can add some information. In the following pic you can see the power consumption profile of the DK with the UDP example, running with 3600s PSM sleep, 60s active time, as well as 3600s data send period.

In the first pic you can see the power consumption when the DK is powered up inside a shield box (= no network). You can see there are continuos retries of approximate duration of 10 minutes. How to control the backoff time? We want the retries to be at least one hour away, in order not to waste battery power.

In the second pic you can see the DK being powered on with the shield box open (= network) and after the first connection, while in PSM, the shieldbox is closed (= non network). The retry pattern restarts after one our when the software tries to send data. Again: how can we control a timeout and a backoff? And try the next hour just for less minutes?

Thanks in advance! Let me know if anything is unclear.

RE: LTE connection timeout & retry policy

barbiz — Tue, 27 Dec 2022 10:04:55 GMT

Hello Oyvind,

our SDK 2.0.2 is and modem FW is 1.3.3.

60 minutes is the PSM time given by network.

We don't really understand the behavior. From our application, we call lte_lc_connect_async() and then we listen to events. I see that lte_lc_connect_async() then calls connect_lte().

analyzing the connect_lte() function - which is called with blocking = false - it seems that it just exits without blocking and it is not influencing the behaviour of the modem, the CONFIG_LTE_NETWORK_TIMEOUT is not even used with blocking=false. Do I miss something?
also, this function does not explain what happens if modem is connected but THEN the network goes out of reach (let's say I put it in a shieldbox AFTER it completed the first connection)

Thanks in advance!

RE: LTE connection timeout & retry policy

Øyvind — Tue, 27 Dec 2022 09:14:13 GMT

Hello Marco,

Due to Christmas Holidays our team is lower staffed than normal and some delays in our answers must be expected. We apologize for the inconvenience.

Can you provide some information on what version of the modem FW and nRF Connect SDK you are running?

[quote user=""]we use nb-iot and PSM with wake-up period of 60 minutes.[/quote]

Is this the PSM that the network provides you?

[quote user=""]what behavior should we expect?[/quote]

From nrf\lib\lte_link_control\lte_lc.c

static int connect_lte(bool blocking)
{
	int err;
	int tries = (IS_ENABLED(CONFIG_LTE_NETWORK_USE_FALLBACK) ? 2 : 1);
	enum lte_lc_func_mode current_func_mode;
	enum lte_lc_nw_reg_status reg_status;
	static atomic_t in_progress;

	if (!is_initialized) {
		LOG_ERR("The LTE link controller is not initialized");
		return -EPERM;
	}

	/* Check if a connection attempt is already in progress */
	if (atomic_set(&in_progress, 1)) {
		return -EINPROGRESS;
	}

	err = lte_lc_nw_reg_status_get(&reg_status);
	if (err) {
		LOG_ERR("Failed to get current registration status");
		return -EFAULT;
	}

	/* Do not attempt to register with an LTE network if the device already is registered.
	 * This check is needed for blocking _connect() calls to avoid hanging for
	 * CONFIG_LTE_NETWORK_TIMEOUT seconds waiting for a semaphore that will not be given.
	 */
	if ((reg_status == LTE_LC_NW_REG_REGISTERED_HOME) ||
	    (reg_status == LTE_LC_NW_REG_REGISTERED_ROAMING)) {
		LOG_DBG("The device is already registered with an LTE network");

		err = 0;
		goto exit;
	}

	if (blocking) {
		k_sem_init(&link, 0, 1);
	}

	do {
		tries--;

		err = lte_lc_func_mode_get(&current_func_mode);
		if (err) {
			err = -EFAULT;
			goto exit;
		}

		/* Change the modem sys-mode only if it's not running or is meant to change */
		if (!IS_ENABLED(CONFIG_LTE_NETWORK_DEFAULT) &&
		    ((current_func_mode == LTE_LC_FUNC_MODE_POWER_OFF) ||
		     (current_func_mode == LTE_LC_FUNC_MODE_OFFLINE))) {
			err = lte_lc_system_mode_set(sys_mode_target, mode_pref_current);
			if (err) {
				err = -EFAULT;
				goto exit;
			}
		}

		err = lte_lc_func_mode_set(LTE_LC_FUNC_MODE_NORMAL);
		if (err || !blocking) {
			goto exit;
		}

		err = k_sem_take(&link, K_SECONDS(CONFIG_LTE_NETWORK_TIMEOUT));
		if (err == -EAGAIN) {
			LOG_INF("Network connection attempt timed out");

			if (IS_ENABLED(CONFIG_LTE_NETWORK_USE_FALLBACK) &&
			    (tries > 0)) {
				if (sys_mode_target == sys_mode_preferred) {
					sys_mode_target = sys_mode_fallback;
				} else {
					sys_mode_target = sys_mode_preferred;
				}

				err = lte_lc_func_mode_set(LTE_LC_FUNC_MODE_OFFLINE);
				if (err) {
					err = -EFAULT;
					goto exit;
				}

				LOG_INF("Using fallback network mode");
			} else {
				err = -ETIMEDOUT;
			}
		} else {
			tries = 0;
		}
	} while (tries > 0);

exit:
	atomic_clear(&in_progress);

	return err;
}

Kind regards,
Øyvind