RE: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

RE: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Vijay.Nayani]

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

 

> Subject: [PATCH] atmodem: CEREG support for LTE network 
> status reporting in AT modem
> 
> [PATCH] atmodem: CEREG support for LTE network status 
> reporting in AT modem Tomasz Gregorek tomasz.gregorek at 
> gmail.com Thu Feb 17 19:52:45 PST 2011
> 
>     * Previous message: [PATCH 2/5] bluetooth: add a 
> bluetoothd connect watch
>     * Next message: Problem with SIM lock states not showing 
> correctly in Ofono API.
>     * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 
> From: Tomasz Gregorek <tomasz.gregorek@stericsson.com>
> 
> This is a proposal for CEREG support based on the AT modem.
> Support in driver should work, though I have an issue with the core.
> 
> The core has one gprs status currently. In case of having 
> second status for LTE, there is need of having two satuses, 
> one for each, 3G and LTE, or to combine those two into one.
> 
> I took second approach as it leaves current oFono API, though 
> it is not perfect.

I have been working on solution that comprises of separate eps atom and
corresponding driver. Code has been tested against modified phonesim for
eps.Will provide an RFC patch soon once I bring it to certain logical
end.

Regards,
Vijay

Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Tomasz Gregorek]

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

Hi Vijay

2011/2/22 <Vijay.Nayani@elektrobit.com>

>
>
> > Subject: [PATCH] atmodem: CEREG support for LTE network
> > status reporting in AT modem
> >
> > [PATCH] atmodem: CEREG support for LTE network status
> > reporting in AT modem Tomasz Gregorek tomasz.gregorek at
> > gmail.com Thu Feb 17 19:52:45 PST 2011
> >
> >     * Previous message: [PATCH 2/5] bluetooth: add a
> > bluetoothd connect watch
> >     * Next message: Problem with SIM lock states not showing
> > correctly in Ofono API.
> >     * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >
> > From: Tomasz Gregorek <tomasz.gregorek@stericsson.com>
> >
> > This is a proposal for CEREG support based on the AT modem.
> > Support in driver should work, though I have an issue with the core.
> >
> > The core has one gprs status currently. In case of having
> > second status for LTE, there is need of having two satuses,
> > one for each, 3G and LTE, or to combine those two into one.
> >
> > I took second approach as it leaves current oFono API, though
> > it is not perfect.
>
> I have been working on solution that comprises of separate eps atom and
> corresponding driver. Code has been tested against modified phonesim for
> eps.Will provide an RFC patch soon once I bring it to certain logical
> end.
>
> Regards,
> Vijay
>

This is what I was thinking about too.
For me, from status point of view, both networks look very similar,
thats why I was thinking about using gprs atom / driver for
status handling and create separate atom for QoS / IMS.

I am at most interested in your solution. I know from Denis that
this is what was agreed.

Br
Tomasz Gregorek

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

RE: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Vijay.Nayani]

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

 

> -----Original Message-----
> From: Tomasz Gregorek [mailto:tomasz.gregorek(a)gmail.com] 
> Sent: 22 February 2011 16:09
> To: ofono(a)ofono.org
> Cc: Nayani Vijay
> Subject: Re: [PATCH] atmodem: CEREG support for LTE network 
> status reporting in AT modem
> 
> Hi Vijay
> 
> 
> 2011/2/22 <Vijay.Nayani@elektrobit.com>
> 
> 
> 
> 
> 	> Subject: [PATCH] atmodem: CEREG support for LTE network
> 	> status reporting in AT modem
> 	>
> 	> [PATCH] atmodem: CEREG support for LTE network status
> 	> reporting in AT modem Tomasz Gregorek tomasz.gregorek at
> 	> gmail.com Thu Feb 17 19:52:45 PST 2011
> 	>
> 	>     * Previous message: [PATCH 2/5] bluetooth: add a
> 	> bluetoothd connect watch
> 	>     * Next message: Problem with SIM lock states not showing
> 	> correctly in Ofono API.
> 	>     * Messages sorted by: [ date ] [ thread ] [ 
> subject ] [ author ]
> 	>
> 	> From: Tomasz Gregorek <tomasz.gregorek@stericsson.com>
> 	
> 	>
> 	> This is a proposal for CEREG support based on the AT modem.
> 	> Support in driver should work, though I have an issue 
> with the core.
> 	>
> 	> The core has one gprs status currently. In case of having
> 	> second status for LTE, there is need of having two satuses,
> 	> one for each, 3G and LTE, or to combine those two into one.
> 	>
> 	> I took second approach as it leaves current oFono API, though
> 	> it is not perfect.
> 	
> 	
> 	I have been working on solution that comprises of 
> separate eps atom and
> 	corresponding driver. Code has been tested against 
> modified phonesim for
> 	eps.Will provide an RFC patch soon once I bring it to 
> certain logical
> 	end.
> 	
> 	Regards,
> 	Vijay
> 	
> 
> 
> This is what I was thinking about too.
> For me, from status point of view, both networks look very 
> similar, thats why I was thinking about using gprs atom / 
> driver for status handling and create separate atom for QoS / IMS.
> 

I agree with you , both bearers are almost similar.Minor difference i
see are context managment (especially default context creation) and some
eps related spill over on other existing atoms (For ex SIM would not
contain some ISIM (IMPU/IMPI)related stuff).My idea is seperate atoms
solution would even work for legacy switch back(CSFB) too with a minimal
impact on exiting architecture.Your comments on these ideas would also
very valuable here as i assume you have real modem unlike me.

> I am at most interested in your solution. I know from Denis 
> that this is what was agreed.
> 
> Br
> Tomasz Gregorek
> 

Will submit the rfc patch and short design write up once i have code
ready.

Br,
Vijay

Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Tomasz Gregorek]

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

2011/2/22 <Vijay.Nayani@elektrobit.com>

