Any plan to fork OpenBTS and/or merge with Osmocom code?

Harald Welte laforge at gnumonks.org
Sat Apr 9 09:24:56 UTC 2011


Hi Fabio,

On Sat, Apr 09, 2011 at 08:37:20AM +0200, Fabio Pietrosanti (naif) wrote:

> this email don't want to be a provocative email but just an opinion
> related to the creation of value for GSM TLC stack into the opensource
> environment.

Sorry, what is TLC?

> The first "pratical" base has been OpenBTS as a simplified GSM um
> interface for VoIP.

well, the Um interface has not been simplified.  But the entire fixed-part
of the traditional GSM network has been simplified.

> The second major implementations was around the osmocom project that
> build-up a complete and well designed GSM stack with all the modular
> interfaces and protocols for communications between BTS and BSC, with
> MSC, HLR, GGSN, SGSN and major GSM network components.

true.

> Additionally, if i understood correctly osmocom is much more advanced
> with broad scope and better design than OpenBTS.

I think it is unfair.  There are many design decisions, and I don't think
you can say something is better or worse.  It depends on your purpose.  Do
you want a sports car or a truck?  Depends on your application which one
is better...

Also with regard to scope, I think there is not too much difference.  Sure,
the OpenBTS initial focus was on the SDR radiomodem and the actual BTS, while
we have been working more on the RAN and now core network parts.  but in the
end, I guess both projects strive for being able to provide a full gsm network
with telephony, sms and data - either stand-alone, as a PBX or interacting
with real international GSM networks at various interfaces.

> It seems to me that OpenBTS it's almost stalled due to the "commercial
> fork" of the OpenSource project and only fairwaves is contributing to
> the opensource branch.

I cannot comment on that, as I don't follow the speed of progress in OpenBTS.

> I personally really dislike the "Commercial fork" approach where the
> community is used only in the early phase of the project to improve it
> and from a certain point the community doesn't get almost any added value.
> I like much more the dual-licensed approach like AGPL/Commercial (like
> http://pjsip.org) where all the value of the code is publicly released.

I personally agree, but you have to let the project owners / copyright holders
decide on that.  They wrote the vast majority of the code, and they get
to say what happens on the licensing side.

But yes, there have been really bad examples of this model before, my
personal "negative favorite" is what happened to GNU Zebra after it was
commercialized and the successive Quagga fork.  I guess today nobody is
using the abandoned zebra code base, and everyone uses Quagga.

Having said that, I am certain this development/licnesing model can work
properly, with satisfaction to both community and commercial interests.
However, a lot of care and attention has to be paid on it.

In any case, I don't think you should confuse your dislike for that licensing
model with a potential combination of OpenBSC and OpenBTS.  That latter
combination does not require a fork, is not seen as 'aggressive' but is
rather a very complimentary approach - for those operators who have legacy
GSM infrastructure.  See below.

> However, my post was related to a question:
> 
> - How complex would be, leveraging existing public OpenBTS code, to
> integrate into the Osmocom project?
>
> I mean, having a sort of lightweight BTS component speaking A-Bis over
> IP to OpenBSC like the cheap nano ip.access BTS does.

We have been talking for quite some time about adding an A-bis interface
to OpenBTS in order to combine it with OpenBSC.  This is complementary,
and of benefit to both projects.  For OpenBSC it means we can not only
run with expensive, proprietary BTS vendors but with a Free Software SDR
based solution.

As for OpenBTS, it means that they might be considered as a RAN provider
by GSM operators with legacy equipment.  OpenBSC in turn can talk the A
interface to a legacy MSC.  David Burgess has indicated that they are very
much interested in this, for _some_ of their users.  It's an alternative,
and the main focus for them will likely (and logically) be the VoIP approach.

I first attempted to move into that direction during the OpenBTS workshop
where I called it 'TrueBTS'.  The result was: It's doable, and the layering
separation between LAPDm and L3(RR/CC/MM) makes it pretty easy to remove
the SIP / L3 part and leave what is left.  The only place where actual code
changes had to be made was the command interface of OpenBTS, since it references
all parts of the code, and was not modular like the rest of OpenBTS.

I never had the time to finish this.

Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation
for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a
simplistic BTS), and I have started to split that code out into a separate
repository at http://cgit.osmocom.org/cgit/osmo-bts/

This code should eventually be used with the OpenBTS, and potentially other
BTS types, too.

> At the current stage of development (2011), with Osmocom finally getting
> a Software-BTS part communicating to the Software-BSC side, how really
> complex it would be to integrate the GSM-um related part of OpenBTS into
> the project?

It's not really complex, it just needs engineering time.  

> With that approach the 'GSM-um' interface would be a very simplified
> module of the overall system and osmocom would completely replace
> OpenBTS all-in-one project.

This is where I don't get you. All that needs to be removed is the L3-to-SIP
bridge.  It doesn't make the vast majority of OpenBTS code disappear,
and it does not render that latter part useless.  A full-blown GSM network with
all its components brings a lot of complexity.   The stand-alone OpenBTS is
much more simple.   And why would you want all the complexity if you don't
need to interoperate with legacy GSM?

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)




More information about the baseband-devel mailing list