A SIM fails to register to the RAN if MT cannot speak 2G=GERAN?

frr · November 9, 2022, 11:23am

Dear polite fellow forum inhabitants,

excuse my noob question. I work as a support techie / FAE in a company selling various industrial PC’s, Ethernet and fieldbus communication gadgets. I have fond memories of dial-up modems and episodic experience with WWAN modems over the last two decades. So much for my background.

The problem at hand is: I have a PC with an M.2 WWAN modem. The original was a Sierra 7455, which I tried replacing with a Quectel EM05 upon the first sign of trouble And, I have a SIM card, supplied by the customer, who’s running a fleet of vehicles with on-board computers containing WWAN modems - obviously, my customer is not willing to switch his GSM operator just to get that pesky tablet to work. The “culprit operator” here is O2 CZ. Czech Republic is an EU member country - the trio of operators here are the ex-incumbent O2 (no longer owned by O2 international), T-Mobile and Vodafone. We have various RAN’s in bands 1/3/7/8/20/28. Curiously to me, as I have started debugging this particular case yesterday, I’ve noticed that apparently, no 3G networks are in sight anymore (WCDMA, UTRAN, whatever). All the transponders I can see are either 2G=GERAN or 4G=LTE=E-UTRA (I don’t have a 5G=NR modem in my claws yet). So much for the environment.

Now for the problem description: with either of those two modems (Sierra/Quectel), the O2 SIM at hand fails to achieve network registration. The SIM is present, AT+CPIN? says READY, but AT+CREG says “searching for network”.

ati3
Quectel
EM05
Revision: EM05EFAR06A04M4G

OK
AT+CPIN?
+CPIN: READY

OK
at+creg?
+CREG: 0,2

OK
AT+QNWINFO
+QNWINFO: "FDD LTE","23002","LTE BAND 20",6300

OK
AT+QENG="servingcell"
+QENG: "servingcell","SEARCH"

OK
AT+QENG="neighbourcell"
+QENG: "neighbourcell intra","LTE",6300,235,-13,-83,-52,-20,41,255,20,8,62
+QENG: "neighbourcell intra","LTE",6300,432,-20,-92,-60,-20,31,255,20,8,62
+QENG: "neighbourcell inter","LTE",9260,335,-12,-80,-58,-20,39,0,20,255
+QENG: "neighbourcell inter","LTE",100,-,-,-,-,-,-,0,20,6

AT+QENG="servingcell"
+QENG: "servingcell","LIMSRV","LTE","FDD",230,02,64407B4,335,9260,28,3,3,5E7,-96,-10,-68,10,27

OK
AT+QENG="neighbourcell"
+QENG: "neighbourcell intra","LTE",6300,235,-16,-99,-65,-20,24,255,20,8,62
+QENG: "neighbourcell intra","LTE",6300,432,-15,-98,-72,-20,26,255,20,8,62
+QENG: "neighbourcell inter","LTE",100,-,-,-,-,-,-,0,20,6
+QENG: "neighbourcell inter","LTE",1379,-,-,-,-,-,-,0,20,5

at+qcops=7,1
+QCOPS: "4G","","56047","LTE BAND 3",1379,5e7,3A,-84,-115,-10
+QCOPS: "4G","","56047","LTE BAND 20",6300,5e7,1B0,-68,-100,-15
+QCOPS: "4G","","56047","LTE BAND 28",9260,5e7,14F,-63,-96,-16
+QCOPS: "4G","","56031","LTE BAND 1",473,3866,FC,-75,-102,-8
+QCOPS: "4G","","56031","LTE BAND 3",1579,3866,B4,-75,-111,-15
+QCOPS: "4G","","56031","LTE BAND 20",6200,3866,AE,-71,-99,-11
+QCOPS: "4G","","56063","LTE BAND 1",300,8dcc,CC,-75,-109,-14
+QCOPS: "4G","","56063","LTE BAND 3",1849,8dcc,2C,-69,-107,-18
+QCOPS: "4G","","56063","LTE BAND 20",6400,8dcc,84,-70,-100,-13