>
>
> > -----Original Message-----
> > From: Tomasz Gregorek [mailto:tomasz.gregorek(a)gmail.com]
> > Sent: 22 February 2011 16:09
> > To: ofono(a)ofono.org
> > Cc: Nayani Vijay
> > Subject: Re: [PATCH] atmodem: CEREG support for LTE network
> > status reporting in AT modem
> >
> > Hi Vijay
> >
> >
> > 2011/2/22 <Vijay.Nayani@elektrobit.com>
> >
> >
> >
> >
> >       > Subject: [PATCH] atmodem: CEREG support for LTE network
> >       > status reporting in AT modem
> >       >
> >       > [PATCH] atmodem: CEREG support for LTE network status
> >       > reporting in AT modem Tomasz Gregorek tomasz.gregorek at
> >       > gmail.com Thu Feb 17 19:52:45 PST 2011
> >       >
> >       >     * Previous message: [PATCH 2/5] bluetooth: add a
> >       > bluetoothd connect watch
> >       >     * Next message: Problem with SIM lock states not showing
> >       > correctly in Ofono API.
> >       >     * Messages sorted by: [ date ] [ thread ] [
> > subject ] [ author ]
> >       >
> >       > From: Tomasz Gregorek <tomasz.gregorek@stericsson.com>
> >
> >       >
> >       > This is a proposal for CEREG support based on the AT modem.
> >       > Support in driver should work, though I have an issue
> > with the core.
> >       >
> >       > The core has one gprs status currently. In case of having
> >       > second status for LTE, there is need of having two satuses,
> >       > one for each, 3G and LTE, or to combine those two into one.
> >       >
> >       > I took second approach as it leaves current oFono API, though
> >       > it is not perfect.
> >
> >
> >       I have been working on solution that comprises of
> > separate eps atom and
> >       corresponding driver. Code has been tested against
> > modified phonesim for
> >       eps.Will provide an RFC patch soon once I bring it to
> > certain logical
> >       end.
> >
> >       Regards,
> >       Vijay
> >
> >
> >
> > This is what I was thinking about too.
> > For me, from status point of view, both networks look very
> > similar, thats why I was thinking about using gprs atom /
> > driver for status handling and create separate atom for QoS / IMS.
> >
>
> I agree with you , both bearers are almost similar.Minor difference i
> see are context managment (especially default context creation) and some
> eps related spill over on other existing atoms (For ex SIM would not
> contain some ISIM (IMPU/IMPI)related stuff).My idea is seperate atoms
> solution would even work for legacy switch back(CSFB) too with a minimal
> impact on exiting architecture.Your comments on these ideas would also
> very valuable here as i assume you have real modem unlike me.
>
> My main concern is about LTE only modems, these ones would not register
gprs
atom so all stuff from gprs atom needs to be done in eps atom, plus CEREG
and initial PDN. Than if you have a mix modem with 3G and LTE than all this
"stuff"
would be done twice without some additional logic. Sounds complicated to me.
About initial PDN, acually I think it can be placed in gprs atom
too, it won't influence 3G modems at all and we have +CGEV: handling there
already
(maybe not the strongest argument but would make things easier).


> > I am at most interested in your solution. I know from Denis
> > that this is what was agreed.
> >
> > Br
> > Tomasz Gregorek
> >
>
> Will submit the rfc patch and short design write up once i have code
> ready.
>
Ok. More comments as soon as there will be some code.


>
> Br,
> Vijay
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
>

Br
Tomasz

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

RE: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Soum, RedouaneX]

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

Hi guys,


>>I agree with you , both bearers are almost similar.Minor difference i
>>see are context managment (especially default context creation) and some
>>eps related spill over on other existing atoms (For ex SIM would not
>>contain some ISIM (IMPU/IMPI)related stuff).My idea is seperate atoms
>>solution would even work for legacy switch back(CSFB) too with a minimal
>>impact on exiting architecture.Your comments on these ideas would also
>>very valuable here as i assume you have real modem unlike me.
>>
>My main concern is about LTE only modems, these ones would not register gprs
>atom so all stuff from gprs atom needs to be done in eps atom, plus CEREG
>and initial PDN. Than if you have a mix modem with 3G and LTE than all this "stuff"
>would be done twice without some additional logic. Sounds complicated to me.
>About initial PDN, acually I think it can be placed in gprs atom
>too, it won't influence 3G modems at all and we have +CGEV: handling there already
>(maybe not the strongest argument but would make things easier).

I agree, the differences between 2G/3G and LTE are not so big so it'll be better if we keep the logic in the existing atoms.
A lot of LTE AT commands were extended from 2G/3G to support LTE.

A good approach would be to extend netreg and gprs atoms to handle lte including initial default bearer (as part of attach procedure) and dedicated bearers( secondary context in 2G/2G).

For the concepts that are not present in 2G and 3G, such as IMS related concepts then we can use a dedicated atom.

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: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Denis Kenzior]

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

Hi,

On 02/22/2011 10:08 AM, Soum, RedouaneX wrote:
> Hi guys,
> 
> 
>>> I agree with you , both bearers are almost similar.Minor difference i
>>> see are context managment (especially default context creation) and some
>>> eps related spill over on other existing atoms (For ex SIM would not
>>> contain some ISIM (IMPU/IMPI)related stuff).My idea is seperate atoms
>>> solution would even work for legacy switch back(CSFB) too with a minimal
>>> impact on exiting architecture.Your comments on these ideas would also
>>> very valuable here as i assume you have real modem unlike me.
>>>
>> My main concern is about LTE only modems, these ones would not register gprs
>> atom so all stuff from gprs atom needs to be done in eps atom, plus CEREG
>> and initial PDN. Than if you have a mix modem with 3G and LTE than all this "stuff"
>> would be done twice without some additional logic. Sounds complicated to me.
>> About initial PDN, acually I think it can be placed in gprs atom
>> too, it won't influence 3G modems at all and we have +CGEV: handling there already
>> (maybe not the strongest argument but would make things easier).
> 
> I agree, the differences between 2G/3G and LTE are not so big so it'll be better if we keep the logic in the existing atoms.
> A lot of LTE AT commands were extended from 2G/3G to support LTE.
> 
> A good approach would be to extend netreg and gprs atoms to handle lte including initial default bearer (as part of attach procedure) and dedicated bearers( secondary context in 2G/2G).
> 
> For the concepts that are not present in 2G and 3G, such as IMS related concepts then we can use a dedicated atom.

