[RFC PATCH] gprs: add function to handle activated context

[RFC PATCH] gprs: add function to handle activated context

[Soum, RedouaneX]

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

gprs: add function to handle activated context
ofono_gprs_context_activated : this function is symetric to ofono_gprs_context_deactivated.
This function must be call by any gprs-context driver when a context has been activated without explicit request.

Behavior of the function :

List all the context and try to find correct APN
If such context is not found create a new one with "Internet" type

For the context (found or created):
	Update the settings
	Set to active
---
 include/gprs-context.h |    6 +++
 src/gprs.c             |  105 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 111 insertions(+), 0 deletions(-)

diff --git a/include/gprs-context.h b/include/gprs-context.h
index c29c0dc..57cd60b 100644
--- a/include/gprs-context.h
+++ b/include/gprs-context.h
@@ -76,6 +76,12 @@ struct ofono_gprs_context_driver {
 					ofono_gprs_context_cb_t cb, void *data);
 };
 
+void ofono_gprs_context_activated(struct ofono_gprs_context *gc,
+				const int cid, const char *apn,
+				const char *interface, ofono_bool_t static_ip,
+				const char *address, const char *netmask,
+				const char *gw, const char **dns);
+
 void ofono_gprs_context_deactivated(struct ofono_gprs_context *gc,
 					unsigned int id);
 
diff --git a/src/gprs.c b/src/gprs.c
index 58166f8..b7a4768 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -212,6 +212,11 @@ static unsigned int gprs_cid_alloc(struct ofono_gprs *gprs)
 	return idmap_alloc(gprs->cid_map);
 }
 
+static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id)
+{
+	idmap_take(gprs->cid_map, id);
+}
+
 static void gprs_cid_release(struct ofono_gprs *gprs, unsigned int id)
 {
 	idmap_put(gprs->cid_map, id);
@@ -1977,6 +1982,106 @@ void ofono_gprs_add_context(struct ofono_gprs *gprs,
 	__ofono_atom_register(gc->atom, gprs_context_unregister);
 }
 
+void ofono_gprs_context_activated(struct ofono_gprs_context *gc,
+		const int cid, const char *apn,
+		const char *interface, ofono_bool_t static_ip,
+		const char *address, const char *netmask,
+		const char *gw, const char **dns)
+{
+	DBusConnection *conn = ofono_dbus_get_connection();
+	GSList *l;
+	dbus_bool_t value;
+	struct pri_context *context;
+	const char *path;
+	DBusMessage *signal;
+	GKeyFile *settings;
+
+	if (gc->gprs == NULL)
+		return;
+
+	for (l = gc->gprs->contexts; l; l = l->next) {
+		context = l->data;
+
+		if (strcmp(context->context.apn, apn) == 0)
+			break;
+	}
+
+	if (!l) {
+		context = add_context(gc->gprs, "Internet",
+				OFONO_GPRS_CONTEXT_TYPE_INTERNET);
+
+		path = __ofono_atom_get_path(gc->gprs->atom);
+		signal = dbus_message_new_signal(path,
+				OFONO_CONNECTION_MANAGER_INTERFACE,
+				"ContextAdded");
+
+		if (signal) {
+			DBusMessageIter iter;
+			DBusMessageIter dict;
+
+			dbus_message_iter_init_append(signal, &iter);
+
+			path = context->path;
+			dbus_message_iter_append_basic(&iter,
+					DBUS_TYPE_OBJECT_PATH,
+					&path);
+
+			dbus_message_iter_open_container(&iter,
+					DBUS_TYPE_ARRAY,
+					OFONO_PROPERTIES_ARRAY_SIGNATURE,
+					&dict);
+
+			append_context_properties(context, &dict);
+			dbus_message_iter_close_container(&iter, &dict);
+
+			g_dbus_send_message(conn, signal);
+		}
+
+		strcpy(context->context.apn, apn);
+		settings = context->gprs->settings;
+
+		if (settings) {
+			g_key_file_set_string(settings, context->key,
+					"AccessPointName", apn);
+			storage_sync(context->gprs->imsi,
+					SETTINGS_STORE, settings);
+		}
+
+		ofono_dbus_signal_property_changed(conn, context->path,
+					OFONO_CONNECTION_CONTEXT_INTERFACE,
+					"AccessPointName",
+					DBUS_TYPE_STRING, &apn);
+	}
+
+	gprs_cid_take(gc->gprs, cid);
+	context->context.cid = cid;
+	value = context->active = TRUE;
+
+	if (interface != NULL)
+		pri_update_context_settings(context, interface, static_ip,
+					address, netmask, gw, dns);
+
+	for (l = context->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 == context->type) {
+			context->context_driver = gc;
+			context->context_driver->inuse = TRUE;
+		}
+	}
+
+	ofono_dbus_signal_property_changed(conn, context->path,
+					OFONO_CONNECTION_CONTEXT_INTERFACE,
+					"Active", DBUS_TYPE_BOOLEAN, &value);
+
+}
+
+
+
 void ofono_gprs_context_deactivated(struct ofono_gprs_context *gc,
 					unsigned int cid)
 {
-- 
1.7.0.4

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC PATCH] gprs: add function to handle activated context

