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