> Nokia modems both send and receive MNC/MCC pairs as Binary Coded Decimal > (BCD) strings. Any 2 digit MNC is padded with 0xF. Problem is, when > listing operators, the conversion of MNC codes from BCD to short loses > this information, and will result in manual network selection failing > (BCD '001' -> short '1' -> BCD '01F' != BCD '001'). > > Anyone opposed to changing the mnc and mcc code types from short to > string? I agree that this does seem to be an issue, so no problems in changing this. Do you consider this an implementation issue only (e.g. APIs do not change) or do you want to change the NetworkOperator attributes to a string as well? If this is an implementation issue we can always adopt the Nokia convention of padding the MNC by 0xF on the right and leave them as a 'short'.

I understand perfectly. But remember, oFono does not expose the user to such details. Manual registration is accomplished by using Register() method (with no arguments) of the NetworkOperator interface. The internal storage representation is never exposed. Thus it doesn't matter whether internally it is a string or short, etc. The attributes are really only for informational purposes only. The user would not base his decision on the mcc/mnc, but on the operator name. So before we start changing the D-Bus APIs, we need to answer these two questions: - Can a country/administrative domain have both 001 and 01 MNCs such that the use of string for the MNC is actually necessary. - What does the user find easier to use, a string or a short?

> > The attributes are really only for informational purposes only. The > > user would not base his decision on the mcc/mnc, but on the operator > > name. > > > > So before we start changing the D-Bus APIs, we need to answer these > > two questions: > > - Can a country/administrative domain have both 001 and 01 MNCs such > > that the use of string for the MNC is actually necessary. > > - What does the user find easier to use, a string or a short? > > I wasn't aware of this and so it might be better to just expose these as > an operator id string. So we might not even split into MCC/MNC at all > since it is meaning less anyway. This is probably the way to go... > That said, we do want some exposure of these values since it is an easy > way to determine geo location help and switch timezones etc. However I > am now thinking that me might just add a Country property and do the > proper translation inside oFono. Since we mostly care about these ones > most. While inferring the country from MCC sounds nice, there are some corner cases where is causes problems: Digicel Bermuda uses 310/38 (or 310/038?), 310 is the US MCC: http://dougtoombs.com/2008/07/23/bermuda-the-iphone-and-att-beware-the-da... Montenegro used MCC 220 (Serbia) before it switched to MCC 297. Wikipedia has a list: http://en.wikipedia.org/wiki/Mobile_Network_Code If you plan to ship such a list with ofono, maybe http://git.freesmartphone.org/?p=framework.git;a=blob;f=etc/freesmartphon... can be useful for you. OTOH, Nokia probably has a better list.

> I wasn't aware of this and so it might be better to just expose these as > an operator id string. So we might not even split into MCC/MNC at all > since it is meaning less anyway. I'm tending to agree, which is why I wanted to start the conversation. By the way, just so that we're all clear, here's the relevant quote from the standard: " MCC, Mobile country code (octet 2 and 3) The MCC field is coded as in ITU-T Rec. E212, Annex A. MNC, Mobile network code (octet 3 bits 5 to 8, octet 4) The coding of this field is the responsibility of each administration but BCD coding shall be used. The MNC shall consist of 2 or 3 digits. For PCS 1900 for NA, Federal regulation mandates that a 3-digit MNC shall be used. However a network operator may decide to use only two digits in the MNC in the LAI over the radio interface. In this case, bits 5 to 8 of octet 3 shall be coded as "1111". Mobile equipment shall accept LAI coded in such a way. " > > That said, we do want some exposure of these values since it is an easy > way to determine geo location help and switch timezones etc. However I > am now thinking that me might just add a Country property and do the > proper translation inside oFono. Since we mostly care about these ones > most. > About the only thing that MCC/MNC is useful for is to display it during manual operator selection. MCC/MNC is not helpful at all for countries like U.S. with 4+ timezones and the same carrier id across all of them. A country property would work just as well for this. What standard do we want to use here? ITU 212? ISO 3166? or E164? Any objections from actually removing the MCC/MNC Properties?

> About the only thing that MCC/MNC is useful for is to display it during > manual > operator selection. That's not true. In fact, I'd say manual operator selection is just about the last place where the codes should be displayed. > MCC/MNC is not helpful at all for countries like U.S. > with 4+ timezones and the same carrier id across all of them. A country > property would work just as well for this. For geolocation help, sure, but there are other places where MNC/MCC are used as keys to databases containing operator-specific information, like default Internet APN names and such.

>> For geolocation help, sure, but there are other places where MNC/MCC are >> used as keys to databases containing operator-specific information, like >> default Internet APN names and such. > > shouldn't we just integrate that database into oFono directly or as > something like ofono-info.git that will be installed along with (for > easier updates). This particular database of default APN names, maybe, although I think it's really oFono users like Connman that should integrate with that information. However, this wouldn't be the only database ever, so we would still need a way to reliably identify a specific operator.

On Thu, 11 Jun 2009 21:18:02 +0200, Marcel Holtmann <marcel(a)holtmann.org&gt; wrote: >> However, this wouldn't be the only database ever, so we would still need >> a >> way to reliably identify a specific operator. > > if we are unclear about the format and the users at this moment, The format should be 's' in D-Bus and in struct ofono_network_operator: char mnc[4]; char mcc[4]; And as for users, we need access to both MNC and MCC. What part of this is unclear?

Anyway, here it is. Please test; seems to work for me on my N95.

Take two attached.

Hi Aki, > >> For geolocation help, sure, but there are other places where MNC/MCC > >> are used as keys to databases containing operator-specific > >> information, like default Internet APN names and such. > > > > shouldn't we just integrate that database into oFono directly or as > > something like ofono-info.git that will be installed along with (for > > easier updates). > > This particular database of default APN names, maybe, although I think > it's really oFono users like Connman that should integrate with that > information. > > However, this wouldn't be the only database ever, so we would still need > a way to reliably identify a specific operator. if we are unclear about the format and the users at this moment, I prefer we remove that interface and just keep it around as a TODO item to add it later.

>> For geolocation help, sure, but there are other places where MNC/MCC are >> used as keys to databases containing operator-specific information, like >> default Internet APN names and such. > > shouldn't we just integrate that database into oFono directly or as > something like ofono-info.git that will be installed along with (for > easier updates). This particular database of default APN names, maybe, although I think it's really oFono users like Connman that should integrate with that information. However, this wouldn't be the only database ever, so we would still need a way to reliably identify a specific operator.

That said, we do want some exposure of these values since it is an easy way to determine geo location help and switch timezones etc.