Gathering SIM operator MCC/MNC without reading EFad

[Dan Williams]

On Wed, 2013-10-23 at 09:27 +0200, Aleksander Morgado wrote:
> Hey Dan,
> 
> >>
> >> The generic implementation of load_operator_identifier() in MMSim (the
> >> one reading the MCC/MNC of the operator which issued the SIM card)
> >> currently relies on reading the 'MNC length' field from the EFad file in
> >> the SIM card. Once it knows the MNC length, it will just get the [3+MNC
> >> length] bytes long prefix of the IMSI string.
> >>
> >> Now, the 'MNC length' field in the EFad file is *optional*; so even in
> >> successful reads of EFad, the field may just be unavailable. I was
> > 
> > It's optional in the GSM specifications (11.11) but has been mandatory
> > in USIM specifications (131.102) since at least 2001.  So we'll only
> > encounter this case when the SIM is really old.  (Unless they have still
> > recently distributed non-USIMs in places where 3G networks took longer
> > to deploy, like Africa or India?)
> > 
> 
> I've got 2 SIMs myself, one from Orange (3 years old) and one for
> Vodafone (less than one year old); and none of those come with the MNC
> length field in EFad. I've also checked this in an AT&T card from the
> US, and this one also didn't have the mnc length field in EFad.

Is the SIM file read completing without errors, just that the length of
the file is not enough to include the digit?

To determine SIM vs. USIM, try reading EFdir and looking for
"A0000000871002" (the USIM AID; RID=A000000087, Application Code=1002)
in the results, which shouldn't ever show up in a non-USIM SIM.

AT+CRSM=178,12032,1,4,0
+CRSM:
144,0,"61184F10A0000000871002F310FFFF89080000FF50045553494DFFFFFFFFFFFFFFFFFFFFFFFF"

If you get that, we would expect EFad to be at least 4 bytes long.

I tested 10 SIMs, including 3UK, Vodafone, T-Mobile US, AT&T, and
Verizon LTE.  Results:

Non-USIM:
* 2x T-Mobile cards that have 2 or 3-byte EFad; one responds "00FF" and
the other "00FFFF".  Both have an IMSI that starts with "310260".  Note
that for a long time the US allocated 3-digit MNCs that only ended with
0, specifically for compatibility with CDMA/GSM, so it's unclear if
these SIMs really have 3-digit MNCs or not.

* One Verizon/Vodafone card, which *does* have a 4-byte EFad reading
"00000102" indicating a 2-byte MNC.  MCC/MNC indicate Vodafone NL.

USIMs:
* Mix of Verizon LTE, AT&T, O2, 3UK; all respond to EFdir request and
all provide a 4-byte EFad including the MNC length.  Oddly the O2 SIM
reports 3-byte MNC and AT&T MCC/MNC for the IMSI...

But it's actually worse...

http://www.mail-archive.com/ofono@ofono.org/msg14709.html

Denis brings up some good points; given the variability, is it wise to
expose this value that we may be getting wrong?  Perhaps we should
simply advertise the operator code if we can figure it out (eg, if EFad
is 4-byte) and the Operator Name if we have it, and leave it up to
clients to use some kind of database if they want to?

Also, in the next few years, more countries will begin assigning 3-digit
MNCs alongside the existing 2-digit ones.  Hopefully they won't
overlap...

Dan

> >> looking for a way to handle this case, when I found that the IMSI is
> >> defined as follows (3GPP TS23.003):
> >>
> >>   IMSI is composed of three parts:
> >>   i) Mobile Country Code (MCC) consisting of three digits. The MCC
> >> identifies uniquely the country of domicile of the mobile subscriber;
> >>   ii) Mobile Network Code (MNC) consisting of two or three digits for
> >> GSM applications. The MNC identifies the home GSM PLMN of the mobile
> >> subscriber. The length of the MNC (two or three digits) depends on the
> >> value of the MCC. A mixture of two and three digit MNC codes within a
> >> single MCC area is not recommended and is outside the scope of this
> >> specification.
> >>   iii) Mobile Subscriber Identification Number (MSIN) identifying the
> >> mobile subscriber within a GSM PLMN
> >>
> >> In particular, it explicitly states that there shouldn't be any MCC
> >> which allows both 2 and 3 digit MNCs. With that in mind, I compiled a
> >> list of MCC values with 3 digit MNCs (using the m-b-p-i). This ends up
> >> giving us a method like this:
> >>
> >> From the list above; the only MCC for which I have doubts is '405'.
> >> India has several MCCs assigned: '404' has all 2-digit MNCs; while '405'
> >> seems to have both 2-digit and 3-digit MNCs (in the m-b-p-i database I
> >> mean). My assumption right now is that the 2-digit MNCs with a '405' MCC
> >> really should all have an extra leading zero to make them 3-digit. It
> >> would be great if someone could confirm this, though.
> > 
> > http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212B-2013-PDF-E.pdf
> > 
> > Note these two entries, which are separate:
> > 
> > Reliance Infocomm Ltd, Andhra Pradesh    405 012
> > Reliance Infocomm Ltd, Kolkata           405 12
> > 
> > If we added a leading zero here, these would appear the same network.
> > But technically, when coding these into the SIM in EFplmnsel or even in
> > the UMTS LAI over-the-air, they would be:
> > 
> > 405-012 = 04 05 21
> > 405-12  = 04 F5 21
> > 
> 
> Can't we try to detect in this case the 2-digit MNC looking at the 'F'
> there? And wouldn't it be '04 15 F2'?
> > and thus not the same.  Plus, I think it gets worse.  If you're actually
> > parsing the IMSI, you really have no idea whatsoever how many digits the
> > operator used.  In this case of 405 12/012, we might certainly get it
> > wrong if somebody bought a SIM in Kolkata.
> > 
> 
> That's quite unfortunate... But doesn't this case fall out of 3GPP
> standards then? 3GPP explicitly says that MCC cannot mix MNC lengths.
> 
> > Do you have a SIM that has this problem?  Can you check if it's actually
> > USIM or not?
> > 
> 
> How do I check that?