Problems provisioning APN from SIMs

Problems provisioning APN from SIMs

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

Hi,

A request for some advice.

We're having trouble provisioning APNs for SIMs from certain Telcos, and
it seems to be because of the ordering of providers in serviceproviders.xml

Vodafone and O2 are cases in point. SIMs from either of those two
telcos, used in the UK, will fail to default to the standard APNs upon
provisioning.

In the case of Vodafone it is because an ASDA Mobile provider is present
before the Vodafone provider and both have the same MNC.

It's similar with O2, excepting that in this case there's a Giffgaff
provider before the O2 provider which thus is used for the APN.

I suspect our use case is similar to many others. We have a headless
embedded Linux board and we want an installation technician to be able
to put a SIM in, power the unit, and have everything else automated.

It looks like we may have to implement a custom serviceproviders.xml,
which would be a shame.

I am wondering if there are any other algorithmic or configuration
alternatives we can look at, such as Ofono trying different contexts
until one works? Or some additional Ofono provisioning configuration?

Thanks,

Alex

Re: Problems provisioning APN from SIMs

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

Hi Alex,

On 06/03/2015 07:07 AM, Alex J Lennon wrote:
> Hi,
>
> A request for some advice.
>
> We're having trouble provisioning APNs for SIMs from certain Telcos, and
> it seems to be because of the ordering of providers in serviceproviders.xml
>

Ordering should have nothing to do with it.

> Vodafone and O2 are cases in point. SIMs from either of those two
> telcos, used in the UK, will fail to default to the standard APNs upon
> provisioning.
>
> In the case of Vodafone it is because an ASDA Mobile provider is present
> before the Vodafone provider and both have the same MNC.
>
> It's similar with O2, excepting that in this case there's a Giffgaff
> provider before the O2 provider which thus is used for the APN.

oFono's provisioning logic is very conservative.  We do not allow 
duplicate contexts.  Thus if the database contains multiple matches for 
a MCC/MNC pair, the provisioning will fail.  The way to to deal with 
this is to extend the database with additional identifying information. 
  E.g. SPN.  I believe we added the SPN field to 
Mobile-Broadband-Provider-Info XML DTD.  But I haven't been paying much 
attention whether the database has been properly populated with this 
field since then.

>
> I suspect our use case is similar to many others. We have a headless
> embedded Linux board and we want an installation technician to be able
> to put a SIM in, power the unit, and have everything else automated.
>
> It looks like we may have to implement a custom serviceproviders.xml,
> which would be a shame.
>
> I am wondering if there are any other algorithmic or configuration
> alternatives we can look at, such as Ofono trying different contexts
> until one works? Or some additional Ofono provisioning configuration?
>

oFono can use any information present on the SIM to try and figure out 
the SIM provider.  We already provide MCC, MNC and SPN to the 
provisioning plugin.

However, this really depends on the underlying provisioning database to 
contain this information and do so in such a way that duplicates are not 
possible.

Regards,
-Denis

Re: Problems provisioning APN from SIMs

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

Hi Denis,

On 04/06/2015 21:52, Denis Kenzior wrote:
> Hi Alex,
>
> On 06/03/2015 07:07 AM, Alex J Lennon wrote:
>> Hi,
>>
>> A request for some advice.
>>
>> We're having trouble provisioning APNs for SIMs from certain Telcos, and
>> it seems to be because of the ordering of providers in
>> serviceproviders.xml
>>
>
> Ordering should have nothing to do with it.
>

Yes, the ordering is relevant. We (like other ofono users I suspect)
have to allow multiple APNs or the automatic provisioning process fails.

Then, the first context found in serviceproviders.xml is what is used by
default for the connection.

An example of the problem is that if you use a major telco's SIM card in
the UK - Vodafone, ofono will then default to using an ASDA mobile
context because of the ordering, and this will fail.

My feeling is that a larger provider like Vodafone or O2 should be the
default, not ASDA mobile or GiffGaff, and this should thus come first
(understanding that the Ofono project does not control this document)

