Re: MNC/MCC as string?
Hi Aki, > Take two attached. I've pushed the patch out as well as an addendum patch that took care of some new and existing style issues. Also a small fix to the test case as a result of the API changes. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Fri, 12 Jun 2009 12:12:33 +0200, Marcel Holtmann wrote: > Hi Aki, > >> Anyway, here it is. Please test; seems to work for me on my N95. > > +static void extract_mcc_mnc(const char *str, char *mcc, char *mnc) > { > - int num = 0; > - unsigned int i; > - > /* Three digit country code */ > - for (i = 0; i < 3; i++) > - num = num * 10 + (int)(str[i] - '0'); > - > - *mcc = num; > - > - num = 0; > + strncpy(mcc, str, sizeof(mcc)); > + mcc[3] = '\0'; > > maybe I am blind, but how is this suppose to work. The sizeof(mmc) is 1 > byte. Actually, it is the size of a pointer, which will work (by accident) on 32-bits platform, and overflow on others. -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Fri, 12 Jun 2009 12:12:33 +0200, Marcel Holtmann wrote: > + strncpy(mcc, str, sizeof(mcc)); > + mcc[3] = '\0'; > > maybe I am blind, but how is this suppose to work. The sizeof(mmc) is 1 > byte. Actually, sizeof(mmc) is 4 bytes. Coincidentally, so is the char array in mcc. ;) Take two attached. Cheers, AkiFrom 5ea55baef4a10b3977675284c83d21e0a8f54a7b Mon Sep 17 00:00:00 2001 From: Aki Niemi Date: Fri, 12 Jun 2009 10:02:52 +0300 Subject: [PATCH] Change MNC and MCC variable types to string This is to make sure both 2 and 3-digit MNC values are correctly handled. Both the modem plugin API as well as the D-Bus API are affected. --- drivers/atmodem/network-registration.c | 57 +++- src/driver.h |7 +++- src/network.c | 48 ++ 3 files changed, 51 insertions(+), 61 deletions(-) diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c index 40796d5..30dd0f7 100644 --- a/drivers/atmodem/network-registration.c +++ b/drivers/atmodem/network-registration.c @@ -45,28 +45,20 @@ static const char *csq_prefix[] = { "+CSQ:", NULL }; struct netreg_data { gboolean supports_tech; - short mnc; - short mcc; + char mnc[OFONO_MAX_MNC_MCC_LENGTH + 1]; + char mcc[OFONO_MAX_MNC_MCC_LENGTH + 1]; }; -static void extract_mcc_mnc(const char *str, short *mcc, short *mnc) +static void extract_mcc_mnc(const char *str, char *mcc, char *mnc) { - int num = 0; - unsigned int i; - /* Three digit country code */ - for (i = 0; i < 3; i++) - num = num * 10 + (int)(str[i] - '0'); - - *mcc = num; - - num = 0; + strncpy(mcc, str, OFONO_MAX_MNC_MCC_LENGTH); + mcc[OFONO_MAX_MNC_MCC_LENGTH] = '\0'; /* Usually a 2 but sometimes 3 digit network code */ - for (; i < strlen(str); i++) - num = num * 10 + (int)(str[i] - '0'); - - *mnc = num; + strncpy(mnc, str + OFONO_MAX_MNC_MCC_LENGTH, + OFONO_MAX_MNC_MCC_LENGTH); + mnc[OFONO_MAX_MNC_MCC_LENGTH] = '\0'; } static void at_creg_cb(gboolean ok, GAtResult *result, gpointer user_data) @@ -154,7 +146,7 @@ static void cops_cb(gboolean ok, GAtResult *result, gpointer user_data) dump_response("cops_cb", ok, result); decode_at_error(&error, g_at_result_final_response(result)); - if (!ok || at->netreg->mcc == -1 || at->netreg->mnc == -1) { + if (!ok || *at->netreg->mcc == '\0' || *at->netreg->mnc == '\0') { cb(&error, NULL, cbd->data); goto out; } @@ -181,12 +173,16 @@ static void cops_cb(gboolean ok, GAtResult *result, gpointer user_data) strncpy(op.name, name, OFONO_MAX_OPERATOR_NAME_LENGTH); op.name[OFONO_MAX_OPERATOR_NAME_LENGTH] = '\0'; - op.mcc = at->netreg->mcc; - op.mnc = at->netreg->mnc; + strncpy(op.mcc, at->netreg->mcc, OFONO_MAX_MNC_MCC_LENGTH); + op.mcc[OFONO_MAX_MNC_MCC_LENGTH] = '\0'; + + strncpy(op.mnc, at->netreg->mnc, OFONO_MAX_MNC_MCC_LENGTH); + op.mnc[OFONO_MAX_MNC_MCC_LENGTH] = '\0'; + op.status = -1; op.tech = tech; - ofono_debug("cops_cb: %s, %hd %hd %d", name, at->netreg->mcc, + ofono_debug("cops_cb: %s, %s %s %d", name, at->netreg->mcc, at->netreg->mnc, tech); cb(&error, &op, cbd->data); @@ -235,15 +231,16 @@ static void cops_numeric_cb(gboolean ok, GAtResult *result, gpointer user_data) strlen(str) == 0) goto error; - extract_mcc_mnc(str, &at->netreg->mcc, &at->netreg->mnc); + extract_mcc_mnc(str, at->netreg->mcc, at->netreg->mnc); - ofono_debug("Cops numeric got mcc: %hd, mnc: %hd", + ofono_debug("Cops numeric got mcc: %s, mnc: %s", at->netreg->mcc, at->netreg->mnc); return; error: - at->netreg->mcc = at->netreg->mnc = -1; + *at->netreg->mcc = '\0'; + *at->netreg->mnc = '\0'; } static void at_current_operator(struct ofono_modem *modem, @@ -356,7 +353,7 @@ static void cops_list_cb(gboolean ok, GAtResult *result, gpointer user_data) if (!g_at_result_iter_next_string(&iter, &n)) break; - extract_mcc_mnc(n, &list[num].mcc, &list[num].mnc); + extract_mcc_mnc(n, list[num].mcc, list[num].mnc); if (!g_at_result_iter_next_number(&iter, &tech)) tech = 0; @@ -376,7 +373,7 @@ static void cops_list_cb(gboolean ok, GAtResult *result, gpointer user_data) int i = 0; for (; i < num; i++) { - ofono_debug("Operator: %s, %hd, %hd, status: %d, %d", + ofono_debug("Operator: %s, %s, %s, status: %d, %d", list[i].name, list[i].mcc, list[i].mnc
Re: MNC/MCC as string?
Hi Aki, > Anyway, here it is. Please test; seems to work for me on my N95. +static void extract_mcc_mnc(const char *str, char *mcc, char *mnc) { - int num = 0; - unsigned int i; - /* Three digit country code */ - for (i = 0; i < 3; i++) - num = num * 10 + (int)(str[i] - '0'); - - *mcc = num; - - num = 0; + strncpy(mcc, str, sizeof(mcc)); + mcc[3] = '\0'; maybe I am blind, but how is this suppose to work. The sizeof(mmc) is 1 byte. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Thu, 11 Jun 2009 15:08:08 -0500, Denis Kenzior wrote: >> What part of this is unclear? > > Please submit a patch to the mailing list reflecting how you think it > should be > implemented. If it looks reasonable then I'll integrate it. Uh. You know I am one of the co-maintainers here? ;) Anyway, here it is. Please test; seems to work for me on my N95. Cheers, AkiFrom 88e6a0a521c69913ab954e5a79f923b317d5ed26 Mon Sep 17 00:00:00 2001 From: Aki Niemi Date: Fri, 12 Jun 2009 10:02:52 +0300 Subject: [PATCH] Change MNC and MCC variable types to string This is to make sure both 2 and 3-digit MNC values are correctly handled. Both the modem plugin API as well as the D-Bus API are affected. --- drivers/atmodem/network-registration.c | 51 +-- src/driver.h |4 +- src/network.c | 48 -- 3 files changed, 42 insertions(+), 61 deletions(-) diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c index 40796d5..f73bb7c 100644 --- a/drivers/atmodem/network-registration.c +++ b/drivers/atmodem/network-registration.c @@ -45,28 +45,18 @@ static const char *csq_prefix[] = { "+CSQ:", NULL }; struct netreg_data { gboolean supports_tech; - short mnc; - short mcc; + char mnc[4]; + char mcc[4]; }; -static void extract_mcc_mnc(const char *str, short *mcc, short *mnc) +static void extract_mcc_mnc(const char *str, char *mcc, char *mnc) { - int num = 0; - unsigned int i; - /* Three digit country code */ - for (i = 0; i < 3; i++) - num = num * 10 + (int)(str[i] - '0'); - - *mcc = num; - - num = 0; + strncpy(mcc, str, sizeof(mcc)); + mcc[3] = '\0'; /* Usually a 2 but sometimes 3 digit network code */ - for (; i < strlen(str); i++) - num = num * 10 + (int)(str[i] - '0'); - - *mnc = num; + strncpy(mnc, str + 3, sizeof(mnc)); } static void at_creg_cb(gboolean ok, GAtResult *result, gpointer user_data) @@ -154,7 +144,7 @@ static void cops_cb(gboolean ok, GAtResult *result, gpointer user_data) dump_response("cops_cb", ok, result); decode_at_error(&error, g_at_result_final_response(result)); - if (!ok || at->netreg->mcc == -1 || at->netreg->mnc == -1) { + if (!ok || *at->netreg->mcc == '\0' || *at->netreg->mnc == '\0') { cb(&error, NULL, cbd->data); goto out; } @@ -181,12 +171,12 @@ static void cops_cb(gboolean ok, GAtResult *result, gpointer user_data) strncpy(op.name, name, OFONO_MAX_OPERATOR_NAME_LENGTH); op.name[OFONO_MAX_OPERATOR_NAME_LENGTH] = '\0'; - op.mcc = at->netreg->mcc; - op.mnc = at->netreg->mnc; + strncpy(op.mcc, at->netreg->mcc, sizeof(op.mcc)); + strncpy(op.mnc, at->netreg->mnc, sizeof(op.mnc)); op.status = -1; op.tech = tech; - ofono_debug("cops_cb: %s, %hd %hd %d", name, at->netreg->mcc, + ofono_debug("cops_cb: %s, %s %s %d", name, at->netreg->mcc, at->netreg->mnc, tech); cb(&error, &op, cbd->data); @@ -235,15 +225,16 @@ static void cops_numeric_cb(gboolean ok, GAtResult *result, gpointer user_data) strlen(str) == 0) goto error; - extract_mcc_mnc(str, &at->netreg->mcc, &at->netreg->mnc); + extract_mcc_mnc(str, at->netreg->mcc, at->netreg->mnc); - ofono_debug("Cops numeric got mcc: %hd, mnc: %hd", + ofono_debug("Cops numeric got mcc: %s, mnc: %s", at->netreg->mcc, at->netreg->mnc); return; error: - at->netreg->mcc = at->netreg->mnc = -1; + *at->netreg->mcc = '\0'; + *at->netreg->mnc = '\0'; } static void at_current_operator(struct ofono_modem *modem, @@ -356,7 +347,7 @@ static void cops_list_cb(gboolean ok, GAtResult *result, gpointer user_data) if (!g_at_result_iter_next_string(&iter, &n)) break; - extract_mcc_mnc(n, &list[num].mcc, &list[num].mnc); + extract_mcc_mnc(n, list[num].mcc, list[num].mnc); if (!g_at_result_iter_next_number(&iter, &tech)) tech = 0; @@ -376,7 +367,7 @@ static void cops_list_cb(gboolean ok, GAtResult *result, gpointer user_data) int i = 0; for (; i < num; i++) { - ofono_debug("Operator: %s, %hd, %hd, status: %d, %d", + ofono_debug("Operator: %s, %s, %s, status: %d, %d", list[i].name, list[i].mcc, list[i].mnc, list[i].status, list[i].tech); } @@ -457,12 +448,12 @@ static void at_register_manual(struct ofono_modem *modem, goto error; if (at->netreg->supports_tech && oper->tech != -1) - sp
Re: MNC/MCC as string?
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. I agree that there might be at some point a need for it, but what I question is the need for it right now. Do we have direct users in userspace that can make use of this information? Giving them directly to the user makes no sense. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Hi Remi, > > > >> 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. > > I don't see any lack of clarity. It is a series of two or three digits. > > Anyway, if the database has a hole, we probably will have to return the > MNC/MCC anyway (ever tried scanning for network with an old phone in a > foreign > country?). Then there is also the uniqueness problem. MNC/MCC pair solves > that. if the database has a whole or we don't have the network provider string then we can just show the MNC/MCC in that case. That is pretty simple. No need to put extra burden into the userspace application and have it looking for two strings. I don't understand your uniqueness issue. We will have unique object path for every network. What else does userspace needs? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Aki, On Thursday 11 June 2009 14:38:49 Aki Niemi wrote: > On Thu, 11 Jun 2009 21:18:02 +0200, Marcel Holtmann > > 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? Please submit a patch to the mailing list reflecting how you think it should be implemented. If it looks reasonable then I'll integrate it. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Le jeudi 11 juin 2009 22:18:02 Marcel Holtmann, vous avez écrit : > 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. I don't see any lack of clarity. It is a series of two or three digits. Anyway, if the database has a hole, we probably will have to return the MNC/MCC anyway (ever tried scanning for network with an old phone in a foreign country?). Then there is also the uniqueness problem. MNC/MCC pair solves that. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Thu, 11 Jun 2009 21:18:02 +0200, Marcel Holtmann 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? Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
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. As I said, adding something is easy, removing/deprecating hard and changing the format of it even harder. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Thu, 11 Jun 2009 20:10:27 +0200, Marcel Holtmann wrote: >> 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. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Aki, On Thursday 11 June 2009 13:00:48 Aki Niemi wrote: > On Thu, 11 Jun 2009 09:32:38 -0500, Denis Kenzior > > wrote: > > 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. The point is MCCMNC is not something the user should realy be exposed to. It is useful to dis-ambiguate the carrier by Country when you're in a border area, but that is about it. Country property can do this just as well. > > > 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. > Then lets design this into oFono instead of exposing an obscure attribute. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Thu, 11 Jun 2009 13:46:55 +0200, Marcel Holtmann wrote: > 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. For geolocation, cell ID and LAC are more useful, especially coupled with information on neighboring cells, RTT measurements, etc. We will probably need to expose this information some way. Also, typically networks provide date-time, timezone and DST information via NITZ [1]. Cheers, Aki [1] http://en.wikipedia.org/wiki/NITZ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Hi Aki, > > 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. 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). I know we need this database and mobilebroadband-providerinfo or similar project is doing this already. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Thu, 11 Jun 2009 09:32:38 -0500, Denis Kenzior wrote: > 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. > What standard do we want to use > > here? ITU 212? ISO 3166? or E164? > > Any objections from actually removing the MCC/MNC Properties? We need them. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Hi Denis, > > 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 > "". 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? you know what. Lets remove them now. If we figure out on how to make better use of them, we can add them later. Adding properties is way simpler than deprecating/removing or changing them. For the country, I would prefer simple alpha2 encoding. That way this becomes similar to what WiFi uses for their regulatory enforcement. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Hi Jan, > > > 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-data-roaming/ > > 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/freesmartphone/ogsmd/networks.tab > can be useful for you. OTOH, Nokia probably has a better list. we will hide this minor defect inside the daemon and not bother the use with details. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Hi Marcel, > 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 "". 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? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Thu, 2009-06-11 at 13:46 +0200, Marcel Holtmann wrote: > Hi Denis, > > > 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-data-roaming/ 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/freesmartphone/ogsmd/networks.tab can be useful for you. OTOH, Nokia probably has a better list. Jan ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Hi Denis, > 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? 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. 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. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
On Wed, 10 Jun 2009 11:15:19 -0500, Denis Kenzior wrote: > It doesn't seem this clear-cut. E.g. according to my Neo on with T-Mobile > US > SIM: > > AT+COPS? > +COPS: 0,0,"T-Mobile" > OK > AT+COPS=3,2 > OK > AT+COPS? > +COPS: 0,2,"31026" > OK > AT+COPS=2 > OK > +CREG: 0 > AT+COPS=1,2,"31026" > OK > +CREG: 2 > +CREG: 1,"99EC","1A11" > > At least according to wikipedia the real MCC/MNC of T-Mobile is 310260. Go > > figure. I think this might be a separate issue with some North American operators that seem to pad also 3-digit codes, effectively dropping that trailing zero. Perhaps this is for legacy reasons. >> 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? I would go ahead and change them as well. In theory, there could exist both 2- and 3-digit MNCs within a single MCC, for which having strings is the safest option. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Hi Remi, Well, the point is that leading zeroes are meaningful (much like with phone > numbers in fact). The API, not just the implementation, must distinguish > network "xy" from network "0xy", so that manual selection remains > unambiguous. > A D-Bus string is probably nicer to use than an integer using ISI's BCD > scheme 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? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Le mercredi 10 juin 2009 19:15:19 Denis Kenzior, vous avez écrit : > > 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'. Well, the point is that leading zeroes are meaningful (much like with phone numbers in fact). The API, not just the implementation, must distinguish network "xy" from network "0xy", so that manual selection remains unambiguous. A D-Bus string is probably nicer to use than an integer using ISI's BCD scheme. -- Rémi Denis-Courmont Nokia Devices R&D ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: MNC/MCC as string?
Aki, On Wednesday 10 June 2009 06:26:07 Aki Niemi wrote: > Hi, > > Currently, the MNC and MCC values are of type short, which is a little > problematic. > > The MNC code can either be 2 or 3 digits, and it would be quite natural to > assume the logic is that 3 digits are used for codes > 99. However, this is > not correct -- it depends on the MCC. It seems mostly American operators > have 3 digit MNCs, whereas most of the rest of the world 2 digit MNCs. The > implication is that 01 and 001 are not considered identical. It doesn't seem this clear-cut. E.g. according to my Neo on with T-Mobile US SIM: AT+COPS? +COPS: 0,0,"T-Mobile" OK AT+COPS=3,2 OK AT+COPS? +COPS: 0,2,"31026" OK AT+COPS=2 OK +CREG: 0 AT+COPS=1,2,"31026" OK +CREG: 2 +CREG: 1,"99EC","1A11" At least according to wikipedia the real MCC/MNC of T-Mobile is 310260. Go figure. > > 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'. > > Cheers, > Aki > ___ > ofono mailing list > ofono@ofono.org > http://lists.ofono.org/listinfo/ofono Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
MNC/MCC as string?
Hi, Currently, the MNC and MCC values are of type short, which is a little problematic. The MNC code can either be 2 or 3 digits, and it would be quite natural to assume the logic is that 3 digits are used for codes > 99. However, this is not correct -- it depends on the MCC. It seems mostly American operators have 3 digit MNCs, whereas most of the rest of the world 2 digit MNCs. The implication is that 01 and 001 are not considered identical. 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? Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono