Hello everyone,
I just want to ask, if there is a general interest in operating a licensed GSM-Network at the chaos congress. Is there anything planned for 26c3 (openBSC desk etc.)? Maybe there is a good chance to get a temp. license for the 900 GSM band from BNetzA.
I had little time in the past year to work on openBSC, but in the coming months there will be more time for fun ;)
Best regards Bjoern
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Björn Heller Jabber: tec@jabber.hellercom.de
On Tue, Oct 06, 2009 at 09:29:45AM +0200, Bjoern Heller wrote:
I just want to ask, if there is a general interest in operating a licensed GSM-Network at the chaos congress. Is there anything planned for 26c3 (openBSC desk etc.)?
yes, we're planning to operate something like 3 bts with a total of 5 trx in GSM 1800 and connection to the DECT phone network of eventphone.
This is why Andreas Eversberg is currently workin on the nanoBTS / RTP integration with lcr.
Maybe there is a good chance to get a temp. license for the 900 GSM band from BNetzA.
impossible for 900MHz. All frequencies are commercially licensed to the GSM operators.
I've finally prepared the license application yesterday and will send it off later today. The CCC will be the applicant of that license.
Regards.
Hi Harald,
We're thinking about bringing one or two USRPs configured to run OpenBTS. We'll be interested in testing the setup in real life and interconnecting them with your OpenBSC setup - I think it should be possible with Asterisk.
On Tue, Oct 6, 2009 at 14:19, Harald Welte laforge@gnumonks.org wrote:
On Tue, Oct 06, 2009 at 09:29:45AM +0200, Bjoern Heller wrote:
I just want to ask, if there is a general interest in operating a licensed GSM-Network at the chaos congress. Is there anything planned for 26c3 (openBSC desk etc.)?
yes, we're planning to operate something like 3 bts with a total of 5 trx in GSM 1800 and connection to the DECT phone network of eventphone.
This is why Andreas Eversberg is currently workin on the nanoBTS / RTP integration with lcr.
Maybe there is a good chance to get a temp. license for the 900 GSM band from BNetzA.
impossible for 900MHz. All frequencies are commercially licensed to the GSM operators.
I've finally prepared the license application yesterday and will send it off later today. The CCC will be the applicant of that license.
Regards.
- 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 Alexander,
On Tue, Oct 06, 2009 at 08:36:04PM +0400, Alexander Chemeris wrote:
We're thinking about bringing one or two USRPs configured to run OpenBTS. We'll be interested in testing the setup in real life and interconnecting them with your OpenBSC setup - I think it should be possible with Asterisk.
I don't think we have a particular interest in interconnecting those two, as our resources are typically _extremely_ stressed, and we would rather not reconfigure the installation while it is running. It will already be very hard to do what we currently have on the agenda. I don't really see what would be gained from routing voice data over voip between OpenBTS and OpenBSC.
What would be an interesting project is to reuse the OpenBTS transceiver code (but not the layer3 protocol stack + sip gateway) and add a BTS-side A-bis implementation, turning OpenBTS into a real BTS that can connect to OpenBSC through A-bis. If there's anyone volunteering to get that work started, I'd be willing to experiment with it at 26C3. But that also not on the actual production/live setup, but on a second OpenBSC instance.
Regards,
Hi Harald,
On Wed, Oct 7, 2009 at 10:19, Harald Welte laforge@gnumonks.org wrote:
On Tue, Oct 06, 2009 at 08:36:04PM +0400, Alexander Chemeris wrote:
We're thinking about bringing one or two USRPs configured to run OpenBTS. We'll be interested in testing the setup in real life and interconnecting them with your OpenBSC setup - I think it should be possible with Asterisk.
I don't think we have a particular interest in interconnecting those two, as our resources are typically _extremely_ stressed, and we would rather not reconfigure the installation while it is running. It will already be very hard to do what we currently have on the agenda. I don't really see what would be gained from routing voice data over voip between OpenBTS and OpenBSC.
What would be an interesting project is to reuse the OpenBTS transceiver code (but not the layer3 protocol stack + sip gateway) and add a BTS-side A-bis implementation, turning OpenBTS into a real BTS that can connect to OpenBSC through A-bis. If there's anyone volunteering to get that work started, I'd be willing to experiment with it at 26C3. But that also not on the actual production/live setup, but on a second OpenBSC instance.
We see this from different points of view. :) We're interested to show possible ways of OpenBTS interoperability with more conventional BTSes like ones OpenBSC use and evaluate problems which will arise there. But we want to show this with "flat IP" network instead of burdening OpenBTS with A-bis interface. I believe in the positive impact of OpenBTS and OpenBSC interoperability for the both communities and as encouraging factor for possible future OpenBTS test sites.
We're ready to work with you beforehand to minimize on-site efforts.
PS Where can we find agenda? Official 26C3 site is nearly empty.
We see this from different points of view. :) We're interested to show possible ways of OpenBTS interoperability with more conventional BTSes like ones OpenBSC use and evaluate problems which will arise there. But we want to show this with "flat IP" network instead of burdening OpenBTS with A-bis interface.
There is A-bis over IP of course :)
Because just connecting them with asterisk just proves asterisk works, you still have two independent GSM network. A better integration would allow roaming between an openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool.
Now that can be done either by OpenBTS having a Abis-over-IP IF (much like the nanoBTS), or by implementing inter-msc roaming in both (I think, didn't check deeper).
I must admit I don't personally think it's ideal to have the BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's pretty common in opensource to have several project 'doing the same thing' and it usually helps innovation and such but in this case there aren't thousands of developers with good GSM knowledge ... OTOH, OpenBTS and OpenBSC have made some choice that don't make a seamless reuse of code trivial (C vs C++, single vs multi thread). The licenses are compatible that's a start :) (v2 or later vs v3)
Anyway, just my 2cents.
Sylvain
Hi Sylvain and others,
On Wed, Oct 07, 2009 at 02:09:14PM +0000, 246tnt@gmail.com wrote:
We see this from different points of view. :) We're interested to show possible ways of OpenBTS interoperability with more conventional BTSes like ones OpenBSC use and evaluate problems which will arise there. But we want to show this with "flat IP" network instead of burdening OpenBTS with A-bis interface.
There is A-bis over IP of course :)
Because just connecting them with asterisk just proves asterisk works, you still have two independent GSM network.
I agree. Showing that you can make a call from OpenBTS through asterisk through asterisk (through lcr) through openbsc to a nanobts doesn't really say anything about a GSM level of interaction. you're simply testing whether one asterisk can talk voip to the other asterisk.
There is no GSM protocol level interaction between those two networks, so you would have no way for handover, or things like sending sms from one network to the other.
A better integration would allow roaming between an openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool.
Indeed!
Now that can be done either by OpenBTS having a Abis-over-IP IF (much like the nanoBTS), or by implementing inter-msc roaming in both (I think, didn't check deeper).
yes, both ways should work. To me, Abis-over-IP would make a lot of sense. Why not reuse the existing transceiver code and the code that we already have for the BSC side of A-bis (like TLV parser, lots of utility functions, etc.) to turn the USRP into a true BTS.
Having a BTS side A-bis implementation would also help us with my other dream: A virtual/simulated BTS. This BTS would not talk to an actual RF layer, but it would simply use something like mac-blocks or gsm bursts with GSMTAP header over multicase UDP/IP. It would allow us to further work on a MS side layer 2+3 stack, without even having to touch the actual radio interface.
That, in turn, would allow us to do 90% of a GSM phone without having a full RF / layer 1 implementation. Also, it would allow us to do regression and load testing of OpenBSC without any real phone or even real BTS.
So far my "if I only had the time" plan.
I must admit I don't personally think it's ideal to have the BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's pretty common in opensource to have several project 'doing the same thing' and it usually helps innovation and such but in this case there aren't thousands of developers with good GSM knowledge ...
yes, but I would never have the knowledge (and neither would e.g. Holger have his), if we didn't actually do the implementation.
OTOH, OpenBTS and OpenBSC have made some choice that don't make a seamless reuse of code trivial (C vs C++, single vs multi thread).
Also, the intended purpose is quite different. OpenBSC is about playing with higher level GSM protocols, research and analysis. To some people it also serves as a cheap minimal BSC to work with proprietary BTS, which is fine.
OpenBTS is about creating an as thin as possible gateway between the Um interface and SIP. They don't want to run a BTS program, a BSC program, a MSC program, a SIP proxy program, a SMSC program and then configure each of those programs individually.
Which is why I think a modular approach makes sense. We're already splitting BSC and MSC functionality inside the OpenBSC project. If somebody finds the time to introduce some kind of API between layer 2 and layer 3 of OpenBTS, then that would be the ideal case. People who want to use OpenBTS standalone can continue to do so, while people who want to put a BTS-Side A-bis on top (and use with proprietary BSC or OpenBSC) can also do that.
I haven't spoken about this with David so far, since I didn't have the time to actually do the implementation. But I believe as long as the changes are not intrusive and OpenBTS doesn't loose features / stability or performance, I wouldn't expect much objection to it.
The licenses are compatible that's a start :) (v2 or later vs v3)
You may be missing the fact that (I believe) Kestrel might be interested in doing dual licensing on OpenBTS. However, thinking more about this, it seems unlikely since the copyright is now with the FSF.
Harald, Alexander, Sylvain, others -
I should probably speak up here at some point.
On Oct 7, 2009, at 8:35 AM, Harald Welte wrote:
Hi Sylvain and others,
On Wed, Oct 07, 2009 at 02:09:14PM +0000, 246tnt@gmail.com wrote:
We see this from different points of view. :) We're interested to show possible ways of OpenBTS interoperability with more conventional BTSes like ones OpenBSC use and evaluate problems which will arise there. But we want to show this with "flat IP" network instead of burdening OpenBTS with A-bis interface.
There is A-bis over IP of course :)
That doesn't count.
Because just connecting them with asterisk just proves asterisk works, you still have two independent GSM network.
I agree. Showing that you can make a call from OpenBTS through asterisk through asterisk (through lcr) through openbsc to a nanobts doesn't really say anything about a GSM level of interaction. you're simply testing whether one asterisk can talk voip to the other asterisk.
There is no GSM protocol level interaction between those two networks, so you would have no way for handover, or things like sending sms from one network to the other.
True. If you could just share registration information, you could have mobility among the cells, but OpenBTS does not yet support handovers of active calls.
We can send SMS, though, if you support RFC-3428. (We even tested that interface with Voxbone's messaging gateway.)
A better integration would allow roaming between an openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool.
Indeed!
Yes, and that would not be too hard if we could share an HLR function.
Now that can be done either by OpenBTS having a Abis-over-IP IF (much like the nanoBTS), or by implementing inter-msc roaming in both (I think, didn't check deeper).
yes, both ways should work. To me, Abis-over-IP would make a lot of sense. Why not reuse the existing transceiver code and the code that we already have for the BSC side of A-bis (like TLV parser, lots of utility functions, etc.) to turn the USRP into a true BTS.
Having a BTS side A-bis implementation would also help us with my other dream: A virtual/simulated BTS. This BTS would not talk to an actual RF layer, but it would simply use something like mac-blocks or gsm bursts with GSMTAP header over multicase UDP/IP. It would allow us to further work on a MS side layer 2+3 stack, without even having to touch the actual radio interface.
That, in turn, would allow us to do 90% of a GSM phone without having a full RF / layer 1 implementation. Also, it would allow us to do regression and load testing of OpenBSC without any real phone or even real BTS.
So far my "if I only had the time" plan.
From a testing standpoint, I can see value in putting an Abis interface on OpenBTS, but it's not a high priority for us, either.
I must admit I don't personally think it's ideal to have the BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's pretty common in opensource to have several project 'doing the same thing' and it usually helps innovation and such but in this case there aren't thousands of developers with good GSM knowledge ...
yes, but I would never have the knowledge (and neither would e.g. Holger have his), if we didn't actually do the implementation.
Same here. You don't really understand it until you actually do it.
OTOH, OpenBTS and OpenBSC have made some choice that don't make a seamless reuse of code trivial (C vs C++, single vs multi thread).
Also, the intended purpose is quite different. OpenBSC is about playing with higher level GSM protocols, research and analysis. To some people it also serves as a cheap minimal BSC to work with proprietary BTS, which is fine.
OpenBTS is about creating an as thin as possible gateway between the Um interface and SIP. They don't want to run a BTS program, a BSC program, a MSC program, a SIP proxy program, a SMSC program and then configure each of those programs individually.
Yes. We can learn a lot from each other and face a lot of similar technical problems, but our goals and implementation styles are very different.
However, our design approach *is* to keep everything above L3 in outside applications. Our L3 is just a collection of gateway functions between the ISDN world and the IETF world. Everything else is done with outside applications over IP interfaces. Our SIP-based SMSC replacement is a separate application. Our SIP-based PBX is a separate application. Our HLR replacement is also an outside application, although for now it is just Asterisk's SIP registry.
Something I think could be useful, and would allow a lot of interoperability, would be to have a common HLR/VLR replacement. The Asterisk SIP registry doesn't meet our long-term requirements and so we need to develop one anyway. If we can agree on an interface and an implementation, we could do something here.
Which is why I think a modular approach makes sense. We're already splitting BSC and MSC functionality inside the OpenBSC project. If somebody finds the time to introduce some kind of API between layer 2 and layer 3 of OpenBTS, then that would be the ideal case. People who want to use OpenBTS standalone can continue to do so, while people who want to put a BTS-Side A- bis on top (and use with proprietary BSC or OpenBSC) can also do that.
That kind of API should be easy. OpenBTS follows a data-flow design. At the top of L2, every channel is just a pair of FIFOs (up/ down) of L3 message objects. It should be easy to funnel all of that through some kind of Abis adapter.
I haven't spoken about this with David so far, since I didn't have the time to actually do the implementation. But I believe as long as the changes are not intrusive and OpenBTS doesn't loose features / stability or performance, I wouldn't expect much objection to it.
No objection, but there will be questions about licensing. To date, there are very few outside contributions in the OpenBTS distribution, maybe a few dozen lines out of ~12k. The FSF copyright assignment gives us the flexibility to distribute a non-GPL release if we want. Given GPLv3's treatment of patent licenses, that will be very desirable for some users, even if the actual code is identical to what we release under GPL. It also give us the opportunity to charge licensing fees and royalties for use of OpenBTS in commercial products, a plan for which we make no apology. ("Free as in freedom, not free beer.") We have no problem with sharing royalties with contributors, but our business plan requires that we preserve licensing flexibility, and so we would need to have formal agreements with any significant contributors if we were to actually use their contributions. Admittedly, this creates a tension in the open source project, a tension that we are still learning to manage, especially since the lifting of the injunction has removed the biggest barrier to participation.
I would very much look forward to discussing this face to face. Maybe we'll get a chance next month.
The licenses are compatible that's a start :) (v2 or later vs v3)
You may be missing the fact that (I believe) Kestrel might be interested in doing dual licensing on OpenBTS. However, thinking more about this, it seems unlikely since the copyright is now with the FSF.
See above. The FSF granted us back a blanket license. We can do anything we want *except* stop the FSF from distributing it under GPL. The text of the agreement says we can use the code "in any why [we] see fit". Period.
Also, since OpenBTS puts different functions in different applications, we can license those components differently, so the final application suite may be used commercially under a mix of GPL and non-GPL licenses.
--
- 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)
David A. Burgess Kestrel Signal Processing, Inc.
Hi all,
I will answer to David's e-mail, because I'm mostly agree with him on tech questions.
On Wed, Oct 7, 2009 at 20:54, David Burgess dburgess@kestrelsp.com wrote:
Harald, Alexander, Sylvain, others -
I should probably speak up here at some point.
On Oct 7, 2009, at 8:35 AM, Harald Welte wrote:
Hi Sylvain and others,
On Wed, Oct 07, 2009 at 02:09:14PM +0000, 246tnt@gmail.com wrote:
We see this from different points of view. :) We're interested to show possible ways of OpenBTS interoperability with more conventional BTSes like ones OpenBSC use and evaluate problems which will arise there. But we want to show this with "flat IP" network instead of burdening OpenBTS with A-bis interface.
There is A-bis over IP of course :)
That doesn't count.
Right, that's not what I meant by "flat". A-bis over IP is a tunneling rather then real network.
Because just connecting them with asterisk just proves asterisk works, you still have two independent GSM network.
I agree. Showing that you can make a call from OpenBTS through asterisk through asterisk (through lcr) through openbsc to a nanobts doesn't really say anything about a GSM level of interaction. you're simply testing whether one asterisk can talk voip to the other asterisk.
There is no GSM protocol level interaction between those two networks, so you would have no way for handover, or things like sending sms from one network to the other.
True. If you could just share registration information, you could have mobility among the cells, but OpenBTS does not yet support handovers of active calls.
We can send SMS, though, if you support RFC-3428. (We even tested that interface with Voxbone's messaging gateway.)
That was what I had in mind too. 1) We should share the same HLR and then it won't be two separate networks with "roaming". And this makes sense, and is the first target to work on. 2) For SMS we can interoperate if we had a gateway between SIP/SIMPLE and OpenBSC's SMSC (not sure what does OpenBSC use for SMSC? Do you plan to support SMPP or such?). That'll be nice, but that's obviously not the top priority.
Could we work on HLR interoperability and try to test it at 26C3?
A better integration would allow roaming between an openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool.
Indeed!
Yes, and that would not be too hard if we could share an HLR function.
Now that can be done either by OpenBTS having a Abis-over-IP IF (much like the nanoBTS), or by implementing inter-msc roaming in both (I think, didn't check deeper).
yes, both ways should work. To me, Abis-over-IP would make a lot of sense. Why not reuse the existing transceiver code and the code that we already have for the BSC side of A-bis (like TLV parser, lots of utility functions, etc.) to turn the USRP into a true BTS.
Having a BTS side A-bis implementation would also help us with my other dream: A virtual/simulated BTS. This BTS would not talk to an actual RF layer, but it would simply use something like mac-blocks or gsm bursts with GSMTAP header over multicase UDP/IP. It would allow us to further work on a MS side layer 2+3 stack, without even having to touch the actual radio interface.
That, in turn, would allow us to do 90% of a GSM phone without having a full RF / layer 1 implementation. Also, it would allow us to do regression and load testing of OpenBSC without any real phone or even real BTS.
So far my "if I only had the time" plan.
From a testing standpoint, I can see value in putting an Abis interface on OpenBTS, but it's not a high priority for us, either.
I must admit I don't personally think it's ideal to have the BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's pretty common in opensource to have several project 'doing the same thing' and it usually helps innovation and such but in this case there aren't thousands of developers with good GSM knowledge ...
yes, but I would never have the knowledge (and neither would e.g. Holger have his), if we didn't actually do the implementation.
Same here. You don't really understand it until you actually do it.
OTOH, OpenBTS and OpenBSC have made some choice that don't make a seamless reuse of code trivial (C vs C++, single vs multi thread).
Also, the intended purpose is quite different. OpenBSC is about playing with higher level GSM protocols, research and analysis. To some people it also serves as a cheap minimal BSC to work with proprietary BTS, which is fine.
OpenBTS is about creating an as thin as possible gateway between the Um interface and SIP. They don't want to run a BTS program, a BSC program, a MSC program, a SIP proxy program, a SMSC program and then configure each of those programs individually.
Yes. We can learn a lot from each other and face a lot of similar technical problems, but our goals and implementation styles are very different.
However, our design approach *is* to keep everything above L3 in outside applications. Our L3 is just a collection of gateway functions between the ISDN world and the IETF world. Everything else is done with outside applications over IP interfaces. Our SIP-based SMSC replacement is a separate application. Our SIP-based PBX is a separate application. Our HLR replacement is also an outside application, although for now it is just Asterisk's SIP registry.
Something I think could be useful, and would allow a lot of interoperability, would be to have a common HLR/VLR replacement. The Asterisk SIP registry doesn't meet our long-term requirements and so we need to develop one anyway. If we can agree on an interface and an implementation, we could do something here.
I second this. See above.
Which is why I think a modular approach makes sense. We're already splitting BSC and MSC functionality inside the OpenBSC project. If somebody finds the time to introduce some kind of API between layer 2 and layer 3 of OpenBTS, then that would be the ideal case. People who want to use OpenBTS standalone can continue to do so, while people who want to put a BTS-Side A-bis on top (and use with proprietary BSC or OpenBSC) can also do that.
That kind of API should be easy. OpenBTS follows a data-flow design. At the top of L2, every channel is just a pair of FIFOs (up/down) of L3 message objects. It should be easy to funnel all of that through some kind of Abis adapter.
I haven't spoken about this with David so far, since I didn't have the time to actually do the implementation. But I believe as long as the changes are not intrusive and OpenBTS doesn't loose features / stability or performance, I wouldn't expect much objection to it.
No objection, but there will be questions about licensing. To date, there are very few outside contributions in the OpenBTS distribution, maybe a few dozen lines out of ~12k. The FSF copyright assignment gives us the flexibility to distribute a non-GPL release if we want. Given GPLv3's treatment of patent licenses, that will be very desirable for some users, even if the actual code is identical to what we release under GPL. It also give us the opportunity to charge licensing fees and royalties for use of OpenBTS in commercial products, a plan for which we make no apology. ("Free as in freedom, not free beer.") We have no problem with sharing royalties with contributors, but our business plan requires that we preserve licensing flexibility, and so we would need to have formal agreements with any significant contributors if we were to actually use their contributions. Admittedly, this creates a tension in the open source project, a tension that we are still learning to manage, especially since the lifting of the injunction has removed the biggest barrier to participation.
I would very much look forward to discussing this face to face. Maybe we'll get a chance next month.
I strongly believe and has spoken several times, that something there must be changed - current situation is simply discouraging both users and potential developers.
My points are: 1) Main svn must be open and all non-funded development should be done there, so everyone will be able to get latest bugfixes and not wait months while David and Harvind have no time and desire to publish them. 2) Funded development may go in a private branch (Mercurial or git helps here a lot) and will be published when needed. Having that OpenBTS architecture will be more and more stable as time passes, changed will be pretty non-intrusive.
re: sharing royalties with contributors That's great, but how do you plan to measure how much each contributor should gain? Should one, contributed 120 lines receive 120/12K part of royalties? But what if these 12 lines where a critical fix or an important feature?
The licenses are compatible that's a start :) (v2 or later vs v3)
You may be missing the fact that (I believe) Kestrel might be interested in doing dual licensing on OpenBTS. However, thinking more about this, it seems unlikely since the copyright is now with the FSF.
See above. The FSF granted us back a blanket license. We can do anything we want *except* stop the FSF from distributing it under GPL. The text of the agreement says we can use the code "in any why [we] see fit". Period.
Also, since OpenBTS puts different functions in different applications, we can license those components differently, so the final application suite may be used commercially under a mix of GPL and non-GPL licenses.
That's an interesting way. But won't this GPL parts have the same problems with the patents as main OpenBTS core?
Hi David,
On Wed, Oct 07, 2009 at 09:54:53AM -0700, David Burgess wrote:
There is A-bis over IP of course :)
That doesn't count.
well, that would be what I'd implement if I was to write a BTS-side Abis implementation that would like to OpenBTS' transceiver + LAPDm code.
That, in turn, would allow us to do 90% of a GSM phone without having a full RF / layer 1 implementation. Also, it would allow us to do regression and load testing of OpenBSC without any real phone or even real BTS.
So far my "if I only had the time" plan.
From a testing standpoint, I can see value in putting an Abis interface on OpenBTS, but it's not a high priority for us, either.
of course, I never assumed it was any of your priorities at all..
However, our design approach *is* to keep everything above L3 in outside applications. Our L3 is just a collection of gateway functions between the ISDN world and the IETF world. Everything else is done with outside applications over IP interfaces. Our SIP-based SMSC replacement is a separate application. Our SIP-based PBX is a separate application. Our HLR replacement is also an outside application, although for now it is just Asterisk's SIP registry.
Well, we at OpenBSC are very interested in the actual GSM layer 3 protocols on the various interfaces (Abis, A, B and others).
Something I think could be useful, and would allow a lot of interoperability, would be to have a common HLR/VLR replacement. The Asterisk SIP registry doesn't meet our long-term requirements and so we need to develop one anyway. If we can agree on an interface and an implementation, we could do something here.
I think I would actually want to have a protocol-compatible HLR, i.e. using the standard interfaces that GSM/3GPP use for the HLR - which I doubt is something that you would want to see :)
Which is why I think a modular approach makes sense. We're already splitting BSC and MSC functionality inside the OpenBSC project. If somebody finds the time to introduce some kind of API between layer 2 and layer 3 of OpenBTS, then that would be the ideal case. People who want to use OpenBTS standalone can continue to do so, while people who want to put a BTS-Side A- bis on top (and use with proprietary BSC or OpenBSC) can also do that.
That kind of API should be easy. OpenBTS follows a data-flow design. At the top of L2, every channel is just a pair of FIFOs (up/down) of L3 message objects. It should be easy to funnel all of that through some kind of Abis adapter.
Yes, I've looked at the code before and thought it should be relatively easy.
I see one other advantage for this: More and more OpenBTS bits that are currently static (like channel configuration or similar) would have to become configurable in order to support GSM 12.21 (A-bis OML). Initially, having all of this static is fine, of course.
I haven't spoken about this with David so far, since I didn't have the time to actually do the implementation. But I believe as long as the changes are not intrusive and OpenBTS doesn't loose features / stability or performance, I wouldn't expect much objection to it.
No objection, but there will be questions about licensing. To date, there are very few outside contributions in the OpenBTS distribution, maybe a few dozen lines out of ~12k. The FSF copyright assignment gives us the flexibility to distribute a non-GPL release if we want. Given GPLv3's treatment of patent licenses, that will be very desirable for some users, even if the actual code is identical to what we release under GPL. It also give us the opportunity to charge licensing fees and royalties for use of OpenBTS in commercial products, a plan for which we make no apology.
sure. That shouldn't be much of a problem either. If we introduce the API that I've proposed above, then the part 'below' the API stays like it is, with copyright assingments to the FSF, etc. However, the BTS side A-bis code on top would be GPL (v2+) licensed and copyright is with whoever does the implementation. That part would not neccesarrily be a part that is required to be part of the OpenBTS standard distribution.
If some alternative licensing is required by one of your customers down the road, arrangements would have to be made with the copyright holder of that A-bis BTS part.
("Free as in freedom, not free beer.") We have no problem with sharing royalties with contributors, but our business plan requires that we preserve licensing flexibility, and so we would need to have formal agreements with any significant contributors if we were to actually use their contributions. Admittedly, this creates a tension in the open source project, a tension that we are still learning to manage, especially since the lifting of the injunction has removed the biggest barrier to participation.
I don't think it will be a big deal, don't worry too much about it :)
See above. The FSF granted us back a blanket license. We can do anything we want *except* stop the FSF from distributing it under GPL. The text of the agreement says we can use the code "in any why [we] see fit". Period.
ok, that's interesting and good to know.
Harald -
On Oct 7, 2009, at 12:53 PM, Harald Welte wrote:
Something I think could be useful, and would allow a lot of interoperability, would be to have a common HLR/VLR replacement. The Asterisk SIP registry doesn't meet our long-term requirements and so we need to develop one anyway. If we can agree on an interface and an implementation, we could do something here.
I think I would actually want to have a protocol-compatible HLR, i.e. using the standard interfaces that GSM/3GPP use for the HLR - which I doubt is something that you would want to see :)
I'm open minded at this point. We eventually have to interface to standard HLRs anyway and I need some project to force me to learn the MAP stuff. It would also be good if the underlying database can be used to generate configurations for FreeSWITCH or Asterisk, but that should not be hard given any SQL-based system.
-- David
David A. Burgess Kestrel Signal Processing, Inc.
Harald, David,
On Thu, Oct 8, 2009 at 00:42, David Burgess dburgess@kestrelsp.com wrote:
Harald -
On Oct 7, 2009, at 12:53 PM, Harald Welte wrote:
Something I think could be useful, and would allow a lot of interoperability, would be to have a common HLR/VLR replacement. The Asterisk SIP registry doesn't meet our long-term requirements and so we need to develop one anyway. If we can agree on an interface and an implementation, we could do something here.
I think I would actually want to have a protocol-compatible HLR, i.e. using the standard interfaces that GSM/3GPP use for the HLR - which I doubt is something that you would want to see :)
I'm open minded at this point. We eventually have to interface to standard HLRs anyway and I need some project to force me to learn the MAP stuff. It would also be good if the underlying database can be used to generate configurations for FreeSWITCH or Asterisk, but that should not be hard given any SQL-based system.
Right. At some point we'll need to create an adapter for normal HLRs anyway, so the early we start, the further we get. ;)
I wonder - is there already any IETF-based protocol for such kind of interaction? Radius?
Something I think could be useful, and would allow a lot of interoperability, would be to have a common HLR/VLR replacement. The Asterisk SIP registry doesn't meet our long-term requirements and so we need to develop one anyway. If we can agree on an interface and an implementation, we could do something here.
I think I would actually want to have a protocol-compatible HLR, ie using the standard interfaces that GSM/3GPP use for the HLR - which I doubt is something that you would want to see :)
After having a quick look at the specs : - The VLR would stay in each OpenBTS/OpenBSC instance (since it's usually attached 1:1 to a MSC) - The common part needed would group HLR/AuC/EIR
If you want 'official' interfaces, that means D interface, F interface & G interface to implement. Each run over SCCP and there are standardized ways to transport SCCP over IP. Most of it seems to be in GSM 09.02 (using ASN.1 notation, enjoy ...) AFAICS.
The whole VLR & D/F/G MSC side code can obviously be shared by both project and just expose an very simple internal API.
Sylvain
-
246tnt＠gmail.com -
Alexander Chemeris -
Bjoern Heller -
David Burgess -
Harald Welte