4G / LTE and osmocom

historical

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

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)