>> Vodafone and O2 are cases in point. SIMs from either of those two
>> telcos, used in the UK, will fail to default to the standard APNs upon
>> provisioning.
>>
>> In the case of Vodafone it is because an ASDA Mobile provider is present
>> before the Vodafone provider and both have the same MNC.
>>
>> It's similar with O2, excepting that in this case there's a Giffgaff
>> provider before the O2 provider which thus is used for the APN.
>
> oFono's provisioning logic is very conservative.  We do not allow
> duplicate contexts.  Thus if the database contains multiple matches
> for a MCC/MNC pair, the provisioning will fail.  The way to to deal
> with this is to extend the database with additional identifying
> information.  E.g. SPN.  I believe we added the SPN field to
> Mobile-Broadband-Provider-Info XML DTD.  But I haven't been paying
> much attention whether the database has been properly populated with
> this field since then.
>

Allowing Duplicates - Not by default no, but you have a boolean
parameter in there and logic to allow for duplicate contexts, which we
have to enable (as do others I think from my Googling on this) or the
provisioning support is unusable with the upstream serviceproviders.xml
as far as I can see.

I'm not entirely sure how the RilModem fork relates to Ofono but you can
see they had the same problem

/*

	* TODO: review with upstream. Default behavior was to

	* disallow duplicate APN entries, which unfortunately exist

	* in the mobile-broadband-provider-info db.

	*/


ref: https://github.com/rilmodem/ofono/blob/master/plugins/provision.c#L55

SPN - Thanks. This seems promising. I will investigate the SPN values
further.

>>
>> I suspect our use case is similar to many others. We have a headless
>> embedded Linux board and we want an installation technician to be able
>> to put a SIM in, power the unit, and have everything else automated.
>>
>> It looks like we may have to implement a custom serviceproviders.xml,
>> which would be a shame.
>>
>> I am wondering if there are any other algorithmic or configuration
>> alternatives we can look at, such as Ofono trying different contexts
>> until one works? Or some additional Ofono provisioning configuration?
>>
>
> oFono can use any information present on the SIM to try and figure out
> the SIM provider.  We already provide MCC, MNC and SPN to the
> provisioning plugin.
>
> However, this really depends on the underlying provisioning database
> to contain this information and do so in such a way that duplicates
> are not possible.
>

I'll have a think about what might be achievable by adding SPN
information into serviceproviders.xml.

Thanks again,

Alex


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 11480 bytes --]

Re: Problems provisioning APN from SIMs

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

Hi Alex,

 >> Ordering should have nothing to do with it.
>>
>
> Yes, the ordering is relevant. We (like other ofono users I suspect)
> have to allow multiple APNs or the automatic provisioning process fails.
>
> Then, the first context found in serviceproviders.xml is what is used by
> default for the connection.
>
> An example of the problem is that if you use a major telco's SIM card in
> the UK - Vodafone, ofono will then default to using an ASDA mobile
> context because of the ordering, and this will fail.
>
> My feeling is that a larger provider like Vodafone or O2 should be the
> default, not ASDA mobile or GiffGaff, and this should thus come first
> (understanding that the Ofono project does not control this document)

It has been years since I wrote the provisioning plugin, but the intent 
was to fail if looking up MCC/MNC combo resulted in multiple matches. 
So this may be a bug, or you might be using some custom behavior.  But 
in the end, ordering of the entries should not affect the provisioning 
logic.

> Allowing Duplicates - Not by default no, but you have a boolean
> parameter in there and logic to allow for duplicate contexts, which we
> have to enable (as do others I think from my Googling on this) or the
> provisioning support is unusable with the upstream serviceproviders.xml
> as far as I can see.

Then that's the problem.  The intent was never to allow duplicates. 
That boolean was added for tools/lookup-apn only.

>
> I'm not entirely sure how the RilModem fork relates to Ofono but you can
> see they had the same problem
>
> /*
>
> 	* TODO: review with upstream. Default behavior was to
>
> 	* disallow duplicate APN entries, which unfortunately exist
>
> 	* in the mobile-broadband-provider-info db.
>
> 	*/
>
>
> ref: https://github.com/rilmodem/ofono/blob/master/plugins/provision.c#L55
>
> SPN - Thanks. This seems promising. I will investigate the SPN values
> further.

