> 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 at 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

> -----Original Message----- > From: Tomasz Gregorek [mailto:tomasz.gregorek@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(a)elektrobit.com&gt; > > > > > > 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 at 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

> 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 _______________________________________________ ofono mailing list ofono(a)ofono.org http://lists.ofono.org/listinfo/ofono

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.

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.

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.

Hi Denis, > -----Original Message----- > From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@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

> > 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?

Hi Denis, >>> -----Original Message----- >>> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@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.