Dear Harald,
I want to discuss this topic in mailing list, because I think we should coordinate our efforts when we work on the same part of project. As I found out from Alex, several important points were discussed at osmodevcon: * reuse gsup protocol for implementing location and authentication interface for osmo-nitb * get rid of using internal osmo-nitb database and use only subscriber list on osmo-nitb side Could you please confirm and/or enhance this list?
I see that you moved all gsup related code from openbsc to libosmocore in laforge/pending branches. Do you have any further plans to continue this development? As you know, we implemented interface based on gsup for exporting LU from osmo-nitb (fairwaves/sup branch), but in our implementation we didn't get rid of using internal database. Despite this I guess that our code could be updated and reused for this implementation.
Hi Ivan,
On Thu, Apr 28, 2016 at 06:18:14PM +0300, Ivan Kluchnikov wrote:
I want to discuss this topic in mailing list, because I think we should coordinate our efforts when we work on the same part of project.
sure.
As I found out from Alex, several important points were discussed at osmodevcon:
- reuse gsup protocol for implementing location and authentication
interface for osmo-nitb
- get rid of using internal osmo-nitb database and use only subscriber list
on osmo-nitb side
this is correct.
Could you please confirm and/or enhance this list?
The goals of my current work are as follows:
1) get rid of synchronous database access from OsmoNITB, which can cause various problems in loaded setups, or with slow disk: http://projects.osmocom.org/issues/1592
2) get rid of libdbi, which is buggy and slow: http://projects.osmocom.org/issues/1591
3) improve concurrent accesses to the database http://projects.osmocom.org/issues/30
4) UMTS AKA support (can be used over 2G) http://projects.osmocom.org/issues/1593
At the same time, I aim for reducing code differences and code duplication between the "VLR part" that is effectively inside both the OsmoNITB/CSCN as well as OsmoSGSN. So basically, SGSN, NITB and CSCN should all link + use a new "libvlr", which includes the GSUP client and takes care of SendAuthInfo/UpdateLocation/InsertSubscriberData on the MSC/SGSN.
I see that you moved all gsup related code from openbsc to libosmocore in laforge/pending branches.
correct.
Do you have any further plans to continue this development?
yes, I'm working on it every day since just before OsmoDevCon.
As you know, we implemented interface based on gsup for exporting LU from osmo-nitb (fairwaves/sup branch), but in our implementation we didn't get rid of using internal database.
Unfortunately there are many features in some branches that have never been pushed to the mailing list for review. As a result, it is hard to know what is going on, and also not clear in which status certain code is. Yes, there's the commitlog mailing list, but that doesn't answer the question about the status of the code :/
Despite this I guess that our code could be updated and reused for this implementation.
This would indeed be great.
So far, my work has been focussing on:
* moving GSUP message parsing to libosmocore * extending GSUP with code for UMTS AKA * removing openbsc dependency from GSUP client code * implementing GSUP server code * using GSUP server code to implement minimal osmo-gsup-hlr (for historic reasons still in osmo-auc.git, will probbably be moved eventually). AUC part (SendAuthInfo) has been implemented for 2G+3G, UpdateLocation, UpdateLocationGPRS and InsertSubscriberData is still pending.
So as you can see, this is so far completely outside the NITB, so I haven't yet touched that side. If you can propose a set of changes that removes the existing related code in the NITB and introduces the asynchronous-ness of the thre relevant operations, I would appreciate that. Also, any patches related to unification between the 'VLR-like' functionality on NITB and CSCN would be appreciated.
If you have any modifications/improvements on the GSUP protocol or related encode/decode/client functions, please also send them by all means. Thanks!
Regards, Harlad
Hi Harald,
Thank you for detailed clarification. As I understood from your description, the following changes should be also implemented on osmo-nitb/osmo-sgsn side: * authentication policy handling will be moved from osmo-nitb/osmo-sgsn side to osmo-gsup-hlr * osmo-nitb/osmo-sgsn will not be able to work independently (without connection with osmo-gsup-hlr). Are these points correct?
2016-04-28 22:24 GMT+03:00 Harald Welte laforge@gnumonks.org:
Hi Ivan,
On Thu, Apr 28, 2016 at 06:18:14PM +0300, Ivan Kluchnikov wrote:
I want to discuss this topic in mailing list, because I think we should coordinate our efforts when we work on the same part of project.
sure.
As I found out from Alex, several important points were discussed at osmodevcon:
- reuse gsup protocol for implementing location and authentication
interface for osmo-nitb
- get rid of using internal osmo-nitb database and use only subscriber
list
on osmo-nitb side
this is correct.
Could you please confirm and/or enhance this list?
The goals of my current work are as follows:
get rid of synchronous database access from OsmoNITB, which can cause various problems in loaded setups, or with slow disk: http://projects.osmocom.org/issues/1592
get rid of libdbi, which is buggy and slow: http://projects.osmocom.org/issues/1591
improve concurrent accesses to the database http://projects.osmocom.org/issues/30
UMTS AKA support (can be used over 2G) http://projects.osmocom.org/issues/1593
At the same time, I aim for reducing code differences and code duplication between the "VLR part" that is effectively inside both the OsmoNITB/CSCN as well as OsmoSGSN. So basically, SGSN, NITB and CSCN should all link + use a new "libvlr", which includes the GSUP client and takes care of SendAuthInfo/UpdateLocation/InsertSubscriberData on the MSC/SGSN.
I see that you moved all gsup related code from openbsc to libosmocore in laforge/pending branches.
correct.
Do you have any further plans to continue this development?
yes, I'm working on it every day since just before OsmoDevCon.
As you know, we implemented interface based on gsup for exporting LU from osmo-nitb (fairwaves/sup branch), but in our implementation we didn't get rid of using internal database.
Unfortunately there are many features in some branches that have never been pushed to the mailing list for review. As a result, it is hard to know what is going on, and also not clear in which status certain code is. Yes, there's the commitlog mailing list, but that doesn't answer the question about the status of the code :/
Despite this I guess that our code could be updated and reused for this implementation.
This would indeed be great.
So far, my work has been focussing on:
- moving GSUP message parsing to libosmocore
- extending GSUP with code for UMTS AKA
- removing openbsc dependency from GSUP client code
- implementing GSUP server code
- using GSUP server code to implement minimal osmo-gsup-hlr (for historic reasons still in osmo-auc.git, will probbably be moved eventually). AUC part (SendAuthInfo) has been implemented for 2G+3G, UpdateLocation, UpdateLocationGPRS and InsertSubscriberData is still pending.
So as you can see, this is so far completely outside the NITB, so I haven't yet touched that side. If you can propose a set of changes that removes the existing related code in the NITB and introduces the asynchronous-ness of the thre relevant operations, I would appreciate that. Also, any patches related to unification between the 'VLR-like' functionality on NITB and CSCN would be appreciated.
If you have any modifications/improvements on the GSUP protocol or related encode/decode/client functions, please also send them by all means. Thanks!
Regards, Harlad
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Harald Welte -
Ivan Kluchnikov -
Ivan Kluchnikov