The real fix is to fix mobile-broadband-provider-info.

>
>>>
>>> I suspect our use case is similar to many others. We have a headless
>>> embedded Linux board and we want an installation technician to be able
>>> to put a SIM in, power the unit, and have everything else automated.
>>>
>>> It looks like we may have to implement a custom serviceproviders.xml,
>>> which would be a shame.
>>>
>>> I am wondering if there are any other algorithmic or configuration
>>> alternatives we can look at, such as Ofono trying different contexts
>>> until one works? Or some additional Ofono provisioning configuration?
>>>
>>
>> oFono can use any information present on the SIM to try and figure out
>> the SIM provider.  We already provide MCC, MNC and SPN to the
>> provisioning plugin.
>>
>> However, this really depends on the underlying provisioning database
>> to contain this information and do so in such a way that duplicates
>> are not possible.
>>
>
> I'll have a think about what might be achievable by adding SPN
> information into serviceproviders.xml.
>

Regards,
-Denis

Re: Problems provisioning APN from SIMs

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]



On 04/06/2015 23:03, Denis Kenzior wrote:
> Hi Alex,
>
> >> Ordering should have nothing to do with it.
>>>
>>
>> Yes, the ordering is relevant. We (like other ofono users I suspect)
>> have to allow multiple APNs or the automatic provisioning process fails.
>>
>> Then, the first context found in serviceproviders.xml is what is used by
>> default for the connection.
>>
>> An example of the problem is that if you use a major telco's SIM card in
>> the UK - Vodafone, ofono will then default to using an ASDA mobile
>> context because of the ordering, and this will fail.
>>
>> My feeling is that a larger provider like Vodafone or O2 should be the
>> default, not ASDA mobile or GiffGaff, and this should thus come first
>> (understanding that the Ofono project does not control this document)
>
> It has been years since I wrote the provisioning plugin, but the
> intent was to fail if looking up MCC/MNC combo resulted in multiple
> matches. So this may be a bug, or you might be using some custom
> behavior.  But in the end, ordering of the entries should not affect
> the provisioning logic.
>
>> Allowing Duplicates - Not by default no, but you have a boolean
>> parameter in there and logic to allow for duplicate contexts, which we
>> have to enable (as do others I think from my Googling on this) or the
>> provisioning support is unusable with the upstream serviceproviders.xml
>> as far as I can see.
>
> Then that's the problem.  The intent was never to allow duplicates.
> That boolean was added for tools/lookup-apn only.
>
>>
>> I'm not entirely sure how the RilModem fork relates to Ofono but you can
>> see they had the same problem
>>
>> /*
>>
>>     * TODO: review with upstream. Default behavior was to
>>
>>     * disallow duplicate APN entries, which unfortunately exist
>>
>>     * in the mobile-broadband-provider-info db.
>>
>>     */
>>
>>
>> ref:
>> https://github.com/rilmodem/ofono/blob/master/plugins/provision.c#L55
>>
>> SPN - Thanks. This seems promising. I will investigate the SPN values
>> further.
>
> The real fix is to fix mobile-broadband-provider-info.

Yes I would agree with that.

As I come to investigate this, I find I am concerned about using the
Service Provider Name as I can't see any registry for those names, it's
free text for display purposes, so I assume it is at least possible it
might change without warning,
whereas there does seem to be a registry for MCC/MNC (e.g.
http://www.mcc-mnc.com/)

I am thinking it may be preferable to use the registered IIN number from
the ICCID - http://www.controlf.net/iccid/

This seems a more controlled way of providing the uniqueness needed to
me and presumably it's easy enough to read the ICCID out, if it's not
already being read out.

What are your thoughts?

Regards,

Alex

Re: Problems provisioning APN from SIMs

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]