If I try a T-Mobile SIM, I do get registered to an LTE RAN, I can launch a PDP context etc. (Windows just get a breath of LTE connectivity, the bar-graph is all green, an IP address gets assigned etc.) Not with the O2 SIM.

The two modems that I’ve mentioned so far, have at least one aspect in common: they lack support for 2G GERAN. They support 3G and 4G only. Does that ring a bell maybe? Could it be that the O2 network requires a registration to a 2G transponder first, and only then allows the MT to switch to 4G ? Is this a feature of the network, or is this somehow encoded in the SIM and a local decision of the MT (modem) based on SIM contents?

I’ve also tried with two other modems:

an old Sierra MC8092 is 2G/3G. Registers happily to 2G GERAN and runs that way. Does not report any 3G carriers in sight.

at+csq
+csq: 31,99

OK
AT+CPIN?
+CPIN: READY

OK
AT+CREG?
+CREG: 0,1

OK
AT+COPS?
+COPS: 0,0,"O2-CZ",0

OK
AT!GSTATUS?
!GSTATUS:
Current Time:  173              Temperature: 21
Bootup Time:   0                Mode:        ONLINE
System mode:   GSM              PS state:    Attached
GSM band:      GSM900
GSM channel:   122
GMM (PS) state:REGISTERED       NORMAL SERVICE
MM (CS) state: IDLE             NORMAL SERVICE
Serving Cell:  519 (GSM 1800   )
RX level (dBm):-47.8750         LAC:         05E7 (1511)
GPRS State:    GPRS STANDBY     Cell ID:     00009C9D (40093)

the low-cost EC200T from Quectel. Capable of 2G/3G/4G, just lacking a WWAN driver in Windows. But the USB Serial interfaces do work, the modem reports 2G and 4G towers in sight and I can see that it quickly locks onto a 4G cell… well at least it says “CREG: 0,1”, just the string “NOCONN” in QENG=“servingcell” raises some doubt on my part…

ati
Quectel
EC200T
Revision: EC200TEUHAR05A01M16

OK
at+cpin?
+CPIN: READY

OK
at+creg?
+CREG: 0,1

OK
at+cgreg?
+CGREG: 0,1

OK
at+QCFG="band"
+QCFG: "band",0x93,0x1a0080800c5

OK
at+qnwinfo
+QNWINFO: "FDD LTE","23002","LTE BAND 3",1379

OK
at+qcfg="nwscanseq"
+QCFG: "nwscanseq",0

OK
AT+QENTAT+QENG="neighbourcell"
+CME ERROR: 50
AT+QENG="neighbourcell"
+QENG: "neighbourcell inter","LTE",44192,65535,-140,-20,-,-,0,2,2,7
+QENG: "neighbourcell inter","LTE",44892,65535,-140,-20,-,-,0,2,2,7
+QENG: "neighbourcell inter","LTE",45490,65535,-140,-20,-,-,0,2,2,7
+QENG: "neighbourcell inter","LTE",100,65535,-140,-20,-,-,0,4,20,6
+QENG: "neighbourcell inter","LTE",2850,65535,-140,-20,-,-,0,4,20,6
+QENG: "neighbourcell inter","LTE",1404,65535,-140,-20,-,-,0,4,20,5
+QENG: "neighbourcell inter","LTE",6300,65535,-140,-20,-,-,0,4,20,4
+QENG: "neighbourcell inter","LTE",9260,65535,-140,-20,-,-,0,4,20,4
+QENG: "neighbourcell inter","LTE",100,7,-121,-14,-,-,2,4,20,6
+QENG: "neighbourcell inter","LTE",6300,235,-92,-15,-,-,27,4,20,4
+QENG: "neighbourcell inter","LTE",9260,335,-81,-14,-,-,38,4,20,4
+QENG: "neighbourcell","GSM",68,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",519,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",122,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",115,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",111,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",101,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",93,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",89,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",87,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",86,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",83,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",75,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",69,0,0,0,0,0,255,0,0
+QENG: "neighbourcell","GSM",111,1,20,4,255,0,14,-63,687
+QENG: "neighbourcell","GSM",69,1,20,4,255,0,11,-72,531
+QENG: "neighbourcell","GSM",519,1,20,4,255,0,14,-74,507

