On Thu, Mar 16, 2017 at 11:06:28PM +0100, Harald Welte wrote:

The [post-VLR] repository currently contains the following main programs (excluding various utilities like abisip-find, isdnsync, measurement stuff, ... :

• osmo-bsc
• osmo-bsc_nat
• osmo-msc (NITB without HLR and BSC)

To clarify for anyone else reading along: the VLR, i.e. libvlr, sits in the OsmoNITB, closely tied to libmsc, on the vlr_2G and vlr_3G branches. See also the block diagrams towards the end of https://osmocom.org/news/67

So in terms of clean-up, one of the questions is: what exactly do the circuit switched programs share with the packet-switched ones?

The answer to this *should* be: anything found in libcommon. For things shared among the circuit-switched parts, we have libcommon-cs, so the rest should be relevant for cs + ps ... However, that's not accurate.

Taking a look at libcommon:

Used everywhere but makes sense to separate instead: bsc_version.c -- just the copyright string common_vty.c -- vty_go_parent() combined for various VTY trees debug.c -- logging categories and filters, combined

Only related to gprs because above debug.c combines unrelated scopes: gsm_subscriber_base.c -- debug.c filter_fn uses msc/bsc subscr_get()/subscr_put()

Completely unrelated to gprs: gsm_data.c -- except tall_bsc_ctx, gprs should have its own. gsm_data_shared.c talloc_ctx.c socket.c -- actually only used by osmo-bsc_nat and ipaccess-proxy, should probably use libosmocore socket code instead?

Used across gprs and cs: gsup_client.c -- not yet, but used by CS on vlr_2G branch gsup_test_client.c oap_client.c

These are proven / illustrated by a playful branch that moves things to libcommon-cs: https://git.osmocom.org/openbsc/log/?h=neels/libcommon-cs

In fact it looks like rather than splitting off libcommon-cs, we should have created a libosmo-gsupclient and left libcommon to be used by cs programs only, separating the minor generic bits to gprs/.

Then there's also libiu, which is shared across OsmoSGSN and OsmoMSC on the 3G branch to provide IuPS and IuCS, respectively.

In summary: only gsup_client and libiu are shared across cs and ps, both of which are also just needed by libmsc/libvlr and OsmoSGSN. (not by osmo-bsc*, not by gb_proxy nor by any utils.)

If we wanted to completely separate cs from ps, we could technically move gsup_client to libosmocore and libiu to osmo-iuh. That would allow having separate osmo-bsc+msc and osmo-sgsn repositories. Actually, our plans for separating MSC and BSC also calls for separating gsm_subscriber_connection and gsm_network, and at that point it would also make sense to have separate osmo-bsc and osmo-msc repositories. The names would then come naturally. We could install libbsc from osmo-bsc and link it in from osmo-msc to build OsmoNITB while we still need to; and when the A-interface comes along stop linking libbsc from osmo-msc.

If we keep bsc, msc and gprs combined, we need to come up with a logical name. Maybe the fact that we still haven't found one is an indicator that we should rather separate openbsc.git up by the familiar names as above?

In redmine we have the 'cellular infrastructure' project as a parent to all the 2G/3G related projects. Maybe we should call it 'osmo-cell-infra', 'osmo-2g3g' or even more generic 'osmo-cellular'? that's actually again a bit too generic, as the BTS and PCU are prime example of other cellular infrastructure projects that are not part of that repo. Also, there's the HLR which lives in a separate repo - simply because it shares no code with the other projects. Still, it might actually be worth to consider merging it into the same repo as the MSC.

With steve, the name Osmocom-CN has kind of stuck, for osmocom core network. But again the HLR is separate and it's not really accurate. Osmocom-CN would make sense if we have a joint BSC, MSC, SGSN and HLR repository.

Maybe a non-descriptive name should be used? Or, in the great tradition of the telecom world, yet another acronym?

Nondescriptive... osmo-kitchensink? :P

Weird that they should have so many acronyms like SIGTRAN, NAS, GERAN/UTRAN, and none of them match our intended grouping :)

But what *is* our intended grouping? I (naively?) tend to like complete separation into separate BSC, separate MSC, separate SGSN, because it matches the separation that the code is moving towards, and our redmine project tree.

In general, when we do the "fork" to the new repo, I would like to use the opportunity to get rid of the extra 'openbsc' sub directory

+1

~N