LTE Link connecting is blocking?

[ExAg]

Hi

In the mqtt_simple example there is a line "modem_configure();" which establishes the LTE Link connection. If connecting the LTE link is not possible (for example no signal), this function never returns.

1. Is this the intention of this function or is there a possibility to configure a timeout?

2. Is it normal, that this function needs several minutes to establish the LTE link, if a provider is present?

regards

ExAg

[Simon]

1. Is this the intention of this function or is there a possibility to configure a timeout?

The reason it is blocking is due to some semaphores inside w_lte_lc_init_and_connect(..) in lte_lc.c. It will wait for the at_handler() to run and if the response is appropriate it will give up the semaphore and the program continues. See code below

//From w_lte_lc_init_and_connect() in lte_lc.c

k_sem_init(&link, 0, 1);
        //k_sem_init(&link, 1, 2);

	at_cmd_set_notification_handler(at_handler);

	if (at_cmd_write(normal, NULL, 0, NULL) != 0) {
		return -EIO;
	}

	k_sem_take(&link, K_FOREVER);

You can set a timeout, by running k_sem_take(&link, timeout_in_ms); where you specify the timeout in timeout_in_ms. 

Be aware that this may cause some unwanted results/race conditions etc., but I am not sure specifically what may happen.

 

2. Is it normal, that this function needs several minutes to establish the LTE link, if a provider is present?

 I will look into this and come back to you.

Best regards,

Simon

[Simon]

ExAg said:

2. Is it normal, that this function needs several minutes to establish the LTE link, if a provider is present?

The time to establish an LTE link varies depending on the signal strength and the network, it may more than 5 minutes at worst. If the network settings are stored on the modem, the connection only takes some few seconds. The network settings are automatically stored to the modem when the modem is turned off, through the call to AT+CFUN=0.

Best regards,

Simon

[Simon]

ExAg said:

What exacltly do you mean with "AT+CFUN=0"? As I understand, it's the same as "lte_lc_power_off()", what causes a power off of the modem?

I understand your confusion. I could not really find much documentation confirming that the modem settings are stored when calling this (except for a lot of  devzone cases: here, here and here). In the nRF91 AT Commands documentation it says the following:

"When commanding the device to power off, wait for OK to make sure that Non-volatile Memory (NVM) has been updated."

In the NCS documentation it says the following:

"If the modem is shut down gracefully before the next boot (by using AT+CFUN=0), it keeps the current setting."

But, I will report it internally and ask for a more explicit explanation.

 

ExAg said:

Where in my code do I have to place this funtion call?

Call it after a connection has been established. Try putting it right before while(1) loop, and remember to power cycle the device after this call has been made. 

If you are still having problems after this has been done, please tell me and I will report that as well, and get somebody to consider your issue more carefully.

Best regards,

Simon

[ExAg]

Hi Simon

First it looked better after calling "lte_lc_power_off()" and power cycling the board. The connection was estalished several times in a row after only some seconds. But I allways had such phases with faster connection times.
After some intense testing, I thing it is the same as before. Sometimes it needs only 2s or 3s, but sometimes it nees over 5 minutes or even longer to establish the LTE connection.

Are the settings persistantly stored on the modem after "lte_lc_power_off()" or are they deleted after erasing the target and downloading a new intel HEX file? Or even when resetting the target an starting a new debug session?

Best regards
Michael

[Simon]

I have reported your issue internally, and I am currently waiting for an answer. Could you provide a modem trace in the meantime?

Best regards,

Simon

[ExAg]

Hi Simon

I have attached the modem trace-2019-10-21T12-15-37.075Z.bintrace file. It took several minutes to establish the LTE connection for this trace file.

Best regards
Michael

[Simon]

Thank you. I have informed the ones responsible about the modem trace, and I will keep you updated when I get answers.

Best regards,

Simon

[Simon]

I got a reply. The reason for the long connection time is because the network rejects the Attach Procedure, due to cause #26 - insufficient resources (See 3GPP TS 24.301 Annex B, B.1). A timer with a timeout of 12 minutes is then started, and a new attempt to attach is done when the timer expires.

You should check with the operator if there is any plans to add more resources.

Best regards,

Simon

[ExAg]

Hi Simon

Thank you for this analysis. So it's our national provider who has not enough capacity. But this changes from minute to minute...
The only thing strange are theese 12 minutes you mentioned, because the duration until the connection can be everything between some seconds, some minutes to over 10 minutes. It's not always fix 12 minutes.

Best regards and thank you again
Michael

[Simon]

Sorry for the delay, I will ask internally tomorrow about this when I'm in office.

Best regards,

Simon

[Simon]

I got the following reply:

"Without log from different delays not possible to say what is the reason in that case but sounds like failures are not always because of ESM cause #26.

If same SIM is always used then there is no difference in "NAS Signalling Low Priority", that is one factor defining UE behavior. If UE is configured for "NAS Signalling Low Priority" next attempt for ESM cause #26 will be done after 10 seconds.
Network can include backoff timer value in reject and in that case delay given by network is used.
With different EMM and ESM reject causes UE might be allowed to retry after 10 seconds."

[ExAg]

Hi Simon

Thank you for your reply. What exactly does this mean for us? I do not really understand, i am not an expert on LTE network connections. Are we doing something wrong?

The only thing I can say is that we are always using the same SIM for all our tests.

regards Michael