OsmoNITB async HLR/VLR

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Apr 28 19:24:31 UTC 2016


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

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



More information about the OpenBSC mailing list