Re: FC8

[Dan Williams <dcbw redhat com>]

On Mon, 2008-04-28 at 12:56 -0700, phil philgorsuch com wrote:
> Into the fray here :-)   Lets be clear, we are trying to make
> generalizations between two different technologies.   UMTS is
> significantly different from EV-DO at all levels be it network, hardware,
> at command sets, etc.

Definitely.  Though as our focus is on the user, hopefully no users have
to care that we've had this discussion.  It needs to just work for them,
irregardless of the technology their particular provider or card uses.

> >> > I don't believe you need the APN except in certain circumstances like
> >> > roaming or other less-common configurations.  We've got somebody
> >> working
> >> > on a mobile wizard that should be able to select the right APN for you
> >> > though if you need it.
> >>
> >> Different APNs often mean different billing schemes - for my no-limit
> >> flat
> >> data plan i need a different APN than for the normal, data volume
> >> charged data
> >> plans. Guess what APN was stored in the SIM when i got it...
> 
> Enabling APN in the GSM world is important - it allows carriers to
> differentiate service capabilities, billing rates, and essentially allows
> them to group or classify service offerings.   There is no guarantee the
> default profile or APN will be the one that should be used.   EV-DO
> doesn't quite have this concept, hence perhaps the importance is not so
> obvious.

Right.  No argument there.  APN is a heavily used GSM feature, and
obviously its one NM must support and must support well.

> >>
> >> >> Was just wondering if it should show the network name, i.e. T-Mobile?
> >> and is there a way to get it to show the signal strength?
> >> >
> >> > Yeah, both of these would be nice things to have.  Unfortunately, some
> >> > of that is blocked on the card vendors themselves becoming a bit more
> >> > open.  Most cards do not allow you to retrieve information about the
> >> > connection while you're connected, unless you use a proprietary
> >> protocol
> >> > that you must license from the vendor.
> 
> 1) In Asia/Europe where there are large numbers of carriers competeing for
> your business, its pretty critical to be able to identify and select the
> appropriate carrier.

Of course; this has to happen no matter where you are.  It's got to
happen even in the US when you roam, since no carrier has 100%
nationwide coverage.

> 2) Network and signal should be available from the single AT port devices
> before a PPP connection is established... which would be the critical
> stage  to look at these parameters.  Both UMTS and EVDO cards should be
> able to do this - albient using different AT commands (IS-707 for EV-DO TS
> 127 007 for UMTS).

Correct; we certainly can show signal strength before we connect, and we
can and should check whether the card is actually locked on a tower
before we allow the device to be activated.

> >>
> >> Please quantify "most cards". From the ~10 cards i have, only one, the
> >> Novatel
> >> X870 which only has one usable port, has this problem (but you can still
> >> select the provider and check signal strength before connecting).
> >> All other cards (Option, Sierra Wireless, Huawei) have two usable ports
> >> and
> >> you can use one of them to query for network data while being connected.
> >
> > Yes, you can do this on some cards.  I've never said this was impossible
> > for all cards.  I just said it was impossible for huge numbers of common
> > cards, many of which are CDMA, and many of which are GSM.
> >
> 
> Crass generalization here - from my own knowledge of the industry - not
> from comments posted here:
> 
> 1) Most (All?) EV-DO cards do not have a second AT command port (Market
> factors perhaps?).

Correct.

> 2) Most UMTS cards built within the last 2 years have a second AT command
> port

Right.

> 3) All cards older than 2 or so years have a single AT command port

Seems to be the case from what I've seen.

> 4) Some UMTS cards also support GSM 07.01 multiplexing, allowing multiple
> ttys on a single USB endpoint.
> 
> For the record:
> 
> MC727 - EV-DO
> S620 - EV-DO
> AC595U - EV-DO
> AC580 - EV-DO
> AC860 - Older UMTS
> PC5750 - EV-DO
> KPC680 - EV-DO
> 
> Thus I can see the difference in perception.

Though I do have access to an MC8775 and an AC880, which supposedly do
support AT commands on the secondary interface.  My point is simply that
a huge number of people in the US, whether they use GSM _or_ CDMA
cellular providers, don't necessarily have the capability of signal
strength while connected.

> 
> >
> > My point is that lots of people have cards that don't allow this
> > functionality under Linux yet.  If most cards used AT commands, I'd add
> > support tomorrow.  That would be awesome.
> 
> I think the split rather runs - Lots of people with EV-DO cards or older
> UMTS cards which cant support multiple AT ports, and another lots of
> people with relatively new UMTS cards which do support multiple AT
> ports... both are big groups, both are for the most part georaphically
> seperated.
> 
> > don't, we need to understand the entire field; what cards do?  how do
> > they support it?  what cards don't?  how can we easily identify cards
> > that do and cards that do not?  If a card does, are there variations in
> > the commands and responses?
> 
> This is where the umtsmon knowledge can be leveraged - there is alot of
> experience dealing with the tricks of the various cards to get them going
> sucessfully.

Right, and why Tambet and I are looking around for a single, common
project in which to store this knowledge.  It makes no sense for this to
be in umtsmon, comgt, NM, and vmc separately, otherwise it's a complete
duplication of effort.

But to actually be useful, the single common project must (a) use HAL
for hardware and capability detection, (b) support CDMA devices, (c)
provide a D-Bus interface so that NM _and_ other things can talk to it,
and (d) separate the backend from the UI.

Essentially, wpa_supplicant for mobile broadband devices that use an
AT-command interface.

> >
> > The way this support gets into NetworkManager is going to be the
> > following:
> >
> > 1) Add a property in HAL to tag the secondary port that can be used for
> > communication, if it exists
> >
> > 2) Tag secondary ports of cards known to support AT commands with the
> > correct modem.command_sets properties, and then add the property from
> > (1) so we know they are a secondary port
> >
> > 3) Recognize secondary ports in NM, and for those cards that support
> > them, provide signal strength and connection speed status to the user
> >
> 
> Sounds like a good plan to me - note secondary ports could be marked by
> what they support - be it AT commands or some proprietary protocol :)

Which is exactly why we specified the "modem.command_sets" as a string
list, so we could add the tag for the proprietary protocol to a port if
needed.

Dan