gprs: add function to handle activated context
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Redouane,
Quoted 4 lines
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.
Quoted 11 lines
In order to avoid issue regarding CID allocation :
- driver should call the core usingofono_gprs_set_cid_rangefunction 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.
Quoted 15 lines
ofono_gprs_context_activatedis similar toofono_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.
Quoted 5 lines
For the context (found or created):
Update the settings
Set to activeThe function will also assign the context to a context driver.
Please correct me if i miss some information.
Regards
Arun
Hi Arun,
2011/4/6 Arun Ravindran <[email protected]>:
Quoted 2 lines
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.
Signature · 1 line
Pekka.Pessi mail at nokia.com
Hi Pessi,
Quoted 10 lines
Hi Arun,
2011/4/6 Arun Ravindran<[email protected]>:
Quoted 2 lines
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
Soum
Hi All,
Quoted 14 lines
-----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 contextHi Pessi,
Quoted 4 lines
Hi Arun,
2011/4/6 Arun Ravindran<[email protected]>:
Quoted 1 line
According to this, the cid of user initiated context and network
initiated
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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).
Quoted 4 lines
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.
Quoted 3 lines
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.
Hi Redouane,
Quoted 22 lines
Quoted 5 lines
Quoted 4 lines
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).
Quoted 2 lines
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.
Quoted 3 lines
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:
(quoted diff) +0
-3- 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. ----
Quoted 7 lines
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
Soum
Hi,
Quoted 10 lines
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.
Quoted 7 lines
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.
Hi Redouane,
Quoted 14 lines
Quoted 14 lines
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?
Quoted 7 lines
Quoted 3 lines
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_rangefrom 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_rangewith 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
Soum
Hi Arun,
Quoted 20 lines
Quoted 6 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 8 lines
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
Quoted 3 lines
Quoted 2 lines
a cid not in range of CGDCONT.
Exactly so the idea to avoid any issue was to call
ofono_gprs_set_cid_rangefrom the driver with a range which doesn't include the CID used for initial EPS context.
Quoted 8 lines
Quoted 1 line
Normaly we know from the modem vendor which CID will be used for the
initial EPS context.
Quoted 2 lines
For instance if +CGDSCONT=? Is returning 1-25 as range then we call
ofono_gprs_set_cid_rangewith 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 ...)
Quoted 4 lines
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. --
Quoted 2 lines
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.
Joly
Hi,
My 2 cts.
Quoted 8 lines
-----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
Quoted 10 lines
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.