[Marcel Holtmann]

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

Hi Redouane,

> gprs: add function to handle activated context
> ofono_gprs_context_activated : this function is symetric to ofono_gprs_context_deactivated.
> This function must be call by any gprs-context driver when a context has been activated without explicit request.
> 
> Behavior of the function :
> 
> List all the context and try to find correct APN

we have to be careful to only match against APN==APN and Username=="" +
Password=="".

The username and password option is pretty much pointless, but it is
present and we do support it. So we need to make sure the APN matching
sensible. Or does the network provide us with additional information
about the username + password as well?

> If such context is not found create a new one with "Internet" type.

I don't really agree that we should create a context if no match is
found. I think the better sensible strategy is to hold this information
internally and only map it to a context once the user or provisioning
creates it.

Also oFono will create at least one Internet context automatically. And
in the future that might be auto-provisioned.

Another option would be to introduce the concept of temporary context
where the lifetime is mandated by the network.

> For the context (found or created):
> 	Update the settings
> 	Set to active

Regards

Marcel

Re: [RFC PATCH] gprs: add function to handle activated context

[Denis Kenzior]

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

Hi Marcel,

> 
>> If such context is not found create a new one with "Internet" type.
> 
> I don't really agree that we should create a context if no match is
> found. I think the better sensible strategy is to hold this information
> internally and only map it to a context once the user or provisioning
> creates it.

From what I understood it should be quite safe to assume it is an
internet context.  All IMS contexts will have a well-known APN and the
only other one that would make sense for the network to activate
automatically would be the internet one.

Perhaps this is the missing piece in the description? The fact that
either the IMS or an Internet context is created.

I also don't like the temporary approach, since if we roam off LTE we
still need a way to deactivate this context.

Regards,
-Denis

Re: [RFC PATCH] gprs: add function to handle activated context

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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

On Thursday 06 January 2011 02:17:09 ext Denis Kenzior, you wrote:
> >> If such context is not found create a new one with "Internet" type.
> > 
> > I don't really agree that we should create a context if no match is
> > found. I think the better sensible strategy is to hold this information
> > internally and only map it to a context once the user or provisioning
> > creates it.
> 
> From what I understood it should be quite safe to assume it is an
> internet context.  All IMS contexts will have a well-known APN and the
> only other one that would make sense for the network to activate
> automatically would be the internet one.
> 
> Perhaps this is the missing piece in the description? The fact that
> either the IMS or an Internet context is created.

