Hi Fabio, On Sat, Apr 09, 2011 at 08:37:20AM +0200, Fabio Pietrosanti (naif) wrote: Sorry, what is TLC? well, the Um interface has not been simplified. But the entire fixed-part of the traditional GSM network has been simplified. true. 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. I cannot comment on that, as I don't follow the speed of progress in OpenBTS. 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. 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. It's not really complex, it just needs engineering time. 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)

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&gt; wrote: