Hi,
a couple month ago I proposed to make the VLR code of the osmo-msc independent of the osmo-msc and create a new library called libosmo-vlr. Later use the libosmo-vlr code to integrate it into osmo-sgsn.
But after take more time of this approach, I'm not sure if it is a very good idea to guarantee high stability of libosmo-vlr as we do for other osmocom libraries.
Because the code is heavily integrated with both daemon and some code path are quite complex and partly not fully understood. I would rather guarantee runtime stability within a library version, but not at build time. The strategy would be increasing the library major version more often.
Any thoughts?
Best, lynxis
PS. The current concept (because of time pressure) is to keep 2 copies of libosmo-vlr in the code base of osmo-msc and osmo-sgsn and to move it later out of it into an own library.
On Thu, Aug 28, 2025 at 02:25:29PM +0200, Alexander 'lynxis' Couzens wrote:
a couple month ago I proposed to make the VLR code of the osmo-msc independent of the osmo-msc and create a new library called libosmo-vlr. Later use the libosmo-vlr code to integrate it into osmo-sgsn.
A separate libosmo-vlr would be the idealistic optimum. But I think the most important part is that, instead of starting a new VLR implementation from scratch, to use what we learned in osmo-msc and use that in osmo-sgsn.
So if there is too much complexity in marrying msc and sgsn to a common libosmo-vlr, I'd personally agree with adding a copy of the MSC's VLR into the SGSN and just make it work from there, without idealistic expectations on having a fully independent external library. I myself did once try to create libiu-client to share Iu interface handling between SGSN and MSC, which was a great idea in my nerdy dreams, but only held us back in practice. We've finally recently gotten rid of it.
The vlr in osmo-msc does try to do proper layer separation, with those vlr_ops callback functions and so on. So the vision *was* to be independent from the MSC's code. But did it work out? It would be interesting for me personally to take a closer look at the individual places that cause problems, to see the places where the MSC's VLR isn't properly separated, after all. Maybe we can even resolve those problems, but, I still think just keeping an own VLR copy in osmo-sgsn is a very good option, too. If we ever make important fixes to the VLR, copying those fixes over between SGSN and MSC, and otherwise allowing them to slightly diverge, will very likely be less work than constantly keeping both VLRs in sync. The VLR is not libosmocore...
PS. The current concept (because of time pressure) is to keep 2 copies of libosmo-vlr in the code base of osmo-msc and osmo-sgsn and to move it later out of it into an own library.
(...and i would also be fine with not bothering to move it out later.)
I would rather guarantee runtime stability within a library version, but not at build time. The strategy would be increasing the library major version more often.
(I don't understand this paragraph, I hope I gave a sufficient answer above)
~N
Hi,
On 9/10/25 5:06 PM, Neels Hofmeyr wrote:
So if there is too much complexity in marrying msc and sgsn to a common libosmo-vlr, I'd personally agree with adding a copy of the MSC's VLR into the SGSN and just make it work from there, without idealistic expectations on having a fully independent external library. I myself did once try to create libiu-client to share Iu interface handling between SGSN and MSC, which was a great idea in my nerdy dreams, but only held us back in practice. We've finally recently gotten rid of it.
I also already expressed the same concerns to lynxis in private. So yes, agree with keeping a separate copy for now.
The vlr in osmo-msc does try to do proper layer separation, with those vlr_ops callback functions and so on. So the vision *was* to be independent from the MSC's code. But did it work out? It would be interesting for me personally to take a closer look at the individual places that cause problems, to see the places where the MSC's VLR isn't properly separated, after all. Maybe we can even resolve those problems, but, I still think just keeping an own VLR copy in osmo-sgsn is a very good option, too. If we ever make important fixes to the VLR, copying those fixes over between SGSN and MSC, and otherwise allowing them to slightly diverge, will very likely be less work than constantly keeping both VLRs in sync. The VLR is not libosmocore...
I think sometimes what ends up being a bit convoluted regarding those abstractions is that still those are meant to be used as a synchronous/blocking API, while the real interface in the end is expected to be asynchronous (over the wire). So in the end if we ever switch to an external VLR we'd need to change the code quite a lot in order to convert those calls to be asynchronous. In that kind of events where we expect this final asynchronous behavior, for the future, we may want to implement an API eg. over libosmo-netif's osmo_prim_srv (which uses a unix socket internally) to already make the code asyncrhonous from the start.
Regards, Pau
Types of gambling vary across Europe, including lotteries, sports betting, card games, and digital casino formats. In recent years, AI in European gambling platforms has been used to personalize interfaces, detect fraud, and support responsible participation <a href="https://babkarantena.sk/">babkarantena.sk</a> These systems analyze patterns, helping operators understand preferences while regulators monitor fairness, transparency, and user protection in both land-based and online environments for players, communities, and digital entertainment cultures.
-
Alexander 'lynxis' Couzens -
krisperesh＠gmail.com -
Neels Hofmeyr -
Pau Espin Pedrol