OK
AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","LTE","FDD",230,02,644075A,58,1379,3,5,5,5E7,-93,-12,-78,11,30

What an amazing sensitivity, BTW. The longest list of towers that I’ve seen so far, here in my lab.
And, kudos to Quectel for providing the “neighbourcell” listing. Very useful.

I’m still waiting for an EC25-E to arrive in a day or two, which should allow me to probe the bands and carriers and practical Windows behavior a little further.

Ho hum.
As for the EM05 - is there some way for me to debug the mystery further?
Increase verbosity, add some progress messages related to network registration (CREG), make the modem comment on SIM contents? I’ve also noticed the AT+CRSM command - would this possibly be any use to identify any “service configuration features” relevant to the observed misbehavior?

frr · November 11, 2022, 2:09pm

I’m inclined to believe that this is something about the SIM card or the behavior of this particular operator’s network.

I’ve got the EC25E in my hands (2G/3G/4G) and with the culprit SIM by O2, I see the following behavior:
On start-up, the modem registers to the GSM network (GERAN).
I do get a +CREG: 0,1 and in Windows, the O2 CZ connection profile gets offered.
Only after I tell Windows to “connect”, the modem shifts to the LTE RAN. AT+CREG still says “registered”, and the “servingcell” attribute indicates LTE technology.
If I then tell Windows to “disconnect” from the profile, the modem remains registered to the LTE RAN.

at
OK
at+cpin?
+CPIN: READY

OK
at+creg?
+CREG: 0,1

OK
at+cops?
+COPS: 0

OK
AT+QENG="servingcell"
+QENG: "servingcell","SEARCH"

OK
AT+QENG="neighbourcell"
OK
AT+QENG="servingcell"
+QENG: "servingcell","SEARCH"

OK
AT+QENG="neighbourcell"
OK
AT+QCOPS=7,1

+QCOPS: "2G","O2 - CZ","23002","GSM 1800",519,5E7,9C9D,14,-63,43,1
+QCOPS: "2G","O2 - CZ","23002","GSM 900",69,5E7,9C9E,11,-63,43,1
+QCOPS: "2G","T-Mobile CZ","23001","GSM 900",26,3866,4EF7,37,-72,0,1
+QCOPS: "2G","T-Mobile CZ","23001","GSM 900",54,3866,5072,10,-72,0,1
+QCOPS: "2G","Vodafone CZ","23003","GSM 900",1006,8DCC,5E94,58,-59,0,1
+QCOPS: "4G","","56047","LTE BAND 3",1379,5e7,3A,-64,-93,-8
+QCOPS: "4G","","56047","LTE BAND 20",6300,5e7,EB,-53,-83,-12
+QCOPS: "4G","","56031","LTE BAND 20",6200,3866,AE,-54,-85,-13
+QCOPS: "4G","","56063","LTE BAND 3",1849,8dcc,2C,-60,-99,-18
+QCOPS: "4G","","56063","LTE BAND 20",6400,8dcc,84,-61,-90,-11

OK
AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","GSM",230,02,5E7,9C9D,14,519,0,-61,255,255,0,45,45,1,-,-,-,-,-,-,-,-,-,"-"

OK
AT+QENG="neighbourcell"
OK

### Here, I have told Windows to "connect" to the O2 CZ wireless connection profile

AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","LTE","FDD",230,02,6440700,235,6300,20,3,3,5E7,-83,-13,-52,1,40

OK
AT+QENG="neighbourcell"
+QENG: "neighbourcell intra","LTE",6300,235,-14,-83,-51,-20,40,4,20,8,62
+QENG: "neighbourcell inter","LTE",100,7,-8,-116,-98,-20,7,0,20,6
+QENG: "neighbourcell inter","LTE",1379,0,0,0,0,-20,0,0,20,5
+QENG: "neighbourcell","GSM",68,1,20,4,255,0,0,-1531,9
+QENG: "neighbourcell","GSM",519,1,20,4,255,0,14,-1069,35
+QENG: "neighbourcell","GSM",122,1,20,4,255,0,0,-1560,7
+QENG: "neighbourcell","GSM",115,1,20,4,255,0,0,-1388,14
+QENG: "neighbourcell","GSM",111,1,20,4,255,0,0,-1302,24
+QENG: "neighbourcell","GSM",101,1,20,4,255,0,0,-1674,-1
+QENG: "neighbourcell","GSM",93,1,20,4,255,0,0,-1391,18
+QENG: "neighbourcell","GSM",89,1,20,4,255,0,0,-1589,4

OK
at+CSQ
+CSQ: 29,99

OK
AT+COPS
OK
AT+COPS?
+COPS: 0,0,"O2 - CZ O2-CZ",7

OK

### Here, I have told Windows to "disconnect" the wireless connection profile

A/
+COPS: 0,0,"O2 - CZ O2-CZ",7

OK
AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","LTE","FDD",230,02,644075A,58,1379,3,5,5,5E7,-93,-14,-57,9,31

OK

I was wondering, if perhaps the first successful logon has changed something. But, not the case. After I move the SIM back to a modem that’s not capable of 2G, just 3G+4G (and 3G is absent in the Ether), I’m left with +CREG: 0,2 and the modem never registers to the LTE network.

frr · November 11, 2022, 4:00pm

Later I’ve also tried banning 2G on the EC25E - but, inbetween, I’d noticed that my LTE session was not very stable. The EC25E kept losing the carrier and kept reconnecting or even searching for network. So I took a closer look and I’ve noticed that without manual intervention, the modem gets instructed by the network to attach to some “urban high band”, with free data capacity but poor signal coverage. I went “oh crap, not this topic again, has it all been about this old game of hide and seek?” I myself have covered this years ago, at that time mostly on the 3G RAT. Perhaps I’ve been on the wrong track all the time, over the past few days?

It took me a few moments to limit the selection of bands = allow only band 20 @ 800 MHz, which has the strongest signal by far. That’s using the AT+QCFG=“band” command. After that, my LTE service became reliable again. That was with 2G still enabled.

Next, I went on to disable 2G, and to leave only 4G=LTE enabled. Done that using the AT+QCFG=“nwscanmode” command. I entered the command, and restarted the EC25E for a good measure. After the reset, I verified that my settings stuck, yes they did, and indeed, the familiar misbehavior was back = no service, no WWAN connection profile advertised by the Windows systray applet. Identical behavior to the EM7455 / EM05.

So: my hypothesis still holds water. The one that with O2, 2G is needed to get the modem registered to the network. Modems without 2G capability cannot register to 4G.

snowgum · November 12, 2022, 7:03am

It might tell us something if we look at the contents of a couple of SIM files.

Firstly, Operator controlled PLMN selector with Access Technology at SIM address 0x6F61.

We read this with the AT command AT+CRSM=176,28513,0,0,0

Secondly, User controlled PLMN selector with Access Technology at SIM address 0x6F60.

Read with AT+CRSM=176,28512,0,0,0

As the names suggest, we can change the contents of the second of these only.

frr · November 12, 2022, 12:17pm

@snowgum thanks for offering help

I’ve taken two samples, from an O2 SIM and a T-Mobile SIM, using the EC25E modem.

