LTE attach settings

[Giacinto Cifelli]

Hi Aleksander,


On Thu, Jul 23, 2020 at 8:28 AM Aleksander Morgado
<aleksander at aleksander.es> wrote:
>
> Hey
>
> > > > I need to set up the default LTE bearer settings: APN, type of APN,
> > > > authentication parameters, in the Cinterion plugin.
> > > >
> > > > And for this, I am going to add the two methods:
> > > >     void     (* set_initial_eps_bearer_settings)
> > > > (MMIfaceModem3gpp     *self, ..
> > > >     gboolean (* set_initial_eps_bearer_settings_finish)
> > > > (MMIfaceModem3gpp     *self, ..
> > > >
> > > > Is this the right way to do it? I see that nobody implemented it so
> > > > far. Is this called for mbim or qmi?
> > > >
> > >
> > > This is currently implemented for MBIM devices, because in MBIM
> > > devices there are explicit APIs to set them without needing to worry
> > > about what specific CID number we're touching.
> > >
> > > > I will have to run the following sequence:
> > > > -        go in AT+CFUN=4 (airplane mode with SIM connected). This is
> > > > necessary because the CID might be locked or not taken into account
> > > > immediately (in case there is an attach attempt ongoing).
> > > > -        set AT+CGDCONT for the right CID (normally 1)
> > > > -        set AT^SGAUTH for the same CID
> > > > -        go back to AT+CFUN=1.
> > > >
> > > > Is this ok to you?
> > >
> > > The requirement to run CFUN=4 before and CFUN=1 after seems very
> > > generic to me; at the end we're changing the APN settings used during
> > > LTE registration, so it is assumed the device needs to re-register. I
> > > say this because it may make sense to move that logic "up" to the
> > > Modem3gpp interface, so that the interface itself puts the modem in
> > > low-power mode before the change and puts it back into full-power mode
> > > after the change. But don't worry about that, this can be done later,
> > > if you do the CFUN=4/1 yourself in the cinterion plugin for now it's
> > > ok.
> > >
> >
> > ok, I think that it should also be moved up, but this requires further
> > consideration.
> > For example in case of SIM hot swap: then the entire state should be
> > moved back to that point.
>
> Do not worry at all about SIM hot swap, because a SIM hot swap
> triggers a full modem re-probe: the modem is removed from DBus and
> re-probed from scratch, and then re-exposed in DBus with a new object
> path. At this point, SIM hot swap is always seen in MM as a full modem
> power cycle, even if there isn't such power cycle really.
>

This is exactly the behavior that would be necessary.
So it is already in place. Cool!

> >
> > > >
> > > > Instead of CFUN=4/1 also COPS=2/0 could be used, but I prefer the former.
> > > >
> > >
> > > The only issue I see is the selection of the "right CID" in CGDCONT.
> > > As you said, it is normally 1, but as we've already found in the past
> > > it may be operator dependent; e.g. wasn't it CID=4 for Verizon?
> > >
> >
> > Cinterion modules use CID=3 for VZW, CID=2 for T-Mobile Germany with
> > VoLTE, 1 in all other cases.
>
> Is this a choice done by the manufacturer, or a choice done by the
> carrier, or a mix of both?

for t-mobile, I think it is a chipset decision, but for VZW it is an
intrusive choice of the carrier,
and so the manufacturers have to comply to get access to the network.
Due to this and other requirements, VZW products are limited (of
course most the handsets for the US market follow the requirements,
but they are in another league), so it is not surprising you don't
hear much about it.

>
> > I intend to filter for this by querying the current VoLTE profile with
> > AT^SCFG="MEopMode/Prov/Cfg".
> > This would go between steps 1 and 2 above, but for the general
> > discussion I left this out as an implementation detail.
> >
>
> I'm trying to understand whether this is a change we require to do in
> a more generic way (if the CIDs are chosen by carrier) or just
> specific in this plugin (if the CIDs are chosen by manufacturer or by
> both). CID=3 for Verizon is the first time I've seen, IIRC, so not
> sure.
>

I am not sure I can help you here directly. I will anyway implement
the entire logic for it in the Cinterion plugin, then we can decide
whether it makes sense to broaden it.

> > > I believe that other vendors use other approaches, even with separate
> > > APIs, e.g. the u-blox TOBY-L2 had specific commands for this IIRC.
> >
> > I saw uBlox specifications, and they use CID=1 and CID=4 quite often.
> > It is not impossible that they also use a special API in some models.
> > Some XMM modems use CID=0 (as would be prescribed by the 3GPP 27.007).
> >
>
> Oh, so 3GPP specs specify CID=0 for the initial LTE default bearer
> settings, but almost no manufacturer implements it that way? :( CID=0
> would be a proper default then, but we would need to subclass that in
> each plugin that doesn't follow that.
>

Yes, but only Intel implements it, and only on some products, as far
as I know. And Intel is going out of market soon.
So the reference remains Qualcomm, whose products and choices dominate
the market, and whose default is 1.

>
> > For the rest, the great majority use CID=1, I believe because it is
> > the most common setting from the chipset makers.
> >
>
> Yes, I'd understand that.
>
> > >
> > > At this point, and given that it is everyday more common to have the
> > > requirement to change the initial LTE bearer settings, I wouldn't mind
> > > to have this logic with the "far from perfect" initial default of
> > > reconfiguring CID=1. I just got this very same requirement just
> > > yesterday debugging connectivity with an Orange Morocco SIM, so I'm
> > > sure there are users out there also requiring this kind of
> > > configuration.
> > >
> >
> > Sound good.
> > Only I am not sure how you would do it in MM.
> > The modem is set to CFUN=1 as soon as it is mapped, and the APN and
> > other parameters have to be supplied via dbus, and so after the modem
> > has already attempted to attach.
> >
>
> There is no limitation on when the SetInitialEpsBearerSettings can be
> run, and that means it may be run in any modem state. This means
> plugins can do whatever they require to update these settings at this
> point, so you can implement the CFUN=4/CFUN=1 cycle if you need to.
> BUT, the cycle should make sure the initial state is not 4; i.e. if it
> is already 4 (because the modem was put in low power mode via MM) then
> you shouldn't do the CFUN=1 at the end. You should do a CFUN? first,
> store the state it was in, and at the end of the cycle, recover that
> state (if it was 1 or some other thing) or do nothing (if it was the 4
> you needed).
>

Ok, this means that it could also fail. While MM doesn't give the
option for CFUN=0, the module could be in that state.
cfun=0 is airplane mode with SIM off. Used to be a command to switch
off the modem in old models.
Au passage, also cfun=4 and cfun=7 used to be values to go in
low-power mode (there are still traces in the MM code) on the serial
interface, but now they are just radio settings, given that the serial
interface is rarely used, and modern implementations can also sense
the tx/rx lines for knowing when to switch on the UART.

Back to our settings, ok for checking at+cfun? beforehand, and
restoring the initial status if needed.
So the sequences will be:
cfun=0 -> abort
cdun=1 -> go to cfun=4, set everything, go back to cfun=1
cfun=4 -> just set everything without changing settings
cfun=other -> abort