It could be MMS(/WAP) or it could be some private corporate VPN. Or it could 
even be some other silliness from some operator(s). I have seen such thing, 
but I am unsure I can talk freely about the details :-(

I would definitely advise against marking unknown context as Internets.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

RE: [RFC PATCH] gprs: add function to handle activated context

[Joly, Frederic]

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



-----Original Message-----
From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of Rémi Denis-Courmont
Sent: Friday, January 07, 2011 9:52 AM
To: ofono(a)ofono.org
Subject: Re: [RFC PATCH] gprs: add function to handle activated context

On Thursday 06 January 2011 02:17:09 ext Denis Kenzior, you wrote:
>> >> If such context is not found create a new one with "Internet" type.
>> > 
>> > I don't really agree that we should create a context if no match is
>> > found. I think the better sensible strategy is to hold this information
>> > internally and only map it to a context once the user or provisioning
>> > creates it.
>> 
>> From what I understood it should be quite safe to assume it is an
>> internet context.  All IMS contexts will have a well-known APN and the
>> only other one that would make sense for the network to activate
>> automatically would be the internet one.
>> 
>> Perhaps this is the missing piece in the description? The fact that
>> either the IMS or an Internet context is created.
>
>It could be MMS(/WAP) or it could be some private corporate VPN. Or it could 
>even be some other silliness from some operator(s). I have seen such thing, 
>but I am unsure I can talk freely about the details :-(
>
>I would definitely advise against marking unknown context as Internets.

This makes sense.

In the case this context is resulting from a PDN connectivity Request piggybacked on an Attach Request, should we assume that that this initial context could be an MMS or a private corporate VPN related context?
My assumption would be that in this particular case that the context is an "internet" or an "IMS" context.

The reception of an MMS "push" over SMS on the circuit switched  domain could provoke the attach, but I would guess in this case that:
a second context initiated by the UE is used specifically for the MMS
or
the PDN connectivity request includes a MMS APN with an ESM information transfer flag to transfer securely the "login and password"  required to download the MMS.  

I can also hardly imagine that an initial bearer context being a "VPN" specific bearer.

But, maybe I'm wrong.

BR,

Fred  





 
-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC PATCH] gprs: add function to handle activated context

[Denis Kenzior]

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

Hi Rémi,

On 01/07/2011 02:52 AM, Rémi Denis-Courmont wrote:
> On Thursday 06 January 2011 02:17:09 ext Denis Kenzior, you wrote:
>>>> If such context is not found create a new one with "Internet" type.
>>>
>>> I don't really agree that we should create a context if no match is
>>> found. I think the better sensible strategy is to hold this information
>>> internally and only map it to a context once the user or provisioning
>>> creates it.
>>
>> From what I understood it should be quite safe to assume it is an
>> internet context.  All IMS contexts will have a well-known APN and the
>> only other one that would make sense for the network to activate
>> automatically would be the internet one.
>>
>> Perhaps this is the missing piece in the description? The fact that
>> either the IMS or an Internet context is created.
> 
> It could be MMS(/WAP) or it could be some private corporate VPN. Or it could 
> even be some other silliness from some operator(s). I have seen such thing, 
> but I am unsure I can talk freely about the details :-(
> 
> I would definitely advise against marking unknown context as Internets.
> 

So there might be two things going on here:

- Default Bearer when attaching to LTE.  From what I understood this is
unlikely to ever be anything but an Internet context.  Maybe an IMS
default bearer, but then the APN should be well known.  So the proposed
approach should work well enough in my view.  We might need some extra
sanity checking here.  E.g. we're in LTE domain, and this is the first
context active.

- Random Primary / Secondary PDN activation from the network.  This
context can indeed be just about anything.  Fortunately this isn't
really used all that often.  So if we got one of these activated and we
don't have any idea what this context is (e.g. no provisioning info),
then about the only sane thing to do is to deactivate it.

Exposing "unknown" contexts is the wrong approach in my view.  Unless of
course someone plans to ship a psychic with every phone..

Regards,
-Denis

RE: [RFC PATCH] gprs: add function to handle activated context

[Soum, RedouaneX]

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

Hi Marcel,

> > Behavior of the function :
> >
> > List all the context and try to find correct APN
> 
> we have to be careful to only match against APN==APN and Username=="" +
> Password=="".
> 
> The username and password option is pretty much pointless, but it is
> present and we do support it. So we need to make sure the APN matching
> sensible. Or does the network provide us with additional information
> about the username + password as well?

Network doesn't provide login/password information, the UE shall provide it if needed. I'm not aware of any case where we can have network initiated connection with an APN usually used with authentication.
If the connection requires a login/password then it's UE initiated procedure.

If you think it's safer to check against Login/Password anyway, it's OK for me.

> 
> > If such context is not found create a new one with "Internet" type.
> 
> I don't really agree that we should create a context if no match is
> found. I think the better sensible strategy is to hold this information
> internally and only map it to a context once the user or provisioning
> creates it.
> 
> Also oFono will create at least one Internet context automatically. And
> in the future that might be auto-provisioned.
> 
> Another option would be to introduce the concept of temporary context
> where the lifetime is mandated by the network.

I agree with Denis, I think for now we can assume that it's either Internet or IMS (well-known APN).

Later if we see operators doing something else we ll adapt.
So I propose to keep this behavior for now, until we see a real need for something else.

Regards,

Redouane.

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC PATCH] gprs: add function to handle activated context

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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

On Thursday 06 January 2011 02:12:01 ext Marcel Holtmann, you wrote:
> > If such context is not found create a new one with "Internet" type.
> 
> I don't really agree that we should create a context if no match is
> found. I think the better sensible strategy is to hold this information
> internally and only map it to a context once the user or provisioning
> creates it.

Indeed. Alternatively, we could have a dedicated type, e.g. "Unknown". Using 
the Internet type is only likely to confuse the connection manager.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

Re: [RFC PATCH] gprs: add function to handle activated context

[Aki Niemi]

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

Hi,

2011/1/7 Rémi Denis-Courmont <remi.denis-courmont@nokia.com>:
> On Thursday 06 January 2011 02:12:01 ext Marcel Holtmann, you wrote:
>> > If such context is not found create a new one with "Internet" type.
>>
>> I don't really agree that we should create a context if no match is
>> found. I think the better sensible strategy is to hold this information
>> internally and only map it to a context once the user or provisioning
>> creates it.
>
> Indeed. Alternatively, we could have a dedicated type, e.g. "Unknown". Using
> the Internet type is only likely to confuse the connection manager.

+1

Cheers,
Aki

Re: [RFC PATCH] gprs: add function to handle activated context

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi Redouane,
...
> +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id)
> +{
> +       idmap_take(gprs->cid_map, id);
> +}
> +
How do we assure that this CID is not already in use?
I think the M7400 is going to use CID=0 and M700 uses CID=1.
Perhaps we should make sure CID=0 is a legal value and reserve CID 0
and 1 at start up.

