All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v3] gprs: add function to handle activated context
@ 2011-02-09 18:31 Soum, RedouaneX
  2011-02-11 14:08 ` Tomasz Gregorek
  2011-02-22 10:19 ` Soum, RedouaneX
  0 siblings, 2 replies; 12+ messages in thread
From: Soum, RedouaneX @ 2011-02-09 18:31 UTC (permalink / raw)
  To: ofono

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

The purpose of the patch is to handle Network Initiated Context Activation and PDN connection request as part of EPS Attach procedure (LTE) in oFono core.

In order to avoid issue regarding CID allocation :
- driver should call the core using ofono_gprs_set_cid_range function to specify CID range for UE initiated PDN connection
- driver could use a new function to check if the CID is already used or not : ofono_gprs_is_cid_used, usefull in case the modem is not using a specific range for UE initiated PDN connection.
- driver will use a new function to notify the gprs atom of a new PDN connection with all the ip parameters from AT+CGCONTRDP (I can provide an update later to handle PCSCF and IMS Signaling Flag as well) commmand : ofono_gprs_context_activated

ofono_gprs_context_activated is similar to ofono_gprs_context_deactivated.
This function must be call by any gprs driver when :
 - a context has been activated without explicit request as part of attach procedure in LTE (PDN ACT X and X is a unused CID)
 - a context has been activated by the Network (NW PDN ACT X, NW ACT X,Y)

Behavior of the function :

List all the context and try to find correct APN with empty username and empty password.
If such context is not found then create a new one with "Internet" type only if we are in LTE with no Active context.
Otherwise deactivate the connection.

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

The function will also assign the context to a context driver.
---
 include/gprs-context.h |    7 +++
 include/gprs.h         |    3 +
 src/gprs.c             |  139 ++++++++++++++++++++++++++++++++++++++++++++++++
 src/idmap.c            |   12 ++++
 src/idmap.h            |    1 +
 5 files changed, 162 insertions(+), 0 deletions(-)

diff --git a/include/gprs-context.h b/include/gprs-context.h
index c29c0dc..e208b66 100644
--- a/include/gprs-context.h
+++ b/include/gprs-context.h
@@ -76,6 +76,13 @@ 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/include/gprs.h b/include/gprs.h
index 157a6f9..5a96c1c 100644
--- a/include/gprs.h
+++ b/include/gprs.h
@@ -75,6 +75,9 @@ void *ofono_gprs_get_data(struct ofono_gprs *gprs);
 
 void ofono_gprs_set_cid_range(struct ofono_gprs *gprs,
 				unsigned int min, unsigned int max);
+ofono_bool_t ofono_gprs_is_cid_used(struct ofono_gprs *gprs,
+				int cid);
+
 void ofono_gprs_add_context(struct ofono_gprs *gprs,
 				struct ofono_gprs_context *gc);
 
diff --git a/src/gprs.c b/src/gprs.c
index 5ea864c..9ab853c 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -730,6 +730,13 @@ static void pri_activate_callback(const struct ofono_error *error,
 					"Active", DBUS_TYPE_BOOLEAN, &value);
 }
 
+static void ofono_gprs_context_activated_deactivate_callback(const struct ofono_error *error, void *data)
+{
+	struct ofono_gprs_context *gc_driver = data;
+	if (gc_driver != NULL)
+		gc_driver->inuse = FALSE;
+}
+
 static void pri_deactivate_callback(const struct ofono_error *error, void *data)
 {
 	struct pri_context *ctx = data;
@@ -2026,6 +2033,15 @@ void ofono_gprs_set_cid_range(struct ofono_gprs *gprs,
 	gprs->cid_map = idmap_new_from_range(min, max);
 }
 
+ofono_bool_t ofono_gprs_is_cid_used(struct ofono_gprs *gprs,
+				int cid)
+{
+	if (gprs == NULL || gprs->cid_map == NULL)
+		return 0;
+
+	return idmap_is_free(gprs->cid_map, cid);
+}
+
 static void gprs_context_unregister(struct ofono_atom *atom)
 {
 	struct ofono_gprs_context *gc = __ofono_atom_get_data(atom);
@@ -2067,6 +2083,129 @@ void ofono_gprs_bearer_notify(struct ofono_gprs *gprs, int bearer)
 					"Bearer", DBUS_TYPE_STRING, &value);
 }
 
