Hi Ruben,

sorry for the delayed response, I've been on holidays.

On Wed, Jul 18, 2018 at 05:11:45PM +0200, Ruben Undheim wrote:

The OpenBSC tools have turned into an impressive collection of tools. It is great to see this huge effort being done successfully! I was searching around on the osmocom site for information about LTE. Either, I am very bad at searching, or there is not so much information about that subject. I was wondering about the plans for LTE, if there are any such plans?

All Osmocom development happens where we get contributions, either in form of code, or in terms of funding for implementing certain bits and features. Despite my huge interest in the 4G area, we have not been getting either of the two in Osmocom so far.

As had been mentioned before, I've been playing around with nextepc as core and srsLTE as well as proprietary LTE eNodeBs in autumn last year. I think there is plenty of good FOSS projects for LTE out there.

I've always been quite vocal about my disappointment in OAI in any number of ways, whether on the side that their (RAN) license is not a Free Software nor an Open Source license, or whether on the coding style side of things.

So my personal recommendation is to stay away from OAI, and instead focus on srsLTE and nextepc instead.

I found a few other projects related to LTE: nextepc [1] and srsLTE [2]. I see that nextepc has been mentioned in a thread related to OsmoDevCon 2018, but I cannot see so much more information. Is the plan maybe some time to incorporate srsLTE and nextepc into osmocom infrastructure?

As you may know, there is quite a bit of common architecture between 2G and 3G, but there's virtually nothing in common between 2G+3G on the one hand side and 4G on the other hand side.

So there's not really much to "incorporate" from the Osmocom point of view.

I personally would love to have introduced some of the C-language infrastructure we have created in Osmocom (osmo_fsm, vty, logging sub-system) into nextepc, but unfortunately nextepc decided against it.

In terms of "using Osmocom for GSM/UMTS and nextepc+srsLTE for 4G in a single network", there are the following areas of interaction:

a) mutual broad-casting of neighbor cells

OsmoBSC + OsmoBTS have received SI2ter + SI2quater support quite some time ago, allowing to broadcast LTE neighbor cells from Osmocom networks. So I think this is done.

b) common HLR / HSS for subscriber data

In order to have one shared subscriber database between Osmocom and LTE, we would have to implement a so-called GSUP-to-DIAMETER IWf (inter-working function). This could go either of the two ways: * translating GSUP to DIAMETER and using a DIAMETER HSS such as that of nextepc [which is unfortunately the part about nextepc I like the least due to it's dependency to node.js], or * translating DIAMETER to GSUP and using OsmoHLR from a 4G network

Or, if somebody wants to do it properly, write a new HLR/HSS with proper separation between the database store and the protocol modules, which then would offer both GSUP and DIMETER (and/or possibly MAP). Would be great to see work or funding in that area, but I'm not seeing any.

c) circuit-switched fall-back, SMS-over-SGs

If your LTE network doesn't have/support IMS, or if you have phones that don't do VoLTE, then CSFB to 2G/3G is needed. For that, we'd have to add a SGS interface.

See http://osmocom.org/projects/osmomsc/wiki/SGs_Interface and http://osmocom.org/issues/2583

Is there currently any cooperation?

Unfortunately not. There is nobody contributing to Osmocom in any of the above-mentioned areas at this point, whether in terms of code or funding.

Or will there be some new and fresh LTE code in osmocom?

I don't think so. There's no point in re-inventing the wheel.

My priorities would be in the folloiwing order (highest prio first)

1) GSUP-to-DIAMETER gateway or a new HLR+HSS 2) SGs interface in OsmoMSC 3) GTPv2 support in OsmoGGSN, or test OsmoSSGN with ergw to keep PDP/EPS bearer alive during RAT changes

Regards, Harald