There is probably other ways of handling this as well, but I think any
other solution
would end up with race conditions, as context could be initiated from
two sources.

Regards,
Sjur

RE: [RFC PATCH] gprs: add function to handle activated context

[Soum, RedouaneX]

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

Hi Sjur,


> > +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id)
> > +{
> > +       idmap_take(gprs->cid_map, id);
> > +}
> > +
> How do we assure that this CID is not already in use?
> I think the M7400 is going to use CID=0 and M700 uses CID=1.
> Perhaps we should make sure CID=0 is a legal value and reserve CID 0
> and 1 at start up.

From my understanding the ID in the core is an internal ID for oFono core, even if today we usually have a mapping 1 to 1 between oFono core ID and modems CID.
Denis, Marcel could you confirm ?

In this case the CID parameter in ofono_gprs_context_activated should be out parameter and renamed as ID.

---
void ofono_gprs_context_activated(struct ofono_gprs_context *gc,
		int *id, const char *apn,
		const char *interface, ofono_bool_t static_ip,
		const char *address, const char *netmask,
		const char *gw, const char **dns)
---


Also if we look to ofono_gprs_context_deactivated function the parameter used is ID and not CID, maybe it'll be beter if we rename cid in ofono_gprs_primary_context structure to avoid confusion : 

----
struct ofono_gprs_primary_context {
	unsigned int id;
	int direction;
	char apn[OFONO_GPRS_MAX_APN_LENGTH + 1];
	char username[OFONO_GPRS_MAX_USERNAME_LENGTH + 1];
	char password[OFONO_GPRS_MAX_PASSWORD_LENGTH + 1];
	enum ofono_gprs_proto proto;
};
----


If we try to do something else oFono core will be modem dependent and it's really not a good idea.


Regards,

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC PATCH] gprs: add function to handle activated context

[Denis Kenzior]

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

Hi Redouane,

On 01/06/2011 08:59 AM, Soum, RedouaneX wrote:
> Hi Sjur,
> 
> 
>>> +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id)
>>> +{
>>> +       idmap_take(gprs->cid_map, id);
>>> +}
>>> +
>> How do we assure that this CID is not already in use?
>> I think the M7400 is going to use CID=0 and M700 uses CID=1.
>> Perhaps we should make sure CID=0 is a legal value and reserve CID 0
>> and 1 at start up.
> 
> From my understanding the ID in the core is an internal ID for oFono core, even if today we usually have a mapping 1 to 1 between oFono core ID and modems CID.
> Denis, Marcel could you confirm ?
> 

Actually the intent was and still is to map it 1:1 to the modem cid to
make life easier for the drivers.  Since we follow 27.007 this makes
sense.  The modem driver can still do its own internal id mapping /
management, e.g. isi drivers do this AFAIK.  For AT modems I'd like to
avoid doing so...

oFono can be told the range of cids to use.  There's nothing precluding
the modem from giving oFono cids that are not in this range when a
context is auto-activated.

However, this gets into a real gray area whether you can have multiple
(network|auto)-activated contexts and whether the cid picked for all of
them is guaranteed to be outside this range.

Regards,
-Denis

Re: [RFC PATCH] gprs: add function to handle activated context

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi,

> From my understanding the ID in the core is an internal ID for oFono core, even if today we usually have a mapping 1 to 1 between oFono core ID and modems CID.
> Denis, Marcel could you confirm ?

