This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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)