O2 CZ = the “cuplrit” SIM

at+CREG?
+CREG: 0,1

OK
# HPLMN
AT+CRSM=176,28514,0,0,0
+CRSM: 144,0,"32F020400032F0208000"

OK
# OPLMN
AT+CRSM=176,28513,0,0,0
+CRSM: 144,0,"62F270000022F210000012F901000012F470000032F401000012F610000002F210000002F602000002F480000022F810000082F610000052F099000006F230000082F450000022F601000042F010000042F210000052F530000092F304000032F820000064F010000062F860000024F420000006F520000025F010000072F220000022F010000082F010000042F419000052F720000024F520000042F610000022F020000072F812000056F501000033F430000012F830000005F510000042F820000004F110000073F010000016F701000072F610000044F001000054F400000092F410000072F410000027F270000005F221000025F510000035F042000014F202000036F930000014F677000015F520000034F440000024F010000082F240000014F720000092F5500000"

OK
# UPLMN
AT+CRSM=176,28512,0,0,0
+CME ERROR: 100

# FPLMN
AT+CRSM=176,28539,0,0,0
+CRSM: 144,0,"32F01032F030FFFFFFFFFFFF"

OK

T-Mobile CZ = my “control sample” for comparison

AT+CREG?
+CREG: 0,1

OK
# HPLMN
AT+CRSM=176,28514,0,0,0
+CRSM: 144,0,"32F010400032F0108000"

OK
# OPLMN
AT+CRSM=176,28513,0,0,0
+CRSM: 144,0,"62F21080C032F12080C012F91080C032F23080C022F21080C052F01080C022F82080C013006280C002F81080C062F02080C032F40380C012F43080C082F61080C052F51080C002F21080C012F60380C002F46180C024F42080C006F21080C052F09980C006F53080C002F60280C064F01080C082F45080C092F31480C042F22080C022F03080C022F63080C022F81080C002F80280C032F43380C012F47080C042F01080C054F24080C025F01080C032F80280C042F41980C016F70180C044F00180C062F86080C006F41080C082F63080C006F23080C006F51080C002F60180C064F00080C0FFFFFF0000FFFFFF0000FFFFFF0000FFFFFF0000FFFFFF0000"

OK
# UPLMN
AT+CRSM=176,28512,0,0,0
+CME ERROR: 100

# FPLMN
AT+CRSM=176,28539,0,0,0
+CRSM: 144,0,"32F02032F030FFFFFFFFFFFF"

OK

Comments welcome…

EDIT: I’ve noticed that there’s also a list of home PLMNs, and forbidden/failed PLMNs. I’ve included those in the dumps. I can see that the “forbidden” list mentions “local competition” = the other network operators, not an own network. No scandal here.
From reading elsewhere, I understand that the modem should try networks from the User-controlled PLMN list first, and from the Operator-controlled PLMN list second - is that correct?

EDIT: I’ve found the texts of some ETSI norms. Hmm!..

EDIT: looking at the definition of the Access Technology Identifier under EF_HPLMNwAcT, it’s not clear to me what those 4000 and 8000 decode to, and whether that actually matters…

snowgum · November 12, 2022, 11:41pm

In order:

PLMN: 23002, RAT: E-UTRAN/LTE
PLNN: 23002, RAT: UTRAN/WCDMA

The RAT encoding is given in 3GPP 31.102, section 4.2.5.

The PLMN encoding is given in 24.008, section 10.5.1.13. That gives a different encoding for 3-digit MNC values from what you might expect.

The OPLMN is indeed interesting.

AT+CRSM=176,28513,0,0,0

