BG96 not using network operator list from sim correctly

When I dial the network with an international roaming sim and automatic network selection (AT+COPS=0,2) it takes several minutes to form a connection even though I am restricting the access technology to just NB1 and the band to only B20:

22/12/19 16:26:02.302 INFO: TX> "AT+QCFG="band",0F,000000400A0E189F,0000000000080000,1"
22/12/19 16:26:02.312 INFO: RX> "AT+QCFG="band",0F,000000400A0E189F,0000000000080000,1"
22/12/19 16:26:02.321 INFO: RX> "OK"
22/12/19 16:26:02.328 INFO: TX> "AT+QCFG="nwscanseq",030102,1"
22/12/19 16:26:02.335 INFO: RX> "AT+QCFG="nwscanseq",030102,1"
22/12/19 16:26:02.342 INFO: RX> "OK"
22/12/19 16:26:02.348 INFO: TX> "AT+QCFG="iotopmode",1,1"
22/12/19 16:26:02.355 INFO: RX> "AT+QCFG="iotopmode",1,1"
22/12/19 16:26:02.361 INFO: RX> "OK"
22/12/19 16:26:02.368 INFO: TX> "AT+QCFG="nwscanmode",3,1"
22/12/19 16:26:02.375 INFO: RX> "AT+QCFG="nwscanmode",3,1"
22/12/19 16:26:02.381 INFO: RX> "OK"

If instead I force the netwok operator (AT+COPS=1,2,“23415”) the dialling takes only a couple of seconds. I believe that the problem is that the BG96 is not correctly using the network operator list from the sim. If I get the list from the sim (AT+CPOL?), the 23415 network (UK Vodafone) is there but it would seem that it isn’t getting preferred in the automated dialling case.

I spoke with Vodafone UK about this and they suggested that perhaps the BG96 is using the start of the IMSI to get the MCC/MNC information rather than using the list from the sim. If that is the case then it would explain the problem because on international roaming sims the IMSI doesn’t hold MCC/MNC information at the start (for example I have a Vodafone UK NB1 sim with IMSI=901288002369837).

FYI, here is the output I have when I call ATI:

22/12/19 16:26:01.960 INFO: TX> "ATI"
22/12/19 16:26:01.964 INFO: RX> "ATI"
22/12/19 16:26:01.969 INFO: RX> "Quectel"
22/12/19 16:26:01.974 INFO: RX> "BG96"
22/12/19 16:26:01.979 INFO: RX> "Revision: BG96MAR02A07M1G"

Can you explain if there is a way to get the automatic dialling to use the network operator list on the sim card correctly? It is very bad for power consumption to take many minutes to dial the network.

Hi pdaj_mm,

Normally ,The search order of the module is as follows
RPLMN -> EHPLMN/HPLMN -> UPLMN -> OPLMN

So For one new sim card , the first time network search will take a lot time , but when you finished network search , the result will be saved to RPLMN , the second time network search
will be quick .

Hi Stephen,

That has not been my experience. I wonder if it is because I am saving battery by powering down the BG96 between each transmission? Would that cause it to lose these settings?

Also can you clarify what the worst case network connection time is once RPLMN has been stored?

Paul.

BG96_test_2.pdf (30.5 KB) BG96_test_1.pdf (28.4 KB)

Stephen,

Here are some dialling procedures to demonstrate the problem. In BG96_test_1.pdf it shows the commands for a network dialup from cold start (8 minutes to connect) and a network dialup from a cold start with the PLMN supplied by my application (5 seconds to connect).

In BG96_test_2.pdf it shows the commands for two sequential automated network dialups from cold starts showing that the PLMN information is not persisting across a power down and back up of the device. I also included the command to show that the sim holds the correct PLMN information to use at the second location in the list.

Note that in both tests the access technology is limited to NB1 and the band is limited to B20 only.

I have two problems with these test results:

  1. The BG96 is clearly not storing the PLMN information in non-volatile memory. Is there a way to get this to happen so I don’t have to maintain the last successfully connected PLMN in my application?
  2. Even from a cold start, the dialling time of 8 minutes seems far too long to me. The BG96 should be getting the preferred PLMN list from the sim and dialling those PLMNs first. In this case it would be the second PLMN and the dialling time should be much less than 8 minutes. Indeed I could do this at the application layer by using the results of the AT_CPOL? command to feed into the AT+COPS=1,2,xxxxx command, but this just feels like the application is performing work that the BG96 should be doing itself on an AT+COPS=0,2. My feeling at the moment is that my own test code that maintains the last connected PLMN is already superior in dialling time to what the BG96 is providing. That makes no sense to me.

Paul.

Hi pdaj_mm

Pls remove all AT+COPS and AT+CPOL in your application , and try again ,

Since when BG96 modules is powered on , It will search network automatically. if you input searching cmd , it will interrupt the normally searching procedure .