Negative, to my understanding the CID is allocated in src/gprs.c and used
when activating/deactivating PDP contexts (PDN Connections):

<snip>
static gboolean assign_context(struct pri_context *ctx)
{
...
	ctx->context.cid = gprs_cid_alloc(ctx->gprs);

<snip>
static void ...gprs_activate_primary(struct ofono_gprs_context *gc,
				const struct ofono_gprs_primary_context *ctx,
				ofono_gprs_context_up_cb_t cb, void *data)
{
	gcd->active_context = ctx->cid;


> If we try to do something else oFono core will be modem dependent and it's really not a good idea.

It has been talk about standardizing the use of CID=0 for initial
PDN.If this comes
true this is no longer modem vendor dependent.

Regards,
Sjur

Re: [RFC PATCH] gprs: add function to handle activated context

[Denis Kenzior]

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

Hi Sjur,

On 01/06/2011 06:02 AM, Sjur Brændeland wrote:
> Hi Redouane,
> ...
>> +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id)
>> +{
>> +       idmap_take(gprs->cid_map, id);
>> +}
>> +
> How do we assure that this CID is not already in use?
> I think the M7400 is going to use CID=0 and M700 uses CID=1.
> Perhaps we should make sure CID=0 is a legal value and reserve CID 0
> and 1 at start up.

You already know how I feel about CID 0, I think you're trying to make
it into something special when it really isn't.

> 
> There is probably other ways of handling this as well, but I think any
> other solution
> would end up with race conditions, as context could be initiated from
> two sources.

The spec is essentially broken in this area.  Barring a complete
redesign of the spec (e.g. making the host stack activate the default
context) reserving a particular range for such default contexts seems
fine to me.

Regards,
-Denis

Re: [RFC PATCH] gprs: add function to handle activated context

[Marcel Holtmann]

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

Hi Sjur,

> > +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id)
> > +{
> > +       idmap_take(gprs->cid_map, id);
> > +}
> > +
> How do we assure that this CID is not already in use?
> I think the M7400 is going to use CID=0 and M700 uses CID=1.
> Perhaps we should make sure CID=0 is a legal value and reserve CID 0
> and 1 at start up.

I thought that we came to the conclusion that CID=0 is pretty much a
really bad idea. So I would prefer that your modem is actually not using
CID=0 ever.

Regards

Marcel

Re: [RFC PATCH] gprs: add function to handle activated context

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi Marcel and Denis.

> I thought that we came to the conclusion that CID=0 is pretty much a
> really bad idea. So I would prefer that your modem is actually not using
> CID=0 ever.
Yea, I know you or Denis said so, but I'm not sure we understood your concern...

Regards,
Sjur

Re: [RFC PATCH] gprs: add function to handle activated context

[Marcel Holtmann]

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

Hi Sjur,

> > I thought that we came to the conclusion that CID=0 is pretty much a
> > really bad idea. So I would prefer that your modem is actually not using
> > CID=0 ever.
> Yea, I know you or Denis said so, but I'm not sure we understood your concern...

I really thought it became pretty much clear during the discussion that
introducing a CID=0 that is just special on LTE is a pretty much bad
idea.

As long as CID=0 concept does not exist in GSM/UMTS, you should not make
LTE a special case. It will not fit and just makes things utterly
complex for the telephony stack to figure out when contexts are moved
from LTE to  GSM/UMTS.

If CID=0 is not valid for GSM/UTMS then you are in big trouble to make
this work properly. And if it is valid, then there is no difference
between it being CID=0 or any other CID.

So please step away from the CID=0 idea and just give the next free CID
to the network activated context. And per specification the CID start
with 1.

Regards

Marcel

Re: [RFC PATCH] gprs: add function to handle activated context

[Denis Kenzior]

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

Hi Sjur,

On 01/06/2011 11:45 AM, Sjur Brændeland wrote:
> Hi Marcel and Denis.
> 
>> I thought that we came to the conclusion that CID=0 is pretty much a
>> really bad idea. So I would prefer that your modem is actually not using
>> CID=0 ever.
> Yea, I know you or Denis said so, but I'm not sure we understood your concern...
> 

The bottom line is that the network can ask for a context to be
initiated at any time.  Furthermore, any number of such contexts can be
activated.  You can't really treat LTE specially and CID=0 really
doesn't help you anyway.

e.g.:

<cr><lf>+CGEV: NW PDN ACT 1<cr><lf>
...
<cr><lf>+CGEV: NW PDN ACT 2<cr><lf>

