On Mon, 2009-11-23 at 00:05 +0100, Michael 'Mickey' Lauer wrote:
> > > * dial prefix per country
> >
> > Do you mean the international dial code like +1 for the US, etc? We
> > could do this.
>
> Yes, that's what I mean.
>
> > At least in the case of the timezone db, I think there's better places
> > to put that. I realize not all platforms use glibc, but I have to
> > believe that even if you don't, there's going to be some timezone/locale
> > information already on the system that it would be a shame to duplicate.
>
> Ok, I agree with that. Could we at least add countries and provider's
> that do not necessarily offer mobile broadband but just telephony? A
> mapping from MCC MNC to country and provider name can be helpful in
> various ways.
I agree. This would turn m-b-p-i into cellular-provider-info.
When we are now talking about augmenting, I would like to make some
proposals also. I would like to have optional network-name field added
to gsm section. Virtual providers use same parent networks with same
mcc/mnc pairs and there's no way telling them a part. Here's an example
with two Finnish operators which both operate on DNA network:
DNA:
at+cops=0,2
at+cops?
+COPS: 0,2,"24412",2
GoMobile:
at+cops=0,2
at+cops?
+COPS: 0,2,"24412",2
Fortunately each provider conveniently happens to claim they "own" the
network they are operating in:
DNA:
at+cops=0,0
at+cops?
+COPS: 0,0,"dna",2
GoMobile:
at+cops=0,0
at+cops?
+COPS: 0,0,"go.mobile",2
We can use this long alphabetical format of the network to identify the
virtual providers from each other:
<provider>
<name>Dna</name>
<gsm>
<network-name>dna</network-name>
<network-id mcc="244" mnc="12"/>
<apn value="internet">
<dns>217.78.192.22</dns>
<dns>217.78.192.78</dns>
</apn>
</gsm>
</provider>
<provider>
<name>GoMobile</name>
<gsm>
<network-name>go.mobile</network-name>
<network-id mcc="244" mnc="12"/>
<apn value="internet.gomobile.fi">
<dns>217.78.192.22</dns>
<dns>217.78.192.78</dns>
</apn>
</gsm>
</provider>
This allows us to automatically select the correct provider.
Any thoughts?
The first proposal is pretty easy to add on top of the current format.
It just adding one field. However in the current format the network-id
fields have to be duplicated with each virtual provider. For example in
Finland there are at least three virtual operators operating on DNA
network which has four mcc/mnc pairs[0]. Database looks like this:
<provider>
<name>Dna</name>
<gsm>
<network-name>dna</network-name>
<network-id mcc="244" mnc="03"/>
<network-id mcc="244" mnc="04"/>
<network-id mcc="244" mnc="12"/>
<network-id mcc="244" mnc="13"/>
<apn value="internet">
<dns>217.78.192.22</dns>
<dns>217.78.192.78</dns>
</apn>
</gsm>
</provider>
<provider>
<name>GoMobile</name>
<gsm>
<network-name>go.mobile</network-name>
<network-id mcc="244" mnc="03"/>
<network-id mcc="244" mnc="04"/>
<network-id mcc="244" mnc="12"/>
<network-id mcc="244" mnc="13"/>
<apn value="internet.gomobile.fi">
<dns>217.78.192.22</dns>
<dns>217.78.192.78</dns>
</apn>
</gsm>
</provider>
I suggest that the next database format has structure based on parent
network, something like this:
<country>
<network>
<gsm>
<network-id mcc="244" mnc="03"/>
<network-id mcc="244" mnc="04"/>
<network-id mcc="244" mnc="12"/>
<network-id mcc="244" mnc="13"/>
<provider>
<name>Dna</name>
<network-name>dna</network-name>
<apn value="internet">
<dns>217.78.192.22</dns>
<dns>217.78.192.78</dns>
</apn>
<provider>
<provider>
<name>GoMobile</name>
<network-name>go.mobile</network-name>
<apn value="internet.gomobile.fi">
<dns>217.78.192.22</dns>
<dns>217.78.192.78</dns>
</apn>
<provider>
</gsm>
</network>
</country>
Naturally the fields can be nested and structured differently. We must
first decide what information we could and want to include in
cellular-provider-info. I'm anyway planning to provide converter script
which allows to convert the current database into older formats. This
way we can prepare updates to older releases.
We also need some sort of information gathering tool, maybe build on top
of modem-manager which is easy to use and allows even non technical
people to easily participate in data gathering for the database. Maybe
some python based application which can be loaded off the web and
executed in place and which allows easily to send the data to a server
or bug tracker.. Anyway the information in the database is growing
steadily and we need some utilities to help to bring it to next level.
If the database grows comprehensive enough we can begin making intuitive
decisions on behalf of the user.
-- Antti
[0]
http://www2.ficora.fi/numerointi/nure_numbering.asp?nums=mnc&lang=en
Attachment:
signature.asc
Description: This is a digitally signed message part