Proposal: identifying modems and mobile broadband cards

[Dan Williams]

On Sat, 2008-02-09 at 00:23 +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.
> 
> okay. I am personally against listing GSM or CDMA if we basically only
> differ between their AT command sets. Since there is more to that.
> 
> So can we either list the standard (for the AT part) that they follow.
> Something like ETSI and TIA.

We might be able to get away with marking CDMA cards as "IS-707-A" or
something like that, but I'd have to check all the cards I can find to
ensure they actually conform.  Most Sierra devices supposedly do
IS-707-A, I'll have to check about Novatel and Kyocera.

> Or list all supported technologies in a string list. If we create FDI
> files for all cards anyway, then we easily list if they support EDGE or
> not. Or HSDPA or not etc.

Could do that, though I'm mostly concerned with the AT command set the
modems support.  Having a string list of the command set standards that
the card supports would be good.

Key: modem.at_command_sets
Type: string list
Values: is-707-a, hayes, <whatever the GSM standard is>

Something like that?

> Or even do both.
> 
> > > > 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.
> 
> They might use both AT command sets :(

Yeah, they probably do.

> > > > > 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.
> 
> Until someone sense me an AT based WiMAX card, I tend to ignore them ;)

Sounds good to me :)

Dan

> > > 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.
> 
> There are also different frequencies involved if I am not mistaken. Have
> to read that up, but it is off-topic anyway.
> 
> Regards
> 
> Marcel
> 
>