One thing to keep in mind about LTE is that we're not only looking to
support GSM style networks.  There are hybrid networks such as Verizon
which have CDMA/LTE mix.  From an API point of view it might not make
sense to expose unneeded GSM details in such situations.

There are also plenty of implementation details inside gprs atom
specific to gprs.  So for ease of implementation it might be sensible to
have a separate LTE atom anyway, even if it still implements the exact
same API.  We can factor out common context / bearer management into a
separate utility / atom if needed.

Regards,
-Denis

Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Tomasz Gregorek]

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

Hi Denis

2011/2/22 Denis Kenzior <denkenz@gmail.com>

> Hi,
>
> On 02/22/2011 10:08 AM, Soum, RedouaneX wrote:
> > Hi guys,
> >
> >
> >>> I agree with you , both bearers are almost similar.Minor difference i
> >>> see are context managment (especially default context creation) and
> some
> >>> eps related spill over on other existing atoms (For ex SIM would not
> >>> contain some ISIM (IMPU/IMPI)related stuff).My idea is seperate atoms
> >>> solution would even work for legacy switch back(CSFB) too with a
> minimal
> >>> impact on exiting architecture.Your comments on these ideas would also
> >>> very valuable here as i assume you have real modem unlike me.
> >>>
> >> My main concern is about LTE only modems, these ones would not register
> gprs
> >> atom so all stuff from gprs atom needs to be done in eps atom, plus
> CEREG
> >> and initial PDN. Than if you have a mix modem with 3G and LTE than all
> this "stuff"
> >> would be done twice without some additional logic. Sounds complicated to
> me.
> >> About initial PDN, acually I think it can be placed in gprs atom
> >> too, it won't influence 3G modems at all and we have +CGEV: handling
> there already
> >> (maybe not the strongest argument but would make things easier).
> >
> > I agree, the differences between 2G/3G and LTE are not so big so it'll be
> better if we keep the logic in the existing atoms.
> > A lot of LTE AT commands were extended from 2G/3G to support LTE.
> >
> > A good approach would be to extend netreg and gprs atoms to handle lte
> including initial default bearer (as part of attach procedure) and dedicated
> bearers( secondary context in 2G/2G).
> >
> > For the concepts that are not present in 2G and 3G, such as IMS related
> concepts then we can use a dedicated atom.
>
> One thing to keep in mind about LTE is that we're not only looking to
> support GSM style networks.  There are hybrid networks such as Verizon
> which have CDMA/LTE mix.  From an API point of view it might not make
> sense to expose unneeded GSM details in such situations.
>
> There are also plenty of implementation details inside gprs atom
> specific to gprs.  So for ease of implementation it might be sensible to
> have a separate LTE atom anyway, even if it still implements the exact
> same API.  We can factor out common context / bearer management into a
> separate utility / atom if needed.
>
> Regards,
> -Denis
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
>

Common gprs atom would be able to handle all situation: 3G only, 3G / LTE,
LTE only,
marking technology in Bearer property. Though it might be difficult to
handle double
registration of 3G and LTE at the same time for mix modems, if this is
allowed.

3G only stuff in gprs seems to be only gprs_suspend during callback as in
LTE
call won't suspend connection, and attached property as LTE is always
attached.
Most of this atom is context related which is common.

Fast look gives me this division of gprs:
- gprs atom: suspend, attached, status handling
- lte atom: status handling
- context atom (common part for 3G and LTE): whole context handling,
    cid map, ~80% of current src/gprs.c, + some IMS stuff
all would probably need to use netreg_watch

In my opinion, combined gprs atom would be easier to do and probably enough,
separate atoms would be more "looking into the future" like but I am not
sure if this division is necessary.

Br
Tomasz

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

Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Denis Kenzior]

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

Hi Tomasz,

> Common gprs atom would be able to handle all situation: 3G only, 3G /
> LTE, LTE only,
> marking technology in Bearer property. Though it might be difficult to
> handle double
> registration of 3G and LTE at the same time for mix modems, if this is
> allowed.
> 
> 3G only stuff in gprs seems to be only gprs_suspend during callback as
> in LTE
> call won't suspend connection, and attached property as LTE is always
> attached.

Yes, unfortunately this is also the nastiest part of the GPRS atom
logic.  From past experience I can tell you that extending the logic
will not be easy.

> Most of this atom is context related which is common.
> 
> Fast look gives me this division of gprs:
> - gprs atom: suspend, attached, status handling
> - lte atom: status handling
> - context atom (common part for 3G and LTE): whole context handling,
>     cid map, ~80% of current src/gprs.c, + some IMS stuff
> all would probably need to use netreg_watch
> 

Most of the context management can be done on a separate atom /
interface if needed.

> In my opinion, combined gprs atom would be easier to do and probably enough,
> separate atoms would be more "looking into the future" like but I am not
> sure if this division is necessary.

Looking at the current ConnectionManager API, none of the properties
(Powered, Attached, Suspended, RoamingAllowed) are applicable to LTE.
If we use a separate LTE atom then the Bearer property's 'lte' value is
redundant as well.  So why would you want to carry this baggage around
for the user of LTE-only systems?

Without those properties and the associated logic, the LTE-only atom
becomes quite trivial, assuming the context management is factored out
somewhere nicely.

You might be right of course and this separation is not necessary.  But
we won't know until we try.

Regards,
-Denis

RE: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Soum, RedouaneX]

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

