Proposal: identifying modems and mobile broadband cards

[Dan Williams]

On Fri, 2008-02-08 at 23:00 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > While adding mobile broadband card support to NetworkManager, it turned
> > > > out that we needed a more specific way of finding modems.  Most of these
> > > > devices present themselves as a few serial ports, either /dev/ttyUSBx
> > > > or /dev/ttyACMx.  The first serial port is the communications port,
> > > > which acts just like a modem and supports AT commands.  When the data
> > > > connection is open though, you must talk to the device (for signal
> > > > strength, etc) on the other serial ports because interrupting the data
> > > > stream for an AT command is a Bad Thing.
> > > > 
> > > > We can already search for the 'serial' capability, but any serial port
> > > > (including COM ports) has that capability, and we certainly don't want
> > > > to go around poking the ports to see what's there.
> > > > 
> > > > Second, we need to differentiate between CDMA and GSM based mobile
> > > > broadband cards, and the best way to do that is through FDI files too.
> > > > 
> > > > Proposal:
> > > > 
> > > > - The interface that has the 'serial' capability acquires the 'modem'
> > > > capability if that serial interface is indeed known to be a modem
> > > 
> > > I agree here. We should do that. Marking the real modem interface as
> > > modem would be a big win.
> > > 
> > > > - A property "modem.type" gets added with the value "at" if the modem
> > > > supports Hayes-compatible AT commands
> > > 
> > > Do we really need that. Modem that doesn't do AT commands is kinda
> > > weird. Do we have any of these and could we actually reliable identify
> > > them. For me capability=modem implies AT commands.
> > 
> > Fair enough, I don't really have any strong feelings about this part.
> > 
> > > Or do we wanna do capability=hayes?
> > 
> > Well, strictly speaking "modems" don't necessarily have a command set; I
> > didn't want to make things to specific to start with.  Don't care much
> > here either.
> 
> I am really fine if we simply mark them as capability=modem. And leave
> the second TTY port as capability=serial. This especially helps for this
> binary only add-on ports of a bunch of cards.
> 
> > > > - A property "modem.phy_type" gets added that contains a value like
> > > > 'gsm', 'cdma', or 'wimax', maybe even 'pots' for old-school modems
> > > 
> > > Why? Lets use AT commands in the client (NM or umtsmon etc.) for that. I
> > > am afraid that vendors screw this up when we do purely identification
> > > via USB or PCI vendor and product here.
> > 
> > The downside of doing it this way is that you have to actually poke the
> > device to know what type of device it is; and it's not always that easy
> > to identify (might have to have quirks for a lot of cards, etc), and
> > it's something that would benefit all clients of HAL, and not requiring
> > everything to re-implement the same type detection code.  How many AT
> > commands do you have to issue? What's the decision tree here for
> > detecting device type, and how complex does it get?
> 
> Good questions. I live in a GSM and UMTS world (UMTS uses CDMA btw.) and
> there you have a nice ETSI command set. So that is pretty simple.

Yeah, but it's WCDMA which uses 5MHz channels, while
"CDMAone" (IS-95a/b) uses 1.25MHz channels.  

> So maybe we should make it as ETSI and others as ... I really don't know
> since I only heard about these EVDO cards. Do they follow the ETSI AT
> command standard? Or how do you actually dial?

1xRTT/EVDO (evolutions of CDMAone which is IS-95) is what half the
people in the US, Canada, Australia, and New Zealand, and everyone Korea
use, plus some large operators in China.  EVDO is the 3G evolution of
CDMAone (IS-95 and later) that Verizon, Sprint, Alltel, and others use
in the US.

Of the two major cellular standards tracks you have:

GSM -> GPRS -> EDGE -> UMTS -> HSDPA -> HSUPA

CDMAone -> 1xRTT (CDMA2000) -> EVDO rev 0 -> EVDO rev A

The dial just the same as GSM cards, but the differences lie in operator
selection, address book, and SIM stuff.  Since IS-95 based systems and
later don't use SIM cards (they are typically locked to an operator
based on the ESN or MEID), they don't have any of those things.
Furthermore, roaming is controlled through system ID lists loaded into
the device itself, you cannot choose networks to roam on that your
operator has not allowed or partnered with.  Most CDMA phones allow you
to set "Roaming: yes/no" but you are almost never allowed to pick a
specific carrier on which to roam.

> Do you actually care about what baseband technology is behind it?

No, but since the CDMA cell standards don't do all the roaming stuff
that GSM does, you don't have the same network scanning, operator
selection, or network ID commands and responses as GSM-based cards.

> > That said, I do know of cases where vendors hide protocols to detect
> > card types and use the same p/v ids.  But the alternative is extremely
> > ugly and duplicating code in everything that would want to know the
> > device type (NM, VMC, umtsmon, comgt, etc) is just wrong.
> 
> If it is two AT commands to get the type, then I would say it is fine if
> they are well defined. If it is full of quirks, then lets use FDI files
> for that. The client can still ignore the HAL value.

That's the problem; I'm not 100% sure what we'll need here.  The
variations between cards exist, and we don't know what cards say what
when you poke them with AT commands.  But we do know that almost all the
mobile broadband cards out today can be categorized into either GSM or
CDMA based categories.  I'm not sure what things like the Blackberry
Worldphone (from Verizon) expose themselves as when you plug them in
with USB, since they contain both GSM and CDMA radios.

Also, I just don't like poking things like this to find out what they
are; it's like HAL having to access your CD drive to figure out what
type of media you have in it, when we almost 99.9% know what type of
device the mobile broadband card is out of the box.

> > > And btw. WiMAX will not be AT modem based.
> > 
> > I've heard that some Zyxel cards are like this, but most of the new
> > stuff coming out in the next few months is likely to need real, actual
> > drivers I've heard.
> 
> >From my knowledge all WiMAX stuff is native IP based. However I have
> seen AP that did PPPoE for the pre-WiMAX stuff and emulating then plain
> PPP over serial is not far away. Not that it makes sense.

Yes, all the new stuff should be native IP based.  And if we don't care
about too many of the older cards then we can drop the WiMAX stuff here
and just treat them more like 802.11.

> Also there is a difference between stationary WiMAX and mobile WiMAX.

Yep, but not much to the OS.  The only difference is that mobile WiMAX
(802.16e-2005) has provisions for roaming between base stations, while
fixed WiMAX (802.16-2004) does not.  I'm not sure what the firmware API
differences are there though.

Dan