On 04/06/2015 23:59, Alex J Lennon wrote:
>
> On 04/06/2015 23:03, Denis Kenzior wrote:
>> Hi Alex,
>>
>>>> Ordering should have nothing to do with it.
>>>>
>>> Yes, the ordering is relevant. We (like other ofono users I suspect)
>>> have to allow multiple APNs or the automatic provisioning process fails.
>>>
>>> Then, the first context found in serviceproviders.xml is what is used by
>>> default for the connection.
>>>
>>> An example of the problem is that if you use a major telco's SIM card in
>>> the UK - Vodafone, ofono will then default to using an ASDA mobile
>>> context because of the ordering, and this will fail.
>>>
>>> My feeling is that a larger provider like Vodafone or O2 should be the
>>> default, not ASDA mobile or GiffGaff, and this should thus come first
>>> (understanding that the Ofono project does not control this document)
>> It has been years since I wrote the provisioning plugin, but the
>> intent was to fail if looking up MCC/MNC combo resulted in multiple
>> matches. So this may be a bug, or you might be using some custom
>> behavior.  But in the end, ordering of the entries should not affect
>> the provisioning logic.
>>
>>> Allowing Duplicates - Not by default no, but you have a boolean
>>> parameter in there and logic to allow for duplicate contexts, which we
>>> have to enable (as do others I think from my Googling on this) or the
>>> provisioning support is unusable with the upstream serviceproviders.xml
>>> as far as I can see.
>> Then that's the problem.  The intent was never to allow duplicates.
>> That boolean was added for tools/lookup-apn only.
>>
>>> I'm not entirely sure how the RilModem fork relates to Ofono but you can
>>> see they had the same problem
>>>
>>> /*
>>>
>>>     * TODO: review with upstream. Default behavior was to
>>>
>>>     * disallow duplicate APN entries, which unfortunately exist
>>>
>>>     * in the mobile-broadband-provider-info db.
>>>
>>>     */
>>>
>>>
>>> ref:
>>> https://github.com/rilmodem/ofono/blob/master/plugins/provision.c#L55
>>>
>>> SPN - Thanks. This seems promising. I will investigate the SPN values
>>> further.
>> The real fix is to fix mobile-broadband-provider-info.
> Yes I would agree with that.
>
> As I come to investigate this, I find I am concerned about using the
> Service Provider Name as I can't see any registry for those names, it's
> free text for display purposes, so I assume it is at least possible it
> might change without warning,
> whereas there does seem to be a registry for MCC/MNC (e.g.
> http://www.mcc-mnc.com/)
>
> I am thinking it may be preferable to use the registered IIN number from
> the ICCID - http://www.controlf.net/iccid/
>
> This seems a more controlled way of providing the uniqueness needed to
> me and presumably it's easy enough to read the ICCID out, if it's not
> already being read out.

No that's not going to work. I see ICCID prefix is the same for e.g. O2
and Tesco Mobile, being MCC and MNC

UK

	

O2

	

894411

	

23410

	

UK

	

Tesco Mobile
<http://autopuk.grg.com/>(MVNO <http://en.wikipedia.org/wiki/MVNO> of O2)

	

894411

	

23410


Regards,

Alex


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7084 bytes --]

Re: Problems provisioning APN from SIMs

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Hi Alex,

 > As I come to investigate this, I find I am concerned about using the
> Service Provider Name as I can't see any registry for those names, it's
> free text for display purposes, so I assume it is at least possible it
> might change without warning,
> whereas there does seem to be a registry for MCC/MNC (e.g.
> http://www.mcc-mnc.com/)

In theory MCC/MNC should be unique even for MVNOs.  But some have not 
followed that properly.  SPN is free-form, but it probably doesn't 
change all that often.  The provisioning database would have to be 
updated frequently.

If you know you will only need a subset of particular providers, it 
might be easier to develop your own provisioning db.

>
> I am thinking it may be preferable to use the registered IIN number from
> the ICCID - http://www.controlf.net/iccid/
>
> This seems a more controlled way of providing the uniqueness needed to
> me and presumably it's easy enough to read the ICCID out, if it's not
> already being read out.
>

I don't recall that any provisioning (proprietary or otherwise) database 
used ICCID as an identifier.  Not saying it won't work, so feel free to 
investigate what is possible.

Regards,
-Denis

Re: Problems provisioning APN from SIMs

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 5049 bytes --]