Hi Denis,


>> In my opinion, combined gprs atom would be easier to do and probably 
>> enough, separate atoms would be more "looking into the future" like 
>> but I am not sure if this division is necessary.
>
>Looking at the current ConnectionManager API, none of the properties 
>(Powered, Attached, Suspended, RoamingAllowed) are applicable to LTE.
>If we use a separate LTE atom then the Bearer property's 'lte' value is 
>redundant as well.  So why would you want to carry this baggage around 
>for the user of LTE-only systems?

After discussing internally with Fred Joly I would like to come back on the 4 properties :
- Suspended is applicable in LTE in case of CS Voice Call using CSFB
- Powered is applicable the only point is that you'll not be registered to LTE network if PS is disabled.
- Attached is also applicable and here also if you are not attached then you'll not be registered to LTE network.
- RoamingAllowed it's a settings from the APE so we can imagine that we would like not to use LTE if we are in roaming.

Our understanding is that LTE is a GSM technology so it's normal to have GSM concepts behind.


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: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Denis Kenzior]

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

Hi Redouane,

On 02/23/2011 10:36 AM, Soum, RedouaneX wrote:
> Hi Denis,
> 
> 
>>> In my opinion, combined gprs atom would be easier to do and probably 
>>> enough, separate atoms would be more "looking into the future" like 
>>> but I am not sure if this division is necessary.
>>
>> Looking at the current ConnectionManager API, none of the properties 
>> (Powered, Attached, Suspended, RoamingAllowed) are applicable to LTE.
>> If we use a separate LTE atom then the Bearer property's 'lte' value is 
>> redundant as well.  So why would you want to carry this baggage around 
>> for the user of LTE-only systems?
> 
> After discussing internally with Fred Joly I would like to come back on the 4 properties :
> - Suspended is applicable in LTE in case of CS Voice Call using CSFB

My understanding was that CS Fallback physically switches technologies.
 It is not 'suspending' LTE like it does with GPRS.  Am I wrong on this one?

> - Powered is applicable the only point is that you'll not be registered to LTE network if PS is disabled.

It sounds like you're talking about RadioSettings properties here.

Powered=False is implemented by simply not attaching today.  The
implementation logic for LTE would be completely different.  So most
likely this will not work out nicely anyway.

> - Attached is also applicable and here also if you are not attached then you'll not be registered to LTE network.

Sounds pointless to expose for LTE to me.

> - RoamingAllowed it's a settings from the APE so we can imagine that we would like not to use LTE if we are in roaming.

Perhaps, but again we have no control of the attach procedure with LTE.
 So the implementation has to rely on vendor specific radio settings.
Same arguments about shoehorning logic apply here.

Regards,
-Denis

RE: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Joly, Frederic]

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

Hi Denis,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
> Behalf Of Denis Kenzior
> Sent: Wednesday, February 23, 2011 5:50 PM
> To: ofono(a)ofono.org
> Cc: tomasz.gregorek(a)gmail.com
> Subject: Re: [PATCH] atmodem: CEREG support for LTE network status
> reporting in AT modem
> > After discussing internally with Fred Joly I would like to come back
> on the 4 properties :
> > - Suspended is applicable in LTE in case of CS Voice Call using CSFB
> 
> My understanding was that CS Fallback physically switches technologies.
>  It is not 'suspending' LTE like it does with GPRS.  Am I wrong on this
> one?

I would say yes. :) 
In case you are obliged to fallback from 4G to 2G without support of DTM, exaclty like in GPRS.

> 
> Perhaps, but again we have no control of the attach procedure with LTE.
>  So the implementation has to rely on vendor specific radio settings.
> Same arguments about shoehorning logic apply here.

I'm a bit puzzled by this statement. It is not specific to LTE, but related to +CFUN proprietary implementation against  +COPS or +CGATT  usage, isn't it?

BR,

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: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Denis Kenzior]

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

Hi Fred,

On 02/23/2011 12:24 PM, Joly, Frederic wrote:
> Hi Denis,
> 
>> -----Original Message-----
>> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
>> Behalf Of Denis Kenzior
>> Sent: Wednesday, February 23, 2011 5:50 PM
>> To: ofono(a)ofono.org
>> Cc: tomasz.gregorek(a)gmail.com
>> Subject: Re: [PATCH] atmodem: CEREG support for LTE network status
>> reporting in AT modem
>>> After discussing internally with Fred Joly I would like to come back
>> on the 4 properties :
>>> - Suspended is applicable in LTE in case of CS Voice Call using CSFB
>>
>> My understanding was that CS Fallback physically switches technologies.
>>  It is not 'suspending' LTE like it does with GPRS.  Am I wrong on this
>> one?
> 
> I would say yes. :) 
> In case you are obliged to fallback from 4G to 2G without support of DTM, exaclty like in GPRS.

From what I understood you physically lose the EPS network registration
and fall back to 3G / 2G.  How is this the same as the suspended
property where your attached status does not change?

> 
>>
>> Perhaps, but again we have no control of the attach procedure with LTE.
>>  So the implementation has to rely on vendor specific radio settings.
>> Same arguments about shoehorning logic apply here.
> 
> I'm a bit puzzled by this statement. It is not specific to LTE, but related to +CFUN proprietary implementation against  +COPS or +CGATT  usage, isn't it?
>

The current GPRS logic is controlled with the equivalent of CGATT.  This
is a well-defined command by 3GPP, but it is not applicable to EPS
domain.  It is applicable only to PS domain, correct?  If so, then the
powered property does not map to LTE at all.  Your proprietary CFUN/COPS
map to the TechnologyPreference setting in RadioSettings.

Regards,
-Denis

Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Arun Ravindran]

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

