Hi Denis,
> I'm not quite sure what you mean here. There are many
different cases, where the network can detach a UE from GPRS
service. See possible detach causes in 24.008. Currently,
oFono does not recover at all. Trying to figure out when GPRS
is again available can get pretty complicated and the
different detach causes require different handling. IMO, the
simplest approach by far is to retry GPRS attach when someone
actually needs a PDP context.
So here's the problem, ConnMan is in charge of activating the
context on
Meego. ConnMan activates the context once we're attached. So how do
you expect your 'on-demand' re-attach to work exactly?
ConnMan really should not care whether we are attached or not. Why do you need a trigger
in ConnMan, anyway? As far as I can see, a GPRS connection should only be activated if
some client of ConnMan requests it.
Besides, 24.008 cause codes give us plenty of hints of
whether / when to
re-attach, and only a few of them require 'special' handling.
I still think that we should come up with some strategy to re-attach
automatically when detached by the network.
Even if you can come up with an algorithm, testing it is very very challenging. There are
plenty of differences in operator networks and it is very difficult to cover all cases.
Making sure that the algorithm works requires extensive IOT and Field testing. We really
don't want a case, where oFono fails to re-attach for whatever reason. We also
don't want the case where oFono has not yet attempted to re-attach (e.g. on a timer)
and a PDP context activation fails, even though GPRS would actually be available.
For the above reasons, retrying attach on PDP context activation makes sense as a
safe-guard, regardless of whether we have a re-attach algorithm or not. We use on-demand
attach in pretty much all our products (except for certain operator specific variants)
precisely because it is certain to work. No funny business. If there is GPRS service, you
get a connection. It is also an approach that should work with any AT modem as well.
Br,
MikaL