+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;
+	const char *path;
+	DBusMessage *signal;
+	GKeyFile *settings;
+	int active_context = 0;
+	int technology = 0;
+	struct pri_context *context = 0;
+
+
+	if (gc->gprs == NULL)
+		return;
+
+	for (l = gc->gprs->contexts; l; l = l->next) {
+		context = l->data;
+
+		if (strcmp(context->context.apn, apn) == 0
+				&& strcmp(context->context.username, "") == 0
+				&& strcmp(context->context.password, "") == 0)
+			break;
+
+		if (context->active)
+			active_context = 1;
+	}
+
+	if (gc->gprs->netreg)
+		technology = ofono_netreg_get_technology(gc->gprs->netreg);
+
+	if (!l && !(active_context == 0 && technology == 7)) {
+
+		for (l = gc->gprs->context_drivers; l; l = l->next) {
+			struct ofono_gprs_context *gc_driver = l->data;
+
+			if (gc_driver->inuse != TRUE) {
+				gc_driver->inuse = TRUE;
+				gc_driver->driver->deactivate_primary(gc_driver, cid,
+						ofono_gprs_context_activated_deactivate_callback, gc_driver);
+				return ;
+			}
+		}
+		return ;
+	}
+
+	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);
+	}
+
+	if (context == NULL)
+		return;
+
+	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;
+
+			break;
+		}
+	}
+
+	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)
 {
diff --git a/src/idmap.c b/src/idmap.c
index 6d46e8a..90dcd41 100644
--- a/src/idmap.c
+++ b/src/idmap.c
@@ -166,6 +166,18 @@ void idmap_take(struct idmap *idmap, unsigned int id)
 	idmap->bits[offset] |= 1 << (bit % BITS_PER_LONG);
 }
 