Hi Denis,
>>> -----Original Message-----
>>> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
>>> Behalf Of Denis Kenzior
>>> Sent: Wednesday, February 23, 2011 5:50 PM
>>> To: ofono(a)ofono.org
>>> Cc: tomasz.gregorek(a)gmail.com
>>> Subject: Re: [PATCH] atmodem: CEREG support for LTE network status
>>> reporting in AT modem
>>>> After discussing internally with Fred Joly I would like to come back
>>> on the 4 properties :
>>>> - Suspended is applicable in LTE in case of CS Voice Call using CSFB
>>> My understanding was that CS Fallback physically switches technologies.
>>>   It is not 'suspending' LTE like it does with GPRS.  Am I wrong on this
>>> one?
>> I would say yes. :)
>> In case you are obliged to fallback from 4G to 2G without support of DTM, exaclty like in GPRS.
>  From what I understood you physically lose the EPS network registration
> and fall back to 3G / 2G.  How is this the same as the suspended
> property where your attached status does not change?
>>
For CSFB there are two settings. First one is that the UE should be 
voice centric.
A voice centric UE will always try to make voice service available 
either using IMS or by CSFB.
And if it cannot avail voice service using the above mechanisms, then it 
should leave E-UTRA and re connect to GERAN/UTRA. A data centric UE in 
turn will not leave E-UTRA if it cannot make a voice service available. 
(23.221, section 7.2a)

The second is that the voice call mode (domain), this can be set to CS, 
CS preferred, PS or PS preferred. A UE with CS or CS preferred will 
always try to make voice service through CS (CSFB or by re connecting to 
GERAN/UTRA). 24.167 and also 23.221 describes these setting. I think the 
AT commands for these in 27.007 are AT+CEMODE and +VCMOD

A UE indicates its CSFB capability in attach and location/routing area 
updates. The network in turn also indicates whether these are supported 
in network.
23.272 section 6.2 details a CSFB for MO call, where PS handover is 
supported. 6.3 where PS handover is not supported and 6.5 where how to 
return to E-UTRA when PS is suspended.

My understanding is that the context behaves the same way as in GPRS, 
where it can be suspended, deactivated or handed over while doing CSFB 
and the attach status will not change because when you are doing CSFB 
you have done a combined attach (EPS/IMSI).

>>> Perhaps, but again we have no control of the attach procedure with LTE.
>>>   So the implementation has to rely on vendor specific radio settings.
>>> Same arguments about shoehorning logic apply here.
>> I'm a bit puzzled by this statement. It is not specific to LTE, but related to +CFUN proprietary implementation against  +COPS or +CGATT  usage, isn't it?
>>
> The current GPRS logic is controlled with the equivalent of CGATT.  This
> is a well-defined command by 3GPP, but it is not applicable to EPS
> domain.  It is applicable only to PS domain, correct?
27.007 release 10, section 10, lists all commands applicable to EPS and 
CGATT is one of them.

> If so, then the
> powered property does not map to LTE at all.  Your proprietary CFUN/COPS
> map to the TechnologyPreference setting in RadioSettings.
>
Regards,
Arun

Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Denis Kenzior]

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

Hi Arun,

On 02/24/2011 04:34 AM, Arun Ravindran wrote:
> Hi Denis,
>>>> -----Original Message-----
>>>> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
>>>> Behalf Of Denis Kenzior
>>>> Sent: Wednesday, February 23, 2011 5:50 PM
>>>> To: ofono(a)ofono.org
>>>> Cc: tomasz.gregorek(a)gmail.com
>>>> Subject: Re: [PATCH] atmodem: CEREG support for LTE network status
>>>> reporting in AT modem
>>>>> After discussing internally with Fred Joly I would like to come back
>>>> on the 4 properties :
>>>>> - Suspended is applicable in LTE in case of CS Voice Call using CSFB
>>>> My understanding was that CS Fallback physically switches technologies.
>>>>   It is not 'suspending' LTE like it does with GPRS.  Am I wrong on
>>>> this
>>>> one?
>>> I would say yes. :)
>>> In case you are obliged to fallback from 4G to 2G without support of
>>> DTM, exaclty like in GPRS.
>>  From what I understood you physically lose the EPS network registration
>> and fall back to 3G / 2G.  How is this the same as the suspended
>> property where your attached status does not change?
>>>
> For CSFB there are two settings. First one is that the UE should be
> voice centric.
> A voice centric UE will always try to make voice service available
> either using IMS or by CSFB.
> And if it cannot avail voice service using the above mechanisms, then it
> should leave E-UTRA and re connect to GERAN/UTRA. A data centric UE in
> turn will not leave E-UTRA if it cannot make a voice service available.
> (23.221, section 7.2a)
> 
> The second is that the voice call mode (domain), this can be set to CS,
> CS preferred, PS or PS preferred. A UE with CS or CS preferred will
> always try to make voice service through CS (CSFB or by re connecting to
> GERAN/UTRA). 24.167 and also 23.221 describes these setting. I think the
> AT commands for these in 27.007 are AT+CEMODE and +VCMOD
> 
> A UE indicates its CSFB capability in attach and location/routing area
> updates. The network in turn also indicates whether these are supported
> in network.
> 23.272 section 6.2 details a CSFB for MO call, where PS handover is
> supported. 6.3 where PS handover is not supported and 6.5 where how to
> return to E-UTRA when PS is suspended.
> 

So everyone keeps talking of suspensions.  However, I still see no CGEV
that supports this event.  It still looks like a 2G holdover that is
being implemented by vendor specific extensions.  Or is this just an
oversight on 3GPP's part and suspensions can happen in LTE as well?

> My understanding is that the context behaves the same way as in GPRS,
> where it can be suspended, deactivated or handed over while doing CSFB
> and the attach status will not change because when you are doing CSFB
> you have done a combined attach (EPS/IMSI).
> 

Attach status fair enough.  However, does the reported technology change
as well?  There are important implications here, e.g. being able to
deactivate the last context, etc.

Overall I think we need detailed traces for all such scenarios and
consider all possibilities.  Currently I'm not convinced sharing LTE and
GPRS logic is the right way to go.

