Fabio -
On Apr 8, 2011, at 11:37 PM, Fabio Pietrosanti (naif) wrote:
Hi all,
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.
As we know currently there are several different projects growing into
the GSM (then tetra and in future 3G?) opensource ecosystem.
The first "pratical" base has been OpenBTS as a simplified GSM um
interface for VoIP.
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.
I think OpenBTS and openbsc were released at very nearly the same time, although neither
was aware of the other at the time.
Additionally, if i understood correctly osmocom is much more advanced
with broad scope and better design than OpenBTS.
That depends a great deal on what you are trying to achieve. The two projects are very
different in their goals and their implementation approaches. For many applications, the
removal of the GSM core network is a great advantage. Also, the OpenBTS approach has more
in common with 4G IMS than with 2G legacy networks, so I'm not sure what you mean by
"more advanced".
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 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.
We created a commercial fork because we've found that a pure dual-license/non-forked
approach is not commercially viable in many of the markets where OpenBTS is being used.
(In fact nearly all of the current public GSM code was written or paid for by just two
people. We have since replaced or relicensed any previous GPL components in the SDR and
GSM stack, allowing us to fork and license OpenBTS however we wish.)
There are several reasons for the decision to fork, including government indemnifications
for copyright violations by government contractors, suspected violations by commercial
interests in inaccessible jurisdictions and specific contractual requirements from project
funders to not make a public release of their features. I still personally fully support
the GPL and would have preferred a pure dual-license approach, however it simply was not
working for the project. The pure public release model was not generating enough income
to justify our work and we've found that it was incompatible with our long-term
business plan, which is to sell complete GSM/VoIP networks, hardware and software, to
commercial customers. Our goal is to provide GSM capabilities with carrier-grade quality
to as many people as possible. The amount of our time and money we've invested into
the project would surprise most of you and the risks associated with it, professional,
personal and financial, have been significant.
All that said, we are committed to continue to support the public release of OpenBTS. I
would also like to see it become more of a true "community" effort, rather than
a small set of people giving their work away to everyone else for free. I realize that
will require more active leadership than what has been typical so far. We are committed
to organizing the public side of the project and we will are happy to answer any questions
clarifying the relationship between the public and commercial releases.
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.
It would not be difficult to replace most of the OpenBTS control layer with an Abis
interface. As Harald Welte described in his own response to this message, we have
considered this before, Harald and I have discussed it, and Harald has even done some work
in that direction.
For what i read now Osmocom have 2 software BTS
(Osmo-BTS and Soft-BTS),
communicating with the A-BIS over IP interface to OpenBSC:
http://lists.gnumonks.org/pipermail/openbsc/2011-March/002529.html
http://lists.gnumonks.org/pipermail/openbsc/2010-April/001508.html
I've read that only a lot of time ago (2009) there was a discussion
about OpenBTS to OpenBSC integration:
http://lists.gnumonks.org/pipermail/openbsc/2009-October/000955.html
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?
From the OpenBTS point of view, Abis is interesting only as a mechanism to integrate
OpenBTS units into a "legacy" GSM network, and even then only in odd
circumstances where other integration methods are not applicable. It is not a preferred
mode of operation and thus we do not see the current lack of Abis as a serious
shortcoming or design flaw. (In fact, the lack of Abis was a deliberate design decision.
Part of the point of OpenBTS was to eliminate many of the things that openbsc is
building.)
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.
I don't know how well these projects would merge together. The implementation styles
are very different. It would also be difficult to find someone to manage such a thing,
especially since none of the lead developers on either project seems to have interest in
doing that.
Am i right?
-naif
p.s. Sorry for the cross-posting, i just wanted to explain the idea and
get the communities feedbacks to understand 'at which point' we are in
order to think 'what would be required to be done' to achieve that goal.
Well, I just cross-posted my reply. So there. :P
-- David