You need to allocate these cids properly.  However, solving the cid
allocation problem in the general case is basically impossible.  The
spec is just not setup to do so in its current form.

e.g.

---> context1.SetActive(True);
idmap_alloc(cid_map) -> cid == 1
[+CGDCONT=1,...]

<----
<cr><lf>+CGEV: ME PDN ACT 1<cr><lf>

Bad things happen.

The best you can do is allocate these cids from a different range than
oFono.  e.g.:

AT+CGDCONT=?
+CGDCONT: (0-25)

ofono_gprs_set_cid_range(gprs, 12, 25)

This way oFono will use the upper range for stack initiated contexts and
you guys have the lower range to play in.

Regards,
-Denis

RE: [RFC PATCH] gprs: add function to handle activated context

[Joly, Frederic]

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

Hi,


My two cents on context activation race: the collision between a network initiated context activation and UE initiated context activation. There is a potential issue if the modem and ofono try to assign the same CID at the same time
Basically the sequence of AT commands looks like the following for the activation of PDP context:

AT+CGDCONT=CID,X,Y,Z
OK
A+CGACT= CID,1
OK

The collision can only occur if the +CGDCONT (or +CGDSCONT) command  from Ofono is sent at the same time as PDP context activation URC from the modem, and both use the same CID.

But in that case, the modem should not reply "OK" to the PDP context configuration command, but "ERROR".
And Ofono should not consider that the PDP configuration command as successful.
Moreover, the "OK" for the context configuration and the context activation URC are sent of the same control channel so they cannot be sent in parallel but only in sequence.

Sjur, is that a correct assumption?

Thanks,

Fred

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC PATCH] gprs: add function to handle activated context

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi Fred,

Frederic wrote:
> The collision can only occur if the +CGDCONT (or +CGDSCONT) command  from Ofono is sent at the same time as PDP context activation URC from the modem, and both use the same CID.
>
> But in that case, the modem should not reply "OK" to the PDP context configuration command, but "ERROR".
> And Ofono should not consider that the PDP configuration command as successful.
> Moreover, the "OK" for the context configuration and the context activation URC are sent of the same control channel so they cannot be sent in parallel but only in sequence.
>
> Sjur, is that a correct assumption?

Yes, this sounds about right.
But I think Denis' proposal for using ofono_gprs_set_cid_range(gprs,
<min>, <max>) pretty much solves this issue,
We can use this to reserve the CID used for Initial PDN, and void this
race condition.

Regards,
Sjur

RE: [RFC PATCH] gprs: add function to handle activated context

[Joly, Frederic]

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

Hi Sjur,

>-----Original Message-----
>From: Sjur Brændeland [mailto:sjurbren(a)gmail.com] 
>Sent: Friday, January 07, 2011 4:39 PM
>To: ofono(a)ofono.org; Joly, Frederic
>Subject: Re: [RFC PATCH] gprs: add function to handle activated context
>
>Hi Fred,
>
>Frederic wrote:
>>The collision can only occur if the +CGDCONT (or +CGDSCONT) command  from Ofono is sent at the same time as PDP >>context activation URC from the modem, and both use the same CID.
>>
>> But in that case, the modem should not reply "OK" to the PDP context configuration command, but "ERROR".
>> And Ofono should not consider that the PDP configuration command as successful.
>> Moreover, the "OK" for the context configuration and the context activation URC are sent of the same control
>> channel so they cannot be sent in parallel but only in sequence.
>>
>> Sjur, is that a correct assumption?
>
>Yes, this sounds about right.
>But I think Denis' proposal for using ofono_gprs_set_cid_range(gprs,
> <min>, <max>) pretty much solves this issue,
> We can use this to reserve the CID used for Initial PDN, and void this
> race condition.
I have to admit that I'm not yet fully comfortable with the solution proposed by Denis. 
At least as long as we want to keep a on 1:1 mapping between the Ofono CID and the AT CID.
If I have understood correctly, the Ofono Core is "chosing" a CID 
and the modem plugin is trying to use the same CID on the AT interface. 
The way to resolve the race condition as proposed by Denis is to "reserve" a range of CIDs
 for the modem and another range for ofono.

My concern is that I don't know if this will work for all the modem implementations.
My understanding is that an AT+CGDCONT=? should return you the list of supported CID 
and not the list of CID that the user/Ofono can use. 

Considering that from a modem standpoint the CID race condition can be resolved, 
some modem implementation may not have reserved a range of CID for their own purpose,
or may not provide a mechanism to reserve a range of CID.

