OsmoNITB async HLR/VLR
ivan.kluchnikov at fairwaves.co
Fri Apr 29 10:57:05 UTC 2016
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 at 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.
> > 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
> > 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:
> 2) get rid of libdbi, which is buggy and slow:
> 3) improve concurrent accesses to the database
> 4) UMTS AKA support (can be used over 2G)
> 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
> > 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?
> 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
> 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!
> - Harald Welte <laforge at gnumonks.org>
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenBSC