[PATCH 0/3] Attach GPRS on demand

[PATCH 0/3] Attach GPRS on demand

[Mika Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

Hi All,

Currently, if GPRS service is detached for whatever reason, the only way
to get PS services back is to set the Powered property to FALSE and back
to TRUE.

With these patches, GPRS context activation will cause oFono to
automatically attempt GPRS attach if the modem is presently detached.

Br,

	MikaL

[PATCH 1/3] gprs: attach on demand
[PATCH 2/3] gprs: update documentation
[PATCH 3/3] isimodem: context activation might follow attach

[PATCH 1/3] gprs: attach on demand

[Mika Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 6614 bytes --]

Attach automatically when a GPRS context is activated
---
 src/gprs.c |  153 ++++++++++++++++++++++++++++++++---------------------------
 1 files changed, 83 insertions(+), 70 deletions(-)

diff --git a/src/gprs.c b/src/gprs.c
index 610f3b2..d4b4e24 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -106,6 +106,7 @@ struct context_settings {
 
 struct pri_context {
 	ofono_bool_t active;
+	ofono_bool_t activation_pending;
 	enum ofono_gprs_context_type type;
 	char name[MAX_CONTEXT_NAME_LENGTH + 1];
 	char message_proxy[MAX_MESSAGE_PROXY_LENGTH + 1];
@@ -647,6 +648,49 @@ static DBusMessage *pri_get_properties(DBusConnection *conn,
 	return reply;
 }
 
+static gboolean assign_context(struct pri_context *ctx)
+{
+	struct idmap *cidmap = ctx->gprs->cid_map;
+	unsigned int cid_min;
+	GSList *l;
+
+	if (cidmap == NULL)
+		return FALSE;
+
+	cid_min = idmap_get_min(cidmap);
+
+	ctx->context.cid = gprs_cid_alloc(ctx->gprs);
+	if (ctx->context.cid == 0)
+		return FALSE;
+
+	for (l = ctx->gprs->context_drivers; l; l = l->next) {
+		struct ofono_gprs_context *gc = l->data;
+
+		if (gc->inuse == TRUE)
+			continue;
+
+		if (gc->type == OFONO_GPRS_CONTEXT_TYPE_ANY ||
+						gc->type == ctx->type) {
+			ctx->context_driver = gc;
+			ctx->context_driver->inuse = TRUE;
+			return TRUE;
+		}
+	}
+
+	return FALSE;
+}
+
+static void free_context(struct pri_context *ctx)
+{
+	gprs_cid_release(ctx->gprs, ctx->context.cid);
+	ctx->context.cid = 0;
+	ctx->active = FALSE;
+	ctx->activation_pending = FALSE;
+	if (ctx->context_driver)
+		ctx->context_driver->inuse = FALSE;
+	ctx->context_driver = NULL;
+}
+
 static void pri_activate_callback(const struct ofono_error *error,
 					const char *interface,
 					ofono_bool_t static_ip,
@@ -666,11 +710,7 @@ static void pri_activate_callback(const struct ofono_error *error,
 		__ofono_dbus_pending_reply(&ctx->pending,
 					__ofono_error_failed(ctx->pending));
 
-		gprs_cid_release(ctx->gprs, ctx->context.cid);
-		ctx->context.cid = 0;
-		ctx->context_driver->inuse = FALSE;
-		ctx->context_driver = NULL;
-
+		free_context(ctx);
 		return;
 	}
 
@@ -706,15 +746,9 @@ static void pri_deactivate_callback(const struct ofono_error *error, void *data)
 		return;
 	}
 
-	gprs_cid_release(ctx->gprs, ctx->context.cid);
-	ctx->context.cid = 0;
-	ctx->active = FALSE;
-	ctx->context_driver->inuse = FALSE;
-	ctx->context_driver = NULL;
-
+	free_context(ctx);
 	__ofono_dbus_pending_reply(&ctx->pending,
 				dbus_message_new_method_return(ctx->pending));
-
 	pri_reset_context_settings(ctx);
 
 	value = ctx->active;
@@ -957,38 +991,6 @@ static DBusMessage *pri_set_message_center(struct pri_context *ctx,
 	return NULL;
 }
 
-static gboolean assign_context(struct pri_context *ctx)
-{
-	struct idmap *cidmap = ctx->gprs->cid_map;
-	unsigned int cid_min;
-	GSList *l;
-
-	if (cidmap == NULL)
-		return FALSE;
-
-	cid_min = idmap_get_min(cidmap);
-
-	ctx->context.cid = gprs_cid_alloc(ctx->gprs);
-	if (ctx->context.cid == 0)
-		return FALSE;
-
-	for (l = ctx->gprs->context_drivers; l; l = l->next) {
-		struct ofono_gprs_context *gc = l->data;
-
-		if (gc->inuse == TRUE)
-			continue;
-
-		if (gc->type == OFONO_GPRS_CONTEXT_TYPE_ANY ||
-						gc->type == ctx->type) {
-			ctx->context_driver = gc;
-			ctx->context_driver->inuse = TRUE;
-			return TRUE;
-		}
-	}
-
-	return FALSE;
-}
-
 static DBusMessage *pri_set_property(DBusConnection *conn,
 					DBusMessage *msg, void *data)
 {
@@ -1030,8 +1032,19 @@ static DBusMessage *pri_set_property(DBusConnection *conn,
 		if (ctx->active == (ofono_bool_t) value)
 			return dbus_message_new_method_return(msg);
 
-		if (value && !ctx->gprs->attached)
-			return __ofono_error_not_attached(msg);
+		if (value && !ctx->gprs->attached) {
+			gprs_netreg_update(ctx->gprs);
+
+			if (!(ctx->gprs->flags & GPRS_FLAG_ATTACHING))
+				return __ofono_error_not_attached(msg);
+
+			if (!assign_context(ctx))
+				return __ofono_error_not_implemented(msg);
+
+			ctx->activation_pending = TRUE;
+			ctx->pending = dbus_message_ref(msg);
+			return NULL;
+		}
 
 		if (ctx->gprs->flags & GPRS_FLAG_ATTACHING)
 			return __ofono_error_attach_in_progress(msg);
@@ -1284,6 +1297,8 @@ static void gprs_attached_update(struct ofono_gprs *gprs)
 	const char *path;
 	ofono_bool_t attached;
 	dbus_bool_t value;
+	GSList *l;
+	struct pri_context *ctx;
 
 	attached = gprs->driver_attached &&
 		(gprs->status == NETWORK_REGISTRATION_STATUS_REGISTERED ||
@@ -1294,24 +1309,32 @@ static void gprs_attached_update(struct ofono_gprs *gprs)
 
 	gprs->attached = attached;
 
-	if (gprs->attached == FALSE) {
-		GSList *l;
-		struct pri_context *ctx;
-
-		for (l = gprs->contexts; l; l = l->next) {
-			ctx = l->data;
+	for (l = gprs->contexts; l; l = l->next) {
+		struct pri_context *ctx = l->data;
+		struct ofono_gprs_context *gc = ctx->context_driver;
 
-			if (ctx->active == FALSE)
+		if (attached) {
+			if (!ctx->activation_pending)
 				continue;
 
-			gprs_cid_release(gprs, ctx->context.cid);
-			ctx->context.cid = 0;
-			ctx->active = FALSE;
-			ctx->context_driver->inuse = FALSE;
-			ctx->context_driver = NULL;
+			ctx->activation_pending = FALSE;
 
+			gc->driver->activate_primary(gc, &ctx->context,
+							pri_activate_callback,
+							ctx);
+		} else {
+			ofono_bool_t active = ctx->active;
+
+			if (ctx->activation_pending)
+				__ofono_dbus_pending_reply(&ctx->pending,
+					__ofono_error_failed(ctx->pending));
+
+			free_context(ctx);
 			pri_reset_context_settings(ctx);
 
+			if (!active)
+				continue;
+
 			value = FALSE;
 			ofono_dbus_signal_property_changed(conn, ctx->path,
 					OFONO_CONNECTION_CONTEXT_INTERFACE,
@@ -1758,12 +1781,7 @@ static void gprs_deactivate_for_all(const struct ofono_error *error,
 		return;
 	}
 
-	gprs_cid_release(gprs, ctx->context.cid);
-	ctx->active = FALSE;
-	ctx->context.cid = 0;
-	ctx->context_driver->inuse = FALSE;
-	ctx->context_driver = NULL;
-
+	free_context(ctx);
 	pri_reset_context_settings(ctx);
 
 	value = ctx->active;
@@ -1997,12 +2015,7 @@ void ofono_gprs_context_deactivated(struct ofono_gprs_context *gc,
 		if (ctx->context.cid != cid)
 			continue;
 
-		gprs_cid_release(ctx->gprs, ctx->context.cid);
-		ctx->context.cid = 0;
-		ctx->active = FALSE;
-		ctx->context_driver->inuse = FALSE;
-		ctx->context_driver = NULL;
-
+		free_context(ctx);
 		pri_reset_context_settings(ctx);
 
 		value = FALSE;
-- 
1.7.1

[PATCH 2/3] gprs: update documentation

[Mika Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

---
 doc/connman-api.txt |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/doc/connman-api.txt b/doc/connman-api.txt
index 22e02e5..e53032c 100644
--- a/doc/connman-api.txt
+++ b/doc/connman-api.txt
@@ -142,6 +142,9 @@ Properties	boolean Active [readwrite]
 			Holds whether the context is activated.  This value
 			can be set to activate / deactivate the context.
 
+			Activating a context will automatically trigger the
+			GPRS attach procedure if necessary.
+
 		string AccessPointName [readwrite]
 
 			Holds the name of the access point.  This is
-- 
1.7.1

[PATCH 3/3] isimodem: context activation might follow attach

[Mika Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

---
 drivers/isimodem/gprs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/isimodem/gprs.c b/drivers/isimodem/gprs.c
index 3c9facd..deffb1a 100644
--- a/drivers/isimodem/gprs.c
+++ b/drivers/isimodem/gprs.c
@@ -259,7 +259,7 @@ static GIsiRequest *attach_request_send(GIsiClient *client, void *data)
 {
 	const unsigned char msg[] = {
 		GPDS_ATTACH_REQ,
-		GPDS_FOLLOW_OFF
+		GPDS_FOLLOW_ON
 	};
 
 	return g_isi_send(client, msg, sizeof(msg), GPDS_TIMEOUT,
-- 
1.7.1

Re: [PATCH 0/3] Attach GPRS on demand

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

Hi Mika,

On 12/02/2010 10:16 AM, Mika Liljeberg wrote:
> Hi All,
> 
> Currently, if GPRS service is detached for whatever reason, the only way
> to get PS services back is to set the Powered property to FALSE and back
> to TRUE.
> 
> With these patches, GPRS context activation will cause oFono to
> automatically attempt GPRS attach if the modem is presently detached.
> 

Before I look at these patches: Have you considered fixing the attach
behavior instead?  It seems like the approach you're proposing is
essentially hitting oFono over the head because it isn't doing what you
want...

Regards,
-Denis

RE: [PATCH 0/3] Attach GPRS on demand

[Mika.Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

Hi Denis,

> > With these patches, GPRS context activation will cause oFono to
> > automatically attempt GPRS attach if the modem is presently 
> detached.
> > 
> 
> Before I look at these patches: Have you considered fixing the attach
> behavior instead?

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. 

>  It seems like the approach you're proposing is
> essentially hitting oFono over the head because it isn't 
> doing what you
> want...

Sorry, still confused. What do you mean?

	MikaL

Re: [PATCH 0/3] Attach GPRS on demand

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

Hi Mika,

On 12/09/2010 02:12 AM, Mika.Liljeberg(a)nokia.com wrote:
> Hi Denis,
> 
>>> With these patches, GPRS context activation will cause oFono to
>>> automatically attempt GPRS attach if the modem is presently 
>> detached.
>>>
>>
>> Before I look at these patches: Have you considered fixing the attach
>> behavior instead?
> 
> 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?

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.

Regards,
-Denis

RE: [PATCH 0/3] Attach GPRS on demand

[Mika.Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

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

Re: [PATCH 0/3] Attach GPRS on demand

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]

Hi Mika,

On 12/09/2010 03:57 AM, Mika.Liljeberg(a)nokia.com wrote:
> 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.

Actually it should care.  We do safe-guard against attaching while
roaming...

Besides, ConnMan doesn't really work this way.  Maybe in the future with
the session API it would be able to, but not at the moment.  I'll let
Marcel explain this more if he wants too..

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

You might be right, but I'd really like to see whether the re-attach
algorithm would be good enough first...

Regards,
-Denis

RE: [PATCH 0/3] Attach GPRS on demand

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

Hi Mika,

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

so what about the cases when roaming is allowed or not? These needs to
be taken into account and that is oFono's job. That is the reason why
ConnMan follows the attach state. Since we don't wanna activate a
context when roaming and data roaming is not allowed.

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

I don't think such an algorithm is hard. Either we are forbidden, then
we wait until we switch to a new cell. Otherwise we will just retry to
attach.

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

This is really not ConnMan's problem and I don't wanna make it ConnMan's
problem.

I am really against just pushing this problem off to someone else. And
in ConnMan we have even less information to decide what happens when
context activation fails. The algorithm to handle such rare error
conditions smoothly becomes more complicated than making this easier.

So I agree with Denis that we need to fix this inside oFono and just try
to intelligently re-attach.

Regards

Marcel

RE: [PATCH 0/3] Attach GPRS on demand

[Mika.Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]

Hi Denis,

> > 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.
> 
> Actually it should care.  We do safe-guard against attaching while
> roaming...

I don't think so. Preventing GPRS attach and GPRS context activation during roaming can be done based on network registation status. Besides, oFono probably should be the component to enforce it, so that the feature cannot be easily bypassed.

> Besides, ConnMan doesn't really work this way.  Maybe in the 
> future with
> the session API it would be able to, but not at the moment.  I'll let
> Marcel explain this more if he wants too..

Admittedly, I haven't really looked at ConnMan. My assumption, though, is that a PDP context is not activated by default when ConnMan starts up. I.e., someone has to request the internet connectivity. Is that correct? Activating a context by default would be very bad for power consumption and standby times, unless both the handset and the network support CPC. The decision should be up to the user.

> >> 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.
> > 
> 
> You might be right, but I'd really like to see whether the re-attach
> algorithm would be good enough first...

But what re-attach algorithm? I sure don't have one up my sleeve...

As I said, extensive IOT and field testing (with mobility) is necessary in order to see how the prospective algorithm works in practise. Even then, you can't possibly cover all the angles. In practise, you end up discovering the rest of the glitches when the first products are already out there. That is a very expensive road indeed for a feature that is a bit dubious to begin with.

Why are we attaching to GPRS by default, anyway?

That said, various operators tend to have different requirements on this. Some want autoattach, some want on-demand attach, and some want a UI for changing the mode. In practise we will probably need at least a variation point on this and possibly a setting to change the behaviour. I'd propose starting by adding the on-demand attach code, to make sure that GPRS at least works in all cases.

	MikaL

RE: [PATCH 0/3] Attach GPRS on demand

[Mika.Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Hi Marcel, 

> so what about the cases when roaming is allowed or not? These needs to
> be taken into account and that is oFono's job. That is the reason why
> ConnMan follows the attach state. Since we don't wanna activate a
> context when roaming and data roaming is not allowed.

Ok, I see the concern. I'd propose making GPRS availability a separate property from GPRS attach status. Availability can be decided on registration status alone (i.e., does the network advertise GPRS and does the roaming check allow GPRS). Both GPRS attach and PDP context activation can in any case fail for transient reasons, so ConnMan needs to have some logic to retry context activation.

Br,

	MikaL

Re: [PATCH 0/3] Attach GPRS on demand

[Kalle Valo]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

<Mika.Liljeberg@nokia.com> writes:

>> Besides, ConnMan doesn't really work this way. Maybe in the future
>> with the session API it would be able to, but not at the moment. I'll
>> let Marcel explain this more if he wants too..
>
> Admittedly, I haven't really looked at ConnMan. My assumption, though,
> is that a PDP context is not activated by default when ConnMan starts
> up. I.e., someone has to request the internet connectivity. Is that
> correct?

Connman services have autoconnect property which control if the
connection is automatically created or not.

> Activating a context by default would be very bad for power
> consumption and standby times, unless both the handset and the network
> support CPC. 

If I plugin a usb modem on my laptop, I really want to connect it
automatically.

> The decision should be up to the user.

And with the autoconnect property the user can control this.

-- 
Kalle Valo

RE: [PATCH 0/3] Attach GPRS on demand

[Mika.Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

Hi Marcel,

I somehow missed your other comments on this mail. More responses below.

> > 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.
> 
> I don't think such an algorithm is hard. Either we are forbidden, then
> we wait until we switch to a new cell.

Mostly that would be just a waste of power. Some of the errors are PLMN or LA specific, so retrying at cell change would be redundant. A proper retry strategy would have to be based on the detach reason and any subsequent attach failure causes. In general, activating the RF all the time, when no-one has even requested a PDP context is simply bad idea. There are better uses for the battery power.

And yes, coming up with an algorithm (whatever it is) is probably easy enough. Making sure it works with all the networks and modems out there is the hard part.

> Otherwise we will just retry to attach.

That's also tricky. What do you do if the attach attempt fails? Retry again? How often? Use some kind of backoff?

> > 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.
> 
> This is really not ConnMan's problem and I don't wanna make 
> it ConnMan's
> problem.
> I am really against just pushing this problem off to someone else.

No-one is proposing to. You're actually making this ConnMan's problem by monitoring the GPRS attach status. If ConnMan needs a trigger, it should be based on network registration status alone.

> And
> in ConnMan we have even less information to decide what happens when
> context activation fails.

Unfortunately, oFono cannot hide context activation failures from ConnMan. ConnMan will just have to cope, regardless of what we do with attach.

> The algorithm to handle such rare error
> conditions smoothly becomes more complicated than making this easier.

As far as I can see, the approach I'm proposing is simpler than the one you and Denis are proposing.

> So I agree with Denis that we need to fix this inside oFono 
> and just try
> to intelligently re-attach.

As I already explained to Denis, it's not really a choise between one or the other. Some opearators require autoattach, some require on-demand attach and some require a UI to change the mode. All of these should be supported. So, by all means develop a re-attach algorith. It won't be easy to maturize, though. Using context activation requests as a triggers to retry attach simply makes a lot of sense as a safe-guard, even if we're in autoattach mode. If anything, it removes one potential failure case.

Br,

	MikaL