875484 - MCC / MNC between Carrier (SIM card) and Operator (mobile network connection/antenna) values are getting mixed up when roaming.

Status: RESOLVED INVALID

(Firefox OS Graveyard :: General, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/a3a49f8d101e
Gaia   09299399500b50de72cdd3b4365fc6455bbbb145
BuildID 20130522070210
Version 18.0

1. plug in Movistar SIM into a phone in the US
2. reboot phone
3. do: 
adb logcat | grep -E 'MCC|MNC'
- waiting for device -
D/ICCIO_QC_B2G(  112): MCC = 214, MNC = 07
D/ICCIO_QC_B2G(  112): MCC = 214, MNC = 07
4. look at logcat
05-23 13:28:05.129: I/Gecko(112): -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:DataInfoChanged{connected : false,emergencyCallsOnly : false,roaming : true,type : 'edge',signalStrength : -99,relSignalStrength : 22,network : {mcc : '310', mnc : '260', longName : 'T-Mobile', shortName : 'T-Mobile'},cell : {gsmLocationAreaCode : 275, gsmCellId :23991},state : 'registered'} 

Expected: logcat MCC value and MNC values should match
Actual: they don't.

Note:
1. Settings shows : T-Mobile even though I'm using a Movistar SIM.
2. It would be good to show both the network operator and SIM carrier values somewhere; having said that these values for MCC and MNC should be consistant.

Comment 1

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Hi, Naoki-san

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #0)
> 1. plug in Movistar SIM into a phone in the US
> 2. reboot phone
> 3. do: 
> adb logcat | grep -E 'MCC|MNC'
> - waiting for device -
> D/ICCIO_QC_B2G(  112): MCC = 214, MNC = 07
> D/ICCIO_QC_B2G(  112): MCC = 214, MNC = 07

This is the MCC/MNC from SIM card.
Wherever you go around the world, these values are always 214/07 because they come from you SIMc ard.

> 4. look at logcat
> 05-23 13:28:05.129: I/Gecko(112): -*- QCContentHelper_QC_B2G: sendMessage to
> content process: RIL:DataInfoChanged{connected : false,emergencyCallsOnly :
> false,roaming : true,type : 'edge',signalStrength : -99,relSignalStrength :
> 22,network : {mcc : '310', mnc : '260', longName : 'T-Mobile', shortName :
> 'T-Mobile'},

This is the MCC/MNC from network operator
Also you are in roaming,
so now you're in US, you will get MCC/MNC from T-Mobile,
if you go to another country, you will get another set of MCC/MNC from the local operator.

> 
> Expected: logcat MCC value and MNC values should match
> Actual: they don't.
> 

Did I misunderstand your question? 
Otherwise I think they are not neccesary to be the same.

> Note:
> 1. Settings shows : T-Mobile even though I'm using a Movistar SIM.
> 2. It would be good to show both the network operator and SIM carrier values
> somewhere; 

There's a SPN (Service Provider Name from the SIM card) field, in this case, Movistar.
Under some condition we should display SPN instead of operator name to the User.

But if you're in roaming mode, operator name will always be displayed.

Comment 2

[Daniel Coloma:dcoloma]

Can we confirm if this a bug or not?

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Krupa - in triage it was discussed that the true bug here (and user impact) is in marketplace/cost control apps which would use the same source of info as we pull from logcat on commercial RIL.  Can you confirm if this is true and also what the impact is when the info does not match?

Comment 4

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

The problem is as krupa/lsblakk have pointed out.

I am also confused, you mean the MCC/MNC can equal the SPN in when the phone is roaming in a different country?

What I am seeing is that in the same session (ie you boot the phone and do both commands), MCC/MNC have different values depending on where you look.  I think that in itself is a bug.

Unforuntately I forgot the SIM card at home, so I will have to test when I get back home.

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

* Unagi Master/MozCen 2013-05-28-03-11-00_MC_unagi mozril: 
** logcat : 
05-28 10:38:54.872: I/Gecko(398): -*- RILContentHelper: Received message 'RIL:DataInfoChanged': {"connected":false,"emergencyCallsOnly":false,"roaming":true,"network":{"rilMessageType":"operatorchange","mcc":"310","mnc":"260","longName":"T-Mobile","shortName":"T-Mobile","batch":true},"lastKnownMcc":null,"cell":{"gsmLocationAreaCode":258,"gsmCellId":22871},"type":"edge","signalStrength":-71,"relSignalStrength":67,"state":"registered"}
** adb logcat | grep -E 'MCC|MNC' :
API : I/Gecko   (  108): RIL Worker[0]: MCC: 214 MNC: 07


* unagi-mozilla-b2g18-20130528070209-ril01.01.00.019.109 :
** logcat : 
05-28 10:53:26.567: I/Gecko(440): -*- RILContentHelper: Received message 'RIL:DataInfoChanged': {"connected":false,"emergencyCallsOnly":false,"roaming":true,"type":"edge","signalStrength":-73,"relSignalStrength":64,"network":{"mcc":"310","mnc":"260","longName":"T-Mobile","shortName":"T-Mobile"},"cell":{"gsmLocationAreaCode":258,"gsmCellId":22871},"state":"registered"}
** adb logcat | grep -E 'MCC|MNC' :
D/ICCIO_QC_B2G( 1691): MCC = 214, MNC = 07

* Inari Partner Build: 
** 05-28 11:08:24.243: I/Gecko(113): -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:DataInfoChanged{connected : false,emergencyCallsOnly : false,roaming : true,type : 'hspa',signalStrength : -75,relSignalStrength : 61,network : {mcc : '310', mnc : '260', longName : 'T-Mobile', shortName : 'T-Mobile'},cell : {gsmLocationAreaCode : 40497, gsmCellId :19945821},state : 'registered'}
** API doesn't seem to be in this build?


https://bugzilla.mozilla.org/show_bug.cgi?id=828307#c65

This issue appears in all builds.  Commercial, non commercial and will most likely appear in partner build.

Comment 6

[José Antonio Olivera Ortega [:jaoo]]

The MCC and MNC codes in the SIM never changes. The ones from both the voice and data connection change when the user is in roaming. This is not a bug.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Marking invalid then according to comment 6

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Android shows the network connecting to T-Mobile, however the MCC / MNC is movistar.
APN on android shows Movistar, Movistar MMS:

01-06 09:38:46.590: I/IccUtils(2218): [MccMncConvert] Convert Result :21407
01-06 09:38:47.155: D/Mms/MmsApp(2408): [start]    onConfigurationChanged(),newConfig={1.0 214mcc7mnc en_US layoutdir=0 sw320dp w320dp h508dp nrml long port finger -keyb/v/h -nav/h s.5 FlipFont=0}
01-06 09:38:47.155: D/Mms/MmsApp(2408): [end]    onConfigurationChanged(),newConfig={1.0 214mcc7mnc en_US layoutdir=0 sw320dp w320dp h508dp nrml long port finger -keyb/v/h -nav/h s.5 FlipFont=0}
01-06 09:40:56.850: I/ActivityManager(1982): Config changed: {1.0 214mcc7mnc en_US layoutdir=0 sw320dp w533dp h294dp nrml long land finger -keyb/v/h -nav/h s.6 FlipFont=0}
01-06 09:40:58.235: I/ActivityManager(1982): Config changed: {1.0 214mcc7mnc en_US layoutdir=0 sw320dp w320dp h508dp nrml long port finger -keyb/v/h -nav/h s.7 FlipFont=0}
01-06 09:41:02.435: I/ActivityManager(1982): Config changed: {1.0 214mcc7mnc en_US layoutdir=0 sw320dp w533dp h294dp nrml long land finger -keyb/v/h -nav/h s.8 FlipFont=0}


Available networks show:
T-Mobile
AT&T

I believe that this is a bug.  Having the values confused based on the network operator may cause future bugs based on roaming.

Comment 9

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #8)
> Android shows the network connecting to T-Mobile, however the MCC / MNC is
> movistar.

There is no anything wrong here. The SIM reports its MCC and MNC codes (Movistar's ones) and the device is connected to a T-Mobile Network (since you are in US).

> APN on android shows Movistar, Movistar MMS:

That's correct because the subscriber's SIM belongs to Movistar.

> Available networks show:
> T-Mobile
> AT&T

Are you expecting to see the Movistar Network in the US?

> I believe that this is a bug.  Having the values confused based on the
> network operator may cause future bugs based on roaming.

I don't see anything wrong here. Why do you think this is a bug? The values are not confused. This is how it is supposed to work.

Comment 10

[Alex Keybl [:akeybl]]

For comment 9

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I think this is a bug because of this return value in logcat: {"mcc":"310","mnc":"260","longName":"T-Mobile","shortName":"T-Mobile"}

Android returns the correct value :
214mcc7mnc

Comment 12

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #11)
> I think this is a bug because of this return value in logcat:
> {"mcc":"310","mnc":"260","longName":"T-Mobile","shortName":"T-Mobile"}

I guess this is the voice or data connection. I would need to see the context in which logcat is showing this.

> Android returns the correct value :
> 214mcc7mnc

Could you provide both the full |adb logcat| (RIL log activated if possible) and the |adb logcat -b radio| outputs please?

Comment 13

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: Android Logcat -b radio

Here is the |adb logcat -b radio| from the android device.

They store the Network Operator in SS (Service State) and override the Service State for roaming.  They do not change the MCC/MNC as far as I can tell from the log.

Comment 14

[Andrew Overholt [:overholt]]

José, with Naoki's logs, do you think should be a blocker?

Comment 15

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Andrew Overholt [:overholt] from comment #14)
> José, with Naoki's logs, do you think should be a blocker?

I would need the |adb logcat| output from a device on B2G.

From what I see in the Android logs the MCC and MNC codes in the SIM corresponds to a subscriber's SIM from Movistar.

> I think this is a bug because of this return value in logcat:
> {"mcc":"310","mnc":"260","longName":"T-Mobile","shortName":"T-Mobile"}

Why is this a bug?. We show in the logs the MCC and MNC codes from the voice connection, the data connection and the SIM. So maybe you are seeing the ones coming from the voice connection (that are from T-Mobile since you are in roaming in the US) Please, provide the full log (from a device on B2G) and that way we can know the context from the info above.

Comment 16

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

It's a bug because if new dev are not aware of the difference between voice and card, they may end up thinking that it's the same thing when it's not.  Android has variables that are different so that there is no confusion.

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Also for troubleshooting purposes, it's also misleading and confusing.  
The logcat is seen in the very first comment.

Comment 18

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: logcat of movistar SIM in b2g device

logcat of movistar SIM.

Comment 19

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #16)
> It's a bug because if new dev are not aware of the difference between voice
> and card, they may end up thinking that it's the same thing when it's not.

New devs should take a look at API specs when coding and IMHO (in this case) the documentation provided in mozMobileConnection API (see [1]) is clear enough. 
  
> Android has variables that are different so that there is no confusion.

IMHO logs are clear enough as well:

06-04 17:37:00.299: I/Gecko(146): -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:VoiceInfoChanged{connected : true,emergencyCallsOnly : false,roaming : true,type : 'unknown',signalStrength : -99,relSignalStrength : 40,network : {mcc : 310, mnc :260, longName : 'T-Mobile', shortName : 'T-Mobile'},cell : {gsmLocationAreaCode : 275, gsmCellId :23991},state : 'registered'}

06-04 17:37:00.299: I/Gecko(146): -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:DataInfoChanged{connected : false,emergencyCallsOnly : false,roaming : true,type : 'unknown',signalStrength : -99,relSignalStrength : 40,network : {mcc : 310, mnc :260, longName : 'T-Mobile', shortName : 'T-Mobile'},cell : {gsmLocationAreaCode : 275, gsmCellId :23991},state : 'searching'}

06-04 17:37:00.409: I/Gecko(465): -*- RILContentHelper: Received message 'RIL:IccInfoChanged': {"iccid":"8934077100001208576","mcc":214,"mnc":7,"msisdn":null,"spn":null,"isDisplayNetworkNameRequired":true,"isDisplaySpnRequired":false}

So this bug is not a matter of malfunction but a nice-to-have improvement in way the info is logged by the RIL, isn't it? WORKSFORME?

[1] http://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMMobileConnection.idl

Comment 20

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I agree to place it down in priority, having said that it is not a WFM.

The logcat showing 2 different mcc/mnc causes an issue.  

This can also be seen in the code when searching for mcc/mnc when we should use a different variable such as what android uses service state.  

Due to this issue, the potential to use the wrong mcc/mnc for coding or diagnosing support issues is likely and a bug won't be noticed until the phone is in roaming in a different network.

Comment 21

[Caitlin Galimidi [:c8o]]

Team - 
What's the next step on this? Who needs to fix?

Marketplace app devs need to be able to readily identify the correct mcc/mnc value in order to display the regional Marketplace accurately.

Caitlin

Comment 22

[Caitlin Galimidi [:c8o]]

team - emailed over this with clee 

mcc / mnc is a really big deal for marketplace
we've promised carriers and oems a way to show regional content and we use mcc / mnc on devise in order to do that

we have a hack in place for launch for wave 1 launches, but the hack is really easy to break during the build cycle and is not a permanent solution

noming to leo+

Comment 23

[José Antonio Olivera Ortega [:jaoo]]

There is no bug here. We print out several mcc/mnc values in the logcat, ones coming from the SIM, ones coming from the camping network, etc. but I don't understand how that could be considered as a bug. If marketplace guys needs to read mcc/mnc values I guess they read such values from the appropriated API and not from the logcat.

Comment 24

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

in the code it's an different object that holds the variables for the value of the network you are connecting to and the network the SIM refers to.

If a gaia developer misunderstand which mcc/mnc he needs to refer to, that could cause an issue.  I believe that the web api points to the SIM mnc, so that should be fine.  

Looking at the log, both variables state MCC/MNC which causes confusion for trouble shooting.  Android makes a clear distinction between the MCC/MNC of the SIM card and the Service State (the network we are connecting to which is NOT the MCC/MNC of the SIM card).  Why are we calling the Service State and the Sim card both MCC/MNC?

Comment 25

[Edgar Chen [:edgar]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #24)
> in the code it's an different object that holds the variables for the value
> of the network you are connecting to and the network the SIM refers to.
> 
> If a gaia developer misunderstand which mcc/mnc he needs to refer to, that
> could cause an issue.  I believe that the web api points to the SIM mnc, so
> that should be fine.  
> 
> Looking at the log, both variables state MCC/MNC which causes confusion for
> trouble shooting.  Android makes a clear distinction between the MCC/MNC of
> the SIM card and the Service State (the network we are connecting to which
> is NOT the MCC/MNC of the SIM card).  Why are we calling the Service State
> and the Sim card both MCC/MNC?

If your concern is about the logging, actually we have a clear distinction for the MCC/MNC of SIM card and the network device is connecting to.

*IccInfoChanged* means the information from sim card:

06-04 17:35:58.269: I/Gecko(146): -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:IccInfoChanged{ iccid : null, mcc : 214, mnc : 7, msisdn : null, spn : null, isDisplayNetworkNameRequired : false, isDisplaySpnRequired : false,  }

*VoiceInfoChanged* means the information from voice registration states (The voice network device is connecting to):

06-04 17:37:00.299: I/Gecko(146): -*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:VoiceInfoChanged{connected : true,emergencyCallsOnly : false,roaming : true,type : 'unknown',signalStrength : -99,relSignalStrength : 40,network : {mcc : 310, mnc :260, longName : 'T-Mobile', shortName : 'T-Mobile'},cell : {gsmLocationAreaCode : 275, gsmCellId :23991},state : 'registered'}

It is quite clear to me, how do you think, :nhirata?

Comment 26

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Doing : adb logcat | grep -E 'MCC|MNC'  will not show the information either way of which mcc|mnc the api is using.

Comment 27

[Edgar Chen [:edgar]]

Renoming: The api and code are all good, the only concern is about the logging.

Comment 28

[Edgar Chen [:edgar]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #26)
> Doing : adb logcat | grep -E 'MCC|MNC'  will not show the information either
> way of which mcc|mnc the api is using.

For the MOZ RIL, grep 'MCC|MNC' is showing the information from the sim card. If you want to get the operator information, please grep 'Operator'.

logcat | grep -E 'MCC|MNC|Operator'

I/Gecko   (  108): RIL Worker[0]: MCC: 466 MNC: 92  <---- MCC/MNC from the sim card
I/Gecko   (  108): RIL Worker[0]: Operator: Chungwa,Chungwa,46692  <--- operator information that device is connecting to

It is quite clear to me.

For the debug logging of commercial RIL, there is nothing we can do, it is controlled by partner.

Comment 29

[Wayne Chang [:wchang]]

Not blocking by partners, Wayne will check if blocking by mozilla re marketplace.

Comment 30

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I see.  Why do we call it Operator when in one logcat output and RIL:VoiceInfoChanged{MCC/MNC} in another?  It's not consistent.

Comment 31

[Edgar Chen [:edgar]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #30)
> I see.  Why do we call it Operator when in one logcat output and
> RIL:VoiceInfoChanged{MCC/MNC} in another?  It's not consistent.

RIL:VoiceInfoChanged is an IPC message sent to content side. It contains a set of voice related information, ex. network's mcc/mnc, signal strength, cell information .... etc.

Comment 32

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Given this information, I will go ahead and close this out.  Hopefully no one will make a mistake in the future between the 2 mnc/mccs either in the log or the code.