798008 - manual network search list shows old names for network operators

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Beatriz Rodríguez [:brg]]

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)

Comment 1

[Daniel Coloma:dcoloma]

Nominating for Blocking Basecamp as this is a VIVO certification requirement

Comment 2

[Andrew Overholt [:overholt]]

Is this Gaia's apps/system/serviceproviders.xml?  If so, can we move the component to Gaia?

Comment 3

[Vicamo Yang [:vicamo][:vyang]]

(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

Comment 4

[Daniel Coloma:dcoloma]

> 
> 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.

Comment 5

[Vicamo Yang [:vicamo][:vyang]]

(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.

Comment 6

[Vicamo Yang [:vicamo][:vyang]]

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.

Comment 7

[Daniel Coloma:dcoloma]

(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?

Comment 8

[Vicamo Yang [:vicamo][:vyang]]

(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.

Comment 9

[Daniel Coloma:dcoloma]

> > 
> > 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.

Comment 10

[Beatriz Rodríguez [:brg]]

(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)

Comment 11

[Andrew Overholt [:overholt]]

(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.

Comment 12

[Andrew Overholt [:overholt]]

Nothing we can do in gecko so I'm going to clear the nom.

Comment 13

[Vicamo Yang [:vicamo][:vyang]]

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.

Comment 14

[Anshul]

Reopening this issue as per comment #39 on bug 834973.

Comment 15

[pgravel]

Issue is not really relevant to bug 834973, re-closing as WONTFIX.