7:30 p.m.
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
11 p.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
Hi Arun,
2011/4/6 Arun Ravindran <ext-arun.1.ravindran(a)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
12:06 a.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
Hi Pessi,
Hi Arun,
2011/4/6 Arun Ravindran<ext-arun.1.ravindran(a)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
7:06 p.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
Hi All,
-----Original Message-----
From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@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(a)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.
10:40 p.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
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
1:47 a.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
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.
11:03 p.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
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
11:34 p.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
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.
5:59 p.m.
New subject: [RFC PATCH v3] gprs: add function to handle activated context
Hi,
My 2 cts.
-----Original Message-----
From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@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.
4181
days inactive
4183
days old
8 comments
4 participants
participants (4)
-
Arun Ravindran -
Joly, Frederic -
Pekka Pessi -
Soum, RedouaneX