Any plan to fork OpenBTS and/or merge with Osmocom code?
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.
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 4/9/11 11:24 AM, Harald Welte wrote:
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? 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.
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...
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.
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.
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=histor.... 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.
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.
Hi again. On Sat, Apr 09, 2011 at 10:03:09PM +0200, Fabio Pietrosanti (naif) wrote:
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? 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.
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...
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 ;)
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?
Hi Harald, On Sun, Apr 10, 2011 at 12:35, Harald Welte <laforge@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
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@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?
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).
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.
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, On Sun, Apr 10, 2011 at 18:52, Harald Welte <laforge@gnumonks.org> wrote:
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@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?
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).
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.
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.
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
Same here. Thanks for clarification. -- Regards, Alexander Chemeris. http://www.fairwaves.ru
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbts-discuss
Hi Fabio,
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
Now we have two software BTS in developing phase, softBTS and osmoBTS, In A-bis side, both communicating with OpenBSC using ipaccess style A-bis over IP protocol. Probably difference would be in Um side. I am not considering Universal Software Radio Peripheral as hardware for softBTS, that mean no plans to use openBTS as bridge to USRP. fadil
participants (6)
-
Alexander Chemeris -
David A. Burgess -
Fabio Pietrosanti (naif) -
Fadil Berisha -
Harald Welte -
James Jordan