Hi Denis 2011/2/22 Denis Kenzior <[email protected]>
> 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 > [email protected] > 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
_______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
