Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property

[Jason Glasgow <jglasgow google com>]

On Mon, Oct 3, 2011 at 7:34 PM, Dan Williams <dcbw redhat com> wrote:

On Sat, 2011-10-01 at 15:45 +0200, Aleksander Morgado wrote:
> Hey hey,
>
> > > Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values,
> > > and preference of a specific mode is now given in the new PreferredMode
> > > property and as an extra argument to the SetAllowedModes() call.
> > >
> > >  * Supported Modes: bitmask specifying which modes are supported by the specific
> > > hardware. For example, a modem may only support 1G/2G/3G connections (not 4G).
> > >
> > >  * Allowed Modes: bitmask specifying which modes, of the ones Supported by the
> > > modem, are allowed to use. For example, a modem may support 1G/2G/3G connections
> > > but only 1G and 2G connections are allowed by the user as 3G involves more
> > > expensive data rates.
> > >
> > >  [Allowed] ⊆ [Supported]
> > >
> > >  * Preferred Mode: specific mode which is preferred among the ones defined in
> > > the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections
> > > but the user would like that if possible 2G be used, as 3G consumes too much
> > > battery. If 2G is not possible, 3G can be used.
> > >
> > >  [Preferred] ∈ [Allowed]
> >
> > I don't have a huge objection to this, but I'm not sure I see the
> > benefit of having the Preferred/Allowed split versus the complexity.
> > Basically, if Allowed were an enum where we enumerated the preference
> > there are 4 items to choose from (4G, 3G, 2G, empty) and 3 slots in the
> > preference order (since empty doesn't get a slot, just a single enum).
> > Thats a total of 25 combinations, but some like 2G>4G don't really make
> > sense, so we have somewhere under 25.  32-bits gives us a lot of range
> > there if it's an enum not a bitfield.  The downside is that it has no
> > relationship with the MM_MODEM_MODE flags.  My worry is just that it's
> > added complexity (3 properties to check instead of 2) that may be just a
> > bit more work for clients.
> >
>
> I do see problems in both implementations, and I understand that the new
> one may be more complex, but trying to cope with the addition of 4G to
> the list is not an easy task, I would say.

Yeah, I know.

> It would be good to check what modes the new LTE devices support. Is
> there anyone out there who can check this? Do the devices support
> specifying 'preferred' modes to automatically connect in one mode or
> another?

Unfortunately I don't have any information on this, we'd have to ask
contacts at Novatel, Sierra, Qualcomm, etc what the plans are here if we
can.  Qualcomm chips do have the ability to select a different "mode
preference", and as far as I can tell from the reverse engineering we've
done, it's a gigantic enum for every mode conceivable because they
include stuff like WiFi in there too.  Think stuff like
CDMA/AMPS/HDR/WLAN-only (ie 2G/1G/3G/Wifi only) as a distinct value from
HDR/LTE only (ie 3G/4G only).  And values for things like "anything
except WiFi".  So you can bet they've added a bunch more options to that
enum for LTE.

> Also, do the 4G devices support complex setups like "3G preferred, and
> if not available go 4G" or "3G preferred, and if not available go 2G".
> As a user, I think I can find good reasons to need these last two
> options, not just "3G preferred".

Yeah, that's the question... not sure we have an answer yet.  But I
guess it would be good to be able to do this since we aren't sure.

I am trying to figure out some more details on what the Novatel E362 supports.  I'll report back to the list.

-Jason

 

Dan

_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
http://mail.gnome.org/mailman/listinfo/networkmanager-list