>>>> Perhaps, but again we have no control of the attach procedure with LTE.
>>>>   So the implementation has to rely on vendor specific radio settings.
>>>> Same arguments about shoehorning logic apply here.
>>> I'm a bit puzzled by this statement. It is not specific to LTE, but
>>> related to +CFUN proprietary implementation against  +COPS or +CGATT 
>>> usage, isn't it?
>>>
>> The current GPRS logic is controlled with the equivalent of CGATT.  This
>> is a well-defined command by 3GPP, but it is not applicable to EPS
>> domain.  It is applicable only to PS domain, correct?
> 27.007 release 10, section 10, lists all commands applicable to EPS and
> CGATT is one of them.
> 

My fault, I mis-interpreted that section.  You're of course correct that
CGATT is indeed applicable.

Regards,
-Denis

[PATCH] atmodem: CEREG support for LTE network status reporting in AT modem

[Tomasz Gregorek]

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

From: Tomasz Gregorek <tomasz.gregorek@stericsson.com>

This is a proposal for CEREG support based on the AT modem.
Support in driver should work, though I have an issue with
the core.

The core has one gprs status currently. In case of having
second status for LTE, there is need of having two satuses,
one for each, 3G and LTE, or to combine those two into one.

I took second approach as it leaves current oFono API, though
it is not perfect.
---
 drivers/atmodem/gprs.c  |  151 +++++++++++++++++++++++++++++++++++++++++++----
 drivers/isimodem/gprs.c |    6 +-
 include/gprs.h          |   11 +++-
 src/gprs.c              |   43 ++++++++++++-
 4 files changed, 189 insertions(+), 22 deletions(-)

diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index 6e01994..f6585de 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -43,12 +43,15 @@
 #include "vendor.h"
 
 static const char *cgreg_prefix[] = { "+CGREG:", NULL };
+static const char *cereg_prefix[] = { "+CEREG:", NULL };
 static const char *cgdcont_prefix[] = { "+CGDCONT:", NULL };
 static const char *none_prefix[] = { NULL };
 
 struct gprs_data {
 	GAtChat *chat;
 	unsigned int vendor;
+	ofono_bool_t have_cgreg;
+	ofono_bool_t have_cereg;
 };
 
 static void at_cgatt_cb(gboolean ok, GAtResult *result, gpointer user_data)
@@ -80,6 +83,31 @@ static void at_gprs_set_attached(struct ofono_gprs *gprs, int attached,
 	CALLBACK_WITH_FAILURE(cb, data);
 }
 
+static void at_cereg_cb(gboolean ok, GAtResult *result, gpointer user_data)
+{
+	struct cb_data *cbd = user_data;
+	ofono_gprs_status_cb_t cb = cbd->cb;
+	struct ofono_error error;
+	int status;
+	struct gprs_data *gd = cbd->user;
+
+	decode_at_error(&error, g_at_result_final_response(result));
+
+	if (!ok) {
+		cb(&error, -1, GPRS_PS_STATUS_SOURCE_LTE, cbd->data);
+		return;
+	}
+
+	if (at_util_parse_reg(result, "+CEREG:", NULL, &status,
+				NULL, NULL, NULL, gd->vendor) == FALSE) {
+		CALLBACK_WITH_FAILURE(cb, -1,
+				GPRS_PS_STATUS_SOURCE_LTE, cbd->data);
+		return;
+	}
+
+	cb(&error, status, GPRS_PS_STATUS_SOURCE_LTE, cbd->data);
+}
+
 static void at_cgreg_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
 	struct cb_data *cbd = user_data;
@@ -91,17 +119,28 @@ static void at_cgreg_cb(gboolean ok, GAtResult *result, gpointer user_data)
 	decode_at_error(&error, g_at_result_final_response(result));
 
 	if (!ok) {
-		cb(&error, -1, cbd->data);
+		cb(&error, -1, GPRS_PS_STATUS_SOURCE_LTE, cbd->data);
 		return;
 	}
 
 	if (at_util_parse_reg(result, "+CGREG:", NULL, &status,
 				NULL, NULL, NULL, gd->vendor) == FALSE) {
-		CALLBACK_WITH_FAILURE(cb, -1, cbd->data);
+		CALLBACK_WITH_FAILURE(cb, -1,
+				GPRS_PS_STATUS_SOURCE_3G, cbd->data);
+		g_free(cbd);
 		return;
 	}
 
-	cb(&error, status, cbd->data);
+	cb(&error, status, GPRS_PS_STATUS_SOURCE_3G, cbd->data);
+
+	if (gd->have_cereg) {
+		if (g_at_chat_send(gd->chat, "AT+CEREG?", cereg_prefix,
+				at_cereg_cb, cbd, g_free) == FALSE) {
+			CALLBACK_WITH_FAILURE(cb, -1,
+					GPRS_PS_STATUS_SOURCE_LTE, cbd->data);
+			g_free(cbd);
+		}
+	}
 }
 
 static void at_gprs_registration_status(struct ofono_gprs *gprs,
@@ -132,9 +171,17 @@ static void at_gprs_registration_status(struct ofono_gprs *gprs,
 		break;
 	}
 
-	if (g_at_chat_send(gd->chat, "AT+CGREG?", cgreg_prefix,
-				at_cgreg_cb, cbd, g_free) > 0)
+	if (gd->have_cgreg) {
+		if (g_at_chat_send(gd->chat, "AT+CGREG?", cgreg_prefix,
+			at_cgreg_cb, cbd, NULL) > 0)
 		return;
+	}
+	else {
+		if (g_at_chat_send(gd->chat, "AT+CEREG?", cereg_prefix,
+			at_cereg_cb, cbd, g_free) > 0)
+		return;
+	}
+
 
 	g_free(cbd);
 
@@ -151,7 +198,20 @@ static void cgreg_notify(GAtResult *result, gpointer user_data)
 				NULL, NULL, NULL, gd->vendor) == FALSE)
 		return;
 
