u-blox TOBY-L2, TOBY-R2, and LARA-R2 new initial bearer recommendations

Giacinto Cifelli gciofono at gmail.com
Sat Sep 5 08:38:19 UTC 2020

Hi Matthew,

On Sat, Sep 5, 2020 at 10:27 AM Aleksander Morgado <aleksander at aleksander.es>

> Hey Matthew,
> > u-blox released the following guidance in June 2020 on the TOBY-L2,
> TOBY-R2, and LARA-R2 to setup your APN you want to connect to as the
> initial bearer at CID=1.
> >
> >
> https://www.u-blox.com/sites/default/files/LTE-initial-default-bearer_AppNote_%28UBX-20015573%29.pdf
> >
> > These modems already have a default CID=1 APN setup that is generic and
> ModemManager then uses another CID based on the APN you want to use and the
> IP type (IPv4, IPv6, both).  When I manually modified the modem's CID=1
> entry to the correct APN and IP type to match what ModemManager is trying
> to use, the modem connected so much faster with ModemManager and did not
> have as many issues with re-connection times.
> >
> > I am interested in making changes to ModemManager to implement always
> using CID=1 for these modems.  I know the code that handles the CID
> selection and creation of new ones if there is no a match is in
> src/mm-broadband-bearer.c.  I also know there is a plugin for u-blox that
> can detect model types.  What I am not sure how to do is override the
> functions in src/mm-broadband-bearer.c with ones that will be in the u-blox
> plugin.  The AT command u-blox uses to modify CIDs is AT+CGDCONT.
> >
> > Additionally I still want to use the code in src/mm-broadband-bearer.c
> for all other u-blox modems that don't match these models.
> >
> > Another difficult part of this is the modem needs to be de-registered
> from the network when changing CID=1 if the APN and IP type do not match
> what the ModemManager APN and IP type are.  The modems use AT+CFUN to put
> the modem in airplane mode and back to full mode when changing the CID=1
> APN settings.  I don't think this works with the current data connection
> flow in ModemManager.
> >
> > I am currently using the ModemManager 1.8.X series, but could implement
> the changes on the newest version and the back port them for the product I
> am working on.  I plan to update to the newest ModemManager eventually, but
> if updating now makes this easier to implement, then I might do that sooner
> than originally planned.
> >
> > I would really appreciate some guidance on how I would best go about
> implementing these changes.  Thanks.
> >
> Please take a look at the recent Cinterion plugin changes, because
> Giacinto has already implemented this kind of thing for Cinterion
> modems, using the SetInitialEpsBearerSettings() method:
> https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Modem.Modem3gpp.html#gdbus-method-org-freedesktop-ModemManager1-Modem-Modem3gpp.SetInitialEpsBearerSettings
> See
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/e2ab49db0f5078716156c70a23f8f5d5b6d27848
> for the specific details. In the case of Cinterion modems, it was not
> always CID=1, it was required some additoinal logic to guess which
> would be the correct CID to use based on the operator.
> My suggestion would be to provide a u-blox specific implementation for
> now, without looking at making it generic yet, and once we have
> several such implementations we can simplify the logic and build up
> the generic code to match all.

I would like to add one note: NM does not call this
SetInitialEpsBearerSettings() method.
You will need a separate supervision to set it adequately on a given
trigger (when the modem is detected or when a new SIM is detected).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20200905/909d7e12/attachment-0001.htm>

More information about the ModemManager-devel mailing list