> +CRSM: 144,0,"62F270000022F210000012F901000012F470000032F401000012F610000002F210000002F602000002F480000022F810000082F610000052F099000006F230000082F450000022F601000042F010000042F210000052F530000092F304000032F820000064F010000062F860000024F420000006F520000025F010000072F220000022F010000082F010000042F419000052F720000024F520000042F610000022F020000072F812000056F501000033F430000012F830000005F510000042F820000004F110000073F010000016F701000072F610000044F001000054F400000092F410000072F410000027F270000005F221000025F510000035F042000014F202000036F930000014F677000015F520000034F440000024F010000082F240000014F720000092F5500000"

The first entry is 62F2700000.

That’s PLMN 26207, with no preferred RAT. It’s Telefónica Germany GmbH & Co. OHG according to: https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212B-2018-PDF-E.pdf

PLMN 23002 is not present there.

Unfortunately, they’ve provided a SIM with no UPLMN file for you to customise. Eg, I’ve set the RAT preference to 5G, 4G, 3G for PLMN 50501 on one of my SIMs

AT+CRSM=214,28512,0,0,15,"05F510080005F510400005F5108000"

I’d not seen that written, but I’d hope it’s the case.

The relative order between the HPLMN file and the OPLMN file might be very relevant to the problems you’re seeing.

23001 and 23003 are forbidden. This file is user editable.

frr · November 14, 2022, 3:10pm

@snowgum thanks again for your help - namely, for the interpretation of those results.

I don’t see a problem there, either, nor even a significant difference between O2 CZ vs. T-Mobile CZ. I’ve learned a bit about the technology though - for which I am grateful.

The key bit of data appears to be the list of Home PLMNs.
This one is analogous between O2 and T-Mobile.

The “Operator controlled PLMN selector” list basically means “peering partners of the home PLMNs”.

In our small country, apparently we have a single MCC and just 3 MNC’s. The HPLMN list mentions just the home operator at two different technologies. The “home MCC” is not mentioned in the EF_OPLMNwAcT. I.e. all the networks mentioned are “abroad”. It could be speculated that EU could have its own MCC, and operators would be active EU-wide - but, that’s not the case. The large holding companies such as Deutsche Telkom / T-Mobile apparently have local daughters that act as national-scale operators, each with its own MCC+MNC, and for traveling MT’s, roaming is used. (Nowadays with an EU-mandated EU-wide cap on roaming fees to end users.)

Note that in the EF_OPLMNwAcT, O2 CZ accepts any RAT, while the T-mobile SIM does limit the RAT selection. But, given that both SIM’s in the modems here try to register to the respective HPLMN, I’d argue that this difference in EF_OPLMNwAcT is irrelevant.

Interestingly, G2=GSM=GERAN does not seem to be mentioned in the AcT part of the HPLMN/OPLMN lists in my SIM cards, although the chapters of the TS31.102 standard do have the respective data types (flags). Yet the modems can see the GERAN, can register to it, and in the case of O2 CZ, it appears to be a a requirement, before the modem can switch to 4G=LTE=E-UTRA. I understand that the EF_HPLMNwAcT and EF_OPLMNwAcT are actually somewhat young in the evolution of 3GPP standards, and the modems can follow “more archaic ways” while negotiating access to the network…

Apparently, the actual explanation of my trouble is “deeper under the hood” - either something else in the SIM, or in the behavior of the operator’s network. If I understand correctly, we’re out of debugging tools at the MT end. And, I need to pester the operator to check out his auth logs. Ho hum.

As a side note, out of curiosity, I’ve cobbled together a proggie that reformats the HPLMN/OPLMN string into the constituent numbers. Adding a country or operator lookup and direct access to the modem would not be hard, but I just don’t have the time at the moment… Here is a transformed listing of the CRSM dumps provided above, sorted by MCC and MNC.

C:\Data\Prog\SIM>plmn o2_hplmn.txt
230:02:4000
230:02:8000