-	ofono_gprs_status_notify(gprs, status);
+	ofono_gprs_status_notify(gprs, status, GPRS_PS_STATUS_SOURCE_3G);
+}
+
+static void cereg_notify(GAtResult *result, gpointer user_data)
+{
+	struct ofono_gprs *gprs = user_data;
+	int status;
+	struct gprs_data *gd = ofono_gprs_get_data(gprs);
+
+	if (at_util_parse_reg_unsolicited(result, "+CEREG:", &status,
+				NULL, NULL, NULL, gd->vendor) == FALSE)
+		return;
+
+	ofono_gprs_status_notify(gprs, status, GPRS_PS_STATUS_SOURCE_LTE);
 }
 
 static void cgev_notify(GAtResult *result, gpointer user_data)
@@ -226,8 +286,15 @@ static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data)
 	struct gprs_data *gd = ofono_gprs_get_data(gprs);
 
 	g_at_chat_register(gd->chat, "+CGEV:", cgev_notify, FALSE, gprs, NULL);
-	g_at_chat_register(gd->chat, "+CGREG:", cgreg_notify,
+
+	if (gd->have_cgreg)
+		g_at_chat_register(gd->chat, "+CGREG:", cgreg_notify,
 						FALSE, gprs, NULL);
+
+	if (gd->have_cereg)
+		g_at_chat_register(gd->chat, "+CEREG:", cereg_notify,
+						FALSE, gprs, NULL);
+
 	g_at_chat_register(gd->chat, "+CPSB:", cpsb_notify, FALSE, gprs, NULL);
 
 	g_at_chat_send(gd->chat, "AT+CPSB=1", none_prefix, NULL, NULL, NULL);
@@ -257,15 +324,15 @@ static void at_cgreg_test_cb(gboolean ok, GAtResult *result,
 	const char *cmd;
 
 	if (!ok)
-		goto error;
+		goto cgreg_notsupported;
 
 	g_at_result_iter_init(&iter, result);
 
 	if (!g_at_result_iter_next(&iter, "+CGREG:"))
-		goto error;
+		goto cgreg_notsupported;
 
 	if (!g_at_result_iter_open_list(&iter))
-		goto error;
+		goto cgreg_notsupported;
 
 	while (g_at_result_iter_next_range(&iter, &range[0], &range[1])) {
 		if (1 >= range[0] && 1 <= range[1])
@@ -281,9 +348,16 @@ static void at_cgreg_test_cb(gboolean ok, GAtResult *result,
 	else if (cgreg1)
 		cmd = "AT+CGREG=1";
 	else
-		goto error;
+		goto cgreg_notsupported;
+
+	gd->have_cgreg = TRUE;
 
 	g_at_chat_send(gd->chat, cmd, none_prefix, NULL, NULL, NULL);
+
+cgreg_notsupported:
+	if (gd->have_cgreg == FALSE && gd->have_cereg == FALSE)
+		goto error;
+
 	g_at_chat_send(gd->chat, "AT+CGAUTO=0", none_prefix, NULL, NULL, NULL);
 
 	switch (gd->vendor) {
@@ -354,6 +428,10 @@ static void at_cgdcont_test_cb(gboolean ok, GAtResult *result,
 	if (found == FALSE)
 		goto error;
 
+	/* In case of LTE modem reserve lowest cid for Initial PDN */
+	if (gd->have_cereg)
+		min++;
+
 	ofono_gprs_set_cid_range(gprs, min, max);
 
 	g_at_chat_send(gd->chat, "AT+CGREG=?", cgreg_prefix,
@@ -366,6 +444,53 @@ error:
 	ofono_gprs_remove(gprs);
 }
 
+static void at_cereg_test_cb(gboolean ok, GAtResult *result,
+				gpointer user_data)
+{
+	struct ofono_gprs *gprs = user_data;
+	struct gprs_data *gd = ofono_gprs_get_data(gprs);
+	gint range[2];
+	GAtResultIter iter;
+	int cereg1 = 0;
+	int cereg2 = 0;
+	const char *cmd;
+
+	if (!ok)
+		goto test_cgdcont;
+
+	g_at_result_iter_init(&iter, result);
+
+	if (!g_at_result_iter_next(&iter, "+CEREG:"))
+		goto test_cgdcont;
+
+	if (!g_at_result_iter_open_list(&iter))
+		goto test_cgdcont;
+
+	while (g_at_result_iter_next_range(&iter, &range[0], &range[1])) {
+		if (1 >= range[0] && 1 <= range[1])
+			cereg1 = 1;
+		if (2 >= range[0] && 2 <= range[1])
+			cereg2 = 1;
+	}
+
+	g_at_result_iter_close_list(&iter);
+
+	if (cereg2)
+		cmd = "AT+CEREG=2";
+	else if (cereg1)
+		cmd = "AT+CEREG=1";
+	else
+		goto test_cgdcont;
+
+	gd->have_cereg = TRUE;
+
+	g_at_chat_send(gd->chat, cmd, none_prefix, NULL, NULL, NULL);
+
+test_cgdcont:
+	g_at_chat_send(gd->chat, "AT+CGDCONT=?", cgdcont_prefix,
+			at_cgdcont_test_cb, gprs, NULL);
+}
+
 static int at_gprs_probe(struct ofono_gprs *gprs,
 					unsigned int vendor, void *data)
 {
@@ -381,8 +506,8 @@ static int at_gprs_probe(struct ofono_gprs *gprs,
 
 	ofono_gprs_set_data(gprs, gd);
 
-	g_at_chat_send(gd->chat, "AT+CGDCONT=?", cgdcont_prefix,
-			at_cgdcont_test_cb, gprs, NULL);
+	g_at_chat_send(gd->chat, "AT+CEREG=?", cgdcont_prefix,
+			at_cereg_test_cb, gprs, NULL);
 
 	return 0;
 }
diff --git a/drivers/isimodem/gprs.c b/drivers/isimodem/gprs.c
index ea90704..7d54df3 100644
--- a/drivers/isimodem/gprs.c
+++ b/drivers/isimodem/gprs.c
@@ -459,11 +459,11 @@ static void status_resp_cb(const GIsiMessage *msg, void *opaque)
 
 	suspend_notify(gprs, data[10], data[11]);
 
-	CALLBACK_WITH_SUCCESS(cb, status, cbd->data);
+	CALLBACK_WITH_SUCCESS(cb, status, GPRS_PS_STATUS_SOURCE_3G, cbd->data);
 	return;
 
 error:
-	CALLBACK_WITH_FAILURE(cb, -1, cbd->data);
+	CALLBACK_WITH_FAILURE(cb, -1, GPRS_PS_STATUS_SOURCE_3G, cbd->data);
 }
 
 static void isi_gprs_attached_status(struct ofono_gprs *gprs,
@@ -485,7 +485,7 @@ static void isi_gprs_attached_status(struct ofono_gprs *gprs,
 		return;
 
 error:
-	CALLBACK_WITH_FAILURE(cb, -1, data);
+	CALLBACK_WITH_FAILURE(cb, -1, GPRS_PS_STATUS_SOURCE_3G, data);
 	g_free(cbd);
 }
 
diff --git a/include/gprs.h b/include/gprs.h
index 157a6f9..305e12f 100644
--- a/include/gprs.h
+++ b/include/gprs.h
@@ -31,8 +31,14 @@ extern "C" {
 struct ofono_gprs;
 struct ofono_gprs_context;
 
+enum gprs_ps_status_source {
+	GPRS_PS_STATUS_SOURCE_3G,
+	GPRS_PS_STATUS_SOURCE_LTE,
+};
+
 typedef void (*ofono_gprs_status_cb_t)(const struct ofono_error *error,
-						int status, void *data);
+			int status, enum gprs_ps_status_source status_src,
+			void *data);
 
 typedef void (*ofono_gprs_cb_t)(const struct ofono_error *error, void *data);
 
@@ -55,7 +61,8 @@ enum gprs_suspend_cause {
 	GPRS_SUSPENDED_UNKNOWN_CAUSE,
 };
 
-void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status);
+void ofono_gprs_status_notify(struct ofono_gprs *gprs,
+		int status, enum gprs_ps_status_source status_src);
 void ofono_gprs_detached_notify(struct ofono_gprs *gprs);
 void ofono_gprs_suspend_notify(struct ofono_gprs *gprs, int cause);
 void ofono_gprs_resume_notify(struct ofono_gprs *gprs);
diff --git a/src/gprs.c b/src/gprs.c
index 33711dc..faccb91 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -80,6 +80,8 @@ struct ofono_gprs {
 	ofono_bool_t powered;
 	ofono_bool_t suspended;
 	int status;
+	int status3G;
+	int statusLTE;
 	int flags;
 	int bearer;
 	guint suspend_timeout;
@@ -138,6 +140,17 @@ struct pri_context {
 	struct ofono_gprs *gprs;
 };
 
+static const char status_priority[]={
+               0, /* NETWORK_REGISTRATION_STATUS_NOT_REGISTERED */
+               4, /* NETWORK_REGISTRATION_STATUS_REGISTERED */
+               3, /* NETWORK_REGISTRATION_STATUS_SEARCHING */
+               2, /* NETWORK_REGISTRATION_STATUS_DENIED */
+               1, /* NETWORK_REGISTRATION_STATUS_UNKNOWN */
+               5  /* NETWORK_REGISTRATION_STATUS_ROAMING */
+               /*0,  AT+CxREG? error */
+};
+
+
 static void gprs_netreg_update(struct ofono_gprs *gprs);
 static void gprs_deactivate_next(struct ofono_gprs *gprs);
 
@@ -1370,7 +1383,8 @@ static void gprs_attached_update(struct ofono_gprs *gprs)
 }
 
 static void registration_status_cb(const struct ofono_error *error,
-					int status, void *data)
+			int status, enum gprs_ps_status_source status_src,
+			void *data)
 {
 	struct ofono_gprs *gprs = data;
 
@@ -1378,7 +1392,7 @@ static void registration_status_cb(const struct ofono_error *error,
 		error->type, status);
 
 	if (error->type == OFONO_ERROR_TYPE_NO_ERROR)
-		ofono_gprs_status_notify(gprs, status);
+		ofono_gprs_status_notify(gprs, status, status_src);
 
 	if (gprs->flags & GPRS_FLAG_RECHECK) {
 		gprs->flags &= ~GPRS_FLAG_RECHECK;
@@ -1985,11 +1999,32 @@ void ofono_gprs_detached_notify(struct ofono_gprs *gprs)
 	 */
 }
 
-void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status)
+void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status,
+		enum gprs_ps_status_source status_src)
 {
 	DBG("%s status %d", __ofono_atom_get_path(gprs->atom), status);
 
-	gprs->status = status;
+	/*
+	 * Combine statuses from 3G and LTE network into one.
+	 * Use prioryty table as a base.
+	 */
+	if (status != -1) {
+		switch(status_src)
+		{
+			case GPRS_PS_STATUS_SOURCE_3G:
+				gprs->status3G = status;
+				break;
+			case GPRS_PS_STATUS_SOURCE_LTE:
+				gprs->statusLTE = status;
+				break;
+		}
+
+		gprs->status = ((status_priority[gprs->status3G] >=
+				status_priority[gprs->statusLTE]) ?
+					gprs->status3G : gprs->statusLTE);
+	}
+	else
+		gprs->status = -1;
 
 	if (status != NETWORK_REGISTRATION_STATUS_REGISTERED &&
 			status != NETWORK_REGISTRATION_STATUS_ROAMING) {
-- 
1.7.4