LTE attach settings

[Aleksander Morgado]

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.

>
> > >
> > > 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?

> 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 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.


> 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).

-- 
Aleksander
https://aleksander.es