C:\Data\Prog\SIM>plmn o2_oplmn.txt
202:01:0000
204:08:0000
206:20:0000
214:07:0000
216:01:0000
218:03:0000
219:10:0000
220:01:0000
220:02:0000
222:01:0000
226:10:0000
228:01:0000
234:10:0000
238:02:0000
240:01:0000
242:01:0000
244:91:0000
246:01:0000
248:02:0000
250:99:0000
255:03:0000
257:02:0000
262:07:0000
268:06:0000
272:02:0000
274:01:0000
276:01:0000
278:21:0000
280:01:0000
282:04:0000
284:05:0000
286:01:0000
293:40:0000
294:01:0000
295:05:0000
334:03:0000
370:01:0000
401:01:0000
412:20:0000
416:77:0000
417:02:0000
420:01:0000
424:02:0000
425:02:0000
434:04:0000
440:10:0000
454:00:0000
460:01:0000
502:12:0000
505:01:0000
515:02:0000
520:01:0000
525:01:0000
530:24:0000
602:03:0000
605:02:0000
617:10:0000
639:03:0000
655:10:0000
722:07:0000

C:\Data\Prog\SIM>plmn tmo_hplmn.txt
230:01:4000
230:01:8000

C:\Data\Prog\SIM>plmn tmo_oplmn.txt
202:01:80C0
204:16:80C0
206:10:80C0
206:20:80C0
208:01:80C0
208:20:80C0
214:03:80C0
214:07:80C0
216:30:80C0
219:01:80C0
220:03:80C0
222:01:80C0
226:03:80C0
228:01:80C0
228:02:80C0
231:02:80C0
232:03:80C0
234:30:80C0
234:33:80C0
238:20:80C0
240:01:80C0
242:02:80C0
244:91:80C0
250:01:80C0
250:99:80C0
255:01:80C0
260:02:80C0
262:01:80C0
268:06:80C0
284:05:80C0
286:01:80C0
286:03:80C0
293:41:80C0
310:260:80C0
424:02:80C0
440:10:80C0
452:04:80C0
460:00:80C0
460:01:80C0
520:01:80C0
602:01:80C0
602:03:80C0
604:01:80C0
605:01:80C0
605:03:80C0
617:10:80C0

snowgum · November 14, 2022, 9:45pm

There’s a good reason for that. This mobile technology the world uses was originally meant for Europe’s internal use. “GSM” meant “Group Special Mobile” (in the translation from the French).

Back in the 1990s, Australia broke ranks, and adopted GSM, being the first country outside the EU to do so. The rest of the world followed, resulting in an acronym change to “Global System for Mobiles”. 3GPP is built from these foundations.

Going back to your initial post, I’m thinking you may have hit on the cause here.

I recall thinking that one of my SIMs here in Australia had similar behaviour many years ago. Unfortunately I haven’t found anything in the 3GPP standards to support this idea, but that can be like finding a needle in a haystack.

These SIM PLMN (with access technology) files are about preferences. Other than that, they do not restrict access (unlike the forbidden PLMN file, which does).

I’m not a c++ speaker. But on a quick look, I’m not sure whether your algorithm correctly decodes 130094 as 310490.

frr · November 14, 2022, 10:28pm

I haven’t seen that PLMN code in my dumps. But, T-Mobile does mention 130062, which decodes as 310260.
The decoding algorithm actually comes from here, only I’m not a fan of Python.

Thanks again for all your comments including the interesting history.

frr · November 23, 2022, 11:21am

BTW, someone in another forum has asked me about the result code of AT+CEER while in the goofy “can’t register” state. I can reproduce that for +CREG: 0,2. I haven’t been able to observe or reproduce +CREG: 0,3 this time around. Here goes the result code:

AT+CEER
+CEER: 5,38

OK

As per documentation:
5 = “PS LTE cause” = the error response has arrived from the network (not locally) in LTE mode (not 3G, not 2G)
38 = “Concur service not supported by network”

Not too explanatory to me, but slightly better than nothing at all
This is from the EM05E. The Sierra EM7455 doesn’t support AT+CEER.

