Trying to register for one provider causes registration for other provider

IoT Modules LPWA Module
1

Hi,
I use a BG95-M4 and have observed the following issue:
I’m using a SIM-Card which obviously allows the registration for “26203” only.
If I try to register manually to a different provider, e.g. Vodafone (26202), the registration status changes to “registered, roaming” (5). So it looks like I was able to register for 26202. But when checking with at+cops? and at+qeng=“servingcell”, I see that I’m registered for a different provider “26203”:

at+cops=1,2,“26202”,9 //<< try to register for 26202
OK

+QIND: SMS DONE

+CEREG: 2 //<< searching

+CEREG: 5,“8FC”,“78CFDE”,9 //<< unsolicited registration status: registered (roaming)
at+cops?
+COPS: 0,2,“26203”,9 //<< but I’m registered at 26203 while 26202 was intended.

OK
at+qeng=“servingcell”
+QENG: “servingcell”,“NOCONN”,“NBIoT”,“FDD”,262,03,78CFDE,312,6154,20,0,0,8FC,-100,-11,-87,14,23

OK

I would expected that the registration status (CEREG) changes to “3” (not allowed) or “0”. But not that the modem tries to register at a different network than intended and the registration status shows “5”.

Best Regards,

Stefan

2

That’s the sort of behaviour I’d expect from the AT+COPS=4,2,"26202",9 command (manual/automatic mode).

Not manual mode, with a “1”.

3

Yes, indeed this is the behavior I would expect with mode “4”, but not with “1”.
Do you have any idea for a work-around for this issue? I guess this might be some bug in the BG95-M4.

Best Regards,

Stefan

4

Blacklist 26203 by including it in in the SIM’s EF_FPLMN (Forbidden PLMNs) file, if the file exists on your SIM.

Here is a worked example:

Read the existing file:

AT+CRSM=176,28539,0,0,0
+CRSM: 144,0,"05F510FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
OK

I have one entry there. “05F510” decodes to 50501 (Telstra AU).

Encoding 26203 (as six digits in order):

MCC 262
MNC 03F (“F” is a filler digit for places where MNCs are two-digit).

MCC digit 2, 6
MCC digit 1, 2
MNC digit 3, F
MCC digit 3, 2
MNC digit 2, 3
MNC digit 1, 0

See 3GPP 31.102, section 4.2.16 and 24.008, section 10.5.1.13

So 62F230 is the encoded value.

Add 26203 and write the file with two entries (12 digits = 6 bytes):

AT+CRSM=214,28539,0,0,6,"05F51062F230"
+CRSM: 144,0,""
OK

Finally, read it back:

AT+CRSM=176,28539,0,0,0
+CRSM: 144,0,"05F51062F230FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
OK
5

Hi,

thanks for the work-around.

Do you know if this is some issue with the modem itself? Will there be an update of the BG95 firmware?

And I discovered a similar issue regarding the radio access technology: I found that quite often the modem registers for eMTC instead of NB-IoT as required by the AT-COPS, even if I set the network search sequence to NB-IoT only:

AT+QCFG=“nwscanseq”,03 // << set to 3 to scan NB-IoT only
OK

AT+COPS=1,2,“26203”,9 //<< set to “9” for NB-IoT
OK

…

AT+CEREG?
+CEREG: 0,5

AT+QENG=“servingcell”
+QENG: “servingcell”,“CONNECT”,“eMTC”,“FDD”,262,03,7C4A02,409,6200,20,3,3 // << registration with eMTC, not expected
OK

Any idea on how to solve this?

Best Regards,

Stefan

6

It seems so. We’ve been using AT+COPS=1,2,<PLMN> (hard lock) and AT+COPS=4,2,<PLMN> (soft lock) on a wide variety of Quectel modems (mostly broadband) around the world for years as a user option in the ROOter project. There hasn’t been feedback that these locks are failing.

I take it that AT+COPS? is returning “8” rather than “9” as the RAT here.

The closest thing I have to your BG95 is a BG96, and it seems well-behaved. I’d be looking for a firmware upgrade.

7

Hi,

we cannot use the BG96 as we need the Band 31/72 support.

I will check for a firmware update.

Best Regards,

Stefan