9 Apr
2011
9 Apr
'11
8:37 a.m.
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.
Additionally, if i understood correctly osmocom is much more advanced
with broad scope and better design than OpenBTS.
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.
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.
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?
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.
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.
9 Apr
9 Apr
11:24 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:03 p.m.
On 4/9/11 11:24 AM, Harald Welte wrote:
Absolutely agree, that OpenBTS had very appreciable short term practical
goals, such as hooking a GSM phone to Asterisk.
While Osmocom had very long term goals, like making a overall set of
technologies and libraries usable to build a complete gsm systems, from
bsc to baseband, to network analyzer, to ggsn/sgsn, msc, hlr.
So imho current status of OpenBTS is near to stalled, without strong
opensource improvements.
While the current status of Osmocom is growing fast, differentiating
itself in various projects, doing important refactoring to create a
solid technology stack reusable for most projects.
So most of the community investments sounds to be directed to Osmocom.
Osmocom now it's missing a complete free hardware/software BTS (for
example based on USRP devices).
Given it's fast growing community we can forecast in the near future the
need to support also the GSMum on USRP devices?
Said that, mine is a suggestion to the OpenBTS team to rethink about the
future of their projects by directing work to integrate with OpenBSC,
empowering the strength of opensource technologies with the respect to
such a closed industry (the mobile industry).
But for sure, because i am not bringing a single euro to the project, i
am just running as a sort of advocacy troll that would like to see in
the world a *FULL* and *COMPLETE* opensource gsm technology stack.
Well, i just follow the mailing lists and see the code changelog on
http://openbts.git.sourceforge.net/git/gitweb.cgi?p=openbts/openbts;a=histo….
In the last 10 months there are relatively few changes only done by
Sylvain Munaut (mainly working on osmocom stuff as far as i read from
mlist) and by Alexander Chemeris (mainly working on the ClockTamer
hardware design for OpenBTS).
What i know is that several features are only available in commercial
version and those are the ones that enable OpenBTS to be used in a
real-environment (not just testing).
Those features for example are multi ARFCN and handover that are said to
be only in the commercial version:
http://sourceforge.net/mailarchive/message.php?msg_id=26792703
Those feature are already into OpenBSC:
- handover is in OpenBSC code http://laforge.gnumonks.org/weblog/2009/12/21/
- Multi ARFCN / Frequency Hopping is in OpenBSC code
http://lists.gnumonks.org/pipermail/openbsc/2010-June/001744.html
Eventually a light BTS implementation with the DSP logic integrated with
Soft-BTS/OpenBSC would already provide such kind of features, currently
available only in OpenBTS commercial implementation.
It would also much more easy to be able to see the possible future
integration of a GPRS/EDGE endpoint running at home with your own USRP1
with osmo-ggsn.
Mine it's just a a way to express that imho this approach maybe
represent a stopping issue in seeing really pratically usable opensource
gsm technologies, from the bts up to the ggsn passing trough a baseband
processor.
I think that it would create a lot more adopter of opensource gsm
telephony due to the reduction of entrance barrier (costs) of the hardware.
Only one piece of hardware of 1500 usd to play with it.
Hi Fabio,
On Sat, Apr 09, 2011 at 08:37:20AM +0200, Fabio Pietrosanti (naif) wrote:
I refer to TLC as "Telecommunication" that's the
environment and
industry segment where our so "friendly" mobile industry players apply
patent and NDA everywhere to restrict access to the technology.
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? 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... 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. 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.
For the reason explained below i personally think, but i am no-one to
affirm this, that the current approach maybe is not the right approach
as it's a stopping issue just slowly down what's inevitable and before
or later will happen.
In such case,typically, before or later there will be some other
opensource project or group that solve the need covered only the by
commercial code.
But that's something that happens before or later with almost any
opensource project of great value and interests.
I never had the time to finish this.
10 Apr
10 Apr
10:35 a.m.
Hi again.
On Sat, Apr 09, 2011 at 10:03:09PM +0200, Fabio Pietrosanti (naif) wrote:
Absolutely agree, that OpenBTS had very appreciable short term practical
goals, such as hooking a GSM phone to Asterisk.
it's not just a short-term goal, see David's response ;)
On Sat, Apr
09, 2011 at 08:37:20AM +0200, Fabio Pietrosanti (naif) wrote:
I refer to TLC as "Telecommunication" that's the
environment and
industry segment where our so "friendly" mobile industry players apply
patent and NDA everywhere to restrict access to the technology.
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?
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... While Osmocom had very long term goals, like making a
overall set of
technologies and libraries usable to build a complete gsm systems, from
bsc to baseband, to network analyzer, to ggsn/sgsn, msc, hlr.
Making a GSM network that can integrate with an IMS core network without
any of the usual components (bsc, sgsn, ...) is not a long-term goal?
So imho current status of OpenBTS is near to stalled,
without strong
opensource improvements.
While the current status of Osmocom is growing fast,
differentiating
itself in various projects, doing important refactoring to create a
solid technology stack reusable for most projects.
well, I would be careful regarding the 'solid' part. Large parts are
'proof of concept' or 'alpha' status at this time. The BSC is very
stable,
but if you look at the SGSN or the core network parts, it's entirely different
So most of the community investments sounds to be
directed to Osmocom.
Well, there is a community, but it is a small community, isn't it? Basically
Holger and myself on the BSC and core network side, and Sylvain and Andreas
doing the majority of the work on the telephone side. Pablo is sort of an
exceptional case, as he is doing paid work for me to do his cleanups and
improvements. Vance has generously donated his signerl code, for which I'm
grateful, but it was written a long time ago and never really 100% finished, so
we still have to do a lot of work finishing and integrating it with our other
code.
The truth is, I don't think there are significantly more people working on
Osmocom projects than on OpenBTS. Also, the comparison is odd, as you would
probably have to count only the network side projects (BSC, SGSN, ...) on
the Osmocom side.
Osmocom now it's missing a complete free
hardware/software BTS (for
example based on USRP devices).
Given it's fast growing community we can forecast in the near future the
need to support also the GSMum on USRP devices?
3:40 p.m.
New subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code?
Hi Harald,
On Sun, Apr 10, 2011 at 12:35, Harald Welte <laforge(a)gnumonks.org> wrote:
If you use the USRP hardware (or any other SDR
hardware), you cannot use
GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone.
Why do you think that USRP can't support GPRS/EDGE? Is it because of
USB latency?
And definitely there are SDR hardware which support GPRS/EDGE - it's
just more advanced and more integrated then USRP.
Multi-ARFCN: This is an aspect of the radio-modem. So
again, on the same
hardware any OpenBTS/OpenBSC integration will not change this.
Technically, USRP can support multi-ARFCN, but open-source version of
OpenBTS doesn't.
--
Regards,
Alexander Chemeris.
http://www.fairwaves.ru
4:52 p.m.
New subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code?
Hi Alexander,
On Sun, Apr 10, 2011 at 05:40:42PM +0400, Alexander Chemeris wrote:
On Sun, Apr 10, 2011 at 12:35, Harald Welte
<laforge(a)gnumonks.org> wrote:
no, that's not the point. The point is that you need to implement the CCU
and PCU, both of which are not present in OpenBTS.
So whether or not you combine OpenBTS with OpenBSC or run OpenBSC stand-alone,
it will always have the same features regarding GPRS (or not).
If you use the USRP hardware (or any other SDR
hardware), you cannot use
GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone.
Why do you think that USRP can't support GPRS/EDGE? Is it because of
USB latency? And definitely there are SDR hardware which support
GPRS/EDGE - it's
just more advanced and more integrated then USRP.
yes. But whether or not you combine OpenBTS with OpenBSC or run OpenBSC
stand-alone, it will always have the same features regarding multi-arfcn
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Multi-ARFCN: This is an aspect of the
radio-modem. So again, on the same
hardware any OpenBTS/OpenBSC integration will not change this.
Technically, USRP can support multi-ARFCN, but open-source version of
OpenBTS doesn't.
11 Apr
11 Apr
11 a.m.
New subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code?
Hi Harald,
On Sun, Apr 10, 2011 at 18:52, Harald Welte <laforge(a)gnumonks.org> wrote:
Same here.
Thanks for clarification.
--
Regards,
Alexander Chemeris.
http://www.fairwaves.ru
Hi Alexander,
On Sun, Apr 10, 2011 at 05:40:42PM +0400, Alexander Chemeris wrote:
Ok, I see your point now.
You used words "USRP and other SDR hardware" here and that's what
confused me, because hardware can support this feature. It's OpenBTS
software limitation, not hardware limitation.
On Sun, Apr 10, 2011 at 12:35, Harald Welte
<laforge(a)gnumonks.org> wrote:
no, that's not the point. The point is that you need to implement the CCU
and PCU, both of which are not present in OpenBTS.
So whether or not you combine OpenBTS with OpenBSC or run OpenBSC stand-alone,
it will always have the same features regarding GPRS (or not). If you use the USRP hardware (or any other SDR
hardware), you cannot use
GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone.
Why do you think that USRP can't support GPRS/EDGE? Is it because of
USB latency? And definitely
there are SDR hardware which support GPRS/EDGE - it's
just more advanced and more integrated then USRP.
yes. But whether or not you combine OpenBTS with OpenBSC or run OpenBSC
stand-alone, it will always have the same features regarding multi-arfcn Multi-ARFCN: This is an aspect of the
radio-modem. So again, on the same
hardware any OpenBTS/OpenBSC integration will not change this.
Technically, USRP can support multi-ARFCN, but open-source version of
OpenBTS doesn't.
7:18 p.m.
Hi Fabio,
I would just like to add:
On Sun, Apr 10, 2011 at 10:35:53AM +0200, Harald Welte wrote:
Well, there is a community, but it is a small
community, isn't it? Basically
Holger and myself on the BSC and core network side, and Sylvain and Andreas
doing the majority of the work on the telephone side. Pablo is sort of an
exceptional case, as he is doing paid work for me to do his cleanups and
improvements. Vance has generously donated his signerl code, for which I'm
grateful, but it was written a long time ago and never really 100% finished, so
we still have to do a lot of work finishing and integrating it with our other
code.
Please let me note that the 'community' is quite a bit larger, I did not want
to ignore anyone. I was referring to those developers who actively write
substantial parts of the codebase - those are unfortunately few, so my comment
remains:
The truth is, I don't think there are
significantly more people working on
Osmocom projects than on OpenBTS. Also, the comparison is odd, as you would
probably have to count only the network side projects (BSC, SGSN, ...) on
the Osmocom side.
Also, another comment is that most current network-side GSM development is
the result of paid work, at least in the case of Holger and me.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10 Apr
10 Apr
7:33 a.m.
New subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code?
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
11 Apr
11 Apr
3:39 a.m.
New subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code?
Fabio,
I don't think openbts and Osmocom should be integrated together.
If you want to integrated them the source is there.
I don't think there is any wrong in Commercial version. Openbts is the
inteligient property
to their owner. there is nothing wrong even the source is totally not open.
Can anyone get the approve by the government to build truely free gsm
network?
On Sat, Apr 9, 2011 at 2:37 PM, Fabio Pietrosanti (naif) <
lists(a)infosecurity.ch> 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.
Additionally, if i understood correctly osmocom is much more advanced
with broad scope and better design than OpenBTS.
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.
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.
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?
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.
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.
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Openbts-discuss mailing list
Openbts-discuss(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbts-discuss
5198
days inactive
5200
days old
baseband-devel@lists.osmocom.org
9 comments
5 participants
participants (5)
-
Alexander Chemeris -
David A. Burgess -
Fabio Pietrosanti (naif) -
Harald Welte -
James Jordan