frr · December 5, 2022, 11:35am

Meanwhile, we have a couple more updates and a superficial conclusion: got a different SIM from the same operator, and that new SIM does work.

Let me just mention a couple more knobs under the hood that I got to know about along the way. All of the following steps were suggested by colleagues at work and fellow tinkerers in the interwebs.

I first tried using the culprit O2 SIM in a modem that supports 2G/3G/4G (the EC25E again) and cheked if the modem gets greeted by a “captive portal” once I try surfing. I.e. if possibly some sort of “activation” is required for the SIM to get the rest to work.
I was indeed greeted by some “captive portal” (my web browser has a way of detecting this arrangement in the ISP’s network) but the web page did not suggest a logon or some such. Instead, it opined that I had a WAP-only SIM card and that I should contact my operator’s helpdesk to rescue me. Instead, I followed the advice of my customer and entered an APN name for the public internet service (before that moment, I had not specified an APN name) and with that APN name entered, there was no “captive portal” anymore. I did have unobstructed full service, on that culprit SIM, with a modem that was capable of 2G, running at 4G.
Next, I swapped that SIM into a modem that’s 3G+4G only, and… “no service”, +CREG: 0,2.
= the “captive portal required” hypothesis was hereby disproven.

As mentioned, the next step was to try a different / fresh SIM card, from the same operator. Lo and behold, that works!

Yet another friendly soul out there (thanks, Jano) has suggested another possible cause: SIM vs. USIM. Perhaps the culprit SIM is just too old(-fashioned)? To test if the card has the USIM application loaded, he suggested the following commands:

AT+CSIM=14,"00A4000C023F00"
+CSIM: 4,"9000"

OK
AT+CSIM=14,"00A4000C022F00"
+CSIM: 4,"9000"
OK

Interpretation: as both the commands have returned OK (a result other than an ERROR), this card should be a USIM. And, both my O2 SIM cards have returned this result.

Jano has also mentioned another, manual way of looking for the USIM app: read the EFdir using AT+CRSM and interpret its entries. He provided a condensed explanation and pointers… based on that, I first discovered that there was a dedicated command called AT+CUAD for exactly that, next I found a generic explanatory note to AT+CRSM (hint: use “read record” rather than “read binary”) and I was able to google a better shaped recipe on how to use AT+CRSM and to interpret the EFdir entries.

My results:

The culprit SIM:

at+CUAD
+CUAD: "611B4F10A0000000871002FF47F00189000001FF50074F32205553494DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF""FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"

OK
AT+CRSM=178,12032,1,4,0
+CRSM: 144,0,"611B4F10A0000000871002FF47F00189000001FF50074F32205553494DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"

OK

The working SIM:

at+CUAD
+CUAD: "612E4F10A0000000871002FF47F00189000001FF50074F32205553494D7311A00F8002121781045F305F998203454150FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF""FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"

OK
AT+CRSM=178,12032,1,4,0
+CRSM: 144,0,"612E4F10A0000000871002FF47F00189000001FF50074F32205553494D7311A00F8002121781045F305F998203454150FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"

OK

Conclusions:

the AT+CUAD and the AT+CRSM for 0x2F00 i.e. EFdir do return the same data (I’m skipping the AT+CRSM output for the two dummy entries)
the USIM app, as identified by A000000087:1002 , is clearly there, in both cases. Only the proprietary trailing section differs - different length, different contents.
I have no clue whether this proprietary trailer could cause the symptoms observed or not.

The new, working O2 SIM has the UPLMN list defined but empty. Regarding the hypothesis that this is down to the different UPLMN list, empty vs. undefined - note that the working T-Mobile SIM also has the UPLMN list undefined (AT+CRSM throws an error).

Anyway - problem solved.

snowgum · December 5, 2022, 8:06pm

Thank you for your documenting your experience and analysis.

I’ll be following up on the details in due course to expand my own knowledge base.