Hi Alex,

>>>> Ordering should have nothing to do with it.
>>>> 
>>> 
>>> Yes, the ordering is relevant. We (like other ofono users I suspect)
>>> have to allow multiple APNs or the automatic provisioning process fails.
>>> 
>>> Then, the first context found in serviceproviders.xml is what is used by
>>> default for the connection.
>>> 
>>> An example of the problem is that if you use a major telco's SIM card in
>>> the UK - Vodafone, ofono will then default to using an ASDA mobile
>>> context because of the ordering, and this will fail.
>>> 
>>> My feeling is that a larger provider like Vodafone or O2 should be the
>>> default, not ASDA mobile or GiffGaff, and this should thus come first
>>> (understanding that the Ofono project does not control this document)
>> 
>> It has been years since I wrote the provisioning plugin, but the
>> intent was to fail if looking up MCC/MNC combo resulted in multiple
>> matches. So this may be a bug, or you might be using some custom
>> behavior.  But in the end, ordering of the entries should not affect
>> the provisioning logic.
>> 
>>> Allowing Duplicates - Not by default no, but you have a boolean
>>> parameter in there and logic to allow for duplicate contexts, which we
>>> have to enable (as do others I think from my Googling on this) or the
>>> provisioning support is unusable with the upstream serviceproviders.xml
>>> as far as I can see.
>> 
>> Then that's the problem.  The intent was never to allow duplicates.
>> That boolean was added for tools/lookup-apn only.
>> 
>>> 
>>> I'm not entirely sure how the RilModem fork relates to Ofono but you can
>>> see they had the same problem
>>> 
>>> /*
>>> 
>>>    * TODO: review with upstream. Default behavior was to
>>> 
>>>    * disallow duplicate APN entries, which unfortunately exist
>>> 
>>>    * in the mobile-broadband-provider-info db.
>>> 
>>>    */
>>> 
>>> 
>>> ref:
>>> https://github.com/rilmodem/ofono/blob/master/plugins/provision.c#L55
>>> 
>>> SPN - Thanks. This seems promising. I will investigate the SPN values
>>> further.
>> 
>> The real fix is to fix mobile-broadband-provider-info.
> 
> Yes I would agree with that.
> 
> As I come to investigate this, I find I am concerned about using the
> Service Provider Name as I can't see any registry for those names, it's
> free text for display purposes, so I assume it is at least possible it
> might change without warning,
> whereas there does seem to be a registry for MCC/MNC (e.g.
> http://www.mcc-mnc.com/)

actually the TS.25 database from GSMA is the authority. Seems to have over 1800 entries at the moment, but a lot of operators are listed more than once. I think it is a combination of band + MCC + MNC.

The SPN is indeed free form and can change at any time (even during a phone call). They are however a really good indication when you want to differentiate MNVO. But it means you have to update your database. However that needs to happen anyway since even MCC and MNC change all the time. I think that TS.25 updates twice per month.

So some operators are actually assigned parts of the IMSI to their MNVO. I have seen operator documents clearly identifying which part of their ISMI pool is for MNVO a, b, c etc. However that is the exception and not the rule. However one big operator could be easily and clearly identified if you get their documents.

> I am thinking it may be preferable to use the registered IIN number from
> the ICCID - http://www.controlf.net/iccid/
> 
> This seems a more controlled way of providing the uniqueness needed to
> me and presumably it's easy enough to read the ICCID out, if it's not
> already being read out.

As you saw by yourself, that is not going to help. The ICCID is pretty much useless in this regard. It is listed in the TS.25 database, but I have no idea how accurate that is. Some operators only list the first 2 digits and some have no entry at all.

Keep in mind that TS.25 does not list MNVO and with that I am thinking that ICCID prefix is free to assign by the operator. Same as the decision to use parts of the IMSI to identify a MVNO. Some of them might really do not care at all and just map this internally without visibility to the user equipment.

The reason why you can write your own provision plugin and create your own database is exactly this. oFono does not want to be in this business. That is up to the end product to put a proper database in place or write a smarter plugin that can use extra information from the device or SIM card. It is plugin based for that exact reason. And I am surely providing something better than mobile-broadband-provider-info is easy and worth while doing. It is just not an oFono objective.

One thing we spent a lot of time on is to get the MNC length correct. Since it can be 2 or 3 digits, we do make sure that whatever modem quirk it takes, we read the right value from the SIM card. Without this you would be in an even worse position.

Regards

Marcel

Re: Problems provisioning APN from SIMs

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]

