GPRS support for Ofono

[Aki Niemi]

2009/9/2 Marcel Holtmann <marcel at holtmann.org>:
> Powered = on and RoamingAllowed = yes and Roaming = true will lead to
> auto-attach.
>
> Powered = on and RoamingAllowed = no and Roaming = true will lead to
> detach.
>
> Powered = on and Roaming = false will lead to auto-attach.
>
> Powered = off will lead to detach.

Why is auto-attach dependent on roaming?

> We are not going to expose Attach() or Detach() method. As explained
> there are global anyway and so pointless to expose. This can be handled
> in the background without bothering the higher level application with
> these details.

AFAIK, attach status of GPRS has both regulatory aspects to consider
(some operators require always attached vs. some prohibit it) as well
as power consumption issues (auto-attach might draw more power than
on-demand, although there's an inverse effect on latency). These are
issues you need to take into account, and higher layers in the stack
definitely *need* to be aware of as well. Also, I don' t think oFono
is the correct place for these decisions -> better expose a necessary
API and let upper layers deal with it.


In general, I appreciate the attempt to hide ugly details from
applications, but unfortunately some things can't well be hidden.
Another unrelated, but similar issue is network scanning. It just
isn't going to work without us exposing it in the D-Bus API
explicitly.

The reason is simple, Nokia modems suspend GPRS when scanning (or
registering), simply because the operation will take roughly three
times as long with GPRS attached. You will find this feature in
current phones, too.

Now, there is no way we can have GPRS suspend without warning just
because the stack deems it necessary to scan for networks. Again the
intention is good, but the end result not so good. I don't want to
start patching oFono to support this type of basic stuff.

>> In my proposal the "Status" variable was a three-state variable,
>> having the states "attached", "detached" and "suspended". "Suspended"
>> was specified to mean that the GPRS was attached, but temporarily not
>> available (for instance because of a 2G phone call or temporary loss
>> of cellular connectivity). In the IRC discussion someone said that
>> this property would not be part of Denis's API because the tri-state
>> variables were bad and the "suspended" status was not supported by
>> spec 27.007. However, the problem is that Maemo 5 already has UI
>> support for indicating that the connection is suspended, and that
>> makes it harder to drop the feature. Could the "suspended" status enum
>> still be left there, and just have the modems that don't support the
>> feature to never go to "suspended" mode?
>
> I am still not seeing the point in what suspended will do for us and the
> UI. And that Maemo 5 exposed such a state in the UI is not an argument
> to keep doing it. I asked this before, what are we suppose to be doing
> when we get signaled suspended?

You will find that practically every Nokia phone behaves this way,
i.e., you make a call in 2G, and the UI will inform you that GPRS is
suspended while on call.

>> Still one difference to my proposal was the dropping of the TX and RX
>> byte counts, and the explanation that those statistics would be
>> handled by the upper layers by reading the values from the network
>> interface. I mentioned the problem where the connection was terminated
>> by the network and the network interface was brought down before the
>> upper layer had a chance to read the values. After giving the matter
>> some thought, I still feel that for this reason the modem driver would
>> need to get the TX/RX data and send it to the upper levels, if at all
>> possible. Since many operators charge by the amount of data
>> transferred, not losing the TX/RX data is quite crucial. At least
>> Nokia phones have a GPRS data counter feature, that is supposed to
>> show the transferred data. This said, I know that not all modem
>> drivers can get the data from a connection that has been terminated by
>> the network, but that does not mean that the modem drivers that can
>> get the data should just discard it.
>
> This is for ConnMan or similar to figure out. And we can always count
> via netfilter or some other facility. Counting inside oFono makes no
> sense. However we could send out a statistics signal before taking the
> interface down if it would be really needed. Making it part of the
> properties and having to poll for it is wrong.

I believe emitting a signal was Ismo's original proposal.

> While oFono is sort of low-level, it is not that low-level. If it would
> we could expose the native AT commands. So in summary the PDP context
> are stored persistently in oFono. Like BlueZ remember paired devices.
>
> And for data roaming, we make it as simple as allowed = yes/no. This is
> all the upper layer need to configure.
>
> Not exposing method for attach/detach is a logical consequence as
> explained above. It is a global per modem detail and thus there is not
> point in exposing it. Also there is not point in having ConnMan and some
> other potential application fighting for it. We do auto-attach if
> available and tell the applications the status. If Attached = yes, then
> the application can connect/disconnect contexts. As simple as that.

Then expose an AutoAttach = true/false property. That would work.

>> By looking at Denis's proposal it is easy to see that my proposal
>> wasn't perfect either. ;-) At least the GPRS registration state and
>> possibly other properties need to be added to the D-Bus interface, and
>> the API also needs to be made more future-proof by thinking how the
>> network-initiated connections and the secondary contexts would be
>> made.
>
> I prefer start simple and add more details later. Removing details is
> more complicated than adding them.

For some of these features, there is no question whether or not we
need them. I think you should be listening closely for the
requirements we post, because this isn't something we *think* might be
needed some day -- this is stuff that we've implemented and will ship,
and expect to ship in the future.

Cheers,
Aki