Maybe members of the list could comment on this?

Thanks,

Fred 
 
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC PATCH] gprs: add function to handle activated context

[Denis Kenzior]

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

Hi Fred,

>>> The collision can only occur if the +CGDCONT (or +CGDSCONT) command  from Ofono is sent at the same time as PDP >>context activation URC from the modem, and both use the same CID.
>>>
>>> But in that case, the modem should not reply "OK" to the PDP context configuration command, but "ERROR".
>>> And Ofono should not consider that the PDP configuration command as successful.
>>> Moreover, the "OK" for the context configuration and the context activation URC are sent of the same control
>>> channel so they cannot be sent in parallel but only in sequence.
>>>
>>> Sjur, is that a correct assumption?
>>
>> Yes, this sounds about right.
>> But I think Denis' proposal for using ofono_gprs_set_cid_range(gprs,
>> <min>, <max>) pretty much solves this issue,
>> We can use this to reserve the CID used for Initial PDN, and void this
>> race condition.
> I have to admit that I'm not yet fully comfortable with the solution proposed by Denis. 
> At least as long as we want to keep a on 1:1 mapping between the Ofono CID and the AT CID.
> If I have understood correctly, the Ofono Core is "chosing" a CID 
> and the modem plugin is trying to use the same CID on the AT interface. 
> The way to resolve the race condition as proposed by Denis is to "reserve" a range of CIDs
>  for the modem and another range for ofono.
> 
> My concern is that I don't know if this will work for all the modem implementations.
> My understanding is that an AT+CGDCONT=? should return you the list of supported CID 
> and not the list of CID that the user/Ofono can use. 

It is up to the driver to set the ranges appropriately based upon its
much more intimate knowledge of the modem firmware.  The drivers that do
not support LTE / network activated contexts can ignore this magic.

> 
> Considering that from a modem standpoint the CID race condition can be resolved, 
> some modem implementation may not have reserved a range of CID for their own purpose,
> or may not provide a mechanism to reserve a range of CID.
> 

If the CGDCONT race is guaranteed to be solved by the modem
manufacturers, great.  Unfortunately that is not the only race present.
 Hint: The gatchat implementation uses non-blocking IO, select and a
command queue.  So it is fully possible for oFono to reserve a CID, send
out a driver activation request, but receive a network initiated context
activation / default bearer activation before the CGDCONT was even sent.

Having cid ranges that do not overlap seems the safest approach to me
right now.  Unless someone has a better idea...

Regards,
-Denis

RE: [RFC PATCH] gprs: add function to handle activated context

[Soum, RedouaneX]

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

Hi Denis,

> > Considering that from a modem standpoint the CID race condition can
> be resolved,
> > some modem implementation may not have reserved a range of CID for
> their own purpose,
> > or may not provide a mechanism to reserve a range of CID.
> >
> 
> If the CGDCONT race is guaranteed to be solved by the modem 
> manufacturers, great.  Unfortunately that is not the only race present.
>  Hint: The gatchat implementation uses non-blocking IO, select and a 
> command queue.  So it is fully possible for oFono to reserve a CID, 
> send out a driver activation request, but receive a network initiated 
> context activation / default bearer activation before the CGDCONT was 
> even sent.
> 
> Having cid ranges that do not overlap seems the safest approach to me 
> right now.  Unless someone has a better idea...
> 

I think we have two cases :
1- CGDCONT=X,... is sent to the modem (ERROR response) before we get "+CGEV: ME PDN ACT X"
2- CGDCONT=X,... is sent to the modem (ERROR response) after we get "+CGEV: ME PDN ACT X"

For the first case the CID will be released inside oFono core before we get "+CGEV" event : No problem 
For the second case the CID will be released inside oFono after we get "+CGEV" event , but we are sure it'll be released : No problem

But regardless the solution we choose either the CID sent by the driver should be free or the CID sent by the driver should be outside the range, in both solutions the submitted patch should be ok.
Could you confirm ?

Regarding Context type maybe we can keep Internet today and see how far we can get ?

Regards,
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC PATCH] gprs: add function to handle activated context

[Pekka Pessi]

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

Hi all,