Hi Alex,

>>>> Ordering should have nothing to do with it.
>>>> 
>>> 
>>> Yes, the ordering is relevant. We (like other ofono users I suspect)
>>> have to allow multiple APNs or the automatic provisioning process fails.
>>> 
>>> Then, the first context found in serviceproviders.xml is what is used by
>>> default for the connection.
>>> 
>>> An example of the problem is that if you use a major telco's SIM card in
>>> the UK - Vodafone, ofono will then default to using an ASDA mobile
>>> context because of the ordering, and this will fail.
>>> 
>>> My feeling is that a larger provider like Vodafone or O2 should be the
>>> default, not ASDA mobile or GiffGaff, and this should thus come first
>>> (understanding that the Ofono project does not control this document)
>> 
>> It has been years since I wrote the provisioning plugin, but the
>> intent was to fail if looking up MCC/MNC combo resulted in multiple
>> matches. So this may be a bug, or you might be using some custom
>> behavior.  But in the end, ordering of the entries should not affect
>> the provisioning logic.
>> 
>>> Allowing Duplicates - Not by default no, but you have a boolean
>>> parameter in there and logic to allow for duplicate contexts, which we
>>> have to enable (as do others I think from my Googling on this) or the
>>> provisioning support is unusable with the upstream serviceproviders.xml
>>> as far as I can see.
>> 
>> Then that's the problem.  The intent was never to allow duplicates.
>> That boolean was added for tools/lookup-apn only.
>> 
>>> 
>>> I'm not entirely sure how the RilModem fork relates to Ofono but you can
>>> see they had the same problem
>>> 
>>> /*
>>> 
>>>    * TODO: review with upstream. Default behavior was to
>>> 
>>>    * disallow duplicate APN entries, which unfortunately exist
>>> 
>>>    * in the mobile-broadband-provider-info db.
>>> 
>>>    */
>>> 
>>> 
>>> ref:
>>> https://github.com/rilmodem/ofono/blob/master/plugins/provision.c#L55
>>> 
>>> SPN - Thanks. This seems promising. I will investigate the SPN values
>>> further.
>> 
>> The real fix is to fix mobile-broadband-provider-info.
> 
> Yes I would agree with that.
> 
> As I come to investigate this, I find I am concerned about using the
> Service Provider Name as I can't see any registry for those names, it's
> free text for display purposes, so I assume it is at least possible it
> might change without warning,
> whereas there does seem to be a registry for MCC/MNC (e.g.
> http://www.mcc-mnc.com/)
> 
> I am thinking it may be preferable to use the registered IIN number from
> the ICCID - http://www.controlf.net/iccid/
> 
> This seems a more controlled way of providing the uniqueness needed to
> me and presumably it's easy enough to read the ICCID out, if it's not
> already being read out.

and I stand corrected here. The TS.25 (formerly known as SE13) is just for collection of operator and networks if the need arises by the equipment to map them.

The actual MCC and MNC assignments are ITU T E.212 and the (U)SIM Header of the ICCID is ITU T E.118 document.

And as a side note, the (U)SIM Header is between 6 and 7 digits. The MNC is between 2 and 3 digits.

Regards

Marcel

Re: Problems provisioning APN from SIMs

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Hi Marcel,

 >
> The actual MCC and MNC assignments are ITU T E.212 and the (U)SIM Header of the ICCID is ITU T E.118 document.
>
> And as a side note, the (U)SIM Header is between 6 and 7 digits. The MNC is between 2 and 3 digits.

So in theory E212 should be enough.  Each operator (MVNO or otherwise) 
should have its own MCC/MNC identifier.  However, this practice came in 
too late to the game, so this is not true in reality.

Many operators assigned MVNO SIMs out of their pool, resulting in chaos. 
  Hence why DBs resort to playing tricks with EFspn, EFgid1, etc.

I suspect newly issues SIMs do not have this problem, but it might still 
be relevant for SIMs issued in the past.

Regards,
-Denis

Re: Problems provisioning APN from SIMs

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]



