Howto "AT^SXRAT" (Cinterion specific)

[Giacinto Cifelli]

Hi Norbert,

> >>> We're using a Cinterion ELS61-E R2 and seem to suffer from a lot of
> >>> "packet data disconnects" and cell/rat/MO switching.
> >
> > Are you using the bare modem or on some datacard?
> > Is the power supply good?
> > And the antenna?
> > Please ask your contact in Thales (or a reseller) if there is a more
> > recent FW for your modem.  (I am part of Thales, too, but I am not
> > deep into ELS61 and all its variants and options, so it would take
> > more time to me to find out than for a more direct contact).
> >
>
> Yeah, Thales supports us with the "packet data disconnects" and
> cell/rat/MO switching issues.
> Let me be clear: about 95% of our systems have a proper working and
> stable LTE connection using the bare Cinterion ELS61-E R2 modem.
> We're trying to draw a conclusion on the remaining 5%. It doesn't look
> like it simply is a "too weak signal case" although it might have
> something to do with it.
>
> Thanks for your suggestions, we did plan to checkout the antenna (once
> more).
> About the power supply, I guess you mean it has to be a single voltage
> source (for BATT+BB and BATT+RF) and must be able to provide the peak
> current. Or is there anything else you had in mind?
>
I think it is ok like this.

> > These would be the main things to look at, to understand and fix the
> > root cause, the rest below (in  which I am going to comment anyway),
> > could be workarounds for special situations, but not the solution.
>
> That is quite an interesting and clear statement.
> So what you're saying is that the many cell/rat/MO switching we see
> cannot really be resolved by limiting the RAT?

It can, but I consider it a workaround for strange situations.  The
normal mode should be enough.
You mentioned about that this is for the 5%, which can qualify as
"strange situation".
When the applications start playing with the RAT and the operator
selection, however, they become quickly complicated due to all rules
and exceptions to them that they have to introduce.

> Not even when the signal really is too weak or when we're near the
> 2G<->3G or 3G<->4G RAT-switch-over threshold?

The standard has an hysteresis for switching, which should guarantee
some stability (the acceptable values are not fixed but instead
broadcast by each cell, so that it is possible to design smaller and
more dense cells and bigger cells).
If you are at the border of 2 or 3 cells, all equally weak, then it is
possible that you switch often.  This should be visible in the
AT^SMONI response.

> It's only
> mm_iface_modem_3gpp_register_in_network->modem_3gpp_register_in_network
> that sends "AT+COPS=0" (and factory_reset).
> I'm not sure when modem_3gpp_register_in_network is called. In a quick
> test where I let NetworkManager disconnect(DOWN) and connect(UP) the
> mobile connection it doesn't seem to be called (and so the one RAT that
> was set with --set-allowed-modes was honored)
>
> So SXRAT shouldn't follow COPS=0, OK. Then how to implement SXRAT
> for combined RAT (preferences)?
> I guess it is not "enough" to simply use SXRAT instead of COPS=,,,x in
> the function: set_current_modes?
>

AT+COPS=0 is necessary to force the modem to scan in some conditions,
and so you cannot avoid it.
>From the description of your case, it looks like you really need to
top it up with AT^SXRAT.
However making it generic in the plugin wouldn't be my choice.  Or at
least it should have a flag for the application to decide whether it
wants this quirk or not (default: no).

Best Regards,
Giacinto