+int idmap_is_free(struct idmap *idmap, unsigned int id)
+{
+	unsigned int bit = id - idmap->min;
+	unsigned int offset;
+
+	if (bit >= idmap->size)
+		return 0;
+
+	offset = bit / BITS_PER_LONG;
+	return (idmap->bits[offset] & (1 <<  (bit % BITS_PER_LONG))) == 0;
+}
+
 /*
  * Allocate the next bit skipping the ids up to and including last.  If there
  * is no free ids until the max id is encountered, the counter is wrapped back
diff --git a/src/idmap.h b/src/idmap.h
index d6141c2..3333581 100644
--- a/src/idmap.h
+++ b/src/idmap.h
@@ -25,6 +25,7 @@ struct idmap *idmap_new(unsigned int size);
 void idmap_free(struct idmap *idmap);
 void idmap_put(struct idmap *idmap, unsigned int id);
 void idmap_take(struct idmap *idmap, unsigned int id);
+int idmap_is_free(struct idmap *idmap, unsigned int id);
 unsigned int idmap_alloc(struct idmap *idmap);
 unsigned int idmap_alloc_next(struct idmap *idmap, unsigned int last);
 struct idmap *idmap_new_from_range(unsigned int min, unsigned int max);
-- 
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.


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v3] gprs: add function to handle activated context
  2011-02-09 18:31 [RFC PATCH v3] gprs: add function to handle activated context Soum, RedouaneX
@ 2011-02-11 14:08 ` Tomasz Gregorek
  2011-02-22 10:19 ` Soum, RedouaneX
  1 sibling, 0 replies; 12+ messages in thread
From: Tomasz Gregorek @ 2011-02-11 14:08 UTC (permalink / raw)
  To: ofono

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

Hi Redouane
Find some comments below.

2011/2/9 Soum, RedouaneX <redouanex.soum@intel.com>

> The purpose of the patch is to handle Network Initiated Context Activation
> and PDN connection request as part of EPS Attach procedure (LTE) in oFono
> core.
>
> In order to avoid issue regarding CID allocation :
> - driver should call the core using ofono_gprs_set_cid_range function to
> specify CID range for UE initiated PDN connection
> - driver could use a new function to check if the CID is already used or
> not : ofono_gprs_is_cid_used, usefull in case the modem is not using a
> specific range for UE initiated PDN connection.
> - driver will use a new function to notify the gprs atom of a new PDN
> connection with all the ip parameters from AT+CGCONTRDP (I can provide an
> update later to handle PCSCF and IMS Signaling Flag as well) commmand :
> ofono_gprs_context_activated
>
> ofono_gprs_context_activated is similar to ofono_gprs_context_deactivated.
> This function must be call by any gprs driver when :
>  - a context has been activated without explicit request as part of attach
> procedure in LTE (PDN ACT X and X is a unused CID)
>  - a context has been activated by the Network (NW PDN ACT X, NW ACT X,Y)
>
> Behavior of the function :
>
> List all the context and try to find correct APN with empty username and
> empty password.
> If such context is not found then create a new one with "Internet" type
> only if we are in LTE with no Active context.
> Otherwise deactivate the connection.
>
> For the context (found or created):
>        Update the settings
>        Set to active
>
> The function will also assign the context to a context driver.
> ---
>  include/gprs-context.h |    7 +++
>  include/gprs.h         |    3 +
>  src/gprs.c             |  139
> ++++++++++++++++++++++++++++++++++++++++++++++++
>  src/idmap.c            |   12 ++++
>  src/idmap.h            |    1 +
>  5 files changed, 162 insertions(+), 0 deletions(-)
>
> diff --git a/include/gprs-context.h b/include/gprs-context.h
> index c29c0dc..e208b66 100644
> --- a/include/gprs-context.h
> +++ b/include/gprs-context.h
> @@ -76,6 +76,13 @@ 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);
> +
>

When this function is called we don't know *interface yet, as it is *gc
specific.
You look for a proper *gc_driver later on.
Maybe we should address found *gc_driver for a *interface?

Also looking at incoming IPv6 patches, maybe we should consider sending
connection data with separate functions?

<snip>

Br
Tomasz Gregorek
ST-Ericsson

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3340 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [RFC PATCH v3] gprs: add function to handle activated context
  2011-02-09 18:31 [RFC PATCH v3] gprs: add function to handle activated context Soum, RedouaneX
  2011-02-11 14:08 ` Tomasz Gregorek
@ 2011-02-22 10:19 ` Soum, RedouaneX
  1 sibling, 0 replies; 12+ messages in thread
From: Soum, RedouaneX @ 2011-02-22 10:19 UTC (permalink / raw)
  To: ofono

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of
> Soum, RedouaneX
> Sent: Wednesday, February 09, 2011 7:32 PM
> To: ofono(a)ofono.org
> Subject: [RFC PATCH v3] gprs: add function to handle activated context
> 

This RFC patch includes all the modifications according to the comments I got on previous version.
I didn't get any comment on this one, what are the next steps for acceptance ?

Should I send a patch in two parts (gprs/idmap) ?

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.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-08 13:03             ` Arun Ravindran
@ 2011-04-08 13:34               ` Soum, RedouaneX
  0 siblings, 0 replies; 12+ messages in thread
From: Soum, RedouaneX @ 2011-04-08 13:34 UTC (permalink / raw)
  To: ofono

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

Hi Arun,

>>> So the spec says, ME PDN ACT can come even for an implicit context
>>> activation request associated with CGATT, which is the case with EPS.
>>>
>>> For 3G, if this happens (ME PDN ACT) for UE initiated activation of
>>> context, then the cid is already set with CGDCONT.
>>>
>>> For EPS this can happen for default context, where cid is not set with
>>> CGDCONT, but is in the range as returned by CGDCONT.
>>>
>>> Here the cid issue, because cid is managed by ofono and is never
>>> communicated to modem.  Probably to avoid sending too many CGDCONT's
>>> during startup. or is it something else?
>>>
>>> I thought the default context activation will come to TE as NW ACT,
>with
>>> a cid not in range of CGDCONT.
>>>
>> Exactly so the idea to avoid any issue was to call
>ofono_gprs_set_cid_range from the driver with a range which doesn't
>include the CID used for initial EPS context.
>> Normaly we know from the modem vendor which CID will be used for the
>initial EPS context.
>>
>> For instance if +CGDSCONT=? Is returning 1-25 as range then we call
>ofono_gprs_set_cid_range with 2-25 as range assuming that CID 1 will be
>used for the initial EPS context.
>Ok so you are assuming that cid 1 will be always used for default
>context, and so this is work around for the issue.

The modem vendor should know which CID will be used for the initial default context.
So the idea was to add a requirement in the implementation of the gprs drivers that ofono_gprs_set_cid should be called with a range that's doesn't include the CID used for the initial default bearer.

From what I know there is nothing in the spec saying which CID to use for initial default context.
And there is no standard AT commands to specify settings to use for the initial default context (CID, APN, user , password , IPV4/IPV6/ IPV4V6 ...)

>Instead we could also expect it to have a unique id.
>
>I still feel that the default context should be a NW initiated context
>and will have a unique cid.

As Pessi said before the PDN connectivity request is UE initiated.

-- The problem is, the initial EPS context is initiated by mobile, not by the network. The mobile sends a piggybacked PDN CONNECTIVITY REQUEST with the initial attach request in order to initiate the initial EPS context. --

>Also why can't the context id management be done in modem instead of
>ofono?

What do you mean by context id management be done in the modem ?

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.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-07 15:47           ` Soum, RedouaneX
@ 2011-04-08 13:03             ` Arun Ravindran
  2011-04-08 13:34               ` Soum, RedouaneX
  0 siblings, 1 reply; 12+ messages in thread
From: Arun Ravindran @ 2011-04-08 13:03 UTC (permalink / raw)
  To: ofono

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

Hi Redouane,

>
>> So the spec says, ME PDN ACT can come even for an implicit context
>> activation request associated with CGATT, which is the case with EPS.
>>
>> For 3G, if this happens (ME PDN ACT) for UE initiated activation of
>> context, then the cid is already set with CGDCONT.
>>
>> For EPS this can happen for default context, where cid is not set with
>> CGDCONT, but is in the range as returned by CGDCONT.
>>
>> Here the cid issue, because cid is managed by ofono and is never
>> communicated to modem.  Probably to avoid sending too many CGDCONT's
>> during startup. or is it something else?
>>
>> I thought the default context activation will come to TE as NW ACT, with
>> a cid not in range of CGDCONT.
>>
> Exactly so the idea to avoid any issue was to call ofono_gprs_set_cid_range from the driver with a range which doesn't include the CID used for initial EPS context.
> Normaly we know from the modem vendor which CID will be used for the initial EPS context.
>
> For instance if +CGDSCONT=? Is returning 1-25 as range then we call  ofono_gprs_set_cid_range with 2-25 as range assuming that CID 1 will be used for the initial EPS context.
Ok so you are assuming that cid 1 will be always used for default 
context, and so this is work around for the issue.

Instead we could also expect it to have a unique id.

I still feel that the default context should be a NW initiated context 
and will have a unique cid.

Also why can't the context id management be done in modem instead of ofono?

Regards
Arun



^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-06  9:30 ` Arun Ravindran
  2011-04-06 13:00   ` Pekka Pessi
@ 2011-04-08  7:59   ` Joly, Frederic
  1 sibling, 0 replies; 12+ messages in thread
From: Joly, Frederic @ 2011-04-08  7:59 UTC (permalink / raw)
  To: ofono

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

Hi,

My 2 cts.

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
> Behalf Of Arun Ravindran
> Sent: Wednesday, April 06, 2011 11:30 AM
> To: ofono(a)ofono.org
> Subject: Re: [RFC PATCH v3] gprs: add function to handle activated
> 27.007 section 10.1.1 says
> 
> Defined values
> <cid>: a numeric parameter which specifies a particular PDP context
> definition. The parameter is local to the TE-
> MT interface and is used in other PDP context-related commands. The
> range of permitted values (minimum
> value = 1) is returned by the test form of the command.
> 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.
> 
Rigth, but just a general comment.
This is a release 9 clarification. The 27.007 Change request was only adopted one year ago (March 2010).
I believe we should keep this is mind to maintain if necessary the backward compatibility.
I don't foresee yet an issue, but IMS services seem to get now some traction even on 3G.
Of course no evidence that network initiated PDP context are going to be used, but their usage fits pretty well with IMS...

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.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-07 12:40         ` Arun Ravindran
@ 2011-04-07 15:47           ` Soum, RedouaneX
  2011-04-08 13:03             ` Arun Ravindran
  0 siblings, 1 reply; 12+ messages in thread
From: Soum, RedouaneX @ 2011-04-07 15:47 UTC (permalink / raw)
  To: ofono

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

Hi,

>
>So the spec says, ME PDN ACT can come even for an implicit context
>activation request associated with CGATT, which is the case with EPS.
>
>For 3G, if this happens (ME PDN ACT) for UE initiated activation of
>context, then the cid is already set with CGDCONT.
>
>For EPS this can happen for default context, where cid is not set with
>CGDCONT, but is in the range as returned by CGDCONT.
>
>Here the cid issue, because cid is managed by ofono and is never
>communicated to modem.  Probably to avoid sending too many CGDCONT's
>during startup. or is it something else?
>
>I thought the default context activation will come to TE as NW ACT, with
>a cid not in range of CGDCONT.
>

Exactly so the idea to avoid any issue was to call ofono_gprs_set_cid_range from the driver with a range which doesn't include the CID used for initial EPS context.
Normaly we know from the modem vendor which CID will be used for the initial EPS context.

For instance if +CGDSCONT=? Is returning 1-25 as range then we call  ofono_gprs_set_cid_range with 2-25 as range assuming that CID 1 will be used for the initial EPS context.

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.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-07  9:06       ` Soum, RedouaneX
@ 2011-04-07 12:40         ` Arun Ravindran
  2011-04-07 15:47           ` Soum, RedouaneX
  0 siblings, 1 reply; 12+ messages in thread
From: Arun Ravindran @ 2011-04-07 12:40 UTC (permalink / raw)
  To: ofono

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

Hi Redouane,

>>> the network. The mobile sends a piggybacked
>>> PDN CONNECTIVITY REQUEST with the initial attach request in order to
>>> initiate the initial EPS context.
>>>
>> How does this happen from oFono (or in the TE-MT Interface).
> The problem is, the initial EPS context is initiated by mobile, not by
> It's triggered by AT+CGATT=1 (or AT+CFUN=1 if we have auto attach enabled).
>> Does it mean that in for EPS context the TE will have to do the same
>> steps what it does for GPRS?
> For the EPS context (non initial) yes.
>
> For the initial EPS context we don't use AT+CGACT and CGDCONT.
>> the PDN CONNECTIVITY REQUEST has the APN name, and for TE, CGDCONT to
>> set the APN is called with a context id, in that case what is the need
>> for the cid handling done in this patch?
>  From 24.301:
>
> In order to request connectivity to a PDN using the default APN, the UE includes the Access point name IE in the PDN CONNECTIVITY REQUEST message or, when applicable, in the ESM INFORMATION RESPONSE message, according to the following conditions:
> -    if use of a PDN using the default APN requires PAP/CHAP, then the UE should include the Access point name IE; and
> -    in all other conditions, the UE need not include the Access point name IE.
> ----
>
> For the initial EPS context the UE may have to provide the APN in some cases. From 27007 we don't have an at command such as AT+CGCONT to specify the parameter that'll be used for the initial EPS context (like APN).
>
> Regarding the patch, In 3G when you get the following unsolicited  "ME PDN ACT X" (where X is the CID, see +CGEREP) it's because you activated a context (AT+CGACT).
> In this case you already specified the CID with AT+CDCONT before AT+CGACT.
>
> In LTE you can get this event in two cases; after the attach procedure (AT+CGATT) and in this case you don't know the CID before, or after AT+CGDCONT and AT+CGACT as in 3G.
>

So the spec says, ME PDN ACT can come even for an implicit context 
activation request associated with CGATT, which is the case with EPS.

For 3G, if this happens (ME PDN ACT) for UE initiated activation of 
context, then the cid is already set with CGDCONT.

For EPS this can happen for default context, where cid is not set with 
CGDCONT, but is in the range as returned by CGDCONT.

Here the cid issue, because cid is managed by ofono and is never 
communicated to modem.  Probably to avoid sending too many CGDCONT's 
during startup. or is it something else?

I thought the default context activation will come to TE as NW ACT, with 
a cid not in range of CGDCONT.


regards
Arun



^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-06 14:06     ` Arun Ravindran
@ 2011-04-07  9:06       ` Soum, RedouaneX
  2011-04-07 12:40         ` Arun Ravindran
  0 siblings, 1 reply; 12+ messages in thread
From: Soum, RedouaneX @ 2011-04-07  9:06 UTC (permalink / raw)
  To: ofono

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

Hi All,


>-----Original Message-----
>From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of
>Arun Ravindran
>Sent: Wednesday, April 06, 2011 4:06 PM
>Cc: ofono(a)ofono.org
>Subject: Re: [RFC PATCH v3] gprs: add function to handle activated context
>
>Hi Pessi,
>
>> Hi Arun,
>>
>> 2011/4/6 Arun Ravindran<ext-arun.1.ravindran@nokia.com>:
>>> According to this, the cid of user initiated context and network
>initiated
>>> context doesn't overlap.
>> The problem is, the initial EPS context is initiated by mobile, not by
>> the network. The mobile sends a piggybacked
>> PDN CONNECTIVITY REQUEST with the initial attach request in order to
>> initiate the initial EPS context.
>>
>
>How does this happen from oFono (or in the TE-MT Interface).

It's triggered by AT+CGATT=1 (or AT+CFUN=1 if we have auto attach enabled).

>
>Does it mean that in for EPS context the TE will have to do the same
>steps what it does for GPRS?
>

For the EPS context (non initial) yes.

For the initial EPS context we don't use AT+CGACT and CGDCONT.


>The PDN CONNECTIVITY REQUEST has the APN name, and for TE, CGDCONT to
>set the APN is called with a context id, in that case what is the need
>for the cid handling done in this patch?

From 24.301: 

In order to request connectivity to a PDN using the default APN, the UE includes the Access point name IE in the PDN CONNECTIVITY REQUEST message or, when applicable, in the ESM INFORMATION RESPONSE message, according to the following conditions:
-    if use of a PDN using the default APN requires PAP/CHAP, then the UE should include the Access point name IE; and
-    in all other conditions, the UE need not include the Access point name IE.
----

For the initial EPS context the UE may have to provide the APN in some cases. From 27007 we don't have an at command such as AT+CGCONT to specify the parameter that'll be used for the initial EPS context (like APN).

Regarding the patch, In 3G when you get the following unsolicited  "ME PDN ACT X" (where X is the CID, see +CGEREP) it's because you activated a context (AT+CGACT).
In this case you already specified the CID with AT+CDCONT before AT+CGACT.

In LTE you can get this event in two cases; after the attach procedure (AT+CGATT) and in this case you don't know the CID before, or after AT+CGDCONT and AT+CGACT as in 3G.

The idea was to propose a function to handle the first case with the initial EPS context.

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.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-06 13:00   ` Pekka Pessi
@ 2011-04-06 14:06     ` Arun Ravindran
  2011-04-07  9:06       ` Soum, RedouaneX
  0 siblings, 1 reply; 12+ messages in thread
From: Arun Ravindran @ 2011-04-06 14:06 UTC (permalink / raw)
  To: ofono

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

Hi Pessi,

> Hi Arun,
>
> 2011/4/6 Arun Ravindran<ext-arun.1.ravindran@nokia.com>:
>> According to this, the cid of user initiated context and network initiated
>> context doesn't overlap.
> The problem is, the initial EPS context is initiated by mobile, not by
> the network. The mobile sends a piggybacked
> PDN CONNECTIVITY REQUEST with the initial attach request in order to
> initiate the initial EPS context.
>

How does this happen from oFono (or in the TE-MT Interface).

Does it mean that in for EPS context the TE will have to do the same 
steps what it does for GPRS?

The PDN CONNECTIVITY REQUEST has the APN name, and for TE, CGDCONT to 
set the APN is called with a context id, in that case what is the need 
for the cid handling done in this patch?

Regards
Arun


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v3] gprs: add function to handle activated context
  2011-04-06  9:30 ` Arun Ravindran
@ 2011-04-06 13:00   ` Pekka Pessi
  2011-04-06 14:06     ` Arun Ravindran
  2011-04-08  7:59   ` Joly, Frederic
  1 sibling, 1 reply; 12+ messages in thread
From: Pekka Pessi @ 2011-04-06 13:00 UTC (permalink / raw)
  To: ofono

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

Hi Arun,

2011/4/6 Arun Ravindran <ext-arun.1.ravindran@nokia.com>:
> According to this, the cid of user initiated context and network initiated
> context doesn't overlap.

The problem is, the initial EPS context is initiated by mobile, not by
the network. The mobile sends a piggybacked
PDN CONNECTIVITY REQUEST with the initial attach request in order to
initiate the initial EPS context.

-- 
Pekka.Pessi mail at nokia.com

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v3] gprs: add function to handle activated context
       [not found] <4D9C2965.4080301@nokia.com>
@ 2011-04-06  9:30 ` Arun Ravindran
  2011-04-06 13:00   ` Pekka Pessi
  2011-04-08  7:59   ` Joly, Frederic
  0 siblings, 2 replies; 12+ messages in thread
From: Arun Ravindran @ 2011-04-06  9:30 UTC (permalink / raw)
  To: ofono

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

Hi Redouane,

> The purpose of the patch is to handle Network Initiated Context 
> Activation and PDN connection request as part of EPS Attach procedure 
> (LTE) in oFono core.
>
> In order to avoid issue regarding CID allocation :
> - driver should call the core using ofono_gprs_set_cid_range function 
> to specify CID range for UE initiated PDN connection
> - driver could use a new function to check if the CID is already used 
> or not : ofono_gprs_is_cid_used, usefull in case the modem is not 
> using a specific range for UE initiated PDN connection.
> - driver will use a new function to notify the gprs atom of a new PDN 
> connection with all the ip parameters from AT+CGCONTRDP (I can provide 
> an update later to handle PCSCF and IMS Signaling Flag as well) 
> commmand : ofono_gprs_context_activated
>
27.007 section 10.1.1 says

Defined values
<cid>: a numeric parameter which specifies a particular PDP context 
definition. The parameter is local to the TE-
MT interface and is used in other PDP context-related commands. The 
range of permitted values (minimum
value = 1) is returned by the test form of the command.
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.

According to this, the cid of user initiated context and network 
initiated context doesn't overlap.

Also

+CGEV: ME PDN ACT <cid>[,<reason>[,<cid_other>]]
The mobile termination has activated a context. The context represents a 
PDN connection in LTE or a Primary
PDP context in GSM/UMTS. The <cid> for this context is provided to the 
TE. This event is sent either in result
of explicit context activation request (+CGACT), or in result of 
implicit context activation request associated to
attach request (+CGATT=1). The format of the parameters <cid>, 
<cid_other> are found in command
+CGDCONT.

We should also be able to get the cid of the default context, from CGEV 
indications.

> ofono_gprs_context_activated is similar to 
> ofono_gprs_context_deactivated.
> This function must be call by any gprs driver when :
>  - a context has been activated without explicit request as part of 
> attach procedure in LTE (PDN ACT X and X is a unused CID)
>  - a context has been activated by the Network (NW PDN ACT X, NW ACT X,Y)
>
> Behavior of the function :
>
> List all the context and try to find correct APN with empty username 
> and empty password.
> If such context is not found then create a new one with "Internet" 
> type only if we are in LTE with no Active context.
> Otherwise deactivate the connection.
>
> For the context (found or created):
>     Update the settings
>     Set to active
>
> The function will also assign the context to a context driver.

Please correct me if i miss some information.

Regards
Arun


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2011-04-08 13:34 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-09 18:31 [RFC PATCH v3] gprs: add function to handle activated context Soum, RedouaneX
2011-02-11 14:08 ` Tomasz Gregorek
2011-02-22 10:19 ` Soum, RedouaneX
     [not found] <4D9C2965.4080301@nokia.com>
2011-04-06  9:30 ` Arun Ravindran
2011-04-06 13:00   ` Pekka Pessi
2011-04-06 14:06     ` Arun Ravindran
2011-04-07  9:06       ` Soum, RedouaneX
2011-04-07 12:40         ` Arun Ravindran
2011-04-07 15:47           ` Soum, RedouaneX
2011-04-08 13:03             ` Arun Ravindran
2011-04-08 13:34               ` Soum, RedouaneX
2011-04-08  7:59   ` Joly, Frederic

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.