On 05/06/2015 01:48, Denis Kenzior wrote:
> Hi Marcel,
>
> >
>> The actual MCC and MNC assignments are ITU T E.212 and the (U)SIM
>> Header of the ICCID is ITU T E.118 document.
>>
>> And as a side note, the (U)SIM Header is between 6 and 7 digits. The
>> MNC is between 2 and 3 digits.
>
> So in theory E212 should be enough.  Each operator (MVNO or otherwise)
> should have its own MCC/MNC identifier.  However, this practice came
> in too late to the game, so this is not true in reality.
>
> Many operators assigned MVNO SIMs out of their pool, resulting in
> chaos.  Hence why DBs resort to playing tricks with EFspn, EFgid1, etc.
>
> I suspect newly issues SIMs do not have this problem, but it might
> still be relevant for SIMs issued in the past.

Thanks Denis, Marcel. I appreciate the responses.

So, in essence there seems no good way to do this in the general case.
The core problem is that multiple operators have the same MCC/MNC, and
this is a result of virtual operators piggy-backing on top of
established operators and being given the same MCC/MNC.

The mobile-broadband-providers XML document accurately expresses this,
but as a result provides multiple providers with the same MCC/MNC code
and there needs to be a good way to distinguish between them.

Using the display name may work but strikes me as a potential can of
worms as this does not seem particularly controlled.

For now I may just have to remove the virtual operators from the copy of
mobile-broadband-providers I use.

Thanks/Regards, Alex

Re: Problems provisioning APN from SIMs

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]



On 05/06/2015 10:29, Alex J Lennon wrote:
>
> On 05/06/2015 01:48, Denis Kenzior wrote:
>> Hi Marcel,
>>
>>> The actual MCC and MNC assignments are ITU T E.212 and the (U)SIM
>>> Header of the ICCID is ITU T E.118 document.
>>>
>>> And as a side note, the (U)SIM Header is between 6 and 7 digits. The
>>> MNC is between 2 and 3 digits.
>> So in theory E212 should be enough.  Each operator (MVNO or otherwise)
>> should have its own MCC/MNC identifier.  However, this practice came
>> in too late to the game, so this is not true in reality.
>>
>> Many operators assigned MVNO SIMs out of their pool, resulting in
>> chaos.  Hence why DBs resort to playing tricks with EFspn, EFgid1, etc.
>>
>> I suspect newly issues SIMs do not have this problem, but it might
>> still be relevant for SIMs issued in the past.
> Thanks Denis, Marcel. I appreciate the responses.
>
> So, in essence there seems no good way to do this in the general case.
> The core problem is that multiple operators have the same MCC/MNC, and
> this is a result of virtual operators piggy-backing on top of
> established operators and being given the same MCC/MNC.
>
> The mobile-broadband-providers XML document accurately expresses this,
> but as a result provides multiple providers with the same MCC/MNC code
> and there needs to be a good way to distinguish between them.
>
> Using the display name may work but strikes me as a potential can of
> worms as this does not seem particularly controlled.
>
> For now I may just have to remove the virtual operators from the copy of
> mobile-broadband-providers I use.
>
> Thanks/Regards, Alex
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono
>

fwiw mobile-broadband-provider-info has now been updated to give O2 and
Vodafone preference over the ASDA Mobile and Giff Gaff virtual operators.

ref: https://bugzilla.gnome.org/show_bug.cgi?id=750330

So with a patch for Ofono to support multiple APNs and this latest
database O2/Vodafone SIMS should work out of the box in the UK.

Regards, Alex