OsmoNITB async HLR/VLR

Ivan Kluchnikov ivan.kluchnikov at fairwaves.co
Fri Apr 29 10:57:05 UTC 2016

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 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.
> 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
> > 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 at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160429/d3bf07be/attachment.html>

More information about the OpenBSC mailing list