Re: Augmenting mobile-broadband-provider-info



On Wed, 2010-01-20 at 16:02 -0600, Denis Kenzior wrote:
> Hi Dan,
> 
> On Wed, Jan 20, 2010 at 3:10 PM, Dan Williams <dcbw redhat com> wrote:
> >
> > On Mon, 2009-11-23 at 17:15 +0100, Marcel Holtmann wrote:
> > > Hi Antti,
> > >
> > > > > you can't trust the network name string returned by AT+COPS since there
> > > > > are so many factors coming into play here. So first of all you have the
> > > > > names stored in the modem itself, then the names stored on the SIM card
> > > > > and then the potential updates over the network. Every hardware does
> > > > > different things to present the result of AT+COPS.
> > > >
> > > > AFAIK if there's a name stored in the SIM card it will have precedence
> > > > over the ones stored inside the modem. And the ones that network sends
> > > > are probably most reliable. I have to look though the specs if there's
> > > > any information on this.
> > > >
> > > > Anyway the point is that in most situations we should have a correct
> > > > alphabetical name for the provider, right?
> > >
> > > I have seen different hardware with the same SIM card give different
> > > names. And I also have seen different SIM card with the same hardware
> > > result in different results.
> > >
> > > Also you have the problem that names change over time and some hardware
> > > and SIM card combination returns still the old one, while newer pieces
> > > would give you the new name.
> >
> > T-Mobile USA hasn't been Voicestream Wireless since 2002, but my ZTE
> > MF627 (a quite recent device sold by 3UK) returns:
> >
> > +COPS: (2,"AT&T@","AT&TD","310410",0),(3,"Voicestream Wireless Corporation","VSTREAM","31026",0),
> >
> > The SIM is a T-Mobile US SIM that is known to return "T-Mobile" in most
> > other cases.  And what's up with the "AT&T@" and "AT&TD" anyway?
> >
> > Basically, we simply can't trust that the COPS results are going to be
> > in any way accurate...
> >
> 
> Fully agreed, the COPS name is junk, and on properly implemented
> hardware the COPS name can actually
> change once the network performs a NITZ update.  Unfortunately there's
> no standard way of knowing what
> name the hardware is reporting, the one burned into firmware or taken
> from NITZ.  I've seen this happen on
> the Freerunner.  Immediately after registering COPS returns
> "Cingular", 5 minutes later it will return "AT&T".
> 
> Any such database has to account for the PCS digit for North American
> carriers.  For instance, T-Mobile
> SIMs are provisioned with 3 digit MNC, 260.  Yet most (all?) T-Mobile
> cells will actually report a 2 digit
> MNC, 26.  Whether the 3rd MNC digit is reported is completely up to
> the network cell tower.  Refer to
> table 10.5.3 in 3GPP 24.008.

Yep; I've looked over the MCC/MNC data and that may only be a problem
for India and the US in the future, but there weren't any clashes that I
could find in a quick check where for example one provider's 5-digit
conflicts with another provider's 6-digit with the 6-th digit removed.

But also, it's not *completely* up to the cell tower, as some modems
will pad it out too.  See below.

Some Option devices will also report *7* MCC/MNC digits in the cops
response.  Odd firmware I'd presume.

Option Quicksilver (AT&T locked & branded, with AT&T 3G SIM):

+COPS: (2,"AT&T","","310410",0),(2,"","","3104100",2),(1,"AT&T","","310260",0),,(0-4),(0-2)";

Three interesting notes:  (1) the 3G network MCC/MNC is 7 digits, and
(2) 310260 is T-Mobile, not AT&T, so AT&T is hiding the actual operator,
and (3) it shows 310260 where other devices at that location showed only
5-digit operator strings (Nokia N80).

Standards are relative :)

Dan

> Ultimately the SIM is the one to trust here, not COPS or any other
> combination of COPS/CREG, etc.
> Much of the COPS/CREG information can be ultimately overridden by the
> contents of the SIM
> elementary files like EFspn, EFspdi, EFehplmn, EFehplmnpi, EFpnn,
> EFopl, etc.  Of course various
> stacks / modems get this right in varying degrees of correctness.
> 
> Regards,
> -Denis



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]