2011/1/7 Denis Kenzior <denkenz@gmail.com>:
>> Considering that from a modem standpoint the CID race condition can be resolved,
>> some modem implementation may not have reserved a range of CID for their own purpose,
>> or may not provide a mechanism to reserve a range of CID.
>
> If the CGDCONT race is guaranteed to be solved by the modem
> manufacturers, great.  Unfortunately that is not the only race present.
>  Hint: The gatchat implementation uses non-blocking IO, select and a
> command queue.  So it is fully possible for oFono to reserve a CID, send
> out a driver activation request, but receive a network initiated context
> activation / default bearer activation before the CGDCONT was even sent.
>
> Having cid ranges that do not overlap seems the safest approach to me
> right now.  Unless someone has a better idea...

The 27.007 for release 9 (from version 9.3.0 onwards) says:

NOTE 1: The <cid>s for network-initiated PDP contexts will have values
outside the ranges indicated for the
<cid> in the test form of the commands +CGDCONT and +CGDSCONT.

The change was proposed by STE last February.

This has some ramifications on how we use the CIDs within driver/core.

-- 
Pekka.Pessi mail at nokia.com

Re: [RFC PATCH] gprs: add function to handle activated context

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi,

Pekka Pessi <ppessi@gmail.com> wrote:
> The 27.007 for release 9 (from version 9.3.0 onwards) says:
>
> NOTE 1: The <cid>s for network-initiated PDP contexts will have values
> outside the ranges indicated for the
> <cid> in the test form of the commands +CGDCONT and +CGDSCONT.
>
> The change was proposed by STE last February.
>
> This has some ramifications on how we use the CIDs within driver/core.

I'm not sure we have any problems with Network Initiated Connection in oFono,
unless someone is planning to add support for Network Initiated
Primary Contexts /
PDN Connections. Because the Network Initiated Contexts we are dealing with
will be Secondary PDP Contexts / Dedicated Bearers.

If we need to expose information about the Network Initiated Dedicated Bearers,
I don't think we should model this as separate Connection-Contexts (with CID),
but rather as a dictionary within the primary context object containing
the necessary information about the QoS available.

I guess we need to hear from IMS-folks the minimum information they
need about the QoS, and provide just that information.

Regards,
Sjur

Re: [RFC PATCH] gprs: add function to handle activated context

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi,

So far we have been discussing CID races, but if we solve the CID issue,
we still might end up with two "identical" Connections activated with the same
connection properties (APN, Username, Password), one initiated by the modem
in the LTE Combined Attach procedure and the other being a "normal" Context
Activation, right?

How do we protect against establishing two contexts with the same properties?

Also: what is the likelihood of not having information the initial PDN
defined in the
provisioning database, would this be an exceptional case only?

Regards,
Sjur

Re: [RFC PATCH] gprs: add function to handle activated context

[Pekka Pessi]

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

Hi Sjur,

2011/1/17 Sjur Brændeland <sjurbren@gmail.com>:
>> The 27.007 for release 9 (from version 9.3.0 onwards) says:
>>
>> NOTE 1: The <cid>s for network-initiated PDP contexts will have values
>> outside the ranges indicated for the
>> <cid> in the test form of the commands +CGDCONT and +CGDSCONT.
>>
>> The change was proposed by STE last February.
>>
>> This has some ramifications on how we use the CIDs within driver/core.
>
> I'm not sure we have any problems with Network Initiated Connection in oFono,
> unless someone is planning to add support for Network Initiated
> Primary Contexts / PDN Connections.

AFAIK the initial LTE default bearer context can be network-initiated,
and the CID 0 falls outside the range from +CGDCONT.

> If we need to expose information about the Network Initiated Dedicated Bearers,
> I don't think we should model this as separate Connection-Contexts (with CID),
> but rather as a dictionary within the primary context object containing
> the necessary information about the QoS available.
>
> I guess we need to hear from IMS-folks the minimum information they
> need about the QoS, and provide just that information.

Uh, on one hand, the IMS Signaling flag for signaling. For
audio/video, we need QCI, a GBR rate, and TFT.

-- 
Pekka.Pessi mail at nokia.com

Re: [RFC PATCH] gprs: add function to handle activated context

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi Pekka.

Pekka Pessi <ppessi@gmail.com> wrote:
>> I'm not sure we have any problems with Network Initiated Connection in oFono,
>> unless someone is planning to add support for Network Initiated
>> Primary Contexts / PDN Connections.
>
> AFAIK the initial LTE default bearer context can be network-initiated,
> and the CID 0 falls outside the range from +CGDCONT.

If I am not mistaken the initial LTE default bearer is initiated by the
ME in a combined attach procedure, and not by the Network.
(but the Dedicated bearers / Secondary PDPs are activated by the Network).

Regards,
Sjur