BG96_test_3.pdf (32.5 KB)

Hi Stephen,

That didn’t seem to make much difference (and also it prevents me from changing the network responses to numeric format: AT+COPS=0,2). BG96_test_3.pdf shows the results with two back to back network dialups with no clear connection time improvement in the second dial. Both take several minutes.

Still the best performance that I can get by far is to dial up automatically (AT+COPS=0,2), then determine the connected PLMN with AT+COPS? and save that in my application. Then, in future dialling, apply the saved PLMN with AT+COPS=1,2,“23415”. With this procedure I have one very expensive network dialup initially (several minutes at high power consumption) but then all subsequent dialups are much faster (a few seconds). It just seems very bizarre to me that I have to do this work in the application and the automatic dialling of the BG96 is so much worse.

Paul.

I found a somewhat similar issue:

I tried the AT+QPRTPARA command. Is this an expected response?

28/12/19 13:48:32.298 INFO: TX> "AT+QPRTPARA?"
28/12/19 13:48:32.303 INFO: RX> "AT+QPRTPARA?"
28/12/19 13:48:32.517 INFO: RX> "+QPRTPARA: 1,1,1,1"
28/12/19 13:48:32.523 INFO: RX> "OK"

FYI, I realised that I can use AT+COPS=3,2 to set the numeric format without restarting the dialling process.

BG96_GPRS_test_4.pdf (23.6 KB)

For comparison with the NB1 dial up, here is a GPRS dial up with the same procedure from a cold start (BG96_GPRS_test_4.pdf).

As you can see the connection times are totally different: less than 10s from BG96 power on to connected for both GPRS connection attempts, compared with several minutes for NB1.

In fact I would expect the GPRS connection to take longer than NB1 because there are four bands to search for GPRS and only one band for NB1.

Can you explain why NB1 takes so long to dial successfully from a cold start?

GSM has something to do with Nb’s different search methods. GSM searches net roughly first, then carefully first , while NB searches one by one from low to high.

you can google it for detail

Stephen,

Some questions for you:

  1. Is it expected from a cold start of the BG96 that GSM will connect in under 10s and NB1 will connect in several minutes even if restriced to a single access technology and band (NB1, B20)?
  2. Is it expected that the BG956 will not store any PLMN information in non-volatile memory and hence each cold start for NB1 will perform a long dial up procedure?

Paul.

Hi pdaj_mm,

I attached a table for your reference. ( cold start) ,
image

In BG96 , There are NV rom can save RPLMN list , when you reboot Bg96 , the module will read RPLMN first, the procedure should be very quick .

Hi Stephen,

Thanks for this info. So I think I have been correct about the optimal way to use the BG96 in a battery powered device with occasional network activity (say one transmission per day). My method is this:

  1. BG96 is normally not powered. This saves the current draw of the BG96 in power saving mode for the 23h57m that the device doesn’t need to transmit.
  2. BG96 is powered on. No PLMN information will have been stored as there is no non-volatile memory.
  3. Wait for the first network registration time (I wonder if this should be less than shown in your table if the band is restricted to a single band (B20)? Surely the BG96 doesn’t scan the other bands in this case?)
  4. Save in the device’s non-volatile memory the PLMN information (the BG96 doesn’t store it when it is powered off)
  5. Transmit data
  6. Power the BG96 off for another 23h57m
  7. Power the BG96 on.
  8. Apply the PLMN from the device to the BG96
  9. Wait for the second network registration time
  10. Transmit data
  11. Go to 6)

Hi pdai_mm,

For your scenario , you can use BG96 PSM mode , i attached related docs as below .
https://cnquectel-my.sharepoint.com/:f:/g/personal/america-fae_quectel_com/ElrQukmsbmZCnCqWq3Br_3YB_lbEtSSutS3vphG2Am2NsA?e=2DDrND

BTW, If you lock at B20 , the time of network search should be quick.

Hi Stephen,

Unfortunately the current draw of the BG96 in PSM is still quite a lot more than our device uses so we are much less power efficient to use PSM than to switch off the device completely.

You say that if the device is restricted to only band 20 the search will be fast. Here are my results:
First NB1 connection with all bands searched = 25 minutes
First NB1 connection with B20 only = 3 minutes

First GSM connection with all bands searched = 10 seconds

Is that in line with what you expect? Because it seems very strange to me that GSM is so much faster than NB-IoT. For a battery powered device this makes NB-IoT a waste of time if GSM is available, but my understanding is that it is intended to be a lower power protocol.

Just the first time NB1 connection waste time , the second time ,it will read RPLMN list ,and connect quickly .

Yes, but if you don’t use PSM and instead power off the BG96 between transmissions, then every connection is a first connection. Hence every NB1 connection takes several minutes.

IF band is selected - maximum minute (first time)
IF is more from minute - bad signal…
for next time ~5 second at 900 MHz band