28 Aug
2025
28 Aug
'25
2:25 p.m.
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.
10 Sep
10 Sep
5:06 p.m.
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
6:04 p.m.
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
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
33
days inactive
46
days old
2 comments
3 participants
participants (3)
-
Alexander 'lynxis' Couzens -
Neels Hofmeyr -
Pau Espin Pedrol