Fwd: Cinterion plugin patch

[Aleksander Morgado]

On Mon, Nov 28, 2016 at 10:41 PM, Reinhard Speyerer <rspmn at arcor.de> wrote:
> using CID 1 when this CID could be used for RAT LTE when used with
> AT!SCACT or AT^SWWAN may generally be problematic for the following
> reason: when the mobile is registering to LTE CID 1 is used by most
> mobiles to handle the default bearer assigned by the network during
> the EPS attach procedure.
>
> This means that whenever a value that differs from "IPV4V6","" is stored
> there the mobile asks the network to use this value for the EPS attach
> default bearer parameters whenever it performs the next EPS attach (e.g.
> after poweron) instead of letting the network assign them in the Activate
> Default Bearer request.
>

Is this CID=1 logic related to the default EPS bearer applicable to
all vendors? Or just Cinterion?

> Using a value which is not accepted by the network (e.g. by mistyping the
> APN) normally causes the network to send a EPS Attach reject to the mobile
> which causes the mobile to fall back to UMTS instead of using LTE.
>

Not good!

> If one uses another free CID > 1 and the default "IPV4V6","" for CID 1 the
> mobile would be able to register to LTE and one would only get an error
> after AT!SCACT or AT^SWWAN in case a value which is not accepted by the
> network is used.
>

This is probably what we want, yes.

> A disadvantage of this scheme is that one has to read the
> parameters from AT+CGCONTRDP=1 instead of AT+CGCONTRDP=<n> when the
> APN used for CID <n> matches the APN assigned to the default bearer.

The default CID selection logic in MM will first look for an existing
CID matching the settings we provide; this will likely work with the
statement above.

-- 
Aleksander
https://aleksander.es