Cell registration in low CSQ environments

IoT Modules LPWA Module
1

Hello,
I’m hoping someone might have some insight into some interesting behaviour we are seeing with the BG95.

We are testing our device in remote locations with a rather poor cell signal. The CSQ we are seeing from the BG95 is <=16.
Most of the units we have tested have been provisioned and tested in our office with good cell reception. This includes registering the BG95 on the network and sending data to our servers.
When we drove these units out to a remote location for testing, everything seemed to work well despite the low cell signal.

However, we recently deployed some new units that had been sitting idle for quite some time. We did not connect these units to the cell network at our office, but instead drove out to the remote location and tried to connect from there. These units were unable to register on the cell network and thus could not connect to our server.

We have noticed that even in our office, if a unit sits idle for some time (ie. no connecting to the cell network for weeks), then the next time we do connect, there’s a much longer initial registration.

We did a test with one of these units that was unable to register, in that we brought it back into a good CSQ environment and registered it on the cell network. Then, when we brought it back to the poor CSQ environment it seemed to work fine.

It seems as if once a unit has registered onto the cell network in a good environment, it can be moved into a poor environment and still communicate. However, if a unit is brought directly to a poor CSQ environment, it will be unable to register on the cell network.

I have several questions regarding our observations:

  1. In a poor CSQ environment, is it expected that initial cell registration should fail or take an extremely long time?
  2. Are there network registration parameters that are stored in the BG95 to allow subsequent cell registrations to be quick.
  3. Do the stored parameters “time out” with a full re-negotiation necessary if a unit sits idle for a long time?

Thanks very much!

2

Dear Sachrmed,

Thank you for reaching out!

What you’re observing can happen in weak-coverage deployments and it’s generally expected behavior, especially for the first attach after a long idle period.

To answer your questions,

  1. Yes, in weak coverage (low RSRP/RSRQ/SNR), initial registration can take a long time or fail because the
    modem may not reliably camp on a suitable cell and can enter OOS / periodic re-scan cycles.

  2. Yes, after a successful attach in good signal, the BG95 may leverage stored acquisition history / last-known
    frequencies/RAT to speed up later reacquisition, so it can work again when moved back to poor coverage.

  3. No fixed “timeout”, but this advantage can be lost with hard power cuts/resets, clearing history, or if the serving
    cell/frequency environment changes while the unit is idle.

I hope this clarifies your questions. Kindly reach out to me if you need any further clarification or further analysis.

Best Regards,
Aghelan

3

Hi Aghelan, that’s very helpful!

Do you have any insight into why the initial registration may fail, but registering in a good environment first then transporting to a poor environment works?
Some sort of packet loss on a handshake I imagine, but is there anything we can do to mitigate that?

Thanks again!

4

Dear @sachrmed ,

Thank you for reaching out again.

To address your query, when a unit is taken directly into weak coverage, it may fail before “registration/attach” even starts: the BG95 must first find a cell, synchronize, and decode MIB/SIB, and then satisfy the network’s cell selection criterion (S) to camp; in weak RF this step can fail repeatedly.

If it can’t find any “available/suitable” frequency/cell, the BG95 enters OOS (Out of Service) and then only retries on periodic scan timers (30s/45s/60s phases), so it can look like “it never registers.”

After a successful attach in a good-signal area, the BG95 starts future searches with a system scan, trying historical frequencies saved in NV (up to 10) (queryable via AT+QNWCFG=“acqdb”), instead of immediately doing a wide band scan, this is why “register once in good signal, then move to poor signal” often works.

Mitigation you may apply:

  1. Don’t rapid power-cycle in weak coverage; let it complete the scan/OOS cycle.

  2. Enable priority frequency saving: AT+QNWCFG=“freq_save”,1 (intended for cases where direct power-down prevents history being saved properly, and it speeds next startup registration).

  3. For confirmation, share AT+QNWCFG=“acqdb” output and a short log showing AT+CEREG? progression at the weak site.

Best Regards,
Aghelan