Closed Bug 798008 Opened 10 years ago Closed 10 years ago

manual network search list shows old names for network operators

Categories

(Firefox OS Graveyard :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:tef+)

RESOLVED WONTFIX
blocking-b2g tef+

People

(Reporter: brg, Assigned: pgravel)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Go to Manual network search menu and see the list of networks offered. Their names are old.


Actual results:

Those names are not used any more.


Expected results:

The official list of names is provided by GSMA, it is a file called SE13 Published Database. They keep it up to date. The names are under the column: PPCI&N (PPCI&N = Preferred Presentation of Country Initials and Mobile Network Name)
Product: Core → Boot2Gecko
Version: Trunk → unspecified
Nominating for Blocking Basecamp as this is a VIVO certification requirement
blocking-basecamp: --- → ?
Is this Gaia's apps/system/serviceproviders.xml?  If so, can we move the component to Gaia?
Flags: needinfo?(brg)
(In reply to Beatriz Rodríguez [:brg] from comment #0)
> The official list of names is provided by GSMA, it is a file called SE13
> Published Database. They keep it up to date.

I can only find one[1] from an unofficial mirroring site in Japan, and that's still an out dated 2001 version. Do you have the direct link to the original, up-to-date document?

Besides, according to 3GPP TS 27.007, the string is directly returned by AT+COPS, which means that's probably modem firmware's duty, not Gecko RIL's. I can't either find such mapping in Android AOSP.

[1]: http://www.quintillion.co.jp/3GPP/GSM/SMG_21/tdocs/P-97-067.pdf
> 
> I can only find one[1] from an unofficial mirroring site in Japan, and
> that's still an out dated 2001 version. Do you have the direct link to the
> original, up-to-date document?

I am afraid that table is only for GSMA members.
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #3)
> Besides, according to 3GPP TS 27.007, the string is directly returned by
> AT+COPS, which means that's probably modem firmware's duty, not Gecko RIL's.
> I can't either find such mapping in Android AOSP.

I've found these strings in Otoro libril-qc-1.so. I think Gecko is a wrong target to fix this issue. Same in libsec-ril.so for Samsung Galaxy SII. Since these libraries are all extracted from the original devices, I'll close this issue as WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
BTW, it seems Samsung Galaxy SII has more updated string values because "VIVO" and many other missed ones are found in the binary file in comparison with Otoro's.
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #6)
> BTW, it seems Samsung Galaxy SII has more updated string values because
> "VIVO" and many other missed ones are found in the binary file in comparison
> with Otoro's.

So... did you test this feature with Galaxy SII in VIVO labs? 

By the way, don't understand https://bugzilla.mozilla.org/show_bug.cgi?id=798008#c5 does it mean it should be fixed in Gaia or any other place?
(In reply to Daniel Coloma:dcoloma from comment #7)
> (In reply to Vicamo Yang [:vicamo][:vyang] from comment #6)
> > BTW, it seems Samsung Galaxy SII has more updated string values because
> > "VIVO" and many other missed ones are found in the binary file in comparison
> > with Otoro's.
> 
> So... did you test this feature with Galaxy SII in VIVO labs? 

No, we didn't notice this problem there.

> By the way, don't understand
> https://bugzilla.mozilla.org/show_bug.cgi?id=798008#c5 does it mean it
> should be fixed in Gaia or any other place?

I mean, it looks like a telephony solution provider's issue.
> > 
> > So... did you test this feature with Galaxy SII in VIVO labs? 
> 
> No, we didn't notice this problem there.
> 

Are we talking about the same issue? Afaik this issue was found and reported in the lab sessions you held in Brazil with Beatriz.
(In reply to Andrew Overholt [:overholt] from comment #2)
> Is this Gaia's apps/system/serviceproviders.xml?  If so, can we move the
> component to Gaia?

I do not know from where Otoro got the information. I am sorry.
I do know that those operator names are out of date. We must update the data base where they are read.
Shall I contact QC or chipset provider to fix this issue?

We do discover this issue in Brasil but it is easy to reproduce in any other country where the operators has change the name (i.e. in Spain)
Flags: needinfo?(brg)
(In reply to Beatriz Rodríguez [:brg] from comment #10)
> (In reply to Andrew Overholt [:overholt] from comment #2)
> > Is this Gaia's apps/system/serviceproviders.xml?  If so, can we move the
> > component to Gaia?
> 
> I do not know from where Otoro got the information. I am sorry.
> I do know that those operator names are out of date. We must update the data
> base where they are read.
> Shall I contact QC or chipset provider to fix this issue?

I think that might be best given Vicamo's investigation that the names are not coming from Gecko or Gaia.  Please follow up here with the bug # that you file.  Thanks.
Nothing we can do in gecko so I'm going to clear the nom.
blocking-basecamp: ? → ---
To be more detailed:

1) 3GPP TS 27.007 section 7.3 "PLMN selection +COPS":

     <oper>: ... long alphanumeric format can be upto 16 characters
     long and short format up to 8 characters (refer GSM MoU SE.13
     [9])

  It doesn't explicitly say the string value should be PPCI&N column
  of SE.13, but it does say the format should follow that document.

2) I found proprietary binary files of both Otoro and SGS2 contain
  string tables of the values listed in GSM MoU SE.13. Maybe all
  Android devices have the same behavior because the two devices are
  using popular Qualcomm & Broadcom solutions separately.

3) Android framework does not process the operator names retrieved
  from rild. Android stores retrieved operators info in an
  OperatorInfo-typed array. The data members of that class are
  directly assigned with the values from rild.

4) Android Phone app does not process the operator names retrieved
  from framework. NetworkQueryService sends retrieved operators list
  to NetworkSettings, which populates Settings page with those
  OperatorInfo entries. The preference entry title is set to the
  value of OperatorInfo.getOperatorAlphaLong() directly.

From the very beginning to the end of the operator name showing, no one ever modifies the string or re-maps it by MCC/MNC, so I concluded this is not a Gecko bug.
Reopening this issue as per comment #39 on bug 834973.
Assignee: nobody → pgravel
Status: RESOLVED → REOPENED
blocking-b2g: --- → tef?
Ever confirmed: true
Resolution: WONTFIX → ---
blocking-b2g: tef? → tef+
Issue is not really relevant